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. A documented threat model is produced for each new system and for each significant change, using a named methodology, and each threat it identifies resolves to a security requirement or a test case. The threat model is reviewed at defined intervals and on significant change, taking account of the current threat landscape for the platforms the system runs on. Where a supplier develops a system or component on the organisation's behalf, the same threat modelling and vulnerability analysis is performed on it during development and testing, and its output is reviewed and accepted before the component is used. Requirements are traceable through to implementation and testing.
Rationale
Security requirements defined upfront are far cheaper to implement than those identified post-design, and traceability keeps them from being dropped during implementation. Naming the methodology matters more than which one is chosen: an unnamed method cannot be reviewed for coverage, and a threat model that never resolves to a requirement or a test case is a document rather than a control. The supplier limb exists because a component built elsewhere carries the same threats and arrives with none of the analysis unless it is asked for.
Applicability (9 profiles)
Framework Mappings (12)
| AIS-02 | Application Security Baseline Requirements | full |
| TVM-04 | Threat Analysis and Modelling | full |
| AIS-02 | Application Security Baseline Requirements | full |
| TVM-04 | Threat Analysis and Modelling | full |
| 8.26 | Application security requirements | full |
| NIS2-CIR-6.2 | Secure Development Life Cycle | informative |
| SA-11(2) | Developer Testing and Evaluation | Threat Modeling and Vulnerability Analyses | full |
| SA-4 | Acquisition Process | full |
| SA-8 | Security and Privacy Engineering Principles | informative |
| GV-3.2-005 | Human-AI Configuration Roles | GV-3.2-005 | full |
| MP-2.2-002 | AI System Knowledge Limits Documentation | MP-2.2-002 | partial |
| MP-5.1-006 | Impact Likelihood and Magnitude Documentation | MP-5.1-006 | full |
Evidence (3)
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 for a significant system or feature, produced to a named methodology, showing each identified threat resolved to a security requirement or a test case.
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 for a current or recently launched system. Verify: (1) the model names the methodology it was built to, (2) it identifies specific threats relevant to the system rather than a generic list, (3) each identified threat maps to at least one security requirement or test case in the backlog or design document, (4) the model was produced before or during the design phase rather than retrospectively, (5) a named author and reviewer are identified, (6) the model's last review falls within the interval the policy sets and reflects changes in the platforms the system runs on.
Supplier threat modelling and vulnerability analysis output for a component developed on the organisation's behalf, with the organisation's acceptance of it.
Example: Supplier threat model and vulnerability analysis, ingest-connector v3.1, accepted 2026-06-02
Test: Select a component a supplier developed in the last 12 months. Verify: (1) a threat model and a vulnerability analysis for the component are on file, (2) both are dated within the component's development and testing period rather than after delivery, (3) the methodology used matches the one the organisation's own standard names or a stated equivalent, (4) an acceptance record from the organisation pre-dates the component's first production use, (5) findings the supplier raised resolve to a remediation or a recorded acceptance.
Questions (3)
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.
For which development work is a documented threat model produced?
Options run strongest to weakest. Coverage of supplier-built components is the limb most often missing: the threats are the same and the analysis arrives only if the agreement asks for it. A threat model produced after the design is settled tests documentation rather than design.