Skip to content
← Intel Brief
Enterprise · GRC

SOC 2 without the theater

Controls engineers respect and auditors can evidence, without rebuilding a parallel paperwork company every audit season.

Security controls and evidence workflow for a SOC 2 readiness programme
AN3 · Offensive Research · · 9 min read

Compliance should make you more secure, not just more documented.

SOC 2 theater is what happens when the program exists for the logo: screenshots collected in a panic, policies nobody reads, and engineers who learn that "security" means filling a GRC tool two weeks before the auditor arrives. The report may still pass. The control environment did not improve.

This note is for founders and security leads who need the attestation and refuse to run a second company made of PDFs. It is not legal advice and it is not an audit opinion.

What theater looks like in practice

  • Evidence that only exists because someone remembered to export it
  • Access reviews that are spreadsheets of names with no link to the IdP
  • Change management described in a policy and bypassed in the deploy pipeline
  • Vendor reviews that are questionnaires filed once and never revisited when the vendor's blast radius grows
  • "Annual penetration test" scoped to a marketing site while the product API and admin plane are out of bounds

Auditors can only sample what you show. Attackers sample what you run. Theater optimizes for the first.

Principles that keep SOC 2 connected to the system

### 1. Automate evidence from systems you already run

Prefer logs, tickets, IdP exports, CI attestations, and cloud config snapshots over narrative screenshots. If a control cannot produce evidence without a human performing theater, the control is fragile.

Examples that travel well:

  • SSO and MFA status from the IdP, not a screenshot of a settings page
  • Deploy approvals from the pipeline, not a Word template
  • Access removal from offboarding tickets linked to IdP deprovision events

### 2. Map one control set to many asks

Do not rebuild the program per framework. Maintain a small set of real controls (identity, change, logging, incident response, vendor, availability) and map SOC 2 Trust Services Criteria (and ISO, and customer questionnaires) onto that set.

The goal is one operational truth, many report views. The failure mode is five overlapping policies that disagree.

### 3. Engineers own controls. Security advises.

If only GRC can explain how production deploys work, the control will drift the week after the audit. The team that runs the system should own the control statement and the evidence path. Security defines the bar and tests it. Security does not become a bottleneck that people route around.

### 4. Test controls. Do not only describe them.

A policy that says "access is reviewed quarterly" is not a control. A control is: a scheduled review, a system of record, exceptions with owners, and a sample that would fail if the review was skipped.

Tabletop incident response. Restore a backup. Attempt to deploy without approval and confirm it blocks. Phish a subset of staff and measure report time. Write down what broke.

A practical program shape

Keep the inventory short enough that people can name it:

  1. Identity and access — joiners, movers, leavers; privileged roles; MFA; reviews
  2. Change and release — who can change production, how, and with what record
  3. Logging and monitoring — what is retained, who is paged, what "investigated" means
  4. Incident response — roles, severity, customer/comms path, post-incident actions
  5. Vendors and subprocessors — inventory, risk tier, review cadence, offboarding
  6. Availability and recovery — backups, restore tests, dependency list

For each item: owner, system of record, evidence query, test method, last test date. If any field is empty, you have a slide, not a control.

Where startups usually overspend

  • Buying a GRC platform before the control list fits on one page
  • Writing novel-length policies that duplicate what the handbook already says
  • Scoping pentests for the badge instead of for the product attack surface
  • Treating the auditor as the product manager of security

Underspend is also real: no inventory of admin roles, no restore test, no offboarding that actually revokes SaaS. Theater and neglect often coexist.

Closing note

A clean SOC 2 report is a useful signal to customers. It is not a substitute for a perimeter made of identity, change control, and detection.

Build the smallest set of controls that would still matter if no auditor ever came. Then make that set easy to evidence. The attestation follows. The theater does not have to.


AN3 Intel · field notes on GRC that survives engineering.