TL;DR: Many SOC 2 buyers still judge vendors on badges, speed, and price while missing the control quality that determines whether evidence is trustworthy, whether findings are real, and whether post-audit security stays active, according to Oneleet. The deeper issue is that compliance workflows can certify paperwork faster than they can prove resilience, which leaves buyers exposed to security theatre.
At a glance
What this is: This is an analysis of how SOC 2 vendor selection can reward compliance theater over verifiable security, with an emphasis on test quality, evidence validation, and post-audit monitoring.
Why it matters: For IAM and security practitioners, the warning is that assurance processes can become a governance blind spot when they measure completion rather than control effectiveness, including identity and access evidence that may be superficial.
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
- Only 5.7% of organisations have full visibility into their service accounts.
👉 Read Oneleet's 10 questions for choosing a SOC 2 vendor
Context
SOC 2 vendor selection often fails when buyers treat an attestation as a proxy for security quality. In practice, the control that matters is not whether a checkbox exists, but whether the evidence behind it is independently validated, current, and useful when a real customer review or incident forces scrutiny. For identity-heavy programmes, that same problem shows up when access evidence, service accounts, and third-party controls are accepted on trust rather than tested.
This article is about the governance gap between compliance theatre and operational assurance. That gap matters to IAM and PAM teams because identity evidence, audit trails, and offboarding discipline can all look complete on paper while still failing under real scrutiny. It is a familiar pattern in broader security programmes as well: a control is easier to document than to prove effective, and the difference becomes visible only when a customer, auditor, or incident response team asks harder questions.
Key questions
Q: What breaks when a SOC 2 programme measures evidence quality too loosely?
A: The programme starts rewarding artefacts instead of outcomes. A vendor can submit clean-looking documents, pass an audit, and still leave unresolved security gaps in place. That creates a false sense of assurance, especially where access evidence, remediation status, or pentest quality should have been validated before submission.
Q: Why do weak compliance controls create commercial risk as well as security risk?
A: Because enterprise buyers often re-check the substance behind the report during procurement or renewal. If the evidence is thin, generic, or clearly automated, the customer may treat the programme as unreliable and stop the deal or demand extra scrutiny. Compliance theatre therefore becomes a trust and revenue problem, not just a governance issue.
Q: How do you know if a pentest report is actually useful?
A: A useful report turns findings into prioritised actions, explains exploitability in plain terms, and supports both remediation planning and leadership reporting. If the output reads like a technical dump with no business context or sequencing, it is unlikely to accelerate risk reduction.
Q: How can organisations tell whether post-audit monitoring is really active?
A: Check whether the programme continues to track unresolved findings, environment drift, and control decay after the report is issued. If monitoring stops at the moment compliance is achieved, the organisation has an attestation process, not an active security process. That distinction matters most when access and configuration change continuously.
Technical breakdown
Why compliance evidence can look complete while security remains weak
SOC 2 programmes often collapse when evidence collection is mistaken for control verification. A platform can show that integrations exist, documents are uploaded, and a checklist is complete without proving that the underlying security practice is effective. That distinction matters because auditors assess what is presented, not necessarily whether it would withstand adversarial scrutiny. In identity terms, this is similar to accepting access records without validating whether privileged accounts were actually offboarded, rotated, or continuously reviewed.
Practical implication: require evidence validation before submission, not after audit review.
Pentest quality depends on signal, not just a passed report
A pentest should surface exploitable weaknesses, not just satisfy a compliance requirement. Automated scanning, human-led testing, and agentic assistance can all appear in a delivery model, but the deciding factor is whether the work produces high-fidelity findings that reflect real attack paths. Noise-heavy reports are dangerous because they look substantive while providing little remediation value. For security buyers, the real test is whether the report can survive a skeptical enterprise review and help a team prioritise what actually changes risk.
Practical implication: ask for examples of findings quality, retest terms, and remediation guidance before you sign.
Continuous monitoring is not the same as continuous security
Many compliance tools keep integrations running after the audit, but that is not the same as monitoring security conditions that change over time. A control can remain connected while the environment drifts, findings stay open, or operational protections stop after a report is issued. The governance failure is assuming that an attestation lifecycle equals a security lifecycle. For IAM teams, the same logic applies when access reviews are periodic but credential exposure, privilege creep, and third-party access continue between reviews.
Practical implication: separate post-audit monitoring obligations from evidence collection and insist on ongoing control checks.
Threat narrative
Attacker objective: The objective is to convert a compliant-looking programme into a trust failure that survives long enough to affect sales, audit credibility, or breach response.
- Entry begins when buyers accept compliance evidence, pentest output, or auditor independence claims without validating the underlying substance.
- Escalation occurs when weak testing, shallow review, or hidden remediation gaps allow insecure controls to be treated as compliant.
- Impact follows when the organisation discovers that the report did not reflect real security, often during a customer review, contract negotiation, or incident.
NHI Mgmt Group analysis
Security theatre is a control governance problem, not a marketing problem. When buyers accept compliance output as evidence of security quality, they create an assurance gap that adversaries do not respect. The relevant question is whether controls are measurable, repeatable, and independently verifiable, not whether a dashboard is green. That is why identity and access evidence must be tied to actual lifecycle control, not ceremonial documentation.
The named concept here is evidence-to-control mismatch. This is the point at which a report, scan, or checkbox ceases to represent the real state of the environment. The mismatch is especially dangerous in identity programmes because service accounts, API keys, and third-party access can be present, active, and overprivileged while still appearing covered by process. Practitioners should treat any assurance workflow that cannot prove control effectiveness as incomplete.
SOC 2 itself is not the failure, but the market has built incentives around shallow proof. Vendors can optimise for audit pass rates, short sales cycles, and low customer effort while buyers inherit the residual risk. That distorts purchasing decisions and weakens trust in the wider compliance ecosystem. The corrective move is to evaluate whether the programme produces evidence that can withstand a real security review, not just an attestation.
Identity governance should be part of vendor assurance, even when the subject is not explicitly IAM. Access control evidence, offboarding discipline, and secret handling often sit inside compliance scope but outside buyer scrutiny. That creates a blind spot where machine identities, service accounts, and credentials can be mishandled without affecting the badge. Organisations should align SOC 2 evaluation with identity assurance expectations, including what happens when control evidence is stale or incomplete.
Customer due diligence is becoming a second security gate. Enterprise buyers increasingly validate the substance behind claims, and weak assurance quickly becomes a commercial problem as well as a technical one. That means compliance teams and security teams need a shared standard for evidence quality, independent review, and ongoing monitoring. The practical conclusion is simple: if the control cannot survive buyer scrutiny, it is not yet a control worth trusting.
What this signals
Evidence quality will become a differentiator in compliance-led buying. As more procurement teams ask harder questions about what was actually tested, vendors will be judged less on badge completion and more on whether they can prove control effectiveness. For identity programmes, that means access evidence, secret handling, and remediation status will need the same level of scrutiny as traditional security controls.
Identity governance will keep surfacing inside non-IAM buying decisions. Even when a buyer thinks it is purchasing compliance support, the real risk often sits in service accounts, API keys, and third-party access that live inside the evidence package. Teams that can tie those artefacts back to lifecycle discipline will be better placed to defend both audit outcomes and customer diligence, especially when resources such as Ultimate Guide to NHIs , Regulatory and Audit Perspectives are used to frame accountability.
For practitioners
- Validate evidence before auditor submission Create a pre-audit review step that checks whether each control artifact actually supports the claim being made, especially for pentest reports, access evidence, and remediation records. Do not let integration completeness stand in for proof of effectiveness.
- Separate control presence from control effectiveness Track whether a safeguard exists and whether it is working, then report both. For identity-heavy evidence, that means verifying offboarding, rotation, and review outcomes rather than accepting a completed checklist as success.
- Demand independent testing quality criteria Ask vendors to show how they measure signal quality, false positives, retest terms, and remediation guidance. If they cannot explain those metrics clearly, the report may satisfy compliance without helping you manage risk.
- Keep post-audit monitoring active Require ongoing checks for environment drift, unresolved findings, and control decay after the report is issued. Continuous evidence collection is not enough if the underlying security state is no longer being watched.
Key takeaways
- SOC 2 buyer scrutiny is increasingly about whether evidence proves security, not whether it completes a checklist.
- Weak pentests, shallow validation, and post-audit drift all create an evidence-to-control mismatch that undermines trust.
- Identity-heavy controls such as offboarding, secret rotation, and access review need the same proof standards as any other security control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and SOC 2 (AICPA) defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article repeatedly critiques weak access evidence and control validation. |
| Recommendation — Use PR.AA-05 to verify that access evidence reflects actual entitlements, not just documented intent. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Identity evidence and secret handling are central to the article's assurance gap. |
| Recommendation — Apply IA-5 to confirm credential lifecycle controls are real, current, and independently testable. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article's concern with offboarding and lifecycle proof maps to account control governance. |
| Recommendation — Use CIS-5 to validate account lifecycle evidence before accepting compliance claims. | ||
| SOC 2 (AICPA) | CC6.1 — Logical and Physical Access Controls | The source article is about SOC 2 vendor diligence and the quality of control evidence. |
| Recommendation — Tie vendor evaluation to CC6.1 evidence that shows access controls are operating effectively. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article's identity angle includes weak offboarding and revocation discipline for secrets and access. |
| Recommendation — Audit offboarding and revocation evidence for NHI credentials before treating compliance as complete. | ||
Key terms
- Security Theater: Security theater describes a control that looks protective but adds little real security relative to its cost or risk. The term is used when a measure increases complexity, friction, or failure modes without materially changing the attacker’s position. In practice, it is a warning to test whether a control meaningfully reduces exposure.
- Evidence To Control Mismatch: Evidence to control mismatch occurs when a document or report claims a safeguard exists, but the underlying control is weak, stale, or unverified. It is a governance failure because the organisation is making decisions based on proof of paperwork rather than proof of protection.
- Pentest Signal Quality: Pentest signal quality is the degree to which a test surfaces exploitable, decision-relevant findings instead of noise. High-quality signal helps teams prioritise remediation and assess real exposure, while low-quality output can satisfy compliance workflows without improving security outcomes.
- Continuous Application Security Monitoring: A control approach that watches code, dependencies, pipelines, and runtime activity continuously rather than on a schedule. It aims to detect vulnerabilities and risky changes at the moment they appear, so security teams can prioritize, correlate, and remediate before exposure becomes production risk.
What's in the full article
Oneleet's full blog covers the operational detail this post intentionally leaves for the source:
- The vendor's question set for comparing pentest quality, auditor independence, and evidence validation in practice.
- The specific red flags it uses to separate real security signal from compliance theatre during vendor selection.
- The full discussion of pricing, scoping, and hidden add-ons that affect compliance programme cost over time.
- The detailed examples of what buyers should ask before signing a SOC 2 vendor contract.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps practitioners connect identity control quality to broader security assurance across their programmes.
Published by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org