Five Controls That Always Pass Review and Always Fail in Practice

A control can pass a SOC 2 exam for three straight cycles and still fail the moment it's actually needed. Noncompliance adds close to $174,000¹ to the average cost of a data breach, on top of any fine, and that number shows up whether or not a regulator ever gets involved. The same five controls keep passing review and failing in practice, and the pattern is the same every time: each one was built to satisfy a testing procedure, not to stop a bad outcome.

The Five Controls That Keep Failing the Same Way

Security Awareness Training

Completion sits at 100% because the learning platform won't let anyone log off without clicking through every slide. A phishing simulation three weeks after that “annual refresher” routinely tells a completely different story. The completion report and the simulation results almost never agree, and the simulation is the one worth trusting.

Access Certifications

A manager gets a spreadsheet listing everyone with access to a system and signs off in under two minutes. The signature gets treated as evidence of review. It's evidence of a click, and four hundred rows do not get meaningfully reviewed in ninety seconds.

Vendor Risk Assessments

The questionnaire goes out before the contract is signed, comes back clean, and gets filed. Almost nobody reopens it when the vendor's environment changes or a breach shows up somewhere in their industry, which means the assessment happens at the exact moment the vendor carries the least risk it ever will.

Policy Acknowledgment

“I have read and understand this policy” gets clicked by people who did neither, and the control measures the click, not the comprehension. Everyone downstream treats that click as proof of understanding, which is a bigger leap than anyone admits during the audit.

Disaster Recovery Testing

A tabletop exercise is a conversation. A real test is restoring an actual backup, under a countdown clock, and finding out whether the restore script still works after the last infrastructure migration. Most disaster recovery plans get discussed annually and never get tested, which means the first real test happens during an actual outage, the worst possible time to discover a plan doesn't work.

Why These Five in Particular

85% of executives say compliance requirements have become more complex, and 97% of organizations now run at least two formal audits a year.² 38% of organizations report losing revenue or a competitive bid because they couldn't produce sufficient compliance evidence when asked.² A program built around a single annual audit is already behind the pace most organizations are operating at, and these five controls are exactly the ones that look fine on that annual cycle and fall apart between reviews.

What Continuous Compliance Looks Like

Effective compliance programs, tracing back to the framework the US Sentencing Guidelines popularized, are generally built around seven core elements.

• Policies and procedures: documented, current, and specific enough to be tested, not aspirational.
• Oversight and governance structure: a named accountable owner with a reporting line to leadership.
• Training and communication: measured for comprehension, not just completion.
• Monitoring and auditing: ongoing checks that a control is operating, not a point-in-time test.
• Reporting and internal controls: a mechanism for issues to surface before an external party finds them.
• Enforcement and corrective action: consistent follow-through when a control fails.
• Response and continuous improvement: fixing the root cause, not just the incident that exposed it.

Devensa AI's TruMaturity™ Assessment scores compliance maturity against these seven elements on the CMMI scale from Initial through Optimized, and continuously reassesses as frameworks and business operations change, so the weakest element surfaces before an external auditor finds it first. Devensa AI's vCCO vOfficer maps controls across every framework mapped to your organization, so evidence gets produced once and reused everywhere it's needed instead of rebuilt separately for each one.

Testing Controls the Way They'll Actually Be Tested

• Pair every completion-based control with an outcome-based test: a phishing simulation for training, a real restore for disaster recovery.
• Reopen vendor risk on a trigger: a renewal, a breach in their industry, a material change in their environment.
• Track engagement, not just acknowledgment: measure how long someone actually spends with a policy before confirming they read it.
• Keep evidence ready before it's requested: customers and auditors both expect proof on demand, not proof assembled after the ask.
• Treat the audit as a checkpoint, not the goal: a program built to pass and a program built to work aren't always the same program.