SOC 2 at Parapho
SOC 2 is an independent audit, run by a licensed CPA firm under AICPA standards, of how a service provider protects customer data. A Type I report checks that controls are designed well on a single day. A Type II report goes further: the auditor tests that the controls actually worked, sample by sample, over an observation period of several months. Type II is the one security teams ask for.
SOC 2 Type II in preparation
We're preparing for an independent SOC 2 Type II examination against the AICPA Trust Services Criteria. We haven't been audited yet and don't have a report to share. This page shows how our controls map to the criteria today, and we'll update it as the audit progresses.
1. Scope
The system in scope is the Parapho service: the web app, signing pages, public forms, the verification page, the REST API, webhooks and embedded signing, together with the AWS infrastructure in us-east-1 that runs them and the people and processes that operate it. The examination covers three of the five Trust Services Criteria:
- Security (the common criteria, CC1 to CC9): the system is protected against unauthorized access, use and change.
- Availability (A1): the system is available to operate and use as committed.
- Confidentiality (C1): information designated as confidential, which for us means every document, field value and audit trail, is protected as committed.
Processing Integrity and Privacy are out of scope. Our privacy commitments are set out in the Privacy Policy and the Data Processing Addendum.
2. How our controls map to the criteria
Most of our technical controls are enforced by the software and by infrastructure-as-code rather than by people remembering to do things, which makes them easier to test and harder to skip. Those are in place today, and the Security page describes each one in more detail. The organizational processes an auditor tests over time, such as access reviews and vendor reviews, are written down in our policies and are being rolled out ahead of the audit. We list them separately so it's clear which is which.
| Criteria | In place today | Being rolled out for the audit |
|---|---|---|
| CC1 Control environment | Security commitments are written into our contracts: the security annex of the DPA, and the BAA for HIPAA workspaces. | Written policies with a named owner for every control area, approved by leadership and reviewed yearly. Staff acknowledge them when they join and every year after. |
| CC2 Communication and information | Published security measures, sub-processors (with 30 days' notice of changes) and a responsible-disclosure policy. A contractual commitment to notify customers of a personal data breach within 48 hours. Owners are emailed about account-level actions such as suspension. | Yearly security awareness training for staff. |
| CC3 Risk assessment | Known security gaps and planned fixes are tracked in our engineering documentation, and security-sensitive behavior is pinned by regression tests so a fixed risk stays fixed. | A risk register, including fraud and vendor risk, reviewed yearly and after significant changes, with an owner and treatment for each risk. |
| CC4 Monitoring activities | AWS CloudTrail records every infrastructure change and every read and write of stored documents, with log file validation, KMS encryption and a six-year Object Lock. WAF, load balancer, database and application logs feed CloudWatch. | Quarterly internal control checks, with findings tracked to closure. |
| CC5 Control activities | Production is defined in code (AWS CDK): encryption, network isolation, bucket policies, backups and logging are declared in the stack. Two-factor, CSRF, tenant isolation and tamper detection are covered by automated tests. | Drift detection between the deployed stack and the code. |
| CC6 Logical and physical access | Mandatory two-factor on every account. PostgreSQL row-level security isolates each workspace in the database itself. Two-factor is also required for everyone in our GitHub organization. The app runs as a non-privileged database role with least-privilege IAM and no long-lived AWS keys; deploys use short-lived OIDC credentials. Only the app and an MFA-gated, one-hour break-glass role can read documents. Operator access is limited to named staff set at deploy time, needs a fresh two-factor code, and is logged with a reason; operators can't read HIPAA workspaces' documents at all. Physical security is inherited from AWS. | Quarterly reviews of who has access to production, AWS, GitHub and the operator console, and removal within one business day when someone leaves. |
| CC7 System operations | AWS WAF with managed rule groups and rate limits in front of the app. VPC flow logs, CloudTrail and application logs for detection and investigation. | A written incident response plan with severity levels, roles, customer notification and post-incident reviews, exercised yearly. Alerting on security events. An independent penetration test. |
| CC8 Change management | Branch protection requires every change to go through a pull request and pass the unit, end-to-end and infrastructure checks, with no exception for administrators. Production deploys run only from main, through GitHub Actions with short-lived credentials, and roll back automatically if the new version fails its health checks. Dependabot watches dependencies for known vulnerabilities. | A required second-person review on every change, once a second engineer joins. Vulnerability scanning in CI. |
| CC9 Risk mitigation | Vendors that handle customer data are bound by written contracts: AWS (with a Business Associate Addendum for HIPAA workspaces), Stripe (PCI DSS Level 1) and SendGrid. | Vendor reviews before onboarding and yearly after, including their SOC 2 reports. Written business continuity and disaster recovery plans. |
| A1 Availability | The database runs Multi-AZ with 35 days of encrypted automated backups and point-in-time recovery. At least two app containers run across availability zones and scale out automatically. Stored documents are versioned. | A yearly restore-from-backup test, with the results recorded. Uptime and capacity alerting. |
| C1 Confidentiality | Encryption in transit (TLS 1.2+) and at rest (AES-256 with AWS KMS customer-managed keys). Signing links, API keys and recovery codes are stored only as hashes. Documents are served only through authorized routes, and the app, signing pages and verification load no third-party scripts. Customers can erase envelopes and close workspaces; deleted accounts leave our backups within 35 days. | A data classification scheme applied to every system, and a documented disposal procedure. |
3. Subservice organizations
Some controls are provided by the vendors we build on. These are carved out of our report and covered by their own SOC 2 reports, which we'll review each year as part of vendor management:
- Amazon Web Services: data centers and physical security, hardware, and the managed services we run on (RDS, S3, KMS, ECS, SES, CloudTrail).
- Stripe: card payments. Card details never reach Parapho.
- Twilio SendGrid: email delivery for workspaces that aren't in HIPAA mode.
The full list of sub-processors is in our Privacy Policy.
4. Your side of the controls
Like every cloud service, some controls depend on how you use it. A SOC 2 report calls these "complementary user entity controls". To get the protection described here, you should:
- Add and remove workspace members promptly, give admin and owner roles only to people who need them, and review your member list regularly.
- Keep API keys and webhook secrets in a secret store, use
sk_test_keys outside production, and revoke keys you no longer use. - Verify webhook signatures, and register only the origins you control for embedded signing.
- Use access codes for sensitive documents, and check signers' email addresses before you send.
- Sign the BAA and use a HIPAA workspace before you send protected health information.
- Report suspected unauthorized access to your account to us straight away.
5. Policies and procedures
As part of our SOC 2 preparation, we're writing our security program down in policies and procedures that cover information security, access control, change management, secure development, vulnerability management, logging and monitoring, incident response, business continuity and disaster recovery, backups, encryption and key management, data classification and retention, vendor management, risk assessment, asset management, people security and acceptable use. Customers and prospects can request the current versions under a non-disclosure agreement.
6. Reports and security reviews
Running a vendor security review? Email privacy@parapho.com and we'll answer your questionnaire directly.
To report a vulnerability, follow our responsible disclosure policy.