Verification Checklist - Security Requirements
This file provides an objective and auditable list for assessing whether the security requirements have been properly defined, applied and traced throughout the application lifecycle, as prescribed in this chapter.
It can be used as a control instrument per project, per sprint or per risk type.
📋 Verification Items
| Item | Verified? |
|---|---|
| Is there an application security requirements catalogue adapted to the organisation and derived from the canonical SbD-ToE catalogue? | ☐ |
| Was the selection of the requirements applicable to the project made on the basis of the risk classification (L1–L3) and the matrix by level? | ☐ |
| Does each selected requirement have an explicit, verifiable and testable acceptance criterion? | ☐ |
| Is the project's requirements catalogue versioned, with a change history and an identified owner? | ☐ |
Were normalised traceability tags (SEC-Lx-DOMINIO-CODIGO) linked to the canonical ID assigned to the defined requirements? | ☐ |
| Is there a traceability matrix linking risk → requirement → tag → control → validation → evidence, with the control type (Preventive, Detective or Corrective) classified? | ☐ |
| Were the applicable legal, normative and contractual constraints considered in the definition of the requirements? | ☐ |
| Are the security requirements integrated into the backlog or the architecture artefacts as traceable work? | ☐ |
| Is there a process for reviewing and re-versioning the requirements, triggered by material changes, with a new Threat Modelling analysis recorded? | ☐ |
| Was each applicable requirement validated by an adequate method (SAST, DAST, functional security tests, review or CI/CD gate), with independent validation or a blocking gate for critical requirements and evidence linked to the ID? | ☐ |
| Is there a formal exception process with ID, justification, approval, TTL and mandatory revalidation before expiry? | ☐ |
| Is the use of automation or AI-assisted tools authorised, known and covered by internal policy? | ☐ |
| Is all code, configuration or test generated by automation subject to human review and independent technical validation before integration? | ☐ |
Does each AI agent in operational use (A1+) have a documented mandate, versioned in VCS? (REQ-AGN-001) | ☐ |
Is the autonomy level (A0–A4) of each agent classified by context and reassessed on a change of context? (REQ-AGN-002) | ☐ |
Do A2+ AI agents have a documented operational kill-switch, exercised at the defined cadence? (REQ-AGN-003) | ☐ |
Do A2+ AI agents declare their intent (audit event) before each destructive tool-call or one with external effect? (REQ-AGN-004) | ☐ |
Does file handling (upload, content, compressed archives, quota, storage and serving) comply with the FIL-* requirements applicable to the level? | ☐ |
Do personal data have minimisation, time-limited retention, deletion/export capability and a recorded purpose, in accordance with the applicable PRI-* requirements? | ☐ |
Do message-based integrations have idempotent consumers, a DLQ with handling and alerting, replay protection and ordering where required (INT-009…INT-012)? | ☐ |
| Are the RQS indicators for requirements coverage, traceability and validation collected, and do they meet the thresholds for the level? | ☐ |
📌 Recommended use
- This checklist can be used as a verification instrument per project, sprint or release.
- The results can serve as an operational control indicator and a KPI of maturity in applying the SbD-ToE model.
- The existence of a requirements catalogue and its risk-proportional selection must be considered mandatory preconditions for the adoption of the remaining practices.
- Alignment with frameworks such as OWASP SAMM, SSDF and DSOMM reinforces the value of these verifications, especially in the Security Requirements and Reusable Controls domains (see
achievable-maturity).