SDLC Playbook Template: A Free, Fillable Software Development Lifecycle Playbook for Engineering Teams
The SDLC
Playbook Template.
A fill-in-the-blanks software development lifecycle playbook. Copy it into your wiki, replace the brackets, and you have a process document that says what happens, who owns it, and what proof each step leaves behind.
.docx, 8 pages, brackets highlighted. Or read it on this page and copy what you need.
A playbook is not a process document.
Most teams already have a process document. It describes the ideal: stories get refined, code gets reviewed, tests get run, releases get approved. It is usually accurate about intent and silent about enforcement. Nothing in it can stop a merge or block a deploy, so when the sprint compresses, the document stays the same and the behavior changes.
A playbook adds three things a process document leaves out. For every phase it names the gate, the specific mechanism that refuses to let work proceed without the required artifact. It names the evidence, the record the gate leaves behind so that “we followed the process” can be shown rather than asserted. And it names the exception path, because a gate with no legitimate bypass gets routed around, and then you have lost visibility on top of control.
If a section of your playbook has no gate, it is a hope. If it has no evidence, it is a rumor.
The template below is built around those three columns. Fill in the brackets and delete what does not apply. Where a bracket asks for a tool, name the actual tool. Where it asks for a person, name the role, not the individual, so the document survives turnover.
Three passes, about two hours.
Pass one: describe what actually happens
Fill in every section with the process as it runs today, not as you wish it ran. If reviews are sometimes skipped, write that the gate is “none.” A playbook that describes a fictional team is worse than no playbook, because it will be used as evidence of a control that does not exist.
Pass two: decide what should happen
For each phase, pick the gate you are willing to enforce this quarter. Not all of them. One per phase at most, and usually one total to start. The pull request gate is the highest-leverage choice for almost every team because it is automatable and sits in front of everything.
Pass three: assign owners and a review date
Every gate gets a role that owns it and every section gets a review cadence. A playbook nobody is scheduled to reread is a playbook that will be wrong within two quarters.
If you want to score your current process before filling this in, the companion SDLC Accountability Playbook has a 100-point self-assessment and a 30-day rollout plan. This page is the document you produce afterward.
Copy from here.
Everything in [brackets] is yours to replace. Sections are numbered so they can be referenced from tickets, audit responses, and onboarding docs.
Scope, roles, and definitions
0.1 Scope
This playbook applies to [all production code in the following repositories / products / teams]. It does not apply to [prototypes, internal tooling, spikes, anything else explicitly excluded]. Excluded work must be labeled [label or tag] so the exclusion is visible.
0.2 Roles
Name roles, not people. If one person holds several roles, say so in a note; the separation still matters when the team grows or when an auditor asks who approved a deploy the author also wrote.
0.3 Definitions
- Gate: a mechanism that prevents work from advancing until a condition is met. A gate is a tool setting, not a meeting.
- Artifact: a thing that exists after a phase completes (a story, a PR, a test run, an approval).
- Evidence: the retrievable record that a gate ran and what it decided. Evidence lives in [system] and is retained for [period].
- Exception: a recorded, named bypass of a gate. Unrecorded bypasses are incidents.
Requirements and design
1.1 Purpose
Produce a definition of done that someone other than the author can test against.
1.2 Entry criteria
Work enters this phase when [a request is logged in [backlog tool] with a business owner named].
1.3 Required artifacts
- A story or requirement in [tool] with acceptance criteria written in [Given/When/Then, checklist, or other format]
- For architecturally significant work: a decision record in [location] stating what was chosen, what was rejected, and why
- Review of the requirement by [role] before work starts, recorded as [status change, comment, or approval field]
- [Regulated teams] Security and privacy impact noted in [field]
1.4 Gate
A story cannot move to [Ready / In Sprint] unless [acceptance criteria field is non-empty and reviewed-by field is set]. Enforced by [workflow validator, required field, automation rule]. Owner: product owner.
1.5 Evidence
The story history in [tool] showing the transition, who made it, and the state of required fields at that moment.
1.6 Exception path
[Role] may admit a story without acceptance criteria by [adding label X and a comment stating why]. Exceptions are reviewed [weekly, in refinement].
Watch for
Acceptance criteria written to satisfy the required field rather than to describe done. “User can log in successfully” clears the gate and tests nothing. The check is whether QA could write a test from it without talking to the author.
Development
2.1 Purpose
Produce code that a second qualified person examined, traceable to the requirement it satisfies.
2.2 Entry criteria
A story that passed gate 1.4 and is assigned to a developer.
2.3 Required artifacts
- Branch and commits referencing the story ID using [convention, e.g. PROJ-123 in branch name and commit message]
- A pull request with a description covering [what changed, why, how it was tested]
- Passing CI: build, unit tests, [static analysis tool], [dependency scan tool]
- Test coverage at or above [N%] on changed files, measured by [tool]
- Approval from [1 / 2] reviewer(s) who did not author the change, from [CODEOWNERS group]
2.4 Gate
Merge to [main] is blocked unless all of 2.3 is satisfied. Enforced by [branch protection rules / merge checks / required status checks]. Owner: engineering lead.
2.5 Evidence
The merged PR in [GitHub / GitLab / Azure DevOps]: linked story, CI run, coverage report, reviewer identity, review comments, and timestamps. Review quality signal: [minimum review duration or comment expectation, if any].
2.6 Exception path
[Role] may bypass a required check using [admin merge / override label] only with a comment stating the reason. Bypasses are listed in [weekly report] and reviewed by [role].
Watch for
Approvals under five minutes on non-trivial diffs. The gate ran, but the control did not. If this is common, the fix is smaller PRs and more reviewers, not a reminder to review harder.
Quality assurance
3.1 Purpose
Produce evidence that what was built matches what was specified, from someone with the standing to say no.
3.2 Entry criteria
A build deployed to [test / staging environment] containing only merged, gate-2.4-compliant changes.
3.3 Required artifacts
- Test cases in [tool] linked to the acceptance criteria they verify
- Execution results for this build: passed, failed, deferred, with the run ID
- Defects logged in [tool] with severity, and each critical defect either closed or accepted by [role] with a written reason
- UAT sign-off by [role representing the user], recorded as [field or approval]
- A known-issues list attached to the release candidate
3.4 Gate
A build cannot be promoted to [release candidate / pre-prod] unless test results are attached and no unaccepted critical defects are open. Enforced by [pipeline stage condition / release tool approval]. Owner: QA lead.
3.5 Evidence
The test run record and the promotion event in [tool], plus the defect acceptance records with names and reasons.
3.6 Exception path
Promotion with open critical defects requires written acceptance from [role] naming the defect, the risk, and the remediation date.
Watch for
Sign-off as ceremony. If nobody can remember a release QA blocked, QA does not have the authority this section claims, and the gate is decorative.
Deployment and release
4.1 Purpose
Put a change into production that was authorized, reversible, and documented at the moment it happened.
4.2 Entry criteria
A release candidate that passed gate 3.4.
4.3 Required artifacts
- Deployment approval from [role], who is not the author of the changes being deployed [required in regulated environments; recommended everywhere]
- Release notes generated from [merged PRs / commits], not written from memory
- A rollback plan specific to this release: [link or field]
- Deployment record: who, when, which commit or artifact hash, target environment
- Post-deployment verification: [smoke tests, health checks, monitoring window] with results
4.4 Gate
The production deploy job does not run without the approval in 4.3. Enforced by [environment protection rule / manual approval stage / change ticket check]. Owner: release approver.
4.5 Evidence
The pipeline run in [tool] with the approval event, the artifact hash, and the verification results, retained for [period].
4.6 Exception path (break-glass)
Emergency changes may skip gates 2.4 through 4.4 only by [named break-glass procedure], which records who, what, and why in under a minute, and requires a retroactive review by [role] within [24 hours]. Break-glass usage is reported [monthly].
Watch for
The undocumented hotfix. If the only options are full process or no process, people choose no process at 2am. The break-glass path exists so the emergency is still logged.
AI-assisted development addendum
If any code in scope is written or substantially modified by AI tools, the four phases above still apply unchanged. This section adds what changes when generation is fast and validation is not.
5.1 Disclosure
A PR that includes AI-generated code is labeled [label] or notes it in the description. This is not a judgment; it is so reviewers calibrate and so the label is available later if a question arises.
5.2 Review standard
AI-generated changes receive the same human review as any other change, by a reviewer who did not prompt the tool. Approval of an AI-labeled PR carries the same accountability as approval of a hand-written one. The author remains the author.
5.3 Validation independence
Tests for AI-generated code are derived from the acceptance criteria in section 1, not generated from the code under test by the same tool. [State whether AI-generated tests are permitted, and if so, the independence rule.]
5.4 Approved tools and data boundaries
Approved tools: [list]. Prohibited inputs: [customer data, secrets, regulated data, anything under NDA]. Enforced by [policy, DLP, tool configuration].
5.5 Throughput check
If PR volume rises faster than review capacity, the merge gate (2.4) is the control that fails first. Track review latency and approval duration monthly and treat a sustained drop in review time per line as a finding, not a productivity win.
Evidence retention and retrieval
- Evidence for each gate lives in the system named in that section. It is not copied into spreadsheets.
- Retention: [period, e.g. 3 years, or as required by [framework]]. Systems of record must retain history for at least that long, or export on a schedule to [archive].
- Retrieval test: [quarterly], pick [three] production changes at random and produce the full chain (story, PR, test run, approval, deploy) in under [15 minutes]. Failure to retrieve is logged as a finding against this playbook.
- Framework mapping, if applicable: gate 1.4 and 2.4 support [SOC 2 CC8.1 / SSDF PW.4, PW.7 / NIST 800-171 3.4.x]; gate 3.4 supports [SSDF PW.8]; gate 4.4 supports [SOC 2 CC8.1 / ISO 27001 A.8.32]. Your auditor’s interpretation governs.
Ownership and review cadence
- Playbook owner: [role]
- Reviewed every [quarter] and after any of: a failed audit finding, a production incident traced to a skipped gate, a change in tooling, a new team or partner onboarded
- Changes to this document go through [PR to the docs repo / change record] so that the playbook itself has history
- Partner and offshore teams: [bound by this playbook as written / bound by a variant at [link]]. Their gate evidence is reviewed [monthly] on the same scale as in-house teams.
- Version: [1.0] · Last reviewed: [date] · Next review: [date]
The minimum viable playbook.
- Section 0.2: who owns each gate.
- Section 2.4: what blocks a merge, and the tool setting that enforces it.
- Section 4.4: what blocks a deploy, and who approves.
- Section 4.6: the break-glass path, so emergencies are logged instead of hidden.
- Section 6: where the evidence lives and how long it stays.
Everything else can be filled in over the following quarter. These five are the difference between a process and a hope.
Free to copy, adapt, and share.
Download the Word version · no email required
This template is vendor-neutral. Every gate in it can be built with branch protection, pipeline stages, and workflow rules you already have. The hard part is not writing the playbook. It is keeping the evidence current after the team stops thinking about it. That is what SDLC Playbook automates: it sits on GitHub, Jira, or Azure DevOps and continuously checks that each gate above actually ran, then assembles the evidence for you.
Apply as a design partnerWant to score your process first? Use the SDLC Accountability Playbook self-assessment.
Or read Your Process Is Real. Your Proof Isn’t. · see the product · all resources