Compliance vs Security: Why Audits Are Not Enough

An audit opinion tells you that a defined set of controls, within a defined scope, looked adequate to an assessor on the evidence sampled, while attackers only need the one account, system or path that sat outside that scope or slipped between samples. Compliance and security overlap heavily, and a good compliance programme is one of the best levers a security leader has, but they answer different questions and fail in different ways. This guide sets out where they diverge: scope and sampling, control design versus operating effectiveness, point-in-time evidence, and the incentives each creates. It uses public breach case studies to show the gap, then gives metrics and an operating model that make one programme serve both. It is for CISOs, GRC leads and security managers who own both an audit calendar and a threat model. The wider discipline is introduced in the Audit, Assurance and Compliance Guide.

Key takeaways

Compliance proves conformance; security reduces the chance and impact of compromise. The first is judged against a standard's text and an agreed scope, the second against what an adversary can actually reach.
Scope and sampling are where most gaps hide. Systems declared out of scope, dormant accounts nobody sampled and suppliers outside the boundary are routinely the entry point in breach reports.
Design is not operation. A control can be well written and approved yet not run, or run on most assets but not the ones that matter. Assurance that tests only design says little about exposure.
Frameworks set outcomes, not sufficiency. NIST says the CSF "does not prescribe how outcomes should be achieved", so meeting the wording is the floor; the threat model decides how far above it you need to be.
Bridge them with shared evidence. Continuous, population-wide control data serves auditors and defenders at once, and replaces screenshots gathered once a year.

The short answer

Compliance is necessary and insufficient. It is necessary because regulators, card schemes, customers and insurers require it, and because it forces basics (inventory, access reviews, change control, logging) that many organisations would otherwise neglect. It is insufficient because it measures conformance to a text on a sample at a moment, while security is about exposure across the whole estate all the time. Run compliance as a by-product of a risk-led security programme, not the other way round, and treat every audit finding as a symptom to trace back to a control that is not working everywhere.

Side by side

Dimension	Compliance	Security
Question answered	Do we meet the requirements of standard or law X within scope Y?	Can an attacker achieve outcome Z, and how fast would we know and recover?
Reference point	Text of a standard, regulation or contract	Threat model, attack paths, current adversary behaviour
Boundary	Agreed scope (cardholder data environment, ISMS scope, in-scope system for a SOC 2 report)	Everything an attacker can touch, including suppliers and identities outside the boundary
Evidence	Policies, records and samples examined by an assessor	Telemetry, test results, red team findings, incident data
Timing	Point in time or a defined period, often annual	Continuous
Output	Report, certificate, attestation of compliance, findings list	Reduced likelihood and impact; detection and recovery capability
Typical failure	Findings closed on paper; controls that exist but are not effective	Unprioritised work, controls nobody can evidence, security that cannot be shown to regulators
Who consumes it	Regulators, auditors, customers, insurers, the board	Defenders, engineers, the board through risk reporting

Gap one: scope

Every assessment starts by drawing a boundary. PCI DSS applies to the cardholder data environment and connected systems; an ISO/IEC 27001 certificate covers the ISMS scope the organisation defined; a SOC 2 report describes the system the service organisation chose to describe. Scope reduction is legitimate and often good engineering, since segmentation shrinks what has to be protected to the highest standard. The risk is when scope reduction becomes the goal and the boundary is drawn around what is easy to evidence rather than what an attacker values.

Threat model: attackers start wherever is weakest and move laterally. A remote access portal, a build system or a supplier connection outside scope can still lead into the crown jewels.
Failure mode: the in-scope estate is hardened and evidenced; a legacy portal, test environment or acquired subsidiary is not. In February 2024 attackers used compromised credentials on a Change Healthcare Citrix remote access portal, and UnitedHealth Group's chief executive told Congress in written testimony that the portal did not have multifactor authentication. See Change Healthcare Breach 2024.
Control: keep a security scope that is wider than any audit scope: every internet-facing system, every identity provider and every privileged path, whether or not a certificate covers it.

Reading a supplier's report with scope in mind is covered in the How to Read a SOC 2 Report Guide.

Gap two: sampling

Assessors rarely test every instance of a control. They select a sample of changes, joiners, leavers, access reviews or tickets and infer the population from it. That is sound audit practice for forming an opinion within an accepted level of sampling risk, but an attacker does not sample: one exception is enough.

Threat model: the dormant, unreviewed or orphaned identity that no sample happened to pick. Non-human identities are especially exposed, because many access review procedures and samples are drawn from the HR system, which does not list service accounts, API keys or tokens.
Failure mode: the leaver process passes testing on 25 sampled leavers, while a legacy VPN profile that nobody used remains active. In the 2021 Colonial Pipeline attack, Mandiant found the VPN account used had never been disabled, had no MFA, and its password had appeared in a leaked credential set. See Colonial Pipeline Ransomware Attack 2021.
Control: test populations, not samples, wherever data allows: every account against last use and owner, every internet-facing login against MFA enforcement, every production change against a ticket. Automated full-population checks are what continuous controls monitoring is for.

Gap three: design versus operating effectiveness

Assurance work distinguishes whether a control is suitably designed to meet its objective from whether it operated as designed throughout a period. A SOC 2 Type 1 report addresses design at a point in time; a Type 2 report adds testing of operating effectiveness over a period. NIST SP 800-53A Rev. 5 (Final, January 2022, with Release 5.2.0 adding procedures in August 2025) provides assessment procedures for the SP 800-53 controls on the same principle: a control is assessed, not assumed.

Question	Design testing	Operating effectiveness testing	Security question still open
MFA for remote access	Policy requires MFA; the identity provider supports it	A sample of remote logins shows MFA challenges	Is there any remote access path that bypasses the identity provider?
Access reviews	Quarterly review procedure is documented and approved	Sampled reviews were completed and signed off on time	Did reviewers revoke anything, and did reviews include non-human identities?
Vulnerability management	Patching SLA defined by severity	Sampled critical vulnerabilities were fixed within SLA	Are exploited vulnerabilities on internet-facing assets fixed first, regardless of score?
Logging	Logging standard lists required sources	Sampled systems forward logs	Would anyone notice the specific behaviour of a real intrusion?
Cloud risk management	Cloud governance policy approved	Sampled configurations match baseline	Can any workload role read data it does not need?

The Capital One case shows the right-hand column. An attacker obtained temporary credentials for a web application firewall's cloud role that could list and read far more storage than a firewall needs. The Office of the Comptroller of the Currency assessed an $80 million civil money penalty in August 2020, citing the bank's failure to establish effective risk assessment processes before moving significant IT operations to the public cloud. See Capital One Breach 2019. The testing method in detail is covered in Control Design vs Operating Effectiveness.

Gap four: time and change

Annual assessments describe a period that has already ended. Cloud estates, identities and supplier connections change daily, so a clean report can describe an environment that no longer exists. Standards also move: PCI DSS v4.0.1 was published in June 2024 as a limited revision, v4.0 was retired on 31 December 2024, and the future-dated v4 requirements took effect on 31 March 2025, according to the PCI Security Standards Council. A programme that only reacts at audit time will always be catching up with both the estate and the standard.

Gap five: incentives

Evidence over outcome: teams optimise for artefacts an assessor will accept (a screenshot, a signed form) rather than for whether the control stops anything.
Finding closure over root cause: a finding about one missing log source is closed by adding that source, not by fixing the onboarding process that missed it.
Minimum wording: requirements are read as ceilings. The CSF 2.0 abstract states that it does not prescribe how outcomes should be achieved, which leaves sufficiency to the organisation's own risk judgement.
Quality of assurance: not all assurance is equal. The AICPA notes that SOC services should be thoroughly evaluated by service organisations and CPA firms, and has published ethics guidance on SOC 2 tool providers. A report is only as good as the scope, the tests and the independence behind it.

Where identity fits

Identity is where compliance and security diverge most often. Most frameworks require access reviews, MFA for privileged and remote access, and prompt removal of leavers' access, and most audits test them from a sample drawn from the HR joiner and leaver list. Attackers increasingly use identities that list does not contain: service accounts, API keys, OAuth grants, CI tokens and dormant legacy profiles. Extending access reviews and MFA coverage metrics to every identity type, human and non-human, closes a gap that audits rarely test. See How to Run an Access Review for Service Accounts and the Identity Security Metrics Guide.

Metrics that bridge both

The best metrics are population-wide, threat-informed and producible from system data, so the same number answers the auditor and the defender.

Metric	Compliance use	Security use
Percentage of internet-facing authentication paths enforcing phishing-resistant or strong MFA	Evidence for MFA requirements across the whole population	Direct measure of the most common initial access route
Accounts (human and non-human) with no use in 90 days still enabled	Evidence of timely deprovisioning	Count of dormant entry points
Median age of known-exploited vulnerabilities on internet-facing assets	Evidence of patching against policy	Exposure window for the vulnerabilities attackers use
Assets in the security inventory that are outside every audit scope, with owner and control coverage	Shows scope decisions are deliberate	Shows where attackers might start
Detection coverage of priority ATT&CK techniques, validated by test	Evidence that logging and monitoring operate	Measures whether an intrusion would be seen
Repeat findings rate across audit cycles	Shows whether remediation sticks	Indicates root causes are not being fixed

Board reporting that combines these is covered in the Board Cyber Risk Reporting Guide.

Decision criteria: when compliance should lead and when security should

Compliance leads when a hard deadline carries legal or commercial consequence (a contract that requires a certificate, a regulator's deadline, card scheme validation). Even then, design the controls for the whole estate and let the audit scope be a subset.
Security leads when a credible threat targets something outside scope, when incident data contradicts audit results, or when a control passes testing but red team or purple team exercises bypass it.
Small organisations often get more security from one well-run framework (for example ISO/IEC 27001 or CIS Controls) than from several overlapping certifications; spend saved on duplicated audits can fund testing.
Large organisations carrying many frameworks should map them to one internal control set, test each control once, and reuse the evidence. See the Control Mapping Guide.
Regulated sectors should note that regulators increasingly judge effectiveness, not paperwork, as the OCC's Capital One findings on risk assessment show.

Worked scenario: a SaaS company after a clean SOC 2 Type 2

A 600-person SaaS company receives a clean SOC 2 Type 2 report. A month later a red team engagement reaches production data through a contractor's API token in an old CI system that had been left out of the system description because it was being decommissioned.

Diagnose: the SOC 2 scope excluded the old CI system; access reviews sampled human users from HR; nothing tested tokens.
Fix the control, not the finding: extend the access review procedure to all identity types, add a full-population check for tokens without owners or with no recent use, and make decommissioning a change with an evidenced end state.
Change the scope rule: any system with credentials to production stays in the security scope until those credentials are revoked, whatever the audit boundary says.
Change the metrics: report dormant non-human identities and out-of-scope systems with production access to the board alongside the audit status.
Use the next audit: provide the auditor with full-population evidence, which strengthens the report and reduces sample requests.

Implementation path

Build one control set: map every obligation (laws, standards, contracts) to a single internal catalogue of controls, each with an owner and a security objective, not just a citation.
Draw a security scope: list every system, identity store and supplier connection that could lead to critical assets, and compare it with each audit scope. Record why each exclusion is acceptable.
Automate population tests: start with MFA coverage, dormant accounts, privileged role membership and critical patch age, because these are cheap to measure and frequently exploited.
Add adversarial validation: penetration tests, red team and detection testing on the controls that audits mark effective, to check they stop what they claim to.
Pilot with one framework: run the next audit on the continuous evidence for a subset of controls, keep the manual evidence as fallback, and compare results before switching fully.
Review annually: feed incident, test and audit results into strategy review, consistent with CSF 2.0 GV.OV and ID.IM outcomes.

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	GV.OV-01, GV.OV-02, GV.OV-03	Review strategy and performance using outcomes, not only audit results
NIST CSF 2.0	ID.IM-01, ID.IM-02	Improvements identified from evaluations, tests and exercises
NIST CSF 2.0	GV.RM-01, ID.RA-05	Risk objectives and inherent risk drive priorities
NIST SP 800-53 Rev. 5	CA-2 and CA-2(1) Control Assessments, Independent Assessors	Assessment of whether controls are implemented correctly and operating as intended
NIST SP 800-53 Rev. 5	CA-7 Continuous Monitoring; PM-31 Continuous Monitoring Strategy	Moves evidence from point in time to ongoing
NIST SP 800-53 Rev. 5	CA-8 Penetration Testing; RA-3 Risk Assessment; CA-5 Plan of Action and Milestones	Adversarial validation, risk-led scope and tracked remediation
NIST SP 800-53 Rev. 5	AC-2(3) Disable Accounts; IA-2(1) MFA to Privileged Accounts	Controls behind the Colonial Pipeline and Change Healthcare lessons

Common failure patterns

Scope drawn for the audit, not the attacker: legacy portals, acquisitions and build systems left outside every boundary.
Sample-based confidence: believing a passed leaver test means no stale accounts exist.
Design-only assurance: relying on a Type 1 report or policy review as if it proved operation.
Human-only identity controls: access reviews and MFA metrics that ignore service accounts and tokens.
Finding-by-finding remediation: repeat findings across cycles because root causes are never fixed.
Certificate as a supplier risk answer: accepting a certificate without reading scope, exceptions and complementary user entity controls.

Practitioner checklist

Maintain one internal control set mapped to every obligation, each control with a security objective.
Keep a security scope wider than any audit scope and record why each exclusion is acceptable.
Test MFA coverage, dormant accounts and privileged access on the full population, including non-human identities.
Validate controls marked effective with penetration tests, red team or detection testing.
Track repeat findings and fix root causes, not single instances.
Read supplier reports for scope, period, exceptions and user entity controls before relying on them.
Report bridge metrics to the board alongside audit status.
Review audit, incident and test results together at least annually and adjust strategy.

Compliance vs Security: Why Passing an Audit Is Not Being Secure