Skip to main content

Security / Controls matrix

Security controls.

How Plutosign protects your documents and signing evidence, control by control. Each control lists how it works and the evidence behind it: automated tests that run on every change, production configuration or a named infrastructure provider.

Have a signed PDF? Verify a signed document to check that it is the exact file Plutosign stored when signing completed.

Last reviewed:

In place
32
In progress
7

Access control

  • Customer data isolation between organizations

    In place

    Each API route that reads or writes customer data filters by the caller's organization. A static CI test fails a route that does not compare the organization ID.

    Evidence: CI test: authz-boundary

  • Runtime cross-organization access tests

    In progress

    CI runs route handlers against a real Postgres database. It checks no session → 401, wrong organization → 404 and right organization → 200. Today this runs for the document read route only. More routes are planned.

    Evidence: CI test: documents-authz integration (real Postgres)

  • Database row-level security

    In place

    Row-level security is on for every application table. Public database keys cannot read or write these tables directly. A CI test fails when a table is defined without row-level security.

    Evidence: CI test: rls-coverage; Database migration

  • Workspace roles

    In place

    Workspaces have owner, admin and member roles. Billing, member management and other sensitive actions require owner or admin. Custom roles are not enforced.

    Evidence: Code: role checks in API routes

  • API key storage

    In place

    API keys are stored as SHA-256 hashes. The full key is shown once, when you create it.

    Evidence: Code: API key authentication

  • Signer email verification

    In place

    A sender can require a one-time email code before a recipient signs. The code proves control of the recipient's email address. It is bound to the recipient, not to the device.

    Evidence: Code: signing verification; Policy: compliance posture decision

Change management

  • Automated checks on every pull request

    In place

    Every pull request runs lint, type checks, unit tests, real-database tests, the production build and a schema drift check. A failed check blocks the merge.

    Evidence: CI workflow: ci.yml

  • Gated production deploys

    In place

    Production deploys only from the main branch. The deploy job runs the same checks again before it deploys.

    Evidence: CI workflow: deploy.yml

  • Reviewed database migrations

    In place

    Each production migration is a reviewed SQL file that the operator applies by hand. CI fails when the schema and the migrations do not match.

    Evidence: CI check: schema drift

Data protection and encryption

  • Encryption in transit

    In place

    All traffic uses TLS 1.2 or later. Responses send HSTS, so browsers refuse plain HTTP.

    Evidence: Vendor: Cloudflare; Code: security headers

  • Encryption at rest

    In place

    The managed database and file storage encrypt stored data with AES-256. Our vendors operate this encryption. We do not add field-level encryption for document content.

    Evidence: Vendor: Supabase; Vendor: Cloudflare R2

  • Encryption of connected-account tokens

    In place

    CRM and cloud-import tokens are encrypted with AES-256-GCM before they are stored.

    Evidence: CI test: oauth-token-crypto

  • Secrets management

    In progress

    Production secrets are stored as Cloudflare Worker secrets, not in the code repository. There is no written rotation schedule yet.

    Evidence: Vendor: Cloudflare; Runbook: security hygiene

  • Tamper-evident signing records

    In place

    Each audit event stores a SHA-256 hash linked to the previous event. A daily job walks the chain and alerts on a break. This makes changes detectable. It does not prevent them.

    Evidence: Code: audit hash chain; Scheduled job: verify-audit-chain

  • Signed PDF integrity checks

    In place

    Each completed PDF is hashed when it is finalized. A daily job checks recent PDFs against the stored hash. A weekly job samples older PDFs.

    Evidence: Scheduled job: verify-pdfs; Scheduled job: verify-pdfs-tail

  • Signed-document retention

    In progress

    Our policy keeps signed documents for at least 7 years. Storage lifecycle rules have no expiry for signed files, and a daily job alerts when the rules change. We have not yet recorded an independent check that production storage enforces the full period.

    Evidence: Policy: compliance posture decision; Scheduled job: verify-r2-lifecycle

Logging and monitoring

  • Central application logs

    In place

    Server logs go to Axiom for search and to Cloudflare R2 for long-term archive.

    Evidence: Vendor: Axiom; Vendor: Cloudflare

  • Alerts on server failures

    In place

    Monitors send an email alert on any fatal log line, uncaught exception or 5xx response. We tested delivery with synthetic events.

    Evidence: Vendor: Axiom monitors

  • Alerts on browser errors and error-rate trends

    In progress

    Browser errors are captured in PostHog, but they do not alert anyone yet. There is no error-rate baseline alert yet.

    Evidence: Vendor: PostHog

Incident response

  • Responsible disclosure channel

    In place

    Send reports to security@plutosign.com. We acknowledge within 1 business day and triage within 5.

    Evidence: Policy: published on /security

  • Customer breach notification

    In place

    The DPA commits us to notify customers without undue delay and within 72 hours of a personal data breach.

    Evidence: Policy: DPA

  • Written and tested incident response plan

    In progress

    Runbooks define severity levels and first steps for integrity alerts. There is no complete written incident response plan and no recorded exercise yet.

    Evidence: Runbook: security hygiene; Runbook: durability

Vendor management

  • Published sub-processor list

    In place

    The DPA lists each sub-processor, its purpose and its location.

    Evidence: Policy: DPA section 5

  • Notice of sub-processor changes

    In place

    The DPA commits us to give 30 days' notice before we add or replace a sub-processor.

    Evidence: Policy: DPA section 5.2

  • Card data handling

    In place

    Paddle is our merchant of record. Paddle collects card details in its own checkout. Card numbers never reach Plutosign servers.

    Evidence: Vendor: Paddle

Business continuity and backup

  • Database backups

    In place

    Our database vendor takes managed daily backups.

    Evidence: Vendor: Supabase

  • Tested backup restore

    In progress

    A restore-and-verify script and procedure exist. We have not yet recorded a completed restore drill.

    Evidence: Runbook: durability; Script: db-fire-drill

  • Customer data export

    In place

    An owner or admin can export document records and audit logs. Completed documents have a downloadable Certificate of Completion.

    Evidence: Product feature: Export Data; Product feature: Certificate of Completion

Secure development

  • Written security rules for every change

    In place

    Four security rules apply to every change: SSRF protection, rate limits, OAuth correctness and tenant isolation. A CI test enforces each rule.

    Evidence: Runbook: security hygiene; CI tests: security guards

Application security guards

  • Server-side request forgery (SSRF) protection

    In place

    Outbound requests to addresses that users can influence go through one guarded fetch. It blocks private, loopback and cloud-metadata addresses. A CI test fails any new unguarded fetch.

    Evidence: CI test: no-raw-fetch

  • Rate limits on public endpoints

    In place

    Login, signup, signing links, webhooks and forms are rate-limited. A CI test fails a public route without a limit. The test checks each file, so a person reviews routes that serve both signed-in and public callers.

    Evidence: CI test: rate-limit-coverage; Vendor: Upstash

  • OAuth flow correctness

    In place

    OAuth state is random, single-use, short-lived and bound to the session. Redirect URIs must match an exact allowlist. API clients can use PKCE (S256).

    Evidence: CI test: oauth-invariants; CI test: pkce

  • Bot protection

    In place

    Cloudflare Turnstile protects login, signup and the contact form.

    Evidence: Vendor: Cloudflare Turnstile

  • Browser security headers

    In place

    Pages send a Content Security Policy, frame protection (X-Frame-Options) and HSTS.

    Evidence: Code: middleware; CI test: public-docs-middleware

Privacy

  • Data Processing Agreement

    In place

    A standard DPA is available to paid customers.

    Evidence: Policy: DPA

  • Electronic records consent

    In place

    Signers give consent to electronic records before they sign. The disclosure version is recorded in the audit trail.

    Evidence: Product feature: signer consent

  • AI processing disclosure

    In place

    The security page and DPA say what data AI features send to Anthropic and Datalab. We do not claim zero retention or no-training terms.

    Evidence: Policy: published on /security; Policy: DPA

  • Account deletion that keeps signed evidence

    In progress

    Self-service deletion is blocked when it would destroy a workspace's signed evidence. A full closure and retrieval procedure for former customers is not built yet.

    Evidence: Code: retention guard

  • Privacy contact and India grievance officer

    In place

    The privacy policy names a Grievance and Privacy Officer for India and explains how to raise a request.

    Evidence: Policy: privacy policy

On our roadmap

  • Operator access reviews and MFA policy
  • Cryptographic PDF signatures (PAdES)
  • Log redaction and retention policy
  • Public status page and uptime monitoring
  • Vendor security review process
  • Information security policy set
  • Independent SOC 2 audit and third-party penetration testing, as our customer base grows

Security questionnaires

Send your questionnaire to security@plutosign.com. We answer from this matrix. Review the DPA and sub-processor list or go back to the security overview.