Notifications
Clear all
Topic starter
11/08/2026 3:15 pm
TL;DR: Regulators across DORA, NIS2, the SEC, NYDFS, PCI DSS 4.0, and the EU AI Act are moving from attestation to proof, and CTEM only meets that bar when validation produces timestamped, reproducible evidence of what was tested and what happened, according to SafeBreach. Control inventories without execution evidence are now governance debt, not assurance.
NHIMG editorial — based on content published by SafeBreach: CTEM Has a Silent E and It Stands for Evidence
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.
Questions worth separating out
Q: How should security teams turn CTEM validation into evidence regulators will accept?
A: Teams should treat validation as a controlled execution exercise, not a reporting step.
Q: Why do boards and auditors care more about proof than attestation now?
A: Attestation only says a control exists, while proof shows whether it actually worked under realistic conditions.
Q: What breaks when exposure data is not paired with validation?
A: Exposure data without validation becomes a long to-do list with no way to prioritise real risk.
Practitioner guidance
- Instrument validation as evidence production Capture what was tested, which control fired or failed, the exact timestamp, and the remediation outcome so each run produces an auditable record, not just a dashboard result.
- Map test scenarios to regulatory questions Align each validation scenario to the clauses or control expectations in DORA, NIS2, the SEC disclosure regime, NYDFS Part 500, PCI DSS 4.0, or the EU AI Act where relevant.
- Use repeatable scenarios for privileged and NHI controls Run the same identity and credential abuse scenarios on a fixed cadence so you can show trend lines for access controls, secrets exposure, and detection coverage.
What's in the full article
SafeBreach's full article covers the operational detail this post intentionally leaves for the source:
- The article’s full explanation of how CTEM validation becomes timestamped evidence for auditors and boards
- The regulation-by-regulation breakdown of DORA, NIS2, SEC, NYDFS, PCI DSS 4.0, and the EU AI Act
- The practical distinctions between attestation, evidence, and reproducible validation records
- The examples of how adversarial exposure validation supports continuous proof generation
👉 Read SafeBreach's analysis of CTEM evidence and regulatory validation →
CTEM evidence: are your controls proving what they do?
Explore further
11/08/2026 3:28 pm
CTEM without evidence is governance theatre, not control assurance. Scoping and discovery can help teams understand exposure, but only validation proves whether a control behaves as intended in the real world. That distinction matters because regulators are now asking for proof of effectiveness, not a list of implemented tools. For identity programmes, the same rule applies to privileged access, NHI secrets, and authentication controls. Practitioners should treat evidence generation as a core control outcome, not a by-product.
A question worth separating out:
Q: Which control areas should be included in evidence-led security testing?
A: Start with the controls most likely to create audit and breach exposure: privileged access, authentication, detection, logging, and secrets handling. For identity programmes, include NHI lifecycle controls as well, because service accounts and tokens often fail faster than human accounts and are harder to review after the fact.
👉 Read our full editorial: CTEM needs evidence, not attestation, to satisfy regulators
