Static tools break the evidence chain. They can describe assets and controls at a point in time, but they cannot continuously validate current dependencies, cloud changes, or machine identities. Under DORA, that means firms may appear organized while still lacking defensible proof that controls are operating now.
Why This Matters for Security Teams
DORA expects firms to prove operational resilience, not just maintain tidy inventories. Spreadsheets and CMDBs can help record what should exist, but they do not continuously verify whether dependencies changed, whether a cloud workload was reconfigured, or whether a machine identity now has broader reach than intended. That gap matters because evidence that is stale at the moment of review is weak evidence under stress.
This is especially important where service accounts, API keys, certificates, and tool-to-tool trust paths sit outside classic IAM workflows. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives notes that many organisations still lack full visibility into NHIs, which makes manual governance look more complete than it is. DORA’s resilience lens aligns with the Digital Operational Resilience Act emphasis on demonstrable control effectiveness, not point-in-time documentation.
In practice, many security teams discover the weakness only after a cloud change, expired credential, or third-party dependency has already broken the audit trail.
How It Works in Practice
Spreadsheets and CMDBs are best treated as reporting layers, not control systems. They can list assets, owners, and dependencies, but they rarely capture whether those relationships are current, whether access paths are still valid, or whether the evidence behind a control was produced after the last infrastructure change. Under DORA, that creates a mismatch between governance artifacts and operational proof.
A defensible approach usually connects inventory, identity, and telemetry. Current guidance suggests four operational checks matter most:
- Continuously discover NHIs across cloud, CI/CD, and application runtimes, then reconcile them against recorded ownership.
- Track secrets, certificates, and token lifetimes so rotation and revocation can be verified, not merely scheduled.
- Link dependency maps to runtime signals from logs, cloud control planes, and privilege events so changes are visible quickly.
- Preserve evidence that shows controls were active when a change or incident occurred, not just that they existed in policy.
This is where NIST control thinking is useful. The NIST Cybersecurity Framework 2.0 pushes organisations toward governance, identification, protection, and response as continuous functions. For detailed implementation, NIST SP 800-53 Rev. 5 Security and Privacy Controls supports mapping control evidence to monitoring, configuration management, and access control outcomes.
NHIMG research shows why this matters: in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, 97% of NHIs are reported to carry excessive privileges, and only 5.7% of organisations have full visibility into their service accounts. That is exactly the kind of blind spot that static records hide. These controls tend to break down when cloud resources are ephemeral and service ownership changes faster than record updates because the evidence becomes obsolete before review.
Common Variations and Edge Cases
Tighter control of records often increases operational overhead, requiring organisations to balance audit readability against real-time accuracy. That tradeoff is manageable in stable on-prem environments, but it becomes much harder in containerised platforms, multi-cloud estates, and DevOps pipelines where identities and dependencies change continuously.
There is no universal standard for how much automation is enough, but best practice is evolving toward machine-readable evidence and continuous reconciliation. The important distinction is whether a CMDB is fed by live telemetry or manually updated after the fact. Manual updates can still be useful for governance, yet they should not be relied on as proof that controls were operating at the time of an event. For DORA-aligned programmes, the Top 10 NHI Issues is a useful reminder that unmanaged service accounts, stale secrets, and excessive privilege are not edge cases anymore.
This also intersects with broader resilience work under ISO/IEC 27001:2022 Information Security Management, especially where evidence needs to support internal audit, third-party oversight, and incident response. In highly dynamic environments, the answer is not to abandon spreadsheets entirely, but to stop treating them as the system of record for assurance. They are weakest when used as the sole source of truth for machine identity, cloud dependency, or control-state verification.
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 address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the technical controls, and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC, ID.AM, DE.CM | Static inventories fail the ongoing governance, asset, and monitoring expectations. |
| NIST SP 800-53 Rev 5 | CM-2, CM-8, AC-2 | CMDBs must support configuration, inventory, and account evidence beyond point-in-time records. |
| DORA | Article 9, Article 10, Article 11 | DORA requires demonstrable ICT resilience, testing, and incident-ready evidence. |
| NIST AI RMF | GOVERN | Governance principles apply where control evidence is stale or unverifiable. |
| OWASP Non-Human Identity Top 10 | NHI-2, NHI-5 | Non-human identities and secrets drift are central failure points hidden by spreadsheets. |
Use live discovery and continuous monitoring to keep inventory evidence aligned with current control state.
