Product behaviour
The primary journeys work for the intended users, including the failure paths. Acceptance criteria are written before implementation and are specific enough to disagree with.
Working structure
Enterprise delivery standard.
“Done” is the most expensive undefined word in enterprise software. Without a written standard, it means whatever the least-informed stakeholder assumed at the time, and the difference surfaces during procurement review.
A delivery standard writes the production bar down once, so acceptance is a check rather than an argument.
Build your briefFORMATMarkdown standard
DOMAINSSix
APPLICABILITYTailored per product
01 / SIX DOMAINS
What the bar covers.
Applicability is tailored to the product, its risk profile, and its regulatory scope. A uniform bar applied to unequal risk wastes effort and erodes trust in the standard itself.
Quality
Automated checks appropriate to the risk, a stated test strategy, review standards, and traceable technical decisions. Quality lives in the delivery path rather than in a phase at the end.
Security
A threat model proportionate to the data and the exposure, with the resulting controls implemented and evidenced. Findings are triaged with owners and dates, not logged and forgotten.
Operations
Observability that answers whether users are affected, runbooks for the failures that occur, a deployment path, and a demonstrated rollback.
Evidence
The artifacts that show the above is true, generated by delivery rather than assembled before a review. Each has an owner and a retention location.
Handover
Source, documentation, decision records, and operating knowledge prepared for the team that will own the product, with ownership named per area.
02 / HOW A STANDARD IS ADOPTED
Tailor first, then enforce.
- 01
Agree the risk profile
Data classification, user exposure, regulatory scope, and availability expectations determine how much of the standard applies. This conversation happens once, in writing.
- 02
Tailor the applicability
Mark each requirement as required, conditional, or out of scope for this product, and record why. Unexplained exemptions become precedent.
- 03
Wire it into the path
Requirements that can be automated become pipeline gates. Requirements that need judgement become named review steps with owners.
- 04
Make exceptions expensive but possible
A standard with no exception process gets bypassed silently. A written, owned, time-boxed exception is safer than an undocumented one.
- 05
Review after real releases
The first few releases reveal which requirements were theatre and which caught real problems. Revise on that evidence.
Sample working structure
Take the standard.
The Markdown file carries the six domains and their requirement prompts, ready to tailor. Framework readiness depends on scope, and certification is performed by qualified independent assessors.
03 / QUESTIONS
Delivery standard questions.
What is an enterprise delivery standard?
It is a written definition of the production bar a release must clear, covering product behaviour, quality, security, operations, evidence, and handover. It exists so that acceptance is a check against agreed criteria rather than a negotiation at the end of a build.
Should every requirement apply to every product?
No. Applying a uniform bar to unequal risk wastes effort and erodes trust in the standard. Applicability is tailored to the product, its risk profile, and its regulatory scope, and the tailoring decision is recorded.
Who owns the standard?
The client. A standard maintained by a supplier leaves with the supplier, which defeats the purpose.
Does meeting the standard guarantee certification?
No. It produces engineering and delivery evidence within an agreed scope. Certification and audit opinions are issued by qualified independent assessors.
Next decision
Define the bar before the build.
Acceptance is cheapest when it was agreed in advance.