Definition of done

The definition of done is the agreed state that proves a remediation task is complete. In cloud and identity governance, it must describe the evidence needed to show the underlying risk was removed, not just that an alert was acknowledged or a ticket was closed.

Expanded Definition

The definition of done is a verification standard, not a status label. In NHI remediation and cloud governance, it should specify the observable evidence that the risk has been removed, such as revoked access, rotated secrets, policy updates, and validation that the exposed path no longer works. That distinction matters because a ticket can be closed while the NHI still remains reachable or privileged.

In mature practice, the definition of done is tied to control objectives and audit evidence. It should answer: what changed, how was it tested, and what proves the exposure is gone? This is closely aligned with the intent of NIST Cybersecurity Framework 2.0, which treats outcomes and verification as core governance disciplines rather than administrative completion. For NHI programs, that usually means the remediation is not done until the identity, secret, or permission has been invalidated and the result has been independently confirmed.

Definitions vary across vendors and delivery teams, especially when incident response, engineering, and security operations use the phrase differently. In governance contexts, NHI Management Group recommends treating it as an evidence-backed closure criterion, not a project milestone. The most common misapplication is declaring remediation complete when a human acknowledges the alert, which occurs when closure is based on ticket workflow rather than technical validation.

Examples and Use Cases

Implementing a rigorous definition of done often introduces extra validation work, requiring organisations to balance faster ticket closure against stronger proof that the underlying exposure is actually eliminated.

• A leaked API key is only “done” after the key is revoked, downstream systems are checked for replacement credentials, and a test confirms the old key no longer authenticates.
• A service account over-privilege remediation is only “done” after permissions are reduced, the change is verified in production, and the access review record reflects the new entitlement set.
• A CI/CD secret rotation is only “done” after the old secret is removed from code, config, and pipeline variables, consistent with the risks described in the Ultimate Guide to NHIs — What are Non-Human Identities.
• An expired certificate recovery is only “done” after certificate replacement is deployed and application health checks confirm that no fallback path still accepts the retired certificate.
• A cloud policy misconfiguration is only “done” after the policy is corrected, the affected resource is rescanned, and the exposure no longer appears in the control report.

This approach matches the practical orientation of NIST Cybersecurity Framework 2.0 and the NHI lifecycle and governance emphasis in Ultimate Guide to NHIs — What are Non-Human Identities, where evidence matters more than assertion.

Why It Matters in NHI Security

In NHI security, weak definitions of done create false confidence. A team may believe a leak was contained while the secret still works, the service account still has broad privileges, or the credential remains valid in a third-party pipeline. That is especially dangerous because NHIs are often embedded in automation, making incomplete remediation harder to notice than a human account issue.

NHI Management Group research shows that 91.6% of secrets remain valid five days after the targeted organisation is notified, which highlights how often remediation stalls between awareness and effective invalidation. That gap is exactly where a disciplined definition of done becomes operationally important. It forces teams to prove that the exposure has been removed, not merely deferred.

For governance, this also supports durable reporting. If a control owner cannot show evidence of revocation, rotation, or successful re-test, the issue should stay open. Organisations typically encounter the cost of a weak definition of done only after the same NHI is reused in a second incident, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What should be done with inactive NHIs?
• What breaks when certificate discovery is only done once in a while?
• What breaks when JWT verification is done only in middleware?
• What breaks when MySQL access reviews are done only after incidents?