SOC 2 Readiness Assessment (2026-03-26)

Last Edited: March 26, 2026

Scope

• Monorepo review covering:
  • frontend/
  • go-backend/
  • database/
  • docs/
  • root repo configuration and CI under .github/
• Primary lens:
  • SOC 2 Security criteria
• Secondary notes:
  • Availability
  • Confidentiality
• Method:
  • Static review of repo code and docs only
  • No access to live infrastructure, cloud accounts, Clerk tenant, CI settings outside the repo, SIEM, backup tooling, ticketing system, or HR/access-review records
  • No penetration testing or runtime verification

Important Framing

This is a readiness assessment, not an audit opinion.

SOC 2 is not a single technical feature or a product certification. It is an attestation over controls that are designed and, for Type II, operated over time. A secure application is necessary but not sufficient.

This document therefore separates:

• controls that appear implemented in code
• controls that appear only partially implemented
• controls that may exist operationally but are not evidenced in the repo
• controls that are missing outright

Executive Summary

Project Prism has a stronger application-security baseline than many early-stage internal tools:

• explicit auth and scope middleware
• strong org-isolation patterns
• API key controls
• production config checks
• rate limiting
• audit logging
• monitoring and alerting scaffolding
• frontend security headers
• clear guidance to terminate TLS at the edge

The repo is not yet SOC 2 ready.

The main blockers are not basic auth or input validation. The main blockers are:

1. Missing production operations documentation and evidence processes
2. Missing backup/restore, disaster recovery, and incident-response documentation and proof
3. Missing formal security automation across the monorepo
4. Missing access-review, secrets-rotation, vendor-management, and change-management evidence
5. Incomplete audit/logging coverage for all sensitive operations

If the team wants to pursue SOC 2 Type I, the fastest path is:

1. close the missing ops/runbook/policy gaps
2. enable and document security automation
3. tighten a small number of remaining code/control gaps
4. build an evidence collection routine

Current State Summary

Strengths Already Present

• Production config requires explicit Clerk config and explicit CORS origins in go-backend/cmd/api/main.go.
• Strict Clerk scope mode defaults to true.
• API key management routes require Clerk auth and api_keys:manage.
• Backend routes generally use explicit RequireScope(...) guards.
• Audit logging exists and persists org/user/request context for selected sensitive operations.
• Frontend deploy headers include HSTS, CSP, frame protections, and other hardening headers.
• Backend ops docs already recommend TLS termination at a trusted edge and explicitly warn against exposing backend :8080 publicly.
• CI already runs backend tests, race tests, go vet, swagger drift checks, and Docker compose validation.

Main Readiness Gaps

• No production runbook covering deploy flow, migration execution policy, rollback, backups/restore, incident response, and secrets rotation
• No monorepo env-var matrix
• No current non-legacy import runbook
• No visible repo-level security automation for:
  • Dependabot
  • CodeQL or equivalent SAST
  • secret scanning configuration
  • dependency review enforcement
  • container/image scanning
  • frontend CI
• Audit middleware uses a static route list and likely misses newer sensitive operations
• No evidence in repo of:
  • access review cadence
  • backup restore drills
  • incident tabletop exercises
  • vendor inventory / vendor review
  • formal risk assessment
  • documented change-approval workflow

Evidence Reviewed

The most relevant repo evidence for this assessment:

• go-backend/cmd/api/main.go
• go-backend/internal/middleware/auth.go
• go-backend/internal/middleware/audit.go
• go-backend/internal/handler/apikey_handler.go
• frontend/public/_headers
• .github/workflows/go-backend-ci.yml
• docs/ops/go-backend-runbook.md
• docs/ops/https-tls.md
• docs/backend/security-audit-2026-02-07.md
• docs/audit/documentation-audit-2026-02-14.md
• go-backend/BACKEND_RISK_AND_TEST_REVIEW.md

Detailed Assessment

1. Governance, Policy, and Control Ownership

Current State

Partially implemented.

The repo has strong engineering instructions and area-specific guidance, but not a complete policy set or explicit control ownership model for audit purposes.

Positive signals:

• documentation has explicit source-of-truth and maintenance rules
• security and ops expectations are written down in multiple docs
• there is evidence of periodic internal review documents

Main gaps:

• no repo-evidenced security policy
• no incident response policy
• no change management policy
• no access control policy
• no backup/restore policy
• no secrets rotation policy
• no vendor management policy
• no formal risk register or control owner list

What needs to be done:

1. Create a lightweight control library with named owners.
2. Define which Trust Services Categories are in scope.
3. Publish minimum policies:
   • access control
   • change management
   • incident response
   • vulnerability management
   • backup/restore and disaster recovery
   • secrets management and rotation
   • vendor management
   • log retention and monitoring
4. Establish review cadence and approval records for each policy.

Audit evidence you would need:

• approved policies with owner and effective date
• list of control owners
• risk assessment records
• review/approval history

2. Identity, Authentication, and Authorization

Current State

Mostly implemented in code; partially implemented as an auditable control.

Positive signals in the repo:

• Clerk JWT validation is used for user-facing auth.
• Backend enforces org context and scopes.
• strict scope mode defaults to true
• API keys are treated as server-to-server credentials, not browser credentials
• API key management is scope-gated in go-backend/internal/handler/apikey_handler.go
• account onboarding guidance already includes offboarding and monthly admin review in docs/backend/account-profile-onboarding-guide.md

What still needs to be done:

1. Verify all protected routes have explicit scope coverage and regression tests.
2. Confirm no privileged fallback behavior exists in deployed environments.
3. Document role design:
   • Clerk role/permission mapping
   • PRISM membership role mapping
   • who can grant/revoke which permissions
4. Add formal access review process:
   • monthly or quarterly admin review
   • joiner/mover/leaver evidence
5. Enforce SSO + MFA on:
   • GitHub
   • cloud provider
   • Clerk admin
   • monitoring/alerting tools
   • any CI/CD admin interfaces
6. Produce evidence that offboarding is immediate and repeatable.

Residual code/control risk:

• route-level protection is generally strong, but auditors will expect evidence, not only design intent
• older audit notes should be reconciled against current code to avoid stale internal findings causing confusion

Audit evidence you would need:

• access review exports
• screenshots or config exports proving MFA/SSO enforcement
• onboarding/offboarding checklist
• sample terminated-user deprovision record

3. Org Isolation and Data Authorization

Current State

Strong and central to the architecture, but should be treated as a critical control that needs more explicit regression coverage.

Positive signals:

• org isolation is explicitly called out as a non-negotiable architecture rule
• backend code and internal reviews consistently emphasize orgID filtering
• scope and org context are first-class concepts

What needs to be done:

1. Expand automated tests for cross-org denial behavior across all critical resource types.
2. Create a formal “org isolation verification checklist” for new endpoints and migrations.
3. Add review gates for SQL changes:
   • does the object contain org-scoped data
   • where is org filtering enforced
   • which tests prove denial across orgs
4. Include this control in every release checklist for auth- or data-model-related changes.

Audit evidence you would need:

• regression test reports
• review checklist for sampled changes
• architecture diagram showing org-scoped vs public datasets

4. Network Security and Transport Encryption

Current State

Design guidance is good; deployed control evidence is missing from the repo.

Positive signals:

• docs/ops/https-tls.md correctly documents edge TLS as the recommended pattern
• the docs explicitly warn not to expose backend :8080 publicly
• frontend security headers already assume HTTPS deployment

Important repo fact:

• the Go API currently serves plain HTTP in-process and is intended to sit behind an HTTPS-capable edge

What needs to be done:

1. Define the production network pattern and freeze it in a production runbook.
2. Require:
   • public https:// only
   • backend port not publicly reachable
   • exact CORS origins
   • WAF/rate limiting at the edge
   • trusted proxy/header handling
3. Decide whether the edge-to-origin hop must also be encrypted:
   • private HTTP only if fully trusted/private
   • otherwise HTTPS or mTLS
4. Document HSTS rollout, cert management, and origin restrictions.
5. Collect evidence:
   • LB/CDN config
   • firewall/security-group rules
   • screenshots or IaC diffs

Audit evidence you would need:

• architecture diagram
• LB/CDN and firewall config
• certificate inventory/rotation process
• proof that origin is not public

5. Secrets Management

Current State

Partially implemented.

Positive signals:

• repo guidance clearly says not to commit secrets
• frontend docs correctly treat VITE_* as public
• several docs mention storing tunnel tokens or certs in a secret manager

Main gaps:

• no monorepo secret inventory
• no documented secret classification
• no documented rotation schedule
• no evidence of push protection or secret scanning configuration in-repo

What needs to be done:

1. Create a secret inventory:
   • name
   • owner
   • system
   • storage location
   • rotation cadence
   • break-glass access path
2. Move all production secrets into a managed secret store if not already there.
3. Enable secret scanning and push protection.
4. Define rotation playbooks for:
   • DB credentials
   • Redis credentials
   • Clerk secrets
   • Slack webhooks
   • Cloudflare/LB credentials
   • tunnel tokens
   • BI/export credentials
5. Prove rotation works with records.

Audit evidence you would need:

• secret inventory
• secret manager screenshots or IaC
• rotation logs/tickets
• secret scanning alert history

6. Logging, Auditability, and Monitoring

Current State

Partially implemented with solid foundations.

Positive signals:

• backend includes structured logging, request IDs, audit logging, metrics, and Prometheus/Grafana/Alertmanager docs
• production metrics are gated
• auth failure and rate-limit metrics are called out in runbooks

Main gaps:

• audit middleware uses a static route map in go-backend/internal/middleware/audit.go
• not all sensitive operations appear covered
• no repo-evidenced central log retention policy
• no repo-evidenced alert-response policy
• no SIEM or centralized security-event handling evidence

What needs to be done:

1. Expand audit coverage to include all security-sensitive writes and admin operations:
   • memberships
   • imports
   • exports/credential actions
   • operations workflow mutations
   • auth/admin configuration changes
2. Define retention:
   • application logs
   • audit logs
   • metrics/alerts
3. Define log access controls.
4. Route production logs/alerts to a centralized platform.
5. Add alert playbooks for:
   • abnormal 401/403 spikes
   • repeated rate-limit violations
   • repeated failed auth from same source
   • backup failure
   • cert expiration
   • error-rate and latency incidents

Audit evidence you would need:

• sample audit records
• log retention settings
• alert configuration
• on-call/escalation playbook

7. Change Management and SDLC Controls

Current State

Partially implemented.

Positive signals:

• the repo has contributor instructions
• docs require updates in the same PR
• backend CI runs tests, race tests, go vet, swagger drift, and compose validation
• the codebase shows evidence of internal review and follow-up audits

Main gaps:

• only backend CI is visible in repo
• no frontend CI workflow in .github/workflows/
• no visible branch protection requirements in repo
• no formal change-approval or deployment-approval workflow documented
• no code scanning, dependency review enforcement, or secret-scanning configuration visible in repo

What needs to be done:

1. Extend CI to cover frontend/ and other shipped surfaces.
2. Add security automation:
   • dependency review
   • Dependabot alerts/updates
   • CodeQL or equivalent SAST
   • secret scanning + push protection
   • image/container scanning if containers are shipped
3. Define release process:
   • who can approve
   • what must pass
   • what evidence is retained
4. Define emergency change path and after-the-fact review expectations.
5. Document branch protection settings and required checks.

Audit evidence you would need:

• PR approvals
• CI logs
• protected branch settings
• deployment approvals
• vulnerability scan reports

8. Vulnerability Management

Current State

Weakly evidenced in the repo.

Positive signals:

• there are static audit documents and security reviews
• the backend has had findings identified and remediated

Main gaps:

• no visible vulnerability-management workflow
• no visible repo automation for dependency alerts
• no SAST/secret scanning config visible in repo
• no patch SLA or remediation-severity policy documented
• no penetration test or external application assessment evidence

What needs to be done:

1. Create a vulnerability management policy:
   • intake sources
   • severity definitions
   • SLA by severity
   • exception process
2. Enable automated dependency and code scanning.
3. Run periodic manual security review and at least one external application assessment before audit if feasible.
4. Track remediation tickets with timestamps and owners.

Audit evidence you would need:

• policy
• alert exports
• ticket records
• remediation SLA tracking
• pentest or external review report if performed

9. Availability, Backup, and Disaster Recovery

Current State

This is one of the largest readiness gaps.

The repo explicitly calls out missing documentation for backups/restore, migration execution policy, and incident response in docs/audit/documentation-audit-2026-02-14.md.

What needs to be done:

1. Define service availability objectives:
   • uptime target
   • RPO
   • RTO
2. Implement and document backups for:
   • PostgreSQL
   • Redis if needed for operational continuity
   • any object storage or import files if they are material
3. Document restore steps.
4. Run restore drills and keep evidence.
5. Define migration rollback and recovery paths.
6. Define failover and degraded-mode behavior if dependencies are down.
7. Document how long-running jobs and exports are recovered after interruption.

Audit evidence you would need:

• backup policy
• backup job records
• restore drill results
• DR plan
• migration rollback procedure

10. Incident Response

Current State

Another major readiness gap.

The repo contains operational alerting and logging, but no complete incident-response runbook or evidence of incident exercises.

What needs to be done:

1. Write an incident response plan:
   • severity levels
   • triage owner
   • communications
   • containment
   • eradication
   • recovery
   • postmortem
2. Define who is on-call and how escalation works.
3. Create playbooks for:
   • auth compromise
   • data exposure
   • backup failure
   • production outage
   • third-party outage
4. Run a tabletop exercise and record results.
5. Store incident records consistently.

Audit evidence you would need:

• incident policy
• tabletop notes
• sample incident tickets/postmortems
• on-call roster

11. Data Classification, Retention, and Confidentiality

Current State

Partially implemented technically, weakly documented procedurally.

Positive signals:

• org-scoped data separation is treated seriously
• sensitive fields are redacted in audit logging
• frontend avoids browser API key usage

Main gaps:

• no formal data classification policy
• no retention schedule by dataset
• no deletion/disposal procedures documented
• no explicit confidentiality labeling for data stores and exports
• BI/export credentials and export data handling should be tied to a written confidentiality control set

What needs to be done:

1. Create data classification categories.
2. Map Prism datasets to those categories.
3. Define retention and disposal rules for:
   • database records
   • audit logs
   • exports
   • import files
   • monitoring data
4. Document who may access export data and how it is revoked.

Audit evidence you would need:

• data classification matrix
• retention schedule
• disposal procedures
• export-access review records

12. Vendor and Third-Party Risk

Current State

Not evidenced in the repo.

Likely in-scope vendors include:

• Clerk
• cloud provider / hosting
• database/redis provider if managed
• Cloudflare or load balancer provider
• Slack
• GitHub
• monitoring vendors if externalized

What needs to be done:

1. Build a vendor inventory.
2. Classify vendors by risk and data access.
3. Store contracts / DPAs / security reviews.
4. Track subprocessor list if customer commitments require it.
5. Review critical vendors periodically.

Audit evidence you would need:

• vendor inventory
• security review records
• contracts / DPAs
• periodic reassessment evidence

13. Documentation and Evidence Hygiene

Current State

Partially implemented.

Positive signals:

• the repo has a coherent docs structure
• source-of-truth precedence is explicit
• there is already a documentation audit

Main gaps:

• missing docs called out by the repo itself:
  • production runbook
  • env-var matrix
  • current import runbook
  • secrets rotation policy
  • incident response expectations
• some older security-audit docs contain findings that should be revalidated against current code before being used as current truth

What needs to be done:

1. Write the missing docs already identified internally.
2. Standardize doc metadata:
   • owner
   • last edited
   • last reviewed
   • source of truth
3. Build an audit evidence index:
   • where CI reports live
   • where access reviews live
   • where incident records live
   • where backup drill evidence lives

Audit evidence you would need:

• doc review cadence
• evidence index
• owner assignments

Prioritized Remediation Plan

Phase 0: Decide Scope and Owners

Target outcome:

• one named control owner per domain
• clear Type I target date
• clear in-scope systems and vendors

Actions:

1. Decide whether audit scope includes:
   • frontend app
   • backend API
   • data import worker
   • marketing site
   • monitoring stack
2. Assign owners for:
   • security
   • ops
   • app engineering
   • access administration
   • compliance evidence

Phase 1: Close P0 Documentation and Ops Gaps

Target outcome:

• minimum auditable operating model exists on paper and is usable by engineers

Actions:

1. Write docs/ops/production-runbook.md
2. Write docs/config/env-vars.md
3. Write docs/data-import/README.md
4. Write an incident response runbook
5. Write backup/restore procedure and DR targets
6. Write secrets inventory and rotation policy

Phase 2: Add Security Automation

Target outcome:

• security-relevant changes generate machine-verifiable evidence

Actions:

1. Add frontend CI
2. Enable Dependabot alerts and updates
3. Enable dependency review on PRs
4. Enable CodeQL or equivalent SAST
5. Enable secret scanning and push protection
6. Add image/container scanning if applicable

Phase 3: Tighten Remaining Code/Control Gaps

Target outcome:

• application controls are broad enough and test-backed enough for audit sampling

Actions:

1. Expand audit route coverage
2. Add authz/org-isolation regression tests for high-risk endpoints
3. Reconcile older internal security-audit findings against current code
4. Review log redaction robustness and retention
5. Review import/export data handling against confidentiality rules

Phase 4: Operate Controls and Collect Evidence

Target outcome:

• enough operational history exists for Type I, then Type II

Actions:

1. Run monthly access reviews
2. Run restore drills
3. Run incident tabletop
4. Track vulnerabilities and patch within SLA
5. Record policy reviews and exceptions
6. Retain CI/deploy approval evidence

Suggested Deliverables

Minimum internal deliverables before talking to an auditor:

1. docs/ops/production-runbook.md
2. docs/config/env-vars.md
3. docs/security/incident-response.md
4. docs/security/vulnerability-management.md
5. docs/security/access-control-policy.md
6. docs/security/backup-restore-and-dr.md
7. docs/security/secrets-management.md
8. docs/audit/evidence-index.md
9. docs/data-import/README.md

Control-to-Repo Mapping

This section maps the strongest repo-visible controls to likely SOC 2 areas.

Security

• Authn/Authz:
  • go-backend/internal/middleware/auth.go
  • go-backend/internal/handler/apikey_handler.go
• Security headers:
  • frontend/public/_headers
• TLS architecture guidance:
  • docs/ops/https-tls.md
• CORS and production config hardening:
  • go-backend/cmd/api/main.go

Availability

• metrics and alerting runbook:
  • docs/ops/go-backend-runbook.md
• compose validation:
  • .github/workflows/go-backend-ci.yml
• long-running request timeout awareness:
  • go-backend/cmd/api/main.go

Confidentiality

• org isolation:
  • handler/service/repository patterns
• audit redaction:
  • go-backend/internal/middleware/audit.go
• one-time BI credential exchange:
  • covered in go-backend/BACKEND_RISK_AND_TEST_REVIEW.md

Readiness Verdict

Current verdict: not ready for SOC 2 attestation yet.

Reason:

• application controls are decent
• operational controls and evidence are not yet mature enough
• several foundational compliance documents and automation layers are still missing

Practical judgment:

• with focused execution, Project Prism could plausibly become Type I ready without a major architecture rewrite
• the path is more about operational maturity and evidence than about replacing the core auth/data model

References

Internal repo references:

• docs/audit/documentation-audit-2026-02-14.md
• docs/backend/security-audit-2026-02-07.md
• docs/ops/go-backend-runbook.md
• docs/ops/https-tls.md
• go-backend/BACKEND_RISK_AND_TEST_REVIEW.md

External references consulted while forming the readiness framing:

• AICPA SOC overview
• GitHub docs for dependency review, code scanning, and secret scanning
• NIST guidance for incident handling and contingency planning