Why security belongs inside the Sprint, not after it
The most common DevSecOps failure this module addresses is not a missing tool, it is timing: security scanning, GDPR data-handling review, and audit evidence gathering happen the week before a release instead of inside every Sprint, which means the team discovers blocking issues after the work is already considered finished. The module reframes this as a Definition of Done problem. If a feature that touches personal data is not actually done until its data-handling review has passed, that review needs to happen inside the Sprint that builds the feature, not in a separate compliance phase bolted onto the calendar afterward.
Lessons work through concrete acceptance criteria for regulated and security-sensitive backlog items: a data classification tag on any item touching personal data, a documented data retention and deletion path, and threat-modeling questions raised during refinement rather than during a pre-release security review that happens too late to change the design cheaply. A key scenario puts the team in the position of discovering a GDPR gap in the sprint before a release, with the choice to either ship late or ship with unresolved risk, and shows why that choice only exists because the check happened too late to be cheap.
The module closes on making audit evidence a natural byproduct of normal Sprint work rather than a scramble: Definition of Done checklists that double as compliance evidence, Sprint Review notes that capture who approved a security-relevant change, and a retrospective habit of asking whether this Sprint's security work happened early enough to be cheap or late enough to be expensive. The goal is a team that treats compliance the way it treats testing, as work that belongs inside the Sprint boundary, not a separate track running behind it.
Mistakes teams make with this material
Scheduling security scanning and compliance review for the week before a release, which means any finding requires either shipping late or shipping with known risk, instead of being caught cheaply during the Sprint that introduced it.
Writing a backlog item that touches personal data with no explicit criteria for classification, retention, or deletion, which pushes the actual compliance decision to whoever notices it later, often after release.
Reconstructing who approved what and when during an audit, instead of capturing that information naturally as part of Sprint Review and Definition of Done records while the work is happening.
Refining a feature's functional requirements without raising security-relevant questions until a dedicated security review much later, when the design is already locked in and expensive to change.
Questions people ask
How do you fit security scanning into a single Sprint without slowing everything down?
Automate what can be automated as part of the CI pipeline so it runs continuously rather than as a separate late-stage gate, and reserve human security review for genuinely novel risk introduced that Sprint, raised during refinement rather than after the code is written.
What should a Definition of Done include for a feature that touches personal data?
A data classification tag, a documented retention and deletion path, and confirmation that the data flow has been reviewed against the team's data-handling policy, all completed before the item is considered done, not scheduled as follow-up work.
How do you handle discovering a compliance gap right before a planned release?
Treat it as evidence the check happened too late, not as a one-time exception to work around. Ship late or ship with an explicitly accepted and documented risk, and use the retrospective to move that check earlier in future Sprints so the choice does not recur.
How does a Scrum Master make audit evidence a byproduct of normal work?
By ensuring Definition of Done checklists, Sprint Review notes, and approval records are captured as the work happens, in the tools the team already uses, so an audit is a matter of pulling existing records rather than reconstructing history after the fact.
A question from this module's assessment
One sample question with the reasoning, so you can judge the level before you start. The rest of the assessment stays inside the module.
Where should security work live on a Scrum team?
- In a separate stream after the Sprint
- Inside every relevant PBI, with DoD checks and CI scans, from Refinement onward
- Only at release time
- Only when the auditor asks
Security bolted on after the Sprint is the classic waterfall trap. Inside the Sprint it is cheap; after it, expensive.