Organisations can remain exposed because compliance checks for required controls, while security measures how well those controls actually protect systems and data. A team may pass an audit with a firewall, training, or backups in place, yet still have weak code, flawed workflows, or excessive privileges. Compliance is evidence of minimum alignment, not proof that the environment is resilient.
Why compliance can still leave real exposure
Compliance and security solve different problems. Compliance proves that required controls exist and were documented at a point in time; it does not prove those controls are effective under real workload, attacker, or failure conditions. That gap is why an organisation can pass an audit and still be exposed through weak implementation, excess privilege, brittle workflows, or untested recovery assumptions.
Compliance also tends to be control-centric and snapshot-based. Security is adversarial and operational, so the question is not only whether a control exists, but whether it is correctly configured, kept current, monitored, and able to withstand abuse at scale.
Where the gap usually appears in practice
The most common failure mode is treating a control as proof of protection rather than as one layer in a larger system. A firewall may be present, but a misrouted rule, broad exception, or unmanaged east-west path can still permit movement. Training may be recorded, but weak application logic or unsafe workflows can still expose data. Backups may exist, but if restore tests are poor or ransomware has encrypted the wrong tier first, resilience is still weak.
That same pattern shows up in identity and access. A team can satisfy an audit requirement while leaving service accounts, API keys, or administrative roles with more access than they need. NHIMG research shows how common that is in practice, with NHIMG’s Ultimate Guide to NHIs noting that 97% of NHIs carry excessive privileges. The lesson is that “control present” is not the same as “blast radius contained.”
For a concrete breach pattern, the 52 NHI breaches report and related case studies show how exposed credentials, token sprawl, and overprivilege turn compliant-looking environments into easy compromise paths. The same logic applies outside identity: if the control does not change attacker cost or reduce operational impact, it is compliance theatre rather than meaningful protection.
What practitioners should verify before trusting the control set
What to verify: verify that the control actually changes exposure, not just documentation. Ask whether the system was tested under realistic abuse paths, whether exceptions are tracked and time-bound, and whether the control still works after change, scale, or integration drift.
Common mistake: treating audit pass status as a resilience metric. An environment can be compliant with a policy and still fail because the implementation is incomplete, permissions are too broad, logging is too shallow, or recovery has never been exercised against the kinds of failures that matter.
What good looks like: the control is measurable in operations, not just in policy. Good evidence includes access actually being least privilege, critical workflows being tested end to end, backups being restored successfully, and deviations being visible enough that they can be corrected before they become incidents.
Practitioner takeaway: use compliance as a minimum baseline, then test whether the control meaningfully reduces attack paths, limits blast radius, and survives operational reality.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Access Control | Compliance gaps often show up where access is broader than needed. |
| PR.IP — Information Protection Processes and Procedures | Policies and procedures must translate into effective operational protection. | |
| RC.RP — Recovery Planning | Backups and recovery are often compliant yet still unproven under real failure conditions. | |
| Recommendation — Apply PR.AC to verify access limits reduce real exposure, not just audit findings. Use PR.IP to confirm protection processes work in practice, including exceptions and changes. Test RC.RP by validating restoration and recovery under realistic scenarios. | ||
| CIS Controls v8 | 6 — Access Control Management | Excessive privileges are a common source of exposure despite control presence. |
| 8 — Audit Log Management | Visibility gaps let exposed systems remain vulnerable even when controls are documented. | |
| Recommendation — Implement CIS Control 6 to reduce standing access and verify least privilege. Use CIS Control 8 to ensure logging is sufficient to detect control failure and abuse. | ||
| ISO/IEC 42001:2023 | 6.2 — AI risk treatment planning | Where AI-enabled workflows are in scope, compliance must still be tied to actual risk treatment. |
| Recommendation — Define AI risk treatments that are tested for effectiveness in live operations. | ||
Related resources from NHI Mgmt Group
- Why do manufacturing organisations remain exposed even when they understand the cybersecurity risk?
- Why do organisations still miss exposed credentials even when they have secrets monitoring in place?
- Why do organisations become non-compliant with GDPR even after they have policies in place?
- Why do security controls still leave organisations exposed even when they are already deployed?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
