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).
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.
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).
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).
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.
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).
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).
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).
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).
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 policies that support the practical application of this chapter
Formal policies required to ensure the security, reversibility and traceability of deployments in production.
Formal policies that sustain the governance, exception and supplier management practices described in this chapter
Policies required to support logging, detection and continuous response practices.
Formal policies required to legitimise and operationalise the continuous validation of application security.
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).
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).
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.
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).
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).
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).
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.
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.
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.