Method for deriving abuse and misuse cases — cross-functional workshop, adversarial user stories and integration into the requirements backlog. Adversarial elicitation technique that feeds the threat model and the security requirements; it complements structured threat modelling, it does not replace it.
Organisational policy that defines the lifecycle of the mandate of each AI agent in operational use — registration, ownership, autonomy levels A0-A4, tool scope, periodic review and revocation, in alignment with REQ-AGN-001..004 of Ch. 02 and ARC-015 of Ch. 04, proportionate to the criticality level (L1, L2, L3).
Organisational policy that defines the treatment of AI models, datasets, MCP servers/tools, embedded prompts and AI providers as an auditable supply chain — AI BOM generation per build in a standardised format (CycloneDX 1.6 ml-bom), version pinning, a list of approved providers and response to upstream incidents, complementing Policy 10 (dependencies) and Policy 11 (SBOM), proportionate to the criticality level (L1, L2, L3).
Organisational policy that defines the requirements for the configuration, classification, response SLAs, escalation, runbooks and calibration of security and operational alerts, including the prevention of alert fatigue and quality metrics, proportional to the criticality level (L1, L2, L3).
Canonical catalogue of application criticality classification requirements (CLA-001 to CLA-008), with applicability by risk level and acceptance criteria for formal classification, reclassification, residual risk and proportionality of controls.
Organisational policy that defines the mandatory axis-based risk classification model (Exposure, Data, Impact), the moments of application, the review criteria and the formal recording requirements for all applications developed or operated by the organisation.
Traceability model between ARC requirements, threats, architectural decisions and auditable evidence, with a matrix template and update criteria
Validation criteria per requirement (ARC-001 to ARC-013), with methods, moments and owners, organised by risk level
Organisational policy that defines the requirements for operating automatic dependency update bots, including auto-merge criteria, impact analysis, human handoff and configuration proportional to the application's criticality level (L2, L3).
Canonical catalogue of SbD-ToE application security requirements, organised by technical domain, with applicability by risk level (L1–L3) and minimum acceptance criteria for validation, audit and integration into backlogs.
Organisational policy that defines the requirements for code review as a security control point, including a mandatory checklist, approval criteria, reviewer roles, minimum coverage and integration with automated tools, proportional to the criticality level (L1, L2, L3).
Canonical catalogue of security requirements for containers and images (CNT-001 to CNT-012), with applicability by risk level and acceptance criteria for the selection of base images, hardening, signing, scanning, runtime policies and access to registries.
Proportional application of the monitoring and response controls according to the application's risk classification.
Six cross-cutting dimensions for measuring the health of the SbD-ToE programme, aggregating domain indicators from all chapters for executive and risk management visibility.
The single index of all security verification in SbD-ToE — activity × type × oracle × chapter × risk level — distinguishing testing (behavioural oracle) from analysis/scanning (lookup/policy oracle).
Organisational policy that defines the criteria, the formal process, the approval authorities, the compensating controls and the reassessment deadlines applicable to exceptions to known vulnerabilities (CVEs) in software dependencies, proportional to the application's criticality level (L1, L2, L3).
Organisational policy that defines the requirements, execution criteria, findings management and responsibilities for dynamic security testing (DAST) and fuzzing, proportional to the application's risk level.
Canonical catalogue of security requirements for the management of third-party dependencies (DEP-001 to DEP-010), with applicability by risk level and acceptance criteria for SBOM, SCA, library governance and update policies.
Organisational policy that defines the criteria for approving, pinning, blocking, auditing and updating external dependencies in software projects, proportional to the application's criticality level (L1, L2, L3), with a focus on reducing supply chain risk and ensuring traceability.
Organisational policy that defines the requirements for the controlled use of development support tools, including generative AI assistants (GenAI/Copilot) and autonomous agents with tool-use (A0–A4), with a focus on mandatory review of output, traceability, licence validation, autonomy mandates and the maintenance of human responsibility, proportional to the criticality level (L1, L2, L3).
Technical and process indicators specific to the domain of organisational security governance (GOV), with thresholds by risk level and mapping to the cross-cutting governance dimensions of SbD-ToE.
Organisational policy that defines the requirements for the creation, approval, semantic versioning, patching, deprecation and revocation of container base images approved by the organisation (Golden Base Images), including patching SLAs by criticality and management of the internal catalogue, proportional to the criticality level (L1, L2, L3).
Canonical catalogue of organisational security governance requirements (GOV-001 to GOV-017), with applicability by risk level and acceptance criteria for ownership, exceptions, contracting, traceability, continuous validation, maturity, technical onboarding of third parties, access review, coordinated vulnerability disclosure, privileged accounts and identity lifecycle.
Organisational policy that defines the formal process for reviewing and approving IaC execution plans (terraform plan or equivalent) before any apply in staging or production environments, including segregation of duties, plan signing, dual approval and execution windows, proportional to the criticality level (L1, L2, L3).
Canonical catalogue of security requirements for IaC projects (IAC-001 to IAC-013), organised by risk level, with acceptance criteria for the governance of repositories, pipelines, state, modules and configuration drift.
Organisational policy that defines the requirements for integration between security monitoring and the incident response process (IRP), including activation criteria, mandatory playbooks, response phases, regulatory notification, post-mortem and periodic testing, proportional to the criticality level (L1, L2, L3).
Technical and process indicators for assessing the quality, coverage and currency of application risk classification, with thresholds per risk level and mapping to SbD-ToE cross-cutting governance dimensions.
Technical and operational indicators for the assessment of the effectiveness of security controls in container images and orchestration environments, with thresholds by risk level and mapping to the cross-cutting SbD-ToE governance dimensions.
Technical and operational indicators for the assessment of the effectiveness of the controls for dependency management, SBOM generation and software composition analysis, with thresholds per risk level and mapping to the cross-cutting SbD-ToE governance dimensions.
Technical and operational indicators for assessing the effectiveness of security controls in Infrastructure as Code, with thresholds by risk level and mapping to the cross-cutting SbD-ToE governance dimensions.
Technical and operational indicators for the assessment of the effectiveness of the security monitoring programme, with thresholds by risk level and mapping to the cross-cutting SbD-ToE governance dimensions.
Technical and process indicators for assessing the effectiveness of secure architecture controls, with thresholds per risk level and a mapping to the SbD-ToE cross-cutting governance dimensions.
Technical and operational indicators for assessing the effectiveness of security controls in continuous integration and delivery pipelines, with thresholds by risk level and mapping to the cross-cutting SbD-ToE governance dimensions.
Technical and operational indicators for the assessment of the effectiveness of the security controls in the deployment process and release management, with thresholds by risk level and mapping to the cross-cutting SbD-ToE governance dimensions.
Technical and process indicators for the assessment of the effectiveness of secure development controls, with thresholds per risk level and mapping to the cross-cutting SbD-ToE governance dimensions.
Technical and process indicators for assessing the coverage, traceability and effective validation of the security requirements applied by risk level, with mapping to the cross-cutting SbD-ToE governance dimensions.
Technical and operational indicators for the assessment of the effectiveness of the security testing programme, with thresholds by risk level and mapping to the cross-cutting SbD-ToE governance dimensions.
Technical and process indicators for assessing the coverage, quality and integration of threat modelling in the development cycle, with thresholds by risk level and mapping to the cross-cutting SbD-ToE governance dimensions.
Technical and process indicators for the assessment of the effectiveness, coverage and impact of the security training and onboarding programme, with thresholds by risk level and mapping to the cross-cutting SbD-ToE governance dimensions.
The LINDDUN methodology for privacy threat modelling — the seven threat categories, mapping to data flow diagrams and application to any system with personal or regulated data, at all levels. It complements security threat modelling (STRIDE); it does not replace the legal compliance assessment.
Use of MITRE ATT&CK as the reference vocabulary for detection engineering — mapping of detections to adversarial techniques and tactics and measurement of coverage. ATT&CK is a shared vocabulary and a threat-informed reference, not a complete authority nor a checklist for total coverage.
Canonical catalogue of requirements for the security monitoring and operations programme (OPS-001 to OPS-017), with applicability by risk level and acceptance criteria for centralised logging, critical events, retention, SIEM, alerts, response SLA, correlation, integration with the IRP, behavioural detection, effectiveness metrics and continuous operational health signals, backups with tested restore and recovery of the application.
Organisational policy that defines the requirements for the execution of offensive penetration tests (PenTesting), including scope and formal authorisation, test modalities, rules of engagement, minimum report content, the remediation and retest process, cadence by criticality level and integration with the findings process, proportionate to the criticality level (L1, L2, L3).
Organisational policy that defines the requirements for the traceability of security practices throughout the application lifecycle, including a compliance repository per application, designation of security owners, periodic validations per SbD-ToE chapter, auditable evidence and an organisational dashboard, proportionate to the criticality level (L1, L2, L3).
Organisational policy that defines the mandatory cadence and the review triggers for the application risk classification, ensuring that the criticality level and the associated controls remain appropriate to the technical and business context throughout the entire lifecycle of the application.
Organisational policy that defines the requirements for active monitoring after each deploy to production, including a mandatory observation window, minimum health metrics, alert thresholds, human validation and rollback activation criteria, proportional to the criticality level (L1, L2, L3).
The seven phases of the Penetration Testing Execution Standard (PTES) as a methodological depth reference for pentest, anchoring the existing offensive validation requirement. A method reference proportional to risk; neither a certification nor a substitute for regulatory TLPT.
Organisational policy that defines the formal go/no-go decision process for software releases, including approval authorities by criticality level, separation between automatic signal and human decision, formal acceptance of residual risk and recording of evidence, proportional to the criticality level (L1, L2, L3).
Organisational policy that defines the criteria, the formal process, the approval authorities and the traceability requirements for accepting residual risk in applications classified L1 to L3, including risks arising from controls not applied, unfixed findings and threats identified in threat modelling.
Organisational policy that defines the requirements for the rollback capability of deploys in production, including types of rollback by component (binary, configuration, database, infrastructure), activation criteria, RTO by criticality level, periodic testing procedures and traceability, proportional to the criticality level (L1, L2, L3).
Instrument for assessing the adoption of the SbD-ToE model - 96 verification points organised by domain and risk level, derived from the organisational policies. It answers the question "is this team/organisation doing SbD-ToE?" and serves as a tool for self-assessment, internal audit and contractual requirement.
Organisational policy that defines the requirements for the generation, format, signing, provenance, archiving and retention of SBOMs (Software Bill of Materials) in software, container and IaC builds, proportional to the application's criticality level (L1, L2, L3).
Organisational policy that defines the requirements for the storage, injection, rotation, audit and revocation of secrets (keys, tokens, credentials, certificates) in applications, CI/CD pipelines, containers and infrastructure, proportional to the criticality level (L1, L2, L3).
Organisational policy that defines the requirements for applying secure architecture principles throughout the lifecycle of applications classified L2 and L3, including baseline definition, management of architecture decisions (ADR), review of trust boundaries, integration with threat modelling and formal approval requirements.
Canonical catalogue of structural and design security requirements (ARC-001 to ARC-013), organised by risk level, with acceptance criteria for architecture reviews, ADRs and technical audits.
Organisational policy that defines the security requirements for continuous integration and delivery pipelines, including mandatory gates, integrated scanners, environment separation, artefact signing, secrets management in the pipeline and promotion approvals, proportional to the criticality level (L1, L2, L3).
Canonical catalogue of security requirements for continuous integration and delivery pipelines (CIC-001 to CIC-010), with applicability by risk level and acceptance criteria for pipeline design, secrets management, runner isolation, artefact integrity and security gates.
Organisational policy that defines the security requirements for the building, scanning, signing, runtime configuration and management of container images, including securityContext hardening, admission policies in Kubernetes, network isolation and runtime monitoring, proportional to the criticality level (L1, L2, L3).
Organisational policy that defines the security requirements applicable to the contractual lifecycle with suppliers and contractors, including pre-contractual due diligence, minimum contractual clauses by risk level, technical onboarding, compliance monitoring, periodic reassessment and secure offboarding, proportional to the criticality level (L1, L2, L3).
Organisational policy that defines the security requirements for the process of deploying software to production, including verification of signed artefacts, separation of environments, progressive rollout strategies, separation between automation and human authorisation, and end-to-end traceability, proportional to the criticality level (L1, L2, L3).
Canonical catalogue of security requirements for the deployment process (DPL-001 to DPL-011), with applicability by risk level and acceptance criteria for formal approval, artefact provenance, automated gates, rollback, deployment credentials, staging, post-deployment monitoring, release gates for agentic systems and end-to-end traceability.
Organisational policy that defines the requirements for the selection, tailoring, publication, versioning and periodic review of secure development guidelines per technology stack, including the conversion of rules into automatic linter and SAST configurations, proportional to the criticality level (L1, L2, L3).
Canonical catalogue of security requirements for the development process (DEV-001 to DEV-009), with applicability by risk level and acceptance criteria for code guidelines, linters, formal review, exception management, provenance and traceable annotations.
Organisational policy that defines the security requirements for the definition, validation, execution and maintenance of Infrastructure as Code (IaC), including configuration scanning, policy-as-code, environment separation, drift control, approved modules and plan signing, proportional to the criticality level (L1, L2, L3).
Organisational policy that defines the requirements for the formal approval of software releases, including a pre-release security checklist, an automated compliance gate, go/no-go criteria, an immutable decision artefact and end-to-end commit→pipeline→release traceability, proportional to the criticality level (L1, L2, L3).
Cross-cutting organisational policy that defines the formal process for the submission, assessment, approval, recording and reassessment of exceptions to mandatory security controls, with approval authorities proportional to the application's risk level. It applies to all SbD-ToE chapters in which there are controls with formal mandatory status.
Organisational policy that defines the requirements for the definition, collection, analysis and reporting of security governance KPIs, including metric categories, reporting cadence, responsibilities, intervention thresholds and integration with maturity frameworks (SAMM, SSDF), proportionate to the criticality level (L1, L2, L3).
Organisational policy that defines the requirements for security monitoring in production, including the definition of critical events, SIEM integration, behavioural correlation, coverage of monitoring domains and periodic review of detection rules, proportional to the criticality level (L1, L2, L3).
Organisational policy that defines how security requirements must be selected, documented, traced, validated and maintained throughout the lifecycle of each application, proportionally to its classified risk level.
Canonical catalogue of requirements for the security testing programme (TST-001 to TST-010), with applicability by risk level and acceptance criteria for testing strategy, SAST, DAST, findings management, regression, pentesting and auditable evidence.
Organisational policy that defines the requirements for the security testing strategy throughout the application lifecycle, including SAST, DAST, SCA, IAST, fuzzing and manual testing, with mandatory gates, finding triage SLAs and centralised management of results, proportional to the criticality level (L1, L2, L3).
Organisational policy that defines the requirements for the security training and upskilling programme, including mandatory onboarding, training tracks by profile and risk level, the Security Champions programme, practical exercises, content updates, effectiveness KPIs and integration with individual performance objectives, proportionate to the criticality level (L1, L2, L3).
Organisational policy that defines the requirements for the production, formatting, centralisation, retention and protection of application and security logs, including a minimum event schema, mandatory events, masking of sensitive data, immutability and SIEM integration, proportional to the criticality level (L1, L2, L3).
Organisational policy that defines the mandatory nature, methodology, execution triggers, formal approval requirements, traceability and management of threat modelling artefacts throughout the lifecycle of applications classified L2 and L3.
Canonical catalogue of threat modelling requirements (THR-001 to THR-007), with applicability by risk level and acceptance criteria for threat identification, formal disposition, requirement derivation and methodological traceability.
Cross-cutting organisational policy that defines the traceability requirements between requirements, controls, validation evidence, build artefacts and operational events, ensuring that the security posture is auditable continuously and in proportion to the application's risk level.
Canonical catalogue of security training and onboarding requirements (TRN-001 to TRN-009), with applicability by risk level and acceptance criteria for training tracks, verifiable onboarding, Security Champions and training effectiveness.
Remediation prioritisation layer based on the probability of exploitation (EPSS, FIRST.org) and confirmed exploitation (CISA KEV), applied on top of the CVSS-based patching SLAs. EPSS and KEV refine the order of remediation; the SLAs by severity remain as the mandatory floor.