SOC 2 Preparation

Status: DRAFT Owner: Engineering Last Review: 2026-05-03 Applicable Standards: SOC 2 Type II (AICPA Trust Service Criteria 2017)

1. Purpose

SOC 2 (System and Organization Controls 2) is an auditing framework developed by the AICPA that evaluates an organization’s controls relevant to security, availability, processing integrity, confidentiality, and privacy. This document maps Equa’s current controls to the SOC 2 Trust Service Criteria, identifies gaps, and provides a remediation roadmap toward Type II readiness.

2. Scope

Component	In Scope	Notes
equa-server	Yes	Backend API, authentication, authorization, data persistence
equa-web	Yes	Frontend SPA, input validation, file uploads
PostgreSQL	Yes	Data storage, session management, and audit logs; exact managed provider is still under deployment-audit verification
AWS S3	Yes	Document storage
Railway	Yes	Current interim application hosting and managed service checks
Google Cloud Run	Yes	Legacy backend deploy path still present in repo
equabot-gateway	Partial	Agent permission proxy and rate limiting

3. Common Criteria Control Summary

The following table maps SOC 2 Common Criteria (CC) control IDs to their current implementation status. Detailed coverage is provided in the sections below and in the referenced compliance documents.

CC Category	Control IDs	Description	Status	Reference
CC1 Control Environment	CC1.1—CC1.5	Commitment to integrity, board oversight, organizational structure, competence, accountability	Gap	No formal governance documentation
CC2 Communication and Information	CC2.1—CC2.3	Internal/external communication, information quality	Partial	Audit logging exists; no formal communication policies
CC3 Risk Assessment	CC3.1—CC3.4	Risk identification, fraud risk, change impact	Gap	No formal risk assessment process
CC4 Monitoring Activities	CC4.1—CC4.2	Ongoing monitoring, deficiency evaluation	Gap	Basic health checks only; no continuous monitoring program
CC5 Control Activities	CC5.1—CC5.3	Control selection, technology controls, policy deployment	Partial	Technical controls exist; no formal policies
CC6 Logical and Physical Access	CC6.1—CC6.8	Access security, credentials, authorization, restrictions, threats, system changes	Partial	RBAC implemented; gaps in rate limiting, MFA enforcement; see Access Control Model and Security Architecture
CC7 System Operations	CC7.1—CC7.5	Infrastructure monitoring, incident detection, response, recovery, communication	Partial	Health monitoring and incident response documented; see Incident Response Plan
CC8 Change Management	CC8.1	Infrastructure, data, software, procedure changes	Partial	CI/CD pipeline exists; no formal change approval process
CC9 Risk Mitigation	CC9.1—CC9.2	Risk mitigation activities, vendor management	Gap	No formal vendor risk management

Additional Criteria

Category	Control IDs	Status	Reference
A1 Availability	A1.1—A1.3	Partial	Railway health checks and restart policies; no formal SLA
C1 Confidentiality	C1.1—C1.2	Partial	Encryption at rest/transit; no data classification policy
PI1 Processing Integrity	PI1.1—PI1.5	Partial	ORM validation; no reconciliation checks
P1 Privacy	P1.1—P1.8	Partial	Data inventory documented; no published privacy policy; see Data Privacy and GDPR

4. Trust Service Criteria Detail

4.1 Security (CC6)

Security controls protect the system against unauthorized access. Current Controls:

Control	Implementation	Status	Reference
Authentication	Three methods: password (bcrypt, 10 rounds), Google OAuth 2.0, magic links (15-min expiry)	Implemented	Security Architecture
RBAC Authorization	14 built-in permissions, 13+ built-in roles, cascading permission model	Implemented	Access Control Model
Session Management	express-session with TypeORM store, 29-day rolling sessions, secure cookies	Implemented	Security Architecture
Transport Encryption	HTTPS via provider-managed TLS on the current Railway-backed edge and any remaining legacy Google-managed endpoints	Implemented	Security Architecture
Password Hashing	bcrypt with 10 rounds	Implemented	Security Architecture
Agent Rate Limiting	Tool calls/min, write ops/min, destructive ops/hour limits	Implemented	Security Architecture

Gaps:

Gap	SOC 2 Control	Priority	Reference
No API-wide rate limiting	CC6.1	High	Security Architecture
No enforced multi-factor authentication	CC6.1	High	Security Architecture
No password complexity policy	CC6.1	Medium	—
No intrusion detection system	CC6.6	Medium	—
No vulnerability scanning (equa-server/equa-web)	CC6.8	Medium	Security Architecture
No security headers (helmet)	CC6.6	Medium	Security Architecture

4.2 Availability (A1)

Availability controls ensure the system is operational and accessible as committed. Current Controls:

Control	Implementation	Status
Managed app hosting	Railway service configs define health checks and restart policies for the current app/API edge	Implemented
Health Checks	`equa-web` and `equa-server` expose health endpoints used by managed platform checks	Implemented
Legacy backend deploy path	Cloud Build / Cloud Run configuration remains available in the repo for `equa-server`	Legacy
Managed database	Production PostgreSQL exists, but the exact live provider still needs re-verification in the deployment audit	Partial

Gaps:

Gap	SOC 2 Control	Priority
No formal SLA defined	A1.1	High
No uptime monitoring / status page	A1.2	High
No disaster recovery plan documented	A1.2	High
No load testing performed	A1.1	Medium
No multi-region failover	A1.2	Low

4.3 Confidentiality (C1)

Confidentiality controls protect information designated as confidential. Current Controls:

Control	Implementation	Status	Reference
Database Encryption at Rest	Provider-managed PostgreSQL encryption at rest; exact provider and control wording still need deployment-audit re-verification	Partial	Security Architecture
File Storage Encryption	Amazon S3 server-side encryption (SSE-S3)	Implemented	—
Session Encryption	Sessions stored in encrypted database, transmitted via secure cookies over HTTPS	Implemented	Security Architecture
Transport Encryption	TLS for all client-server and server-database connections	Implemented	—

Gaps:

Gap	SOC 2 Control	Priority	Reference
No data classification policy	C1.1	High	—
Sensitive fields stored in plaintext (bank accounts, tax IDs, OAuth tokens)	C1.2	High	Security Architecture
No customer-managed encryption keys	C1.2	Medium	—
No DLP (Data Loss Prevention) controls	C1.2	Medium	—
S3 bucket access not audited	C1.2	Medium	—

4.4 Processing Integrity (PI1)

Processing integrity controls ensure that system processing is complete, valid, accurate, and timely. Current Controls:

Control	Implementation	Status
ORM Validation	TypeORM entity decorators enforce data types, constraints, and relationships	Implemented
Content-Addressed Hashing	Document integrity verified via content-addressed hashes (Blocks, Changes entities)	Implemented
Database Constraints	Foreign keys, unique constraints, and not-null constraints enforce data integrity	Implemented
Transaction Support	Database transactions ensure atomicity for multi-step operations	Implemented

Gaps:

Gap	SOC 2 Control	Priority	Reference
Limited API input validation	PI1.2	High	Security Architecture
No reconciliation checks for equity calculations	PI1.3	High	Equity Regulatory Compliance
No automated testing of calculation correctness	PI1.4	Medium	—
No change management process documented	PI1.5	Medium	—

4.5 Privacy (P1)

Privacy controls address the collection, use, retention, disclosure, and disposal of personal information. Current Controls:

Control	Implementation	Status	Reference
Data Inventory	PII entities documented with field-level detail	Documented	Data Privacy and GDPR
Purpose Limitation	Processing purposes mapped to GDPR Art. 6 lawful bases	Documented	Data Privacy and GDPR
Email Blacklists	Unsubscribe/bounce management prevents unwanted communications	Implemented	Data Privacy and GDPR
Soft Deletes	`deleted` boolean flag on key entities preserves data while removing from active use	Implemented	Data Retention Policy

Gaps:

Gap	SOC 2 Control	Priority	Reference
No published privacy policy	P1.1	High	Data Privacy and GDPR
No consent management mechanism	P1.1	High	Data Privacy and GDPR
No self-service data export	P3.1	Medium	Data Privacy and GDPR
No self-service data deletion	P4.2	Medium	Data Retention Policy
No data processing agreements with sub-processors	P6.1	High	Data Privacy and GDPR
No automated retention enforcement	P4.2	High	Data Retention Policy

5. Remediation Roadmap

Phase 1: Critical (0—3 months)

Item	SOC 2 Control	Reference
API-wide rate limiting on all endpoints	CC6.1	Security Architecture
Draft and publish privacy policy	P1.1	Data Privacy and GDPR
Data classification policy	C1.1	—
External uptime monitoring and public status page	A1.2	—
Execute DPAs with Google Cloud, AWS, and email providers	P6.1	Data Privacy and GDPR
Document disaster recovery plan (RTO/RPO targets)	A1.2	—
Add security headers (helmet middleware)	CC6.6	Security Architecture

Phase 2: Important (3—6 months)

Item	SOC 2 Control	Reference
Enforce multi-factor authentication (TOTP for admins)	CC6.1	Security Architecture
Immutable audit logs with hash chaining	CC7.2	Audit Trail Design
Comprehensive API input validation	PI1.2	Security Architecture
Automated cap table reconciliation checks	PI1.3	Equity Regulatory Compliance
Vulnerability scanning in CI/CD (equa-server, equa-web)	CC6.8	Security Architecture
Formal SLA with availability commitments	A1.1	—
Encrypt sensitive plaintext fields (bank accounts, tax IDs, OAuth tokens)	C1.2	Security Architecture

Phase 3: SOC 2 Readiness (6—12 months)

Item	SOC 2 Control	Reference
Self-service data rights (export + deletion)	P3.1, P4.2	Data Privacy and GDPR
Cookie consent and processing consent tracking	P1.1	Data Privacy and GDPR
Documented change management process	CC8.1, PI1.5	—
Third-party penetration testing	CC6.1	—
Employee security awareness training	CC1.4	—
Formal risk assessment process	CC3.1—CC3.4	—
Vendor risk management program	CC9.1—CC9.2	—
SOC 2 Type I audit (point-in-time assessment)	All	—
SOC 2 Type II audit (after 6+ months of sustained controls)	All	—

6. Cross-Reference to Compliance Documents

Control Area	Compliance Document
Authentication, encryption, network security	Security Architecture
RBAC, permissions, data room access	Access Control Model
Event logging, audit trail integrity	Audit Trail Design
Data privacy, GDPR, user rights	Data Privacy and GDPR
Data lifecycle, retention schedules	Data Retention Policy
Incident detection, response, recovery	Incident Response Plan
Securities compliance, cap table integrity	Equity Regulatory Compliance

7. Revision History

Date	Version	Author	Changes
2026-02-21	0.1	Agent (Phase 5 Session A)	Initial draft
2026-02-21	0.2	Agent (Phase 5 Session B)	Template alignment (status header, scope table, numbered sections), CC control ID summary table, cross-references to all compliance documents throughout, remediation roadmap with document references

Platform Architecture

Compliance & Security

Feature Specifications

Releases

Developer Onboarding

Business

Reference & Templates

SOC 2 Preparation

SOC 2 Preparation

1. Purpose

2. Scope

3. Common Criteria Control Summary

Additional Criteria

4. Trust Service Criteria Detail

4.1 Security (CC6)

4.2 Availability (A1)

4.3 Confidentiality (C1)

4.4 Processing Integrity (PI1)

4.5 Privacy (P1)

5. Remediation Roadmap

Phase 1: Critical (0—3 months)

Phase 2: Important (3—6 months)

Phase 3: SOC 2 Readiness (6—12 months)

6. Cross-Reference to Compliance Documents

7. Revision History

​SOC 2 Preparation

​1. Purpose

​2. Scope

​3. Common Criteria Control Summary

​Additional Criteria

​4. Trust Service Criteria Detail

​4.1 Security (CC6)

​4.2 Availability (A1)

​4.3 Confidentiality (C1)

​4.4 Processing Integrity (PI1)

​4.5 Privacy (P1)

​5. Remediation Roadmap

​Phase 1: Critical (0—3 months)

​Phase 2: Important (3—6 months)

​Phase 3: SOC 2 Readiness (6—12 months)

​6. Cross-Reference to Compliance Documents

​7. Revision History

SOC 2 Preparation

1. Purpose

2. Scope

3. Common Criteria Control Summary

Additional Criteria

4. Trust Service Criteria Detail

4.1 Security (CC6)

4.2 Availability (A1)

4.3 Confidentiality (C1)

4.4 Processing Integrity (PI1)

4.5 Privacy (P1)

5. Remediation Roadmap

Phase 1: Critical (0—3 months)

Phase 2: Important (3—6 months)

Phase 3: SOC 2 Readiness (6—12 months)

6. Cross-Reference to Compliance Documents

7. Revision History