The SDLC Accountability Playbook: A Free Framework for Proving Your Development Process Was Followed
The SDLC
Accountability Playbook.
Every software organization has a process. Almost none of them can prove it was followed. This is a vendor-neutral framework for measuring that gap and closing it.
Process as designed vs. process as executed.
Every engineering process has two versions. The one that lives in a Confluence page, coherent and complete, describing a team with adequate time. And the one that lives in what actually happens at 6pm on the last day of the sprint, when the reviewer is in another time zone and shipping tomorrow means shipping tomorrow.
The distance between them is not a culture problem. It is a design problem. The documented process has no enforcement surface. It cannot block a merge. It cannot fail a deploy. It relies on human vigilance, and vigilance depletes precisely when deadlines compress.
A control that runs at merge time is a control. A control that runs at audit time is a report.
Everything below follows from that one idea.
How to use this playbook.
Work through the four phases. Each one covers what the phase should produce, where its enforcement point sits, how to verify the control is actually running, and the failure mode that appears when it isn’t. Then score yourself.
Budget two hours for an honest first pass, and do it with one other person. Self-assessment alone tends toward optimism.
One rule before you begin
Do not score the process as designed. Score the process as executed. The only way to do that is to pull real samples — twenty random pull requests, the last ten releases, twenty shipped stories — and check them. If you find yourself scoring from memory, you are measuring the Confluence page, not the team.
Requirements and design.
What this phase owes the rest of the process: an unambiguous definition of done that someone other than the author can test against.
Artifacts that should exist
- A written requirement or user story for every unit of work that reaches production
- Acceptance criteria specific enough to fail
- A decision record for anything architecturally significant — what was chosen, what was rejected, why
- Evidence that someone other than the author reviewed the requirement before work started
The enforcement point
Backlog entry. A story should not be able to enter a sprint without acceptance criteria attached — and attached has to mean more than a non-empty field. This is the cheapest place in the entire lifecycle to catch a problem, and the place almost nobody enforces anything.
How to verify it is running
Pull twenty stories that shipped last quarter. For each one ask: could a QA engineer who has never spoken to the author write a test from this? Count the yeses. That number is your real requirements maturity, regardless of what the process doc claims.
The failure mode
Acceptance criteria written to clear a workflow gate rather than to describe done. One sentence, untestable, something like “user can log in successfully.” The cost surfaces two phases later, when QA writes tests against their own interpretation, the interpretation is wrong, and the rework gets logged as a bug rather than a requirements failure — so the root cause never appears in your metrics.
Development.
What this phase owes: code that a second qualified human actually examined, traceable to the requirement it satisfies.
Artifacts that should exist
- Every commit traceable to a ticket, and every ticket to a requirement
- Code review by someone who did not write the code
- Review that demonstrably happened — time spent and comments made, not just an approval click
- Static analysis and dependency scanning results attached to the change
- Test coverage meeting a defined, enforced floor
The enforcement point
Pull request merge. This is the highest-leverage control in the entire lifecycle, because it is automatable, unambiguous, and sits directly in the path of every change. A PR should not merge without a linked ticket, a passing build, a review from a qualified second party, and coverage at or above your floor.
How to verify it is running
- Ticket linkage rate. What percentage of merged PRs link to a ticket? Under 90% means the traceability chain is broken and an audit will find it.
- Review latency distribution. A cluster of approvals under five minutes on non-trivial diffs is rubber-stamping, and it is visible to anyone who checks.
- Coverage floor bypasses. How often was the floor overridden, by whom, and was a reason recorded?
The failure mode
The rubber stamp. Approval given in ninety seconds on a four-hundred-line diff because the reviewer trusts the author and the sprint is ending. This is the most common accountability failure in software and the most under-discussed, because naming it feels like an accusation against a colleague rather than a critique of a system that made the shortcut rational. Treat it as a system problem: if review is a bottleneck, the fix is smaller PRs and more reviewers, not more discipline.
Quality assurance.
What this phase owes: evidence that the thing built matches the thing specified, produced by someone with the standing to say no.
Artifacts that should exist
- A test plan traceable to the acceptance criteria
- Test execution results — what ran, what passed, what failed, what was deferred
- Defects logged, triaged, and either resolved or explicitly accepted before release
- UAT sign-off from someone who represents the user, not the builder
- A record of known issues shipped knowingly
The enforcement point
Release candidate promotion. A build should not be promotable to production without test results attached and open critical defects either closed or formally accepted with a named accepter.
How to verify it is running
Take your last five releases. For each one, can you produce the test evidence in under five minutes? If it takes longer, the evidence is not a byproduct of your process — it is something you would have to reconstruct. Which means at audit time, you will. Then check the harder question: were there open critical defects at release, and if so, is the risk acceptance written down anywhere with a name on it?
The failure mode
Sign-off as ceremony. A checkbox clicked without the test plan being opened, because the release date is fixed and the sign-off is understood to be a formality. The tell is when nobody can remember a release that QA blocked. If QA has never said no, QA does not have the authority to say no, and the sign-off is decorative.
Deployment and release.
What this phase owes: a production change that was authorized, reversible, and documented at the moment it happened.
Artifacts that should exist
- Deployment approval from someone authorized to give it
- A rollback plan specific to this release that has actually been thought through
- Release notes generated from what actually merged
- A record of who deployed, when, and from which commit
- Post-deployment verification results
- In regulated environments, separation between the person who wrote the code and the person who deployed it
The enforcement point
The deploy itself. This is your last gate and your most consequential one. A pipeline that can refuse to deploy is worth more than any amount of written policy, because it is the only control that cannot be skipped under pressure.
How to verify it is running
Pick three production deploys from the last quarter at random. For each, produce from systems rather than from memory: who approved it, what the rollback plan was, what changed at commit granularity, and whether post-deploy verification ran. If any of those requires asking a person, that is a finding.
The failure mode
The undocumented hotfix. Something breaks, someone fixes it fast, and the fix reaches production outside every control that exists. Defensible in the moment, indefensible in aggregate. The fix is not to block emergency changes — it is to have an emergency path that is fast and still logged. A break-glass procedure that captures who, what, and why in thirty seconds, with a required retroactive review inside 24 hours. If the only options are full process or no process, people will choose no process every time it is 2am.
Score your process out of 100.
Score each phase from 0 to 25. Be honest — the number is only useful if it is real.
The process exists as shared understanding. No artifacts are reliably produced. You could not reconstruct what happened.
Written down and mostly followed by people who remember to follow it. Artifacts exist inconsistently. Compliance is a person, not a system.
Controls run automatically at the key gates. Artifacts are produced as a byproduct of the work. Exceptions are possible but recorded.
Everything above, plus continuous measurement, trending over time, and evidence available for any change on demand.
Reading your score
Under 40 — aspirational
Not unusual under about twenty engineers, and not a crisis. But you carry real audit and incident risk and could not reconstruct what happened for any change older than a few weeks. Start with Phase 2. PR enforcement is the highest-leverage single control available to you.
40–65 — grown past your process
The common range. You have controls, but they are inconsistently enforced and evidence collection is manual. Your audits are painful. Find your lowest-scoring phase and fix that one — raising a 9 to a 16 returns far more than raising a 19 to a 22.
65–85 — solid
Your remaining gaps are in evidence continuity. You can prove things when asked, but proving them takes work. The move is turning point-in-time reconstruction into continuous byproduct.
Above 85 — rare
Your remaining work is drift management, and extending the same rigor to partner and offshore teams — which is almost always where the variance lives.
Score your partners separately.
Score each phase twice — once for your in-house team, once for each partner or offshore team. Most organizations have never done this, and the spread is routinely 20 points or more.
That gap is usually the single most actionable finding in the whole exercise, and it is almost never captured in a vendor contract — which specifies headcount and rate but says nothing about ticket linkage rate or review latency. You cannot manage a delivery partner on process quality if you never defined process quality as a deliverable.
A 30-day sequence.
Do not try to fix all four phases at once. It fails, and it burns the team’s patience for process work.
Days 1–5 — Measure
Pull the samples. Twenty PRs, ten releases, twenty stories. Score honestly. Resist fixing anything yet — you need a baseline you can point at later.
Days 6–10 — Pick one gate
Almost always the PR gate, because it is automatable and sits in front of everything. Define the minimum bar: linked ticket, passing build, genuine second review.
Days 11–20 — Enforce as a warning
Turn it on as a warning first, not a hard block. Let the team see what would have failed. This surfaces the legitimate exceptions you had not thought of and buys the credibility to make it mandatory.
Days 21–25 — Make it binding
Flip from warning to blocking. Keep an override path that requires a name and a reason. An override nobody can use gets routed around entirely, and then you have lost visibility on top of everything else.
Days 26–30 — Re-measure and publish
Score the same way you did in week one. Show the team the delta. Then pick the next phase. This works because it produces a visible win inside a month — process initiatives die when they are all cost and no evidence.
How this maps to audit frameworks.
The controls above line up with what auditors typically examine. This is a starting-point map, not a compliance opinion — your auditor’s interpretation governs and scope varies by organization.
The practical point is not the mapping. It is this: when these controls run continuously and produce artifacts automatically, audit preparation stops being a project. The evidence already exists because the control already ran. You are retrieving, not reconstructing — and that difference is worth roughly the six weeks most teams lose to audit prep every year.
The short version.
- Score the process as executed, not as designed. Pull samples.
- Move every control you can to the moment of action. Merge time, not audit time.
- Make documentation a byproduct. Anything requiring a human to remember will decay.
- Score partners on the same scale as your own team.
- Fix one gate at a time, and show the delta inside 30 days.
Free to use, share, and adapt.
This playbook is deliberately vendor-neutral. Every control described here can be implemented with tools you already have. If you would rather not implement and maintain it by hand, that is what we build.
Apply as a design partnerPrefer the argument before the framework? Read Your Process Is Real. Your Proof Isn’t.
Or see how the agents work · compare to alternatives · request the full brief