Planning
Decide what a change must protect before it is designed: security requirements, abuse cases, and the data and obligations in scope.
What does this change handle, and what must it never allow?
Security practices in this phase
Security requirements
Turn the feature's risks into testable requirements, such as who may do what, to which data and how often, and add them to the acceptance criteria.
Done when: Each requirement names the test or review that proves it, and the Definition of Done says which changes need a security review.
Abuse cases
For each story, describe how it could be misused: replayed, enumerated, raced, scripted or used against another user's data.
Done when: Abuse cases sit in the backlog with the control and the test that answer each one, or a recorded risk acceptance.
Data classification
Record which personal, payment, health or secret data the change touches, how long it is kept, and which laws or contracts apply, before choosing controls.
Done when: The ticket names the data classes, their retention and the obligations in scope.
Guides
11 guides- GDPR, CCPA, HIPAA or the FTC rule: scope privacy and health-data obligations before choosing controls
Map data, actors and processing purposes to the relevant GDPR, California or HIPAA requirements and preserve uncertainty about applicability.
- Data minimization and retention: collect less and prove that deletion works
Design collection and deletion around a data-flow graph that includes logs, derived tables, exports and restored backups, and use per-person keys so deletion can reach copies you cannot edit.
- Tokenization, pseudonymization and privacy transformations: choose deliberately
Choose between vault tokens, keyed pseudonyms, format-preserving encryption, aggregation and differential privacy by the joins, reversibility and leakage each allows, and test re-identification on the data you release.
- Prevent business-logic flaws with server-side invariants
Recompute prices on the server, run workflows as state machines, build reset links from configuration, limit valuable flows, and turn each business rule into an invariant that the database and the tests both check.
- Write testable security requirements and a security Definition of Done
Derive security requirements from OWASP ASVS 5.0, abuse cases and the threat model, write them as acceptance criteria a test can fail, trace each one to a test or evidence, and close stories against a short security Definition of Done.
- Abuse case library: tests and controls by feature
Recurring abuse cases for sign-up and login, password reset, MFA enrolment, invites, file upload, payments and coupons, webhooks, search, export, admin and AI chat or agents: the attacker goal, preconditions, a concrete test and the control, each linked to CWE and CAPEC.
- GDPR privacy by design for engineers: Articles 25, 32 and 35 in code
Turn GDPR data protection by design and by default, security of processing and DPIA triggers into engineering work: a personal-data inventory checked in CI, defaults that collect and share less, a DPIA screen at design time, and access and erasure requests that reach every store.
Also part of this phase
- Cyber Resilience Act and payment pages: turn product-security obligations into an engineering evidence plan
Determine the relevant actor, product, market and requirement before connecting CRA or payment-security expectations to implementation work.
- Turn NIST AI RMF, ISO/IEC 42001 and EU AI Act duties into engineering evidence
What the NIST AI RMF and its Generative AI Profile, ISO/IEC 42001 and the EU AI Act, as amended in 2026, ask of teams that build AI features, turned into engineering practices and one set of evidence. Not legal advice.
- NIS2 and DORA for software suppliers: what reaches you and the evidence to keep
Work out whether NIS2 applies to your software company directly or only through customers, what Article 21 risk-management measures and DORA's ICT third-party rules ask of suppliers, and how to keep one assurance pack and register data sheet for both.
- Regulated product security lifecycles: IEC 62443-4-1, FDA 524B, ISO/SAE 21434 and UN R155/R156
What the secure development lifecycles for industrial, medical and automotive products require, the practices they share (threat modeling, SBOM, vulnerability handling and updates), and how to build that evidence once and package it for each instrument.