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 placeEach 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 progressCI 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 placeRow-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 placeWorkspaces 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 placeAPI 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 placeA 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 placeEvery 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 placeProduction 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 placeEach 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 placeAll 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 placeThe 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 placeCRM and cloud-import tokens are encrypted with AES-256-GCM before they are stored.
Evidence: CI test: oauth-token-crypto
Secrets management
In progressProduction 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 placeEach 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 placeEach 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 progressOur 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 placeServer logs go to Axiom for search and to Cloudflare R2 for long-term archive.
Evidence: Vendor: Axiom; Vendor: Cloudflare
Alerts on server failures
In placeMonitors 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 progressBrowser 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 placeSend reports to security@plutosign.com. We acknowledge within 1 business day and triage within 5.
Evidence: Policy: published on /security
Customer breach notification
In placeThe 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 progressRunbooks 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 placeThe DPA lists each sub-processor, its purpose and its location.
Evidence: Policy: DPA section 5
Notice of sub-processor changes
In placeThe 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 placePaddle 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 placeOur database vendor takes managed daily backups.
Evidence: Vendor: Supabase
Tested backup restore
In progressA 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 placeAn 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 placeFour 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 placeOutbound 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 placeLogin, 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 placeOAuth 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 placeCloudflare Turnstile protects login, signup and the contact form.
Evidence: Vendor: Cloudflare Turnstile
Browser security headers
In placePages 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 placeA standard DPA is available to paid customers.
Evidence: Policy: DPA
Electronic records consent
In placeSigners 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 placeThe 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 progressSelf-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 placeThe 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.