A shared definition of done is a jointly agreed standard that development and security teams use to decide when work is complete. It aligns delivery speed with risk tolerance by specifying which issues must be fixed before release and which may be deferred with clear ownership.
What a shared definition of done is for
A shared definition of done turns completion into an explicit agreement rather than a subjective judgement. It gives delivery, security, and product teams one baseline for release readiness, so “done” means the same thing across engineering, review, testing, and approval workflows.
Its value is practical: it reduces ambiguity at handoff points and prevents late-stage debate over whether a finding is blocking, acceptable with remediation, or already covered by an earlier control. That makes it easier to balance speed with risk tolerance without relying on ad hoc escalation.
Why it matters in secure delivery
In secure delivery, the definition of done is where quality gates become enforceable. It helps teams decide which defects, missing controls, or unresolved risks must be fixed before release, and which can be tracked with named ownership and a deadline after release.
This is especially important when security work competes with feature delivery. A shared standard keeps the release decision tied to agreed evidence, such as testing results, review completion, and remediation status, rather than whichever team has the strongest last-minute argument.
What belongs in the agreement
A useful definition of done is concrete enough to test. It usually covers required testing, code review, security review, documentation, approval, and any unresolved issues that are allowed to ship only with explicit acceptance.
The agreement should be specific about scope, because vague language such as “security reviewed” or “acceptable risk” is hard to operationalise. Teams need to know whether the standard applies to all changes or only to high-risk work, and who has authority to mark something complete when exceptions exist.
Where work crosses teams, the definition also acts as a coordination tool. It clarifies ownership for deferred items, so a release is not treated as finished simply because the code merged or the feature went live.
How it supports governance and delivery discipline
A shared definition of done is most effective when it is treated as a working policy, not a slogan. It creates a repeatable decision point that aligns engineering, QA, security, and product management around the same completion criteria.
For mature teams, it becomes part of the delivery system: backlog items, pull requests, release checks, and exception handling all point back to the same standard. That makes it easier to measure whether teams are shipping responsibly and whether exceptions are accumulating faster than they are being resolved.
Risk and Threat Considerations
A weak or informal definition of done creates release risk because incomplete work can be mistaken for finished work. That can leave known defects, unreviewed changes, or unresolved security issues in production, especially when teams optimise for throughput without a clear exception process.
Failure mechanism: ambiguity at release gates lets teams bypass required checks, defer problems without ownership, or assume someone else has accepted the risk.
Impact: defect leakage, inconsistent control enforcement, and avoidable exposure when unresolved issues are shipped without a disciplined decision trail.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Defines controlled approval and tracking of changes before release. |
| CA-7 — Continuous Monitoring | Supports ongoing validation that release criteria remain effective. | |
| Recommendation — Require approved change control before marking work complete. Monitor whether completed work continues to meet release criteria. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Covers secure development and release practices that depend on clear completion criteria. |
| Recommendation — Embed explicit completion gates into secure software delivery. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Aligns with release readiness criteria that include code quality and architecture checks. |
| Recommendation — Use defined verification criteria before declaring a change complete. | ||
| ISO/IEC 27001:2022 | A.8.32 — Change management | Requires controlled changes so completion is judged against agreed criteria. |
| Recommendation — Apply formal change approval and completion criteria before release. | ||
Practitioner Guidance
Governance implication: treat the definition of done as an owned control standard, not a team preference. If delivery and security disagree on whether something is complete, the disagreement should be resolved in the standard itself, not in each individual release.
What to watch for: recurring exceptions, unclear acceptance criteria, or “done” definitions that differ by team usually indicate the agreement is too loose to support consistent release decisions. Revisit the standard when those patterns start to drive release friction or hidden risk.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
