← Back to Security & Trust

For procurement and security buyers

SOC 2 Readiness

We are not yet SOC 2 attested. This page is the honest readiness picture against the AICPA SOC 2 Trust Services Criteria — which controls exist today, which sub-service organizations cover the rest, and what remains before a formal audit makes sense. It is written for a security-team reader who would otherwise have to ask in a questionnaire.

What this page is not. This is not a SOC 2 attestation, an AICPA opinion letter, or a Type 1 / Type 2 report. It is our own statement of readiness, supported by the publicly verifiable evidence linked from the Trust Architecture page. Until a licensed CPA firm has issued an attestation, no claim on this page should be read as a SOC 2 certificate. We will update this page each time a material control or sub-processor changes.
The honest summary
  • Most CC criteria are covered today by controls already in production and independently verifiable from the Trust Architecture page (tenant isolation, append-only audit with database-level clock_timestamp() ordering, signed export, Merkle-root transparency log, weekly restore-verify, pgaudit second audit channel, prompt registry, LLM call capture and replay).
  • The infrastructure gap is closed. Production migrated from Spaceship VPS to Hetzner Cloud (SOC 2 Type 2 + ISO/IEC 27001) in May 2026. Compute and database are now hosted in Hetzner’s Falkenstein, Germany region, which also strengthens data-residency for European customers. The migration was operational rather than architectural — the application is fully portable (Docker Compose + Postgres on a named volume).
  • The rest of our sub-processors (Clerk, Stripe, Postmark, Backblaze B2, GitHub, Anthropic, Sentry, Healthchecks.io) already hold SOC 2 attestations or equivalent recognized certifications.
  • The written-policy suite is now drafted (v1.0, effective June 6, 2026). Eight policies cover CC1–CC9, A1, and C1; they are versioned in the application repository and reference the same Trust Architecture invariants that anchor the controls. The remaining work for a Type 2 audit is the operating-effectiveness window and an external penetration test, not the paperwork.
  • Until attestation, on request we will share: our internal security packet, our current control mapping (the table below in machine-readable form), a CPA-friendly walkthrough of the controls referenced on the Trust Architecture page, and (under NDA) the policy suite itself.

1. Anticipated audit scope

When we initiate the audit, the system boundary will be the PrivacyAutomated.ai SaaS application and its supporting infrastructure. The marketing site and unrelated assets are excluded.

In scope.

  • The application (app.privacyautomated.ai) and its source code in the private privacy-copilot repository.
  • Production compute and database (the app-vm and ai-db Virtual Private Servers).
  • The public audit-transparency-log repository at github.com/privacyautomated/audit-transparency-log.
  • Personnel with production access (the two founders today; any future hires with production access will be added to scope on day one).
  • Sub-service organizations supporting the in-scope service (carve-out treatment, listed in § 3).

Out of scope.

  • The marketing site (privacyautomated.ai apex) — static HTML, no customer data, hosted on GitHub Pages.
  • Future products that have not yet shipped in production.
  • Personal devices belonging to the founders, except for the narrow access paths to production (which are in scope for CC6.2 logical access controls).

Trust Services Criteria. The Security common criteria (CC1–CC9) are mandatory and will be in scope. We expect to include Availability and Confidentiality at first attestation. Processing Integrity (PI) is naturally satisfied by the judge-model and grounding controls described on the Trust Architecture page; we will consider including it. Privacy (P) overlaps with our GDPR / state-law obligations elsewhere on this site and may be included if requested by a buyer; otherwise omitted to keep audit cost proportionate.

2. Control coverage map

The following Trust Services Criteria families are addressed by named, code-resident, and independently verifiable controls today.

Each row points to where the control lives in production. References to "TA § n" link to the relevant section of the Trust Architecture page, which is the authoritative description with verification commands.

TSC family Topic Controls in place Status
CC1 Control environment — governance, roles, code of conduct. Two-founder governance with explicit role separation; both founders hold an MS in Information Security and a JD. Information Security Policy (01) and Acceptable Use & Code of Conduct (06) issued v1.0 effective June 6, 2026; wet-signed by both Officers; originals on file. In place
CC2 Communication of objectives and policies. Public Trust Architecture page; public Data Processing Addendum; public sub-processor list; this page. Customer notifications via in-app banner and email through Postmark (sub-service). In place
CC3 Risk assessment, including fraud and change risk. Internal 5-phase security audit (28 fix batches landed) is the most recent technical review. Annual Security Risk Assessment policy (08) issued v1.0 effective June 6, 2026 (template + inaugural 2026 assessment recording 27 risks scored L×I with treatment decisions); wet-signed by both Officers. Fraud risk explicitly assessed each cycle (CC3.3). The product’s DPIA / PIA module is the substrate for the privacy-side risk register. In place
CC4 Monitoring activities; detection of control failures. Application write_audit hash-chain (TA § 2) with per-statement clock_timestamp() ordering + per-workspace advisory lock, so concurrent and intra-transaction writes can’t produce ambiguous chain order; daily Merkle-root publication to public GitHub (TA § 3); weekly off-site backup restore-and-verify drill (TA § 8); database-engine pgaudit log as an independent second channel; Sentry application error monitoring; Healthchecks.io dead-man’s switch on scheduled jobs. In place
CC5 Control activities; specifically defined safeguards. Multi-label intent classifier with hard-block category (PII / prompt-injection guard); judge model verifies grounding before customer-facing answers (TA § 6); composite confidence gating (TA § 7); admin-only routes for vendor/document/RoPA writes. In place
CC6 Logical and physical access controls. Database-enforced tenant isolation via Postgres RLS with WITH CHECK and a non-superuser application role (TA § 1); authentication and organization membership via Clerk (SOC 2 Type II); MFA available on all workspaces; Hetzner Cloud firewall restricts SSH and database ports to allowlisted IPs and pins the database to a private network reachable only from the application host; HTTPS-only transport. Physical access is delegated to Hetzner Cloud (SOC 2 Type 2 + ISO/IEC 27001; carve-out, see § 3). Access Control Policy (02) issued v1.0 effective June 6, 2026, wet-signed by both Officers, with quarterly access review cadence on the 1st business day of January / April / July / October (first scheduled review: July 1, 2026). In place
CC7 System operations; incident detection and response. Append-only audit chain (TA § 2) and pgaudit second channel together provide tamper-evident detection at two layers; restore-verify (TA § 8) provides operational recovery evidence; inbox-escalation approval flow routes intent classifier failures to a human; signed export (TA § 2) lets a customer verify integrity offline. Incident Response Runbook (04) issued v1.0 effective June 6, 2026, wet-signed by both Officers — P0/P1/P2/P3 severity rubric, Sentry / Healthchecks / backup-alert detection map, 5 named-scenario sub-runbooks, GDPR Art. 33 72-hour clock, inaugural tabletop scheduled September 1, 2026. In place
CC8 Change management. All production change goes through git in private repositories with author identity required; Alembic database migrations; prompt registry hash-pins every LLM system prompt and records the hash per call (TA § 10); DPIA and RoPA entries are versioned with full snapshot history; CI deploy script (deploy.sh) is the only production change path. Production container images attested at SLSA Build Level 3 — built by GitHub Actions in a hosted isolated runner, signed by GitHub OIDC through Sigstore Fulcio, recorded in Sigstore Rekor, and pinned to git SHA in our public audit-transparency-log; the deploy script pulls images by their immutable :sha-<commit> tag rather than building locally, so the binary in production maps 1:1 to a verifiable attestation. Change Management Policy (03) issued v1.0 effective June 6, 2026, wet-signed by both Officers, codifying the SLSA Build Level 3 pipeline in SOC 2 language and aligned to CC8.1. In place
CC9 Risk mitigation including vendor management. Vendor research module tracks DPA expiry and certification renewal for the customer’s vendors; our own sub-processor list is public (subprocessors.html); LLM cost-cap and plan-tier feature gates prevent uncontrolled spend; signed Data Processing Addendum with each customer. Vendor Management Policy (05) issued v1.0 effective June 6, 2026, wet-signed by both Officers — full inventory with per-vendor next-review tracking, 30-day customer-notice rule mirrored from the DPA, per-vendor risk register populated for all 9 sub-processors. In place
A1 Availability. Weekly off-site backup restore drill with audit-chain walk (TA § 8); dead-man’s switch on the backup pipeline; Sentry alerting on application errors; database health-checks at the container level. Recovery-time objective is measured (~30 seconds on current DB size) but not yet committed customer-facing; that is in the known-gap list (TA § 8). In place
C1 Confidentiality. Database-enforced tenant isolation (TA § 1); HTTPS-only transport; Backblaze B2 storage encrypted with AES-256 before upload; workspace deletion / right-to-erasure path (Article 17) wired through the API across every customer-data table (DPIAs, RoPA entries and versions, vendors, DSAR records, security questionnaires, policy-update suggestions, LLM call captures, and the activity log); LLM-call capture retains verbatim text with a 90-day default TTL (configurable per workspace, see DPA). Data Retention & Disposal Policy (07) issued v1.0 effective June 6, 2026, wet-signed by both Officers, restating the DPA retention regime in SOC 2 language; 35-day backup window is the longest tail; litigation-hold procedure documented. In place
PI1 Processing integrity (optional — not yet committed to scope). Citation validation against the actual retrieval set (TA § 5); judge-model grounding verification (TA § 6); composite confidence (TA § 7); typed 109-jurisdiction statutory deadline table; LLM call capture and replay (TA § 9). The PI criteria are naturally satisfied; we will include them in scope if a buyer asks. In place

3. Sub-service organizations and their attestations

SOC 2 includes everything the attested service depends on. The table below lists each sub-service organization in our production path, its role, and its current SOC 2 (or equivalent) status.

For the SOC 2-attested entries we will rely on the standard carve-out method — the audit cites their report and tests our complementary user-entity controls. As of June 2026 every sub-service organization in the production path holds a SOC 2 attestation (or, in the case of Healthchecks.io, has a narrow no-PII scope).

Sub-processor Role Attestation Status
Hetzner Online GmbH (Hetzner Cloud) Cloud hosting for app-vm and ai-db (compute, storage, networking, physical security). Falkenstein, Germany region. SOC 2 Type 2 (Hetzner Cloud); ISO/IEC 27001 (Hetzner Online GmbH). Covered
Clerk, Inc. Identity, authentication, organization management. SOC 2 Type II. Covered
Stripe, Inc. Billing, subscription, payment processing. SOC 2 Type II; PCI DSS Level 1. Covered
Anthropic, PBC Third-party language-model inference (Claude). SOC 2 Type II; ISO/IEC 27001. Covered
Postmark (ActiveCampaign LLC) Transactional email send/receive. SOC 2 Type II. Covered
Backblaze, Inc. Off-site encrypted backup storage (B2). SOC 2 Type II. Covered
GitHub, Inc. Source-code hosting (private) and public transparency log. SOC 2 Type II; ISO/IEC 27001 (Microsoft / GitHub). Covered
Sentry (Functional Software, Inc.) Application error tracking. SOC 2 Type II. Covered
Healthchecks.io Dead-man’s switch for scheduled jobs. No customer personal data processed. Self-hosted possible; commercial service publishes practices but does not hold a formal SOC 2. Scope here is narrow (job-status pings, no customer data), so the carve-out treatment is straightforward. Narrow scope

4. Known gaps and remediation plan

Before initiating a formal SOC 2 audit, the following work needs to land. The infrastructure pre-audit blocker (a SOC 2-attested host) and the written-policy gap are both resolved as of June 6, 2026 — the remaining items are an external penetration test and the Type 2 operating-effectiveness evidence window.

Infrastructure

  • Hetzner Cloud migration — complete. Production migrated from Spaceship VPS to Hetzner Cloud (SOC 2 Type 2 + ISO/IEC 27001) in May 2026. Both app-vm and ai-db run in Hetzner’s Falkenstein, Germany region, behind a Hetzner Cloud firewall, with the database pinned to a private network reachable only from the application host. Cut-over included a verified restore drill from the running Backblaze B2 backup. EU-residency is now the default for customer data at rest.
  • Independent penetration test of the production application. Strongly recommended before a Type 2 audit. Our internal 5-phase security audit (28 fix batches landed) is a useful baseline but is not a substitute for an external test by a recognized firm.

Written policies — issued and signed

The eight-policy suite SOC 2 expects is now issued at v1.0, effective June 6, 2026, and wet-signed by both Officers on the same date. The policies are versioned in the application repository alongside the code they describe, so a change to the deploy pipeline (for example) updates the change-management policy in the same pull request. For revisions after v1.0, Officer sign-off is taken by signed commit to main; the SLSA Build Level 3 attestation chain (CC8) extends to those commits, so the sign-off itself is in the same verifiability chain as the production binary. Wet-signed v1.0 originals are on file with the Officers and available for inspection during audit fieldwork. The suite is available under NDA for procurement review.

  • 01 Information Security Policy — umbrella governance, 4-class data taxonomy, security commitments mapped to Trust Architecture invariants (CC1 / CC2).
  • 02 Access Control Policy — Clerk + GitHub MFA, app_rw vs postgres role separation, same-day revocation, quarterly access review on 1st business day of Jan / Apr / Jul / Oct (CC6).
  • 03 Change Management Policy — codifies the SLSA Build Level 3 attestation chain in SOC 2 language; emergency-change procedure still goes through the attested pipeline (CC8).
  • 04 Incident Response Runbook — P0–P3 severity rubric, Sentry / Healthchecks / backup-alert detection map, 5 named-scenario sub-runbooks, GDPR Art. 33 72-hour clock; inaugural tabletop scheduled September 1, 2026 (CC7).
  • 05 Vendor Management Policy — 9-sub-processor inventory with per-vendor next-review dates, 30-day customer-notice rule mirrored from the DPA (CC9).
  • 06 Acceptable Use & Code of Conduct — BYOD device standard, AI-assistant rules forbidding customer data in prompts, per-personnel acknowledgement flow (CC1).
  • 07 Data Retention & Disposal Policy — per-category retention table mirroring the DPA + Privacy Notice; 35-day backup window as longest tail; Article 17 erasure path; litigation-hold procedure (C1).
  • 08 Annual Security Risk Assessment — template plus inaugural 2026 assessment recording 27 risks scored L×I with treatment decisions; next reassessment June 1, 2027 (CC3).

Alongside the policies, the repository carries a register directory (docs/policies/registers/) whose subdirectories correspond to specific control outputs: access reviews, sub-processor risk registers, post-incident reviews, tabletops, preservation holds, credential rotations, env-file changes, exceptions, and the annual risk assessment. The inaugural 2026 annual risk assessment (27 risks scored L×I, treatment decisions recorded) and a per-vendor risk register for all 9 sub-processors are already populated. The first scheduled artifact off the suite is the Q3 2026 access review on July 1, 2026.

Operating-effectiveness window (Type 2 only)

  • A SOC 2 Type 2 attestation reports on operating effectiveness over a window (commonly six or twelve months). Most of our controls emit observable evidence today — the daily Merkle-root commits to the public log, the weekly restore-verify report at /ops/restore-status, the pgaudit log, the prompt-registry manifest, the LLM-call capture rows — so the evidence record will already exist when the window opens. A Type 1 attestation (point-in-time design) is a useful first step if a customer needs a near-term report.

5. Timing and what triggers a formal audit

We have not committed to a SOC 2 audit start date. The trigger is customer-driven: when a paying customer’s procurement process requires a report, we initiate.

Until then, running a formal audit would consume founder capacity that is better spent on building the product and reaching the next customer. The honest readiness picture on this page, combined with the verifiable substrate on the Trust Architecture page, is what we offer in the interim — and in our experience it answers the underlying procurement question better than a generic report would.

If you are evaluating PrivacyAutomated.ai and your security team needs a SOC 2 report before sign-off, tell us when you raise the question. With the Hetzner Cloud migration complete and the written-policy suite drafted, the remaining pre-work (the operating-effectiveness window and an external penetration test) can proceed in parallel. A Type 1 attestation (point-in-time design) is the natural next step if a near-term report is required.

Security packet and questionnaires

Email info@privacyautomated.ai for our current security packet, a copy of this readiness statement in a questionnaire-friendly format, or a walk-through call with a founder. We do not charge for security review and we will not gate the answer on an NDA for anything already public on this page or the Trust Architecture page.

Last updated: June 6, 2026 — the eight-policy written-policy suite (Information Security, Access Control, Change Management, Incident Response, Vendor Management, Acceptable Use, Data Retention & Disposal, Annual Risk Assessment) was issued at v1.0 and wet-signed by both Officers on the same day. Alongside the policies, the inaugural 2026 annual risk assessment was filed and a per-vendor risk register was populated for all 9 sub-processors. CC1, CC3, CC7, CC8, and CC9 move from “In progress” to “In place”; CC6 and C1 now cite Access Control (02) and Data Retention (07) respectively. Earlier same-day update: CC8 records that production container images are SLSA Build Level 3 attested. Prior June 4 update: Hetzner Cloud migration recorded as complete; CC6 firewall language updated; audit-chain hardening (per-statement clock_timestamp() ordering) noted under CC4; C1 erasure scope expanded to enumerate every customer-data table. We update this page each time a material control or sub-processor changes, and we date-stamp updates so a procurement team can see the cadence. If you are reading this more than two months after the date above, please ask us what has changed.