Did-do monitoring checks whether a user actually performed the conflicting transactions that their access would permit. It adds behavioural evidence to entitlement review, helping organisations distinguish theoretical conflict from exercised risk in production workflows.
Expanded Definition
Did-do monitoring is a post-authorization control that asks a narrower question than standard entitlement review: not just whether a user or service account could execute conflicting transactions, but whether they actually did. In NHI and IAM programs, that distinction matters because permissions often outgrow business roles, while theoretical conflict may never translate into harmful behaviour.
Usage in the industry is still evolving. Some teams treat did-do monitoring as a segregation-of-duties evidence layer, while others apply it as a behavioural control for privileged service accounts, bots, and AI agents with execution authority. The control is most useful when paired with audit logs, workflow telemetry, and transaction context from systems such as ERP, CI/CD, and cloud control planes. It complements guidance in the NIST Cybersecurity Framework 2.0 by turning access governance into observable activity evidence.
The most common misapplication is treating entitlement data alone as proof of conflict, which occurs when reviewers assume access equals misuse without checking whether the transaction was actually exercised in production.
Examples and Use Cases
Implementing did-do monitoring rigorously often introduces logging and correlation overhead, requiring organisations to weigh stronger assurance against added telemetry, storage, and review cost.
- A finance team reviews whether a service account with invoice approval access actually submitted, approved, and posted the same transaction path during the audit period.
- A CI/CD pipeline monitor checks whether a deployment bot both opened a change and promoted it into production, or whether those permissions were never used together.
- A cloud operations team validates whether a break-glass admin token was exercised to change network policy, rather than merely held in reserve.
- An IAM review uses evidence from the Top 10 NHI Issues to target accounts where excessive privilege and weak logging make conflict detection unreliable.
- A security architect maps the monitoring design to audit expectations described by NIST Cybersecurity Framework 2.0 and then validates transactions against workflow records.
For a deeper governance model, NHI Management Group recommends pairing this control with lifecycle evidence from the NHI Lifecycle Management Guide, especially where service accounts are provisioned temporarily or reused across systems.
Why It Matters in NHI Security
Did-do monitoring matters because NHI risk often hides in permissions that are technically available but rarely exercised. Without evidence of actual activity, organisations can overreact to theoretical conflicts or underreact to real misuse. That leaves reviewers blind to service accounts, API keys, and AI agents that have the authority to perform sensitive actions at machine speed.
NHI Management Group research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage. In that environment, proving whether a conflicting transaction was actually performed is not a reporting nicety, it is a response necessity. The issue becomes even sharper when visibility is weak, as described in the Ultimate Guide to NHIs — Key Challenges and Risks, where excessive privilege and poor visibility often combine.
Organisations typically encounter the need for did-do monitoring only after an audit exception, fraud allegation, or incident review reveals that entitlement data could not prove what actually happened, at which point the control becomes operationally unavoidable to address.
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 and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Focuses on monitoring and detection for NHI misuse and excessive privilege. |
| NIST CSF 2.0 | DE.CM | Continuous monitoring is the baseline for validating whether risky actions occurred. |
| NIST Zero Trust (SP 800-207) | Zero Trust depends on ongoing verification, not one-time trust in entitlement state. |
Treat NHI activity as continuously verified evidence, not assumed safe because access exists.
