How we took a Cursor-built SaaS through a SOC 2 audit with zero significant findings.

A real product, a real audit deadline.

The team had built quickly and well with Cursor — users, revenue, a product enterprise buyers wanted. Then the first enterprise deal asked for a SOC 2 Type I report and the audit was scheduled in twelve weeks.

A brief audit of the codebase made clear this wasn't a paperwork problem. There were real gaps: shared credentials, secrets committed to the repo, no audit log, no role boundaries. Fixing them properly in eight weeks before the audit window was the task.

Six gaps that would have failed the audit.

We ran a structured threat model before writing a line of control code. These were the findings.

1. 01A shared admin credential used by three engineers — no individual attribution, no revocation path.Critical
2. 02Production secrets committed to the git repo in a .env file checked in at launch.Critical
3. 03No audit log — there was no record of who accessed or changed what, ever.Critical
4. 04No role boundaries — all authenticated users had equivalent access to every endpoint.High
5. 05Unstructured logs that made incident reconstruction impossible to do reliably.High
6. 06No incident or change runbook — response was entirely ad hoc.Medium

Ship controls, not binder pages.

SOC 2 audits fail on evidence, not intent. Every control we built needed to produce evidence automatically — logs, policy enforcement at the code level, and configuration-as-code so there was nothing to forget. We prioritised the three critical findings first and built toward the audit, not past it.

The principle throughout was that every control should make the team's daily work easier, not harder. A control that people route around is worse than no control.

Six controls, all in production before the audit.

1. Replaced shared creds with RBAC.

   Individual service accounts, role-scoped tokens, and an admin role enforced at the middleware layer. Every action is attributable to a principal.

2. Scrubbed secrets and centralised them.

   Rotated all compromised credentials, moved secrets to AWS Secrets Manager with access logging, and added a pre-commit hook that blocks new secret commits.

3. Built an immutable audit log.

   Every data read and write appends a signed, tamper-evident entry. The auditor can answer “who accessed this record and when” for any object in the system.

4. Centralised and structured all logs.

   Replaced ad hoc console output with structured JSON shipping to Datadog, with a correlation ID on every request so incidents reconstruct in minutes.

5. Wrote the incident and change runbooks.

   A change-management flow with required review gates and an incident runbook the team rehearsed once before the audit — now part of on-call onboarding.

6. Produced a living threat model.

   A documented threat model the team owns and updates on each major change, so the audit is a snapshot of something real, not a document written for the auditor.

SOC 2 Type I. Zero significant findings.

The audit completed with zero significant findings. The auditors noted the audit log and access controls as well-implemented. More importantly, the team uses the controls daily — the RBAC enforcement has caught two access errors since launch, and the structured logs have resolved three incidents that would otherwise have taken hours to reconstruct.

The company closed the enterprise deal that triggered the audit within a week of receiving the report.