Organisational Policies - Security Requirements

The effective adoption of Chapter 02 - Security Requirements - requires the existence of formal organisational policies that frame, legitimise and sustain the application of the practices described in this chapter.

---

📌 Fundamental note

⚠️ The operational practices prescribed in this chapter (catalogue, risk-based selection, traceability, acceptance criteria) must be formally legitimised by approved organisational policies.

These policies:

• Make the application of security requirements from the start of development binding;
• Allow the controls applied to be proportional to the identified risk;
• Serve as the normative basis for internal audits, technical reviews and contracting with third parties.

🧩 This chapter implements, in practice, what the policies define. The policy approves, the chapter operationalises.

📎 The requirement for formal policies on security requirements is explicitly referred to in frameworks such as NIST SSDF, ISO/IEC 27001, OWASP SAMM, ENISA SDLC and CIS Controls v8 - these policies are not just good practice, they are a normative expectation.

---

🧾 Recommended policies

Policy Name	Mandatory?	Application	Summary of required content
Application Security Requirements Policy	✅ Yes	All projects and product teams	Mandatory catalogue, risk-based selection, traceability, acceptance criteria
Policy on the Integration of Requirements into the Backlog	⚠️ Optional	Development team, PO, QA	Requirements must appear in the planning artefacts (stories/tasks) with tags
Policy on the Validation of Requirements in Pipelines	⚠️ Optional	DevOps, QA, security	Minimum automated criteria for blocking builds and validating releases
Traceability and Audit Policy	⚠️ Optional	Critical apps, audited contexts	Requirement→control→validation mapping; traceable evidence for audit
Security Exception Management Policy	✅ Yes	All applications	Formal process of justification, recording, deadline and acceptance of exceptions to requirements

---

🧩 Suggested structure of each policy

Each organisational policy must contain, at a minimum:

• Objective and scope of the policy;
• Scope of application: who, where and when it applies;
• Mandatory criteria and rules (e.g. when to apply, how to select requirements, when to review);
• Roles and responsibilities (product team, architecture, security, management);
• Traceability and evidence mechanisms;
• Review periodicity of the policy itself (e.g. annual, with review after incidents).

---

✅ Final recommendations

• Policies must be approved by the security leadership and communicated across the organisation;
• They must be documented, accessible and versioned;
• The existence of these policies is a precondition for:
  • Guaranteeing organisational coherence and maturity;
  • Sustaining security audits or certifications;
  • Serving as the basis for software procurement and supplier assessment processes.

📌 Templates for these policies may be made available as complementary 60-*.md files in future versions of the manual.