What are the signs that a SOC 2 program is drifting into security theater?

How SOC 2 turns into performance when the control set stops matching the risk

SOC 2 drift usually starts when teams optimise for passing the examination rather than managing the environment. The result is a program that looks disciplined on paper but no longer changes how access, change, logging, or incident handling actually works. The most visible clue is a control estate that can be described, but not defended: people cannot explain why a control exists, what risk it reduces, or what evidence would show it is working. That is the opposite of a living trust program. The SOC 2 Trust Services Criteria (AICPA) are meant to support trust in the operating environment, not reward theatre. In practice, many security teams first notice this drift when audit prep becomes easier than answering simple operational questions about who approved a change or why a control failed.

What a real SOC 2 program looks like when it is still security-led

A healthy SOC 2 program is anchored in a small number of controls that map cleanly to actual operational risk. That means the team can trace a control from the policy to the implementation, then to the evidence that shows it is active. If the organisation says it enforces access reviews, for example, someone should be able to show who reviewed what, on what cadence, with what exceptions, and what happened when a review found a problem. If it says it monitors changes, the change record should link to deployment activity, approval, testing, and any rollback or incident outcome.

Security theater tends to appear when the program expands faster than its governance. Common markers include policies copied from templates without local tailoring, tools bought to satisfy a questionnaire rather than to reduce exposure, and evidence collection that is performed only at audit time. Another warning sign is when controls are technically present but functionally disconnected from the environment, such as a review process that never changes entitlements or an alerting stack that no one investigates. Controls should also be proportionate. A broad control set with no clear ownership can hide gaps rather than close them, because everyone assumes someone else is watching.

• A control should answer a specific risk question, not just fill a checklist row.
• Evidence should be operational by-product, not something recreated for the auditor.
• Exceptions should be visible and time-bound, not buried in a spreadsheet.
• Ownership should sit with the team that can actually change the control.

For teams comparing control language to an external baseline, NIST’s control catalogue can help separate implementation detail from intent, but the real test is whether the control changes behaviour in the environment. Where the answer is no, the program is drifting away from assurance and toward ceremony. The line between assurance and theater breaks down when the program can produce documents faster than it can produce operational proof.

Where SOC 2 programs get noisy, and why that does not always mean they are false

Tighter audit discipline often increases administrative overhead, requiring organisations to balance demonstrable evidence against operational friction. That tradeoff matters because not every heavy control set is theater. Some environments genuinely need more formality due to scale, distributed ownership, regulated data, or frequent third-party dependencies. The practical question is not whether a control is annoying, but whether the annoyance buys measurable assurance.

One common edge case is a control that looks static but is still useful, such as a policy that rarely changes because the underlying risk is stable. Another is a compensating control that is less elegant than the ideal design but still reduces exposure in a measurable way. The difference from theater is that someone can explain the rationale and show evidence of effect. By contrast, a control becomes suspect when it survives only because it is familiar, or because removing it would make the audit package thinner.

Another nuance is that industry consensus is not always strong on how much automation or centralisation is enough. Good practice is to judge the control by its traceability and operational consequence, not by how modern it sounds. If the control does not alter decision-making, incident handling, or access to data, its value is usually marginal. The practical boundary is reached when a control can still be documented but no longer meaningfully influences the system it is supposed to protect.

Practitioner Guidance

What to prioritise: Start by asking whether each major SOC 2 control can be tied to a current risk, a named owner, and a living evidence source. If any of those three are missing, the control is a candidate for rationalisation rather than expansion.

What to verify: Test the control’s operating reality, not its paperwork. Verify that a review changes access, that a monitoring alert leads to triage, or that a change record matches what was deployed. If the evidence exists only because someone assembled it for the audit, treat that as a weak signal rather than proof.

Common mistake: Teams often confuse comprehensiveness with maturity. A larger control set can create the appearance of stronger governance while actually reducing clarity, especially when exceptions, ownership, and follow-through are fragmented.

What good looks like: The program produces routine operational evidence, weak controls are retired or redesigned, and audit preparation mostly compiles existing records rather than recreating them. That is usually the point at which SOC 2 supports security instead of distracting from it.

Practitioner takeaway: The strongest indicator of theater is not that a control is imperfect, but that the organisation would struggle to explain what would break if the control disappeared tomorrow.

Related resources from NHI Mgmt Group

• What are the signs that an LLM security program is failing in production?
• What are the signs that a code security scanning program is not working well?
• What are the signs that a data security compliance program is not keeping pace with the business?
• What are the signs that a SOC 2 program is not ready for a credible audit?