4.23 Progressive adoption of the playbooks

The product context, risk management and threat-modelling activities described in Section 2 can be used, together with Playbook 4.1, to identify the most relevant threats, trust boundaries and security objectives. This step can guide prioritisation and scoping as regards the implementation of the playbooks.

Based on the product context, security objectives, and identified risks threats, organisations should establish an appropriate engineering baseline. For most products, an initial baseline should include:

• secure coding and verification practices (Playbook 4.9);
• logging, monitoring and alerting (Playbook 4.10);
• vulnerability and patch management (Playbook 4.13);
• supply-chain controls (Playbook 4.14).

This baseline should be supplemented by the secure by default playbooks relevant to the product. For example:

• restrictive initial access (Playbook 4.16), where the product provides user, administrative or maintenance access;
• secure communication by default (Playbook 4.17), where the product communicates over a network or exchanges data with external components;
• unique device identity and secrets by default (Playbook 4.18), where devices, product instances or services require identities or credentials;
• automated maintenance and updates (Playbook 4.20), where the product can be updated after deployment.

Other playbooks should be prioritised at this stage where they are necessary to address the identified risks, threats and security objectives or product context. For example, availability-sensitive products may require early implementation of the incident response and recovery playbook (Playbook 4.12), while products supporting reset, ownership transfer or decommissioning may require the implementation of the secure recovery and ownership life-cycle playbook (Playbook 4.22).

Progressive adoption could also determine the extent to which an individual playbook is implemented. An organisation could begin with the checklist items that address its priority risks and applicable requirements, and then strengthen coverage, evidence and automation over time.

The remaining applicable playbooks can be implemented and prioritised according to the product context, intended use, deployment context and identified risks and threats. Over time, teams should increase the coverage, consistency and automation. Moreover, progress should be assessed using relevant measures.

This illustrative sequencing is intended to help organisations manage implementation effort. It does not mean that playbooks addressed in a later phase are inherently less important or that applicable security or regulatory requirements may be deferred.