Skip to content
Docket
Security and privacy

The controls, described precisely enough to check.

No badges, no adjectives. Here is how separation, credentials and third-party access actually work, and here is what we do not have yet.

Separation is enforced by the database

Every table holding customer data carries row level security, and access is decided by PostgreSQL rather than by the application remembering to filter. An interface bug cannot expose another customer's data, because the query itself is constrained.

How it is verified. A probe in the build attempts a cross-tenant write on representative tables and fails the build if one is ever accepted. It also checks the reverse, that a legitimate write still lands.

Credentials are encrypted at rest

Your WordPress application password and your Google refresh tokens are encrypted before they are stored, with keys held in the deployment environment rather than in the database beside the data.

How it is verified. The columns holding them are not granted to the browser role at all, so no query from a signed-in session can read one back, including your own.

Least privilege on third-party access

Google is connected with read-only scopes. Docket never writes to Search Console or Analytics and cannot post on your behalf. WordPress uses an application password, which is per-application and revocable on its own without changing your account password.

How it is verified. Revoke either from Google or from WordPress at any time and Docket loses that access immediately, with no action needed here.

Every AI operation is logged

What was generated, for which website, by whom and when. Publishing, approvals and connection changes are recorded the same way, per workspace, and are readable by everyone on that workspace's team.

How it is verified. The log is the evidence for a client review and the audit trail if something is ever disputed.

Stated plainly

What Docket does not have yet.

  • No SOC 2 report and no ISO 27001 certificate. Neither has been undertaken.
  • No single sign-on. Sign-in is email and password, or Google.
  • No customer-managed encryption keys, and no bring-your-own-cloud deployment.
  • No audit log export through the interface. The log is visible in the product.
  • No formal penetration test report to share. The database boundary is tested automatically on every build, which is a narrower claim and a true one.

If one of these is a hard requirement, say so early. We would rather lose a deal honestly than win one and disappoint your security team at implementation.

What Procurement Usually Asks.

Have a questionnaire to send us?

Send it. We will fill it in accurately, including the parts where the answer is no.

Get In Touch