Cross-reference
AI Cyber Security Code of Practice
51 items: 35 met directly by a control at Level 3, 16 partly, 0 deliberately out of scope.
| Ref | Item (our description) | Controls | Note |
|---|---|---|---|
| 1.1 | Include AI security content in the cyber security training programme, kept current and tailored to role (System Operators, Developers, Data Custodians) | PPL-05 direct, PPL-01 partial, SEC-05 partial | PPL-05 Level 3 requires pathways for roles that build, run, buy or secure AI to include AI security, with secure design and development for builders, reviewed when significant new threats emerge. That is the role-tailored AI security content of 1.1 and 1.1.1. PPL-01 carries AI security threats into the all-staff baseline and SEC-05 trains incident responders. |
| 1.2 | Keep all staff aware of current AI security threats and vulnerabilities and their mitigations (System Operators, Developers, Data Custodians) | PPL-01 direct, CUL-02 partial, PPL-05 partial | PPL-01 Level 3 requires the literacy baseline to cover AI security threats relevant to all staff, kept current with updates on new threats; CUL-02 regular communication is one of the channels 1.2.1 suggests. Developer training in secure AI coding (1.2.2) is met by PPL-05's secure design and development content for builders. |
| 2.1 | When deciding to create an AI system, document the business need with its AI security risks and mitigations (System Operators, Developers) | SEC-02 direct, RSK-02 partial, POR-05 partial, DAT-02 partial | SEC-02 Level 3 requires AI-specific threats to be assessed for every use, with findings recorded and shaping design; RSK-02 brings the assessment into the approval decision and records treatment with reasons; POR-05 documents the business need. Including the data owner in requirements discussions (2.1.1) rests on DAT-02 owners approving use. |
| 2.2 | Design and build AI systems to withstand adversarial attacks, unexpected inputs and failure (Developers, System Operators) | SEC-01 partial, SEC-02 partial, TEC-06 partial, SEC-06 partial, OPM-09 partial | The baseline (SEC-01) and threat model (SEC-02) set the security requirements, TEC-06 tests robustness, SEC-06 security tests against the threat model and tests attempts to bypass safeguards, and OPM-09 handles failure safely. Resilience to adversarial attack as a design requirement is technical detail left to the baseline by design. |
| 2.3 | Keep documentation and an audit trail of the operation and lifecycle of models, data sets and prompts (Developers) | TEC-05 direct, DAT-08 partial, DAT-06 partial, MON-02 partial, SEC-01 partial | TEC-05 Level 3 versions models, prompts and configuration through a controlled, approved release, and versions data sets alongside each model version, which gives the lifecycle audit trail for models, data sets and prompts. DAT-08 records the source of training and test data, and the operational trail comes from MON-02 event logging, DAT-06 system logs and SEC-01 logs that support investigating AI-specific attacks. Changes made to data during preparation are captured only through the versioned data sets, not step by step. |
| 2.4 | Assess the AI security risks of any external component through due diligence (Developers, System Operators) | SEC-03 direct, RSK-09 partial | SEC-03 Level 3 assesses the security of every external model, data set and component before use, including freely downloaded ones. |
| 2.5 | Make sure a system's intended use suits the sensitivity of the data it was trained on and the controls protecting it (Data Custodians) | SEC-04 direct, DAT-02 partial, DAT-07 partial, DAT-05 partial, CUL-04 partial | SEC-04 Level 3 requires models trained or tuned on protected information to be handled at least at that protection level, taking account of aggregation, so a model's audience and use cannot go beyond what its training data allows. DAT-02 gives the data owner a defined role in approving use, DAT-07 limits access to the agreed purpose and DAT-05 checks purpose compatibility. Encouraging staff to report AI security risks (2.5.1) is met by CUL-04, a no-blame route for any AI concern. |
| 2.6 | Limit and risk assess the permissions an AI system is given on other systems and data sources (Developers, System Operators) | TEC-04 direct, DAT-07 partial, SEC-02 partial | TEC-04 Level 3 limits the permissions and actions an AI system or agent holds on other systems to what its purpose needs, approved and risk assessed. DAT-07 does the same for access to data, and SEC-02's threat model covers misuse of connected tools. |
| 2.7 | Carry out due diligence on external providers and expect them to follow this Code (Developers, System Operators) | RSK-09 direct, SEC-03 direct, OPM-04 partial | RSK-09 Level 3 is standard due diligence on supplier AI, including assurance, and SEC-03 sets security expectations for suppliers. Expecting adherence to this Code is met where the baseline adopted under SEC-01 is this Code or one built on it, and SEC-03 carries it to suppliers. |
| 3.1 | Analyse threats, including AI-specific attacks, and manage the security risks, reviewing on change (Developers, System Operators) | SEC-02 direct, RSK-02 partial, RSK-01 partial | SEC-02 Level 3 covers AI-specific threats for every use before live and again when it changes, which includes new settings or configuration (3.1.1); regular review as new threats emerge is Level 4. Choosing controls in line with cost and corporate risk tolerance (3.1.3) is RSK-02's recorded treatment against the RSK-01 appetite. Managing risk from superfluous model functions (3.1.2) is a developer design point not named, left to the baseline. |
| 3.2 | Pass on security threats the developer cannot resolve, from developer to operator and from operator to end-users (Developers, System Operators) | PPL-08 direct, TEC-05 partial, RSK-09 partial, CUL-02 partial | PPL-08 Level 3 requires guidance for each approved tool to state its known limitations, failure modes and residual security risks, with what users should do, and users to be told promptly of security-relevant changes. RSK-09 obtains the provider's instructions for use, which is how a developer's unresolved threats reach the organisation, and TEC-05 documentation states known limitations and where the AI must not be relied on, for people outside the organisation who use AI it provides. |
| 3.3 | Get assurance that external parties responsible for AI security risks in the organisation's infrastructure can address them (System Operators) | SEC-03 partial, RSK-09 partial, OPM-05 partial | RSK-09 gathers the assurance a supplier offers at due diligence and SEC-03 sets security expectations; reviewing supplier security on a set cycle is SEC-03 Level 4. Missing at Level 3: assurance sought for specific security risks the organisation has found and a third party owns, such as a managed service or hosting provider. |
| 3.4 | Monitor and review system infrastructure continuously according to risk appetite, accepting that residual risk remains (Developers, System Operators) | SEC-01 direct, MON-02 partial, RSK-02 partial, RSK-01 partial, SEC-04 partial | SEC-01 Level 3 puts every live use of AI within security monitoring, with logs that support detecting and investigating AI-specific attacks, at a depth set by risk. RSK-02 records the residual risk accepted against the RSK-01 appetite, MON-02 monitors for misuse and unexpected behaviour, and SEC-04 monitors leakage at Level 4. |
| 4.1 | Build in and maintain the ability for humans to oversee the AI system (Developers, System Operators) | RSK-07 direct, TEC-04 partial | RSK-07 Level 3 sets a documented oversight model for every use, with the authority to override or stop; TEC-04 makes integrations able to be switched off. |
| 4.2 | Design systems so humans can readily assess the outputs they are responsible for, for example through explainability (Developers) | TEC-02 direct, RSK-07 partial, RSK-08 partial | TEC-02 Level 3 reference patterns, applied through design review with departures approved, build in explainability and traceability of outputs; RSK-07 requires reviewers to have the information they need and RSK-08 gives affected people an explanation. |
| 4.3 | Where human oversight is a risk control, design, verify and maintain technical measures that make it work (Developers, System Operators) | RSK-07 partial, RSK-02 partial, TEC-06 partial | RSK-02 records oversight where it is the chosen control, RSK-07 designs the oversight model and tests the design before go-live to show reviewers can detect problems and intervene in time. Still missing: maintaining the technical measures that support oversight through the life of the system, and verifying those measures as such rather than the oversight arrangement as a whole. |
| 4.4 | Verify that the security controls the data custodian specified have been built into the system (Developers) | SEC-01 partial, DAT-07 partial, SEC-06 partial | DAT-07 access rules are approved by the data owner and SEC-01 applies the baseline before go-live, with conformance checked at Level 4; SEC-06 security tests each release against the threat model. Missing: verifying before release that the data owner's security requirements are in place. |
| 4.5 | Make end-users aware of the uses of the AI system that are prohibited (Developers, System Operators) | TEC-01 direct, GOV-01 partial, PPL-01 partial, TEC-05 partial | TEC-01 Level 3 publishes the permitted uses of each approved tool to all staff and GOV-01 communicates prohibited uses. For people outside the organisation who use AI it provides, TEC-05 documentation states where the AI must not be used or relied on. |
| 5.1 | Keep a comprehensive inventory of AI assets and their interdependencies (Developers, System Operators, Data Custodians) | GOV-06 direct, TEC-07 partial, DAT-04 partial, TEC-04 partial, SEC-03 partial, TEC-05 partial | GOV-06 Level 3 links each inventory entry to its models, data sets and integrations, which joins the asset picture held by TEC-07 (model, supplier and platform dependencies), DAT-04 (data catalogue), TEC-04 (integrations and data flows) and SEC-03 (external components). Prompts are held as versioned configuration under TEC-05. |
| 5.2 | Have processes and tools to track, authenticate, version and secure AI assets (Developers, System Operators, Data Custodians) | TEC-05 partial, SEC-03 partial, DAT-08 partial, SEC-01 partial | TEC-05 versions models, prompts and configuration, SEC-03 and DAT-08 record where components and data came from. Authenticating assets (integrity checks such as hashes) and securing them are technical detail left to the SEC-01 baseline. |
| 5.3 | Tailor disaster recovery plans to attacks aimed at AI systems, able to restore a known good state (System Operators) | SEC-05 direct, TEC-05 partial, OPM-09 partial | SEC-05 Level 3 requires playbooks to cover recovery from AI-specific attacks to a known good state, linked to continuity plans; TEC-05 can roll every live use back to a known good version (5.3.1) and OPM-09 puts fallbacks into continuity plans. |
| 5.4 | Protect sensitive data, such as training and test data, against unauthorised access (Developers, System Operators, Data Custodians, End-users) | DAT-07 direct, SEC-04 partial, DAT-03 partial, SEC-01 partial | DAT-07 Level 3 limits access by each AI system and its users to what the purpose needs, approved by the data owner; SEC-04 protects sensitive information in prompts and outputs. Checking and sanitising data and inputs, repeated when the model is revised (5.4.1), and protecting confidential training data and weights (5.4.2) are technical detail left to the baseline; DAT-03 checks quality, not malicious content. |
| 6.1 | Review access control and secure APIs, models, data and training and processing pipelines (Developers, System Operators) | DAT-07 partial, SEC-01 partial, TEC-02 partial, TEC-04 partial | DAT-07 covers least privilege access to data and TEC-02 and TEC-04 govern architecture and integrations. Securing APIs, models and pipelines is technical detail left to the SEC-01 baseline by design. |
| 6.2 | Where an API is offered to outside users, apply controls against attacks through it, such as rate limits (Developers) | SEC-01 partial, SEC-02 partial | Applies when the organisation offers AI to others. SEC-02 threat modelling should find attacks through the API and SEC-01 brings in the baseline; the specific API controls are technical detail left to the baseline. |
| 6.3 | Use separate, least privilege environments for development and tuning, with non-public training data kept in them (Developers) | POR-06 partial, DAT-07 partial, SEC-01 partial, TEC-01 partial | POR-06 sets approved environments and data limits for experiments, TEC-01 approves the environments used to build, test and run AI, each with an owner, and DAT-07 limits access to data. Dedicated, separated development and tuning environments are technical detail left to the baseline. |
| 6.4 | Implement and publish a clear, accessible vulnerability disclosure policy (Developers, System Operators) | SEC-05 direct, CUL-04 partial | SEC-05 Level 3 requires a published vulnerability disclosure route covering the organisation's AI services, with reports feeding incident handling. CUL-04 is the internal route for concerns. |
| 6.5 | Create, test and maintain an AI incident management plan and an AI recovery plan (Developers, System Operators) | SEC-05 direct, OPM-09 partial, TEC-05 partial | SEC-05 Level 3 has AI scenarios, playbooks, trained responders and a way to contain each service (the incident plan), and covers recovery from AI-specific attacks to a known good state and exercises AI scenarios on a set cycle; OPM-09 tests fallbacks on a set cycle at Level 3. TEC-05 rollback supports recovery. |
| 6.6 | Make sure contracts with cloud service providers support these infrastructure requirements (Developers, System Operators) | OPM-04 direct, SEC-03 partial, TEC-03 partial | OPM-04 Level 3 terms set security requirements and the split of security responsibilities, incident notification, access to logs, audit rights or accepted assurance and operational resilience in every relevant procurement, which covers cloud providers; SEC-03 sets supplier security expectations and TEC-03 checks hosting. |
| 7.1 | Follow secure software supply chain processes for AI model and system development (Developers, System Operators) | SEC-03 direct, SEC-01 partial | SEC-03 Level 3 is a defined process for the security of every external model, data set and component, with source recorded; tracking versions in use is Level 4. Specific techniques such as software bills of materials are left to the baseline. |
| 7.2 | Justify in writing any use of poorly documented or secured models or components, with mitigations and a risk assessment (System Operators, Developers) | SEC-03 partial, RSK-02 partial, GOV-08 partial, SEC-01 partial, PPL-08 partial | SEC-03 assesses each component, RSK-02 records the treatment and controls with reasons (7.2.1), and GOV-08 records approved exceptions, with each exception's risk and treatment; a register of baseline gaps with risk acceptance is SEC-01 evidence at Level 4. No control asks specifically for a written justification when a component falls short of security expectations. Sharing that documentation with end users (7.2.2) is met by PPL-08, whose tool guidance states residual security risks. |
| 7.3 | Re-run evaluations on released models the organisation intends to use (Developers, System Operators) | TEC-06 direct, RSK-09 partial, TEC-05 partial | TEC-06 Level 3 tests against criteria agreed in advance before every release, including models from others; detecting supplier model updates is TEC-05 Level 4. |
| 7.4 | Tell end-users in an accessible way before models are updated (System Operators) | TEC-05 direct, OPM-07 partial, CUL-02 partial | TEC-05 Level 3 requires users to be told in advance, accessibly, of planned changes that affect them, alongside controlled release of model changes; OPM-07 runs change management. |
| 8.1 | Document system design and post-deployment maintenance plans with an audit trail, and share them downstream (Developers) | TEC-05 partial, TEC-02 partial, DAT-08 partial, RSK-09 partial | TEC-05 keeps documentation for each version, which states intended purpose and users, how it works, inputs and outputs, known limitations and where it must not be relied on; TEC-02 records design decisions, DAT-08 records data sources, and RSK-09 obtains the provider's instructions for use when the organisation is the operator. Still not set: guardrails, retention time, suggested review frequency and failure modes in that documentation (8.1.1), a maintenance plan as such, and releasing cryptographic hashes for model components (8.1.2), which is left to the baseline. |
| 8.2 | Document how publicly sourced training data was obtained, where from and how it is used (Developers) | DAT-08 direct, SEC-03 partial | DAT-08 Level 3 records source, collection method, rights and use limits for every training, tuning and test data set before use, linked to the models that used it. The minimum detail suggested in 8.2.1 (source address and date obtained) is the level of detail the record should hold, not named in the control. |
| 8.3 | Keep an audit log of changes to system prompts and other model configuration (Developers) | TEC-05 direct, OPM-07 partial | TEC-05 Level 3 versions models, prompts and configuration and releases them through a controlled process with approval; OPM-07 change management covers prompt changes. |
| 9.1 | Security test every model, application and system before release to operators or users (Developers) | SEC-06 direct, TEC-06 partial, SEC-01 partial, SEC-02 partial | SEC-06 Level 3 security tests every release against the threats in the threat model; TEC-06 tests accuracy, robustness and behaviour and signs off results before every release, SEC-02 supplies the threat model and SEC-01 applies the baseline before go-live. |
| 9.2 | Test before deployment, with the developer's support and ideally independent security testers (System Operators) | SEC-06 direct, TEC-06 partial, MON-05 partial, RSK-09 partial | SEC-06 Level 3 security tests every release before deployment, by testers with the right skills who are independent of the build team for higher-risk uses, which meets 9.2.1; TEC-06 covers the wider testing before release. Developer support for the operator's testing rests on RSK-09 due diligence, and MON-05 adds independent assurance by risk tier. |
| 9.3 | Share testing and evaluation findings with system operators to inform their own testing (Developers) | RSK-09 partial, TEC-06 partial | Where the organisation is the operator, RSK-09 gathers the assurance a supplier offers; where it builds AI for its own use, TEC-06 records and signs off results. Missing: asking suppliers for their test findings, and passing test results on when the organisation provides AI to others. |
| 9.4 | Check that outputs do not let users reverse engineer the model or training data, or gain unintended influence over the system (Developers) | SEC-06 partial, SEC-04 partial, SEC-02 partial, MON-02 partial | SEC-06 tests attempts to bypass safeguards and that personal or sensitive information is not disclosed, MON-02 monitors outputs for personal or sensitive data in live use, and SEC-04 protects against outputs revealing information; SEC-02 threat models include manipulated inputs (9.4.1). Still missing: checking that outputs do not allow the model itself to be reverse engineered; testing for model extraction is technical detail left to the baseline. |
| 10.1 | Tell end-users accessibly where and how their data will be used, accessed and stored, including retraining and human review (System Operators; Developers to supply the information) | DAT-05 direct, TEC-01 partial, RSK-09 partial, GOV-09 partial | DAT-05 Level 3 requires people whose data or inputs an AI system uses to be told, accessibly, how they are used, accessed and stored, including any retraining and review by staff or suppliers. RSK-09 learns from suppliers how they use data, which is the information developers supply; TEC-01 tells staff which data may be used with each tool. |
| 10.2 | Give end-users accessible guidance on using and configuring the AI, with limitations, failure modes and security updates (System Operators; Developers to supply the information) | PPL-08 direct, TEC-01 partial, TEC-05 partial, PPL-01 partial | PPL-08 Level 3 gives guidance for all approved tools and requires it to state known limitations, failure modes and residual security risks with what to do, and users to be told promptly of security-relevant changes, which meets 10.2.1 and 10.2.2. TEC-01 states conditions of use and TEC-05 documentation serves people outside the organisation. |
| 10.3 | Support end-users and affected entities to contain and limit the impact of a cyber security incident, with the process agreed in contracts (Developers, System Operators) | SEC-05 direct, MON-04 partial, OPM-04 partial | SEC-05 Level 3 requires playbooks to support affected users and other parties through an incident, set out in agreements where the organisation provides AI to others. |
| 11.1 | Developers provide and notify security updates; operators deliver them to end-users; contingency where updates cannot be provided (Developers, System Operators) | TEC-05 partial, OPM-07 partial, TEC-07 partial, RSK-09 partial, PPL-08 partial | TEC-05 and OPM-07 release changes under control, RSK-09 reassesses on supplier model change, and TEC-07 plans for models and platforms that lose support, which is the contingency in 11.1.1. Users are told promptly of security-relevant changes through PPL-08. Still missing: obtaining security updates from suppliers and applying them promptly, which is general security practice left to the baseline. |
| 11.2 | Treat major AI system updates as a new version, with new security testing and evaluation (Developers) | SEC-06 direct, TEC-06 partial, TEC-05 partial, SEC-02 partial | SEC-06 Level 3 security tests every release against the threat model and TEC-06 re-runs evaluation against the acceptance criteria before every release; TEC-05 controls each release and SEC-02 re-assesses threats on change, so a major update gets new security testing and evaluation. |
| 11.3 | Help operators evaluate and respond to model changes, for example with preview access and versioned APIs (Developers) | OPM-04 partial, TEC-07 partial, RSK-09 partial | OPM-04 contract terms give notice of model changes, TEC-07 plans for supplier change and RSK-09 reassesses on change. Asking suppliers for preview access or versioned interfaces, and offering them when the organisation provides AI to others, is not required. |
| 12.1 | Log system and user actions to support security compliance, incident investigation and fixing vulnerabilities (System Operators) | SEC-01 direct, MON-02 partial, DAT-06 partial, SEC-05 partial | SEC-01 Level 3 requires logs for every live use that support detecting and investigating AI-specific attacks; MON-02 enables event logging while in use, DAT-06 keeps system logs at least as long as the law requires, and SEC-05 uses them in incident handling. Logging of user actions is not named separately; it is part of the logging an investigation needs. |
| 12.2 | Analyse logs to confirm models still produce the desired outputs and to detect anomalies, breaches, drift or poisoning (System Operators) | SEC-01 direct, MON-02 partial, SEC-04 partial | MON-02 Level 3 monitors accuracy, drift, misuse and unexpected behaviour against thresholds, and SEC-01 places every live use within security monitoring, with logs that support detecting AI-specific attacks such as poisoning; SEC-04 detects attempted exposure at Level 4. |
| 12.3 | Monitor internal states of AI systems where this helps address security threats or future security analytics (System Operators, Developers) | MON-02 partial, SEC-01 partial | MON-02 monitors behaviour from outside; monitoring internal model states is technical detail left to the baseline. |
| 12.4 | Monitor model and system performance over time to detect sudden or gradual changes that could affect security (System Operators, Developers) | MON-02 direct, TEC-05 partial | MON-02 Level 3 monitors every live use for accuracy, drift and unexpected behaviour against thresholds, with named responders; detecting unplanned supplier model changes is TEC-05 Level 4. |
| 13.1 | When transferring or sharing ownership of training data or a model, involve data custodians and dispose securely (Developers, System Operators) | DAT-07 partial, DAT-02 partial, POR-09 partial | DAT-07 sharing with other organisations follows documented agreements approved by the data owner (DAT-02), and POR-09 covers disposal at retirement. Missing: secure disposal of the organisation's copies when a model or training data is transferred rather than retired. |
| 13.2 | When decommissioning a model or system, involve data custodians and securely delete data and configuration (Developers, System Operators) | POR-09 direct, DAT-06 partial, DAT-02 partial | POR-09 Level 3 is a retirement process covering records and disposal or retention of models and data; DAT-06 sets deletion rules and DAT-02 gives the data owner a defined role. Secure deletion methods, and configuration such as system prompts and credentials, are left to the baseline. |
References and short descriptions only; see the source publication for its own text. The cross-reference is the author's interpretation and is not endorsed by the publisher. See notices.