Compliance Is a Starting Point, Not a Measure of Exploitability
Why regulated enterprises need to connect failed controls to attack paths and critical assets
Security teams in regulated industries spend substantial time measuring controls, preparing audits, and tracking compliance scores. This work is necessary. It demonstrates that requirements are being addressed and gives management, regulators, and auditors a common framework for evaluating security posture.
But a compliance result cannot answer one of the most important security questions:
Can an attacker use this weakness to reach a critical asset?
A failed control identifies a condition that should be corrected. It does not necessarily show whether the affected identity is reachable, how an attacker could exploit it, or what the compromise would expose.
This distinction matters because two organizations with similar compliance scores can have very different levels of actual exposure. Even within the same organization, two failed controls with the same severity can create significantly different risks.
One might affect an isolated account with no meaningful access. The other might sit on an identity relationship that allows thousands of users to reach privileged infrastructure.
Treating those findings as equivalent leads to the wrong remediation priorities.
The limits of pass and fail
Traditional compliance reporting is organized around controls. A configuration is tested, evidence is collected, and the result is recorded as passing, failing, or not applicable.
This approach is useful for establishing a baseline. It can show whether multifactor authentication is enforced, privileged groups are correctly configured, obsolete protocols remain enabled, or administrative boundaries are properly documented.
What it usually does not show is how those conditions interact.
Attackers rarely rely on one isolated weakness. They combine exposed identities, excessive permissions, inherited access, misconfigurations, active sessions, and relationships between systems. Each element may appear relatively ordinary when viewed alone. Together, they can create a viable route to a domain controller, cloud administration role, sensitive database, backup system, or other critical asset.
A flat control result therefore describes the condition, but not its role in a possible attack.
This is why remediation based only on severity can be misleading. A critical finding may deserve immediate attention, but severity alone does not reveal:
Whether an attacker can reach the affected identity or asset
How far a compromise could propagate
Which critical systems would become accessible
How many attack paths depend on the same weakness
Whether fixing one relationship could remove many paths at once
These questions require exposure context.
Add the attacker’s perspective
A more useful approach connects control results to the identity environment in which they exist.
That means analyzing identities, permissions, group memberships, delegated privileges, configurations, sessions, and system relationships as part of one connected model. Failed controls can then be evaluated according to three practical dimensions.
Reachability: How easily could an attacker reach the affected identity or asset?
Propagation: If it were compromised, how far could the attacker move through the environment?
Impact: Which critical business or infrastructure assets would become reachable?
This changes the purpose of compliance data. Instead of treating every failed control as an independent task, security teams can understand which failures contribute to exploitable attack paths and which ones create the largest blast radius.
A control affecting a lower-tier account may become urgent if that account has a path to Tier 0. A configuration weakness on a server may become a priority if it provides a chokepoint through which thousands of attack paths pass. Conversely, a high-severity finding may be less urgent if it is isolated and has no route to a critical asset.
The control still needs to be addressed. Exposure context helps determine when and in what order.
Prioritize structural risk reduction
Large enterprises can have hundreds of thousands of identities and millions of permission relationships. At that scale, attempting to remediate every failed control sequentially is rarely realistic.
The objective should be to identify the changes that reduce the greatest amount of risk.
This is where attack-path and chokepoint analysis becomes valuable. A chokepoint is a permission or relationship shared by many attack paths. Removing it can disrupt a large number of possible routes to critical assets through one targeted change.
This approach shifts the remediation question from:
“Which control has the highest severity?”
to:
“Which change will remove the most meaningful exposure?”
The answer may still be a critical failed control. But it may also be an inherited permission, a misconfigured Group Policy Object, an excessive group membership, an unmanaged local administrator, or a relationship crossing an administrative tier.
For practitioners, this produces a more defensible remediation sequence. For CISOs, it provides a clearer explanation of why resources are being directed toward specific changes. For auditors and regulators, it demonstrates that controls are being evaluated in the context of actual organizational risk.
From periodic compliance to continuous evidence
Identity environments change constantly. Accounts are created, employees change roles, applications receive new permissions, cloud resources are added, and administrative relationships evolve.
A compliance assessment can be accurate when it is completed and outdated shortly afterward.
Continuous evaluation helps address this problem. Security teams can monitor control posture, attack paths, critical-asset exposure, and remediation progress as the environment changes. Instead of preparing evidence only before an audit, they maintain an ongoing record of what was identified, what was changed, and whether the change produced the expected reduction.
This creates a stronger operating model:
Identity a failed control or identity exposure.
Determine whether it contributes to an attack path.
Evaluate the reachable assets and potential blast radius.
Prioritize the change against other remediation work.
Verify that the control passes and the relevant exposure has been removed.
Compliance then becomes part of a continuous security-improvement process rather than a recurring documentation exercise.
What this looks like in a healthcare environment
A major French hospital group faced exactly this challenge.
The organization had more than 22,000 employees and an identity environment containing approximately 245,000 identities. Years of manual assessments had identified configuration problems, but the team lacked continuous visibility into how those weaknesses combined into attack paths.
The environment also had insufficient tiering and segmentation. This created opportunities for lateral movement and privilege escalation, while periodic audits could not provide the scale or context needed to prioritize remediation.
By connecting security controls to attack-path analysis, the organization could identify which weaknesses created real routes through Active Directory, Active Directory Certificate Services, Azure, and SMB shares.
The results went beyond an improved compliance score. The organization:
Remediated more than 150 security controls
Eliminated more than 2 million attack paths
Saved more than 100 hours of manual work each month
Reached compliance objectives that manual processes had not achieved
Established continuously updated, export-ready audit evidence
The important lesson is not that compliance was replaced. Compliance provided the necessary control framework. Attack-path context made that framework operational by showing which failures created the greatest exposure and which changes should be addressed first.
The questions CISOs should ask
A compliance dashboard should show more than the number of passing and failing controls. It should help leadership understand whether the organization is becoming more difficult to compromise.
For every important control failure, security leaders should be able to ask:
What can an attacker reach because this condition exists?
How many identities, systems, and attack paths are affected?
Which remediation would reduce the greatest amount of risk?
They should also be able to verify whether the answer changed after remediation.
This does not reduce the importance of standards such as ANSSI, CIS, ISO 27001, NIS2, PCI DSS, or SOC 2. It makes their implementation more effective by connecting control requirements to the technical relationships attackers can exploit.
Measure what the attacker loses
Passing more controls is a useful indicator of progress. It should not be the only one.
Organizations should also measure whether remediation is reducing the number of viable attack paths, improving administrative segmentation, protecting critical assets, and limiting the propagation of a compromised identity.
The ultimate objective is not to produce a cleaner compliance report. It is to remove opportunities an attacker could use. A failed control tells you that something is wrong. Exposure context tells you what it could lead to.
That is the difference between measuring compliance and reducing risk.
