APP-002 Security Requirements in Design
Description
Information security and privacy requirements are identified, documented, and approved before development or procurement of any application or system component. Security requirements are derived from risk assessment outcomes, regulatory obligations, and threat modelling. Requirements are traceable through to implementation and testing.
Rationale
Security requirements that are defined upfront are far cheaper to implement than those identified post-design. Traceability ensures requirements are not dropped during implementation.
Framework Mappings (4)
| AIS-02 | Application Security Baseline Requirements | full |
| 8.26 | Application security requirements | full |
| SA-4 | Acquisition Process | full |
| SA-8 | Security and Privacy Engineering Principles | partial |
Evidence (2)
Security requirements specification or design artefacts for a recent project showing that security and privacy requirements were documented and approved before development began.
Example: Jira epic or design document for a recent feature (last 6 months) with a dedicated security requirements section, showing the requirements were written before the first development sprint began and were reviewed/approved by a security or architecture stakeholder.
Test: Select 2–3 recently completed development projects from the past 6 months. For each, verify: (1) a security requirements artefact exists (threat model, security user stories, or design review record), (2) the artefact is dated before or at the start of the first development sprint, (3) a named approver (security lead, architect, or equivalent) has reviewed it, (4) the requirements include at least one control derived from a regulatory or risk input (e.g. data classification, threat model output).
Threat model or risk assessment output for a significant system or feature, demonstrating that security requirements were derived from a structured analysis of threats.
Example: Threat model document, STRIDE worksheet, or architecture risk assessment (e.g. produced using OWASP Threat Dragon or a structured design review template) for a system in production or developed in the last 12 months, showing identified threats and the corresponding security requirements raised.
Test: Request a threat model or risk assessment for a current or recently launched system. Verify: (1) the model identifies specific threats relevant to the system, (2) each identified threat maps to at least one security requirement or mitigating control in the backlog or design document, (3) the model was produced before or during the design phase (not retrospectively), (4) a named author and reviewer are identified.
Questions (2)
Are information security and privacy requirements formally identified, documented, and approved before development begins on new applications or significant features?
Requirements must be documented before the first development sprint — not derived after implementation. Traceability from requirement to implementation and testing is expected.
How are security requirements derived for new development work?
Requirements derived from threat modelling and risk assessments are most robust. Ad hoc approaches without a defined method introduce inconsistency and gaps.