Controls, mapped to the criteria.
Sablewatch is built to the SOC 2 Trust Services Criteria. Here are the controls we operate against each — and an honest note on where we are in the audit process.
Security
Protecting the system against unauthorized access.
- Per-tenant isolation enforced at the database layer (Postgres row-level security)
- Least-privilege, read-only-by-default connectors; response grants are separate & revocable
- API keys hashed (sha256) at rest, shown once, revocable
- Immutable audit log of every privileged action — automated and human
- Encryption in transit (TLS 1.2+) and at rest
Availability
Keeping the platform up and recoverable.
- Managed, multi-region-capable hosting with provider SLAs
- Public status page
- Managed backups + point-in-time recovery
Confidentiality
Keeping sensitive data sensitive.
- Documented data classification & retention
- We store security metadata — never the contents of your files, email, or messages
- No standing master credentials; scoped, revocable response grants
Processing Integrity
Changes are controlled and traceable.
- All changes ship via reviewed pull request → CI build → traceable deploy
- Versioned, reviewable database migrations — no ad-hoc production edits
- Human-in-the-loop approval required for destructive actions
Privacy
Collecting and handling data responsibly.
- Minimal data collection
- Delete-on-request
- Transparent, current subprocessor list
Subprocessors
Connectors you authorize (Google Workspace, Microsoft 365, Okta, AWS) are sources you connect under scopes you grant — not subprocessors of Sablewatch.
Need the details?
Our security policy set (access control, incident response, change management, vulnerability management, data handling, vendor management, and business continuity) is documented and version-controlled. Enterprise teams evaluating Sablewatch can request the policy package and our SOC 2 timeline.