Skip to content
PrivacyAutomated.ai Taking you from zero to privacy™
Features How it works Tour Resources Pricing FAQ
Log in Get started

← Back to home

Security & Trust

Privacy Automated is a privacy compliance product. We hold ourselves to the standards we help our customers meet. This page describes how we protect the Customer Personal Data you submit to the platform.

Last updated: June 6, 2026

Have a security questionnaire? Send it to info@privacyautomated.ai. We respond to all in-scope questionnaires within five business days; vendor risk teams may also request our standard security packet.

Engineering reference for technical buyers: See our Trust Architecture page for the six invariants we engineer for (database-enforced tenant isolation, append-only audit, cryptographic verification, citation validation, judge-verified grounding, composite confidence) with file paths so each can be independently verified.

Tenant isolation

🔒

Row-level security on every table

Every table containing Customer data has PostgreSQL row-level security (RLS) policies that enforce workspace boundaries at the database engine, not just at the application layer. A bug in the API cannot bypass them.

🛡

Non-superuser application role

The application connects to the database under a least-privileged role that cannot disable RLS. Migrations run under a separate privileged role that the running app never holds.

✅

Automated isolation tests

Our test suite contains tenant-isolation tests that fail the build on any cross-workspace data leak. They run on every commit before deploy.

Encryption

🔒

In transit

All traffic to app.privacyautomated.ai and our API is TLS 1.2+ with modern ciphers, HSTS enabled. We do not accept plaintext HTTP for any production endpoint.

🗀

At rest

Database volumes are AES-256 encrypted at the storage layer. Off-site backups are encrypted client-side before upload to our backup provider.

🔑

Secrets

API keys and credentials are stored in root-owned, mode-600 environment files on production hosts. No secrets in the repository or in container images.

Authentication & access

👤

Identity provider

Authentication is provided by Clerk (SOC 2 Type II). SSO, email-based magic links, and optional MFA are available to all workspace administrators.

🏆

Organization-scoped access

Multiple users on one workspace are managed as a Clerk Organization. Members and admins are distinguished; admin-only routes (delete workspace, change plan, modify settings) reject non-admins.

📝

Audit trail

Significant events — document uploads, DPIA approvals, DSAR verifications, plan changes, deletions — are logged with actor identity, per-statement clock_timestamp(), payload, and a SHA-256 hash that chains each row to its predecessor. A per-workspace advisory lock serialises writes; daily Merkle roots are published to a public GitHub log so the chain is independently verifiable, and each root is additionally Bitcoin-anchored via OpenTimestamps so the timestamp does not depend on Git history. Visible in-app under Activity.

Operational security

📊

Monitoring & alerting

Application errors are captured by Sentry with PII scrubbing. Backup pipeline failures trigger Healthchecks.io dead-man's-switch alerts to our on-call address. Per-workspace LLM spend caps prevent runaway cost.

💾

Backups

Daily automated PostgreSQL backups. Stored geographically off-site at Backblaze B2 (US-East), client-side AES-256 encrypted. Retention: 35 days. We performed and documented a restore drill prior to GA and re-test quarterly.

🚧

Deployment & supply chain

Production container images are built by GitHub Actions inside a hosted, isolated Ubuntu runner — never on the operator’s laptop. Each build is attested at SLSA Build Level 3 via actions/attest-build-provenance, signed by GitHub’s OIDC identity through Sigstore Fulcio, and recorded in the public Sigstore Rekor transparency log. Our deploy script pulls images by their immutable :sha-<git-sha> tag, and every prod deploy publishes a build record to our public audit-transparency-log naming the git SHA, the GHA workflow run, and the image digests that went live. Staging is separate; rollback is automatic on health-check failure.

AI safety

🤖

Prompt-injection defence

Every inbound question goes through a multi-label intent classifier that detects prompt injection, conflicting intent, hard-block categories, and out-of-policy content. Suspicious inputs are quarantined and escalated to a human, not answered.

⚖

Independent judge model

A second model independently verifies every Q&A answer before it leaves the system. Low-confidence answers escalate to a human reviewer.

💰

Cost guardrails

Per-workspace AI-ops and dollar-spend caps fail-closed: a workspace that hits its cap stops issuing LLM calls and surfaces an in-app message, rather than continuing to bill silently.

Customer rights & portability

📥

Export your data

Customer data is exportable at any time from the in-app Settings page. PDF export of DPIAs and printable RoPA registers are first-class features.

🗑

Delete your workspace

Workspace administrators can delete the entire workspace from Settings. The purge enumerates every customer-data table — DPIAs and their version history, RoPA entries and versions, vendors, DSAR records and tasks, security questionnaires, policy-update suggestions, document chunks and embeddings, LLM call captures, and the activity log — and completes within thirty (30) days (subject to backup retention; see our DPA Section 8).

📝

DPA on file

Our Data Processing Addendum covers GDPR / UK GDPR, CCPA / CPRA, and PIPEDA. Signed copies available on request.

Incident response

We maintain a documented incident-response runbook with a pre-engaged breach-response counsel and forensic firm available 24/7 through our cyber-liability carrier. In the event of a Personal Data Breach affecting Customer Personal Data, we will notify the affected Customer without undue delay and in any event within seventy-two (72) hours of becoming aware of the breach, per our DPA Section 6.

Insurance

Privacy Automated maintains Technology Errors & Omissions and Cyber Liability insurance with limits of US$3,000,000 per claim and US$3,000,000 in the annual aggregate through an A.M.-Best-rated carrier. Coverage includes technology errors and omissions, network security and privacy liability, regulatory investigations (where insurable), breach response and forensic expenses, and cyber extortion. A certificate of insurance is available to Customers on request — see DPA Section 10.

Compliance status

We are honest about our certification stage. As a young company, we hold ourselves to the substance of these standards while we progress through formal attestation:

  • In place GDPR / UK GDPR processor obligations, CCPA / CPRA Service Provider obligations, PIPEDA accountability, DPA available to all Customers.
  • In place SOC 2 Type II identity provider (Clerk); SOC 2 Type II + PCI DSS Level 1 payment processor (Stripe); SOC 2 Type II language-model provider (Anthropic); SOC 2 Type II off-site backup storage (Backblaze B2); SOC 2 Type II email provider (Postmark); SOC 2 Type II source-code host (GitHub).
  • In place Production hosted on Hetzner Cloud (SOC 2 Type 2 + ISO/IEC 27001) in Falkenstein, Germany — both the application host and the database. EU-residency is the default for customer data at rest.
  • In place SLSA Build Level 3 supply-chain attestation on every production deploy. Container images built by GitHub Actions, signed by GitHub’s OIDC identity through Sigstore Fulcio, recorded in the public Sigstore Rekor transparency log, and pinned in our own public audit-transparency-log. Every binary running in prod is independently verifiable by digest against three third-party witnesses.
  • In place OpenTimestamps Bitcoin anchoring on every daily audit-log Merkle root. Each signed root is submitted to three independent OpenTimestamps calendar servers, which batch the digest into the Bitcoin blockchain via OP_RETURN; the resulting receipt is committed alongside the signed JSON in the public audit-transparency-log and an ots upgrade pass rewrites it with a complete Bitcoin block proof. Once a receipt has upgraded, any reviewer can verify the root’s existence at a specific Bitcoin block height without trusting us, the calendars, or GitHub — only the Bitcoin network. See Trust Architecture for the full chain.
  • Pending SOC 2 Type II for Privacy Automated as a company. Every sub-service organization in the production path is itself SOC 2-attested; what remains are the formal policy documents, an external penetration test, and the Type 2 operating-effectiveness window. See our SOC 2 readiness statement for the honest picture against each Trust Services Criterion. Customer security questionnaires are answered individually via info@privacyautomated.ai.

Responsible disclosure

We welcome security research. If you believe you have discovered a vulnerability in the Services, please email info@privacyautomated.ai with the subject "Security disclosure" and we will respond within two business days. We commit not to pursue legal action against good-faith researchers who follow this disclosure process and avoid privacy violations and service disruption.

For questions, a security questionnaire, or a copy of our security packet: info@privacyautomated.ai.

PrivacyAutomated.ai

Privacy compliance, built right™.

Product

Features How it works Tour Resources Pricing Changelog DSAR deadline calculator

Company

FAQ Security Verify Status Contact LinkedIn

Legal

Privacy Terms DPA Sub-processors Submit a privacy request

© PrivacyAutomated.ai. All rights reserved.

Privacy · Terms · DPA · Sub-processors · Security