# NIST framework reference

Canonical page: https://vikrammohan.com/thought-leadership/nist-framework-reference/

The NIST Cybersecurity Framework 2.0 and AI Risk Management Framework 1.0, searchable, in NIST's own words.

The framework text comes from NIST's own exports, downloaded on 6 October 2026: the CSF 2.0 Core with its implementation examples, without the CSF 1.1 legacy elements, and the AI RMF 1.0 with the AI RMF Playbook. See the sources and counts.

Spelling: American spellings in the NIST Cybersecurity Framework (CSF) 2.0 and AI RMF 1.0 text have been changed to British English, for example organisation, authorise and behaviour. The National Institute of Standards and Technology name, function names, tier names and identifiers are unchanged.

## NIST Cybersecurity Framework (CSF) 2.0

### GV: GOVERN

The organisation's cybersecurity risk management strategy, expectations, and policy are established, communicated, and monitored

#### GV.OC: Organisational Context

The circumstances - mission, stakeholder expectations, dependencies, and legal, regulatory, and contractual requirements - surrounding the organisation's cybersecurity risk management decisions are understood

- **GV.OC-01** The organisational mission is understood and informs cybersecurity risk management
  - Ex1: Share the organisation's mission (e.g., through vision and mission statements, marketing, and service strategies) to provide a basis for identifying risks that may impede that mission
- **GV.OC-02** Internal and external stakeholders are understood, and their needs and expectations regarding cybersecurity risk management are understood and considered
  - Ex1: Identify relevant internal stakeholders and their cybersecurity-related expectations (e.g., performance and risk expectations of officers, directors, and advisors; cultural expectations of employees)
  - Ex2: Identify relevant external stakeholders and their cybersecurity-related expectations (e.g., privacy expectations of customers, business expectations of partnerships, compliance expectations of regulators, ethics expectations of society)
- **GV.OC-03** Legal, regulatory, and contractual requirements regarding cybersecurity - including privacy and civil liberties obligations - are understood and managed
  - Ex1: Determine a process to track and manage legal and regulatory requirements regarding protection of individuals' information (e.g., Health Insurance Portability and Accountability Act, California Consumer Privacy Act, General Data Protection Regulation)
  - Ex2: Determine a process to track and manage contractual requirements for cybersecurity management of supplier, customer, and partner information
  - Ex3: Align the organisation's cybersecurity strategy with legal, regulatory, and contractual requirements
- **GV.OC-04** Critical objectives, capabilities, and services that external stakeholders depend on or expect from the organisation are understood and communicated
  - Ex1: Establish criteria for determining the criticality of capabilities and services as viewed by internal and external stakeholders
  - Ex2: Determine (e.g., from a business impact analysis) assets and business operations that are vital to achieving mission objectives and the potential impact of a loss (or partial loss) of such operations
  - Ex3: Establish and communicate resilience objectives (e.g., recovery time objectives) for delivering critical capabilities and services in various operating states (e.g., under attack, during recovery, normal operation)
- **GV.OC-05** Outcomes, capabilities, and services that the organisation depends on are understood and communicated
  - Ex1: Create an inventory of the organisation's dependencies on external resources (e.g., facilities, cloud-based hosting providers) and their relationships to organisational assets and business functions
  - Ex2: Identify and document external dependencies that are potential points of failure for the organisation's critical capabilities and services, and share that information with appropriate personnel

#### GV.OV: Oversight

Results of organisation-wide cybersecurity risk management activities and performance are used to inform, improve, and adjust the risk management strategy

- **GV.OV-01** Cybersecurity risk management strategy outcomes are reviewed to inform and adjust strategy and direction
  - Ex1: Measure how well the risk management strategy and risk results have helped leaders make decisions and achieve organisational objectives
  - Ex2: Examine whether cybersecurity risk strategies that impede operations or innovation should be adjusted
- **GV.OV-02** The cybersecurity risk management strategy is reviewed and adjusted to ensure coverage of organisational requirements and risks
  - Ex1: Review audit findings to confirm whether the existing cybersecurity strategy has ensured compliance with internal and external requirements
  - Ex2: Review the performance oversight of those in cybersecurity-related roles to determine whether policy changes are necessary
  - Ex3: Review strategy in light of cybersecurity incidents
- **GV.OV-03** Organisational cybersecurity risk management performance is evaluated and reviewed for adjustments needed
  - Ex1: Review key performance indicators (KPIs) to ensure that organisation-wide policies and procedures achieve objectives
  - Ex2: Review key risk indicators (KRIs) to identify risks the organisation faces, including likelihood and potential impact
  - Ex3: Collect and communicate metrics on cybersecurity risk management with senior leadership

#### GV.PO: Policy

Organisational cybersecurity policy is established, communicated, and enforced

- **GV.PO-01** Policy for managing cybersecurity risks is established based on organisational context, cybersecurity strategy, and priorities and is communicated and enforced
  - Ex1: Create, disseminate, and maintain an understandable, usable risk management policy with statements of management intent, expectations, and direction
  - Ex2: Periodically review policy and supporting processes and procedures to ensure that they align with risk management strategy objectives and priorities, as well as the high-level direction of the cybersecurity policy
  - Ex3: Require approval from senior management on policy
  - Ex4: Communicate cybersecurity risk management policy and supporting processes and procedures across the organisation
  - Ex5: Require personnel to acknowledge receipt of policy when first hired, annually, and whenever policy is updated
- **GV.PO-02** Policy for managing cybersecurity risks is reviewed, updated, communicated, and enforced to reflect changes in requirements, threats, technology, and organisational mission
  - Ex1: Update policy based on periodic reviews of cybersecurity risk management results to ensure that policy and supporting processes and procedures adequately maintain risk at an acceptable level
  - Ex2: Provide a timeline for reviewing changes to the organisation's risk environment (e.g., changes in risk or in the organisation's mission objectives), and communicate recommended policy updates
  - Ex3: Update policy to reflect changes in legal and regulatory requirements
  - Ex4: Update policy to reflect changes in technology (e.g., adoption of artificial intelligence) and changes to the business (e.g., acquisition of a new business, new contract requirements)

#### GV.RM: Risk Management Strategy

The organisation's priorities, constraints, risk tolerance and appetite statements, and assumptions are established, communicated, and used to support operational risk decisions

- **GV.RM-01** Risk management objectives are established and agreed to by organisational stakeholders
  - Ex1: Update near-term and long-term cybersecurity risk management objectives as part of annual strategic planning and when major changes occur
  - Ex2: Establish measurable objectives for cybersecurity risk management (e.g., manage the quality of user training, ensure adequate risk protection for industrial control systems)
  - Ex3: Senior leaders agree about cybersecurity objectives and use them for measuring and managing risk and performance
- **GV.RM-02** Risk appetite and risk tolerance statements are established, communicated, and maintained
  - Ex1: Determine and communicate risk appetite statements that convey expectations about the appropriate level of risk for the organisation
  - Ex2: Translate risk appetite statements into specific, measurable, and broadly understandable risk tolerance statements
  - Ex3: Refine organisational objectives and risk appetite periodically based on known risk exposure and residual risk
- **GV.RM-03** Cybersecurity risk management activities and outcomes are included in enterprise risk management processes
  - Ex1: Aggregate and manage cybersecurity risks alongside other enterprise risks (e.g., compliance, financial, operational, regulatory, reputational, safety)
  - Ex2: Include cybersecurity risk managers in enterprise risk management planning
  - Ex3: Establish criteria for escalating cybersecurity risks within enterprise risk management
- **GV.RM-04** Strategic direction that describes appropriate risk response options is established and communicated
  - Ex1: Specify criteria for accepting and avoiding cybersecurity risk for various classifications of data
  - Ex2: Determine whether to purchase cybersecurity insurance
  - Ex3: Document conditions under which shared responsibility models are acceptable (e.g., outsourcing certain cybersecurity functions, having a third party perform financial transactions on behalf of the organisation, using public cloud-based services)
- **GV.RM-05** Lines of communication across the organisation are established for cybersecurity risks, including risks from suppliers and other third parties
  - Ex1: Determine how to update senior executives, directors, and management on the organisation's cybersecurity posture at agreed-upon intervals
  - Ex2: Identify how all departments across the organisation - such as management, operations, internal auditors, legal, acquisition, physical security, and HR - will communicate with each other about cybersecurity risks
- **GV.RM-06** A standardised method for calculating, documenting, categorising, and prioritising cybersecurity risks is established and communicated
  - Ex1: Establish criteria for using a quantitative approach to cybersecurity risk analysis, and specify probability and exposure formulas
  - Ex2: Create and use templates (e.g., a risk register) to document cybersecurity risk information (e.g., risk description, exposure, treatment, and ownership)
  - Ex3: Establish criteria for risk prioritisation at the appropriate levels within the enterprise
  - Ex4: Use a consistent list of risk categories to support integrating, aggregating, and comparing cybersecurity risks
- **GV.RM-07** Strategic opportunities (i.e., positive risks) are characterised and are included in organisational cybersecurity risk discussions
  - Ex1: Define and communicate guidance and methods for identifying opportunities and including them in risk discussions (e.g., strengths, weaknesses, opportunities, and threats [SWOT] analysis)
  - Ex2: Identify stretch goals and document them
  - Ex3: Calculate, document, and prioritise positive risks alongside negative risks

#### GV.RR: Roles, Responsibilities, and Authorities

Cybersecurity roles, responsibilities, and authorities to foster accountability, performance assessment, and continuous improvement are established and communicated

- **GV.RR-01** Organisational leadership is responsible and accountable for cybersecurity risk and fosters a culture that is risk-aware, ethical, and continually improving
  - Ex1: Leaders (e.g., directors) agree on their roles and responsibilities in developing, implementing, and assessing the organisation's cybersecurity strategy
  - Ex2: Share leaders' expectations regarding a secure and ethical culture, especially when current events present the opportunity to highlight positive or negative examples of cybersecurity risk management
  - Ex3: Leaders direct the CISO to maintain a comprehensive cybersecurity risk strategy and review and update it at least annually and after major events
  - Ex4: Conduct reviews to ensure adequate authority and coordination among those responsible for managing cybersecurity risk
- **GV.RR-02** Roles, responsibilities, and authorities related to cybersecurity risk management are established, communicated, understood, and enforced
  - Ex1: Document risk management roles and responsibilities in policy
  - Ex2: Document who is responsible and accountable for cybersecurity risk management activities and how those teams and individuals are to be consulted and informed
  - Ex3: Include cybersecurity responsibilities and performance requirements in personnel descriptions
  - Ex4: Document performance goals for personnel with cybersecurity risk management responsibilities, and periodically measure performance to identify areas for improvement
  - Ex5: Clearly articulate cybersecurity responsibilities within operations, risk functions, and internal audit functions
- **GV.RR-03** Adequate resources are allocated commensurate with the cybersecurity risk strategy, roles, responsibilities, and policies
  - Ex1: Conduct periodic management reviews to ensure that those given cybersecurity risk management responsibilities have the necessary authority
  - Ex2: Identify resource allocation and investment in line with risk tolerance and response
  - Ex3: Provide adequate and sufficient people, process, and technical resources to support the cybersecurity strategy
- **GV.RR-04** Cybersecurity is included in human resources practices
  - Ex1: Integrate cybersecurity risk management considerations into human resources processes (e.g., personnel screening, onboarding, change notification, offboarding)
  - Ex2: Consider cybersecurity knowledge to be a positive factor in hiring, training, and retention decisions
  - Ex3: Conduct background checks prior to onboarding new personnel for sensitive roles, and periodically repeat background checks for personnel with such roles
  - Ex4: Define and enforce obligations for personnel to be aware of, adhere to, and uphold security policies as they relate to their roles

#### GV.SC: Cybersecurity Supply Chain Risk Management

Cyber supply chain risk management processes are identified, established, managed, monitored, and improved by organisational stakeholders

- **GV.SC-01** A cybersecurity supply chain risk management programme, strategy, objectives, policies, and processes are established and agreed to by organisational stakeholders
  - Ex1: Establish a strategy that expresses the objectives of the cybersecurity supply chain risk management programme
  - Ex2: Develop the cybersecurity supply chain risk management programme, including a plan (with milestones), policies, and procedures that guide implementation and improvement of the programme, and share the policies and procedures with the organisational stakeholders
  - Ex3: Develop and implement programme processes based on the strategy, objectives, policies, and procedures that are agreed upon and performed by the organisational stakeholders
  - Ex4: Establish a cross-organisational mechanism that ensures alignment between functions that contribute to cybersecurity supply chain risk management, such as cybersecurity, IT, operations, legal, human resources, and engineering
- **GV.SC-02** Cybersecurity roles and responsibilities for suppliers, customers, and partners are established, communicated, and coordinated internally and externally
  - Ex1: Identify one or more specific roles or positions that will be responsible and accountable for planning, resourcing, and executing cybersecurity supply chain risk management activities
  - Ex2: Document cybersecurity supply chain risk management roles and responsibilities in policy
  - Ex3: Create responsibility matrixes to document who will be responsible and accountable for cybersecurity supply chain risk management activities and how those teams and individuals will be consulted and informed
  - Ex4: Include cybersecurity supply chain risk management responsibilities and performance requirements in personnel descriptions to ensure clarity and improve accountability
  - Ex5: Document performance goals for personnel with cybersecurity risk management-specific responsibilities, and periodically measure them to demonstrate and improve performance
  - Ex6: Develop roles and responsibilities for suppliers, customers, and business partners to address shared responsibilities for applicable cybersecurity risks, and integrate them into organisational policies and applicable third-party agreements
  - Ex7: Internally communicate cybersecurity supply chain risk management roles and responsibilities for third parties
  - Ex8: Establish rules and protocols for information sharing and reporting processes between the organisation and its suppliers
- **GV.SC-03** Cybersecurity supply chain risk management is integrated into cybersecurity and enterprise risk management, risk assessment, and improvement processes
  - Ex1: Identify areas of alignment and overlap with cybersecurity and enterprise risk management
  - Ex2: Establish integrated control sets for cybersecurity risk management and cybersecurity supply chain risk management
  - Ex3: Integrate cybersecurity supply chain risk management into improvement processes
  - Ex4: Escalate material cybersecurity risks in supply chains to senior management, and address them at the enterprise risk management level
- **GV.SC-04** Suppliers are known and prioritised by criticality
  - Ex1: Develop criteria for supplier criticality based on, for example, the sensitivity of data processed or possessed by suppliers, the degree of access to the organisation's systems, and the importance of the products or services to the organisation's mission
  - Ex2: Keep a record of all suppliers, and prioritise suppliers based on the criticality criteria
- **GV.SC-05** Requirements to address cybersecurity risks in supply chains are established, prioritised, and integrated into contracts and other types of agreements with suppliers and other relevant third parties
  - Ex1: Establish security requirements for suppliers, products, and services commensurate with their criticality level and potential impact if compromised
  - Ex2: Include all cybersecurity and supply chain requirements that third parties must follow and how compliance with the requirements may be verified in default contractual language
  - Ex3: Define the rules and protocols for information sharing between the organisation and its suppliers and sub-tier suppliers in agreements
  - Ex4: Manage risk by including security requirements in agreements based on their criticality and potential impact if compromised
  - Ex5: Define security requirements in service-level agreements (SLAs) for monitoring suppliers for acceptable security performance throughout the supplier relationship lifecycle
  - Ex6: Contractually require suppliers to disclose cybersecurity features, functions, and vulnerabilities of their products and services for the life of the product or the term of service
  - Ex7: Contractually require suppliers to provide and maintain a current component inventory (e.g., software or hardware bill of materials) for critical products
  - Ex8: Contractually require suppliers to vet their employees and guard against insider threats
  - Ex9: Contractually require suppliers to provide evidence of performing acceptable security practices through, for example, self-attestation, conformance to known standards, certifications, or inspections
  - Ex10: Specify in contracts and other agreements the rights and responsibilities of the organisation, its suppliers, and their supply chains, with respect to potential cybersecurity risks
- **GV.SC-06** Planning and due diligence are performed to reduce risks before entering into formal supplier or other third-party relationships
  - Ex1: Perform thorough due diligence on prospective suppliers that is consistent with procurement planning and commensurate with the level of risk, criticality, and complexity of each supplier relationship
  - Ex2: Assess the suitability of the technology and cybersecurity capabilities and the risk management practices of prospective suppliers
  - Ex3: Conduct supplier risk assessments against business and applicable cybersecurity requirements
  - Ex4: Assess the authenticity, integrity, and security of critical products prior to acquisition and use
- **GV.SC-07** The risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritised, assessed, responded to, and monitored over the course of the relationship
  - Ex1: Adjust assessment formats and frequencies based on the third party's reputation and the criticality of the products or services they provide
  - Ex2: Evaluate third parties' evidence of compliance with contractual cybersecurity requirements, such as self-attestations, warranties, certifications, and other artifacts
  - Ex3: Monitor critical suppliers to ensure that they are fulfilling their security obligations throughout the supplier relationship lifecycle using a variety of methods and techniques, such as inspections, audits, tests, or other forms of evaluation
  - Ex4: Monitor critical suppliers, services, and products for changes to their risk profiles, and reevaluate supplier criticality and risk impact accordingly
  - Ex5: Plan for unexpected supplier and supply chain-related interruptions to ensure business continuity
- **GV.SC-08** Relevant suppliers and other third parties are included in incident planning, response, and recovery activities
  - Ex1: Define and use rules and protocols for reporting incident response and recovery activities and the status between the organisation and its suppliers
  - Ex2: Identify and document the roles and responsibilities of the organisation and its suppliers for incident response
  - Ex3: Include critical suppliers in incident response exercises and simulations
  - Ex4: Define and coordinate crisis communication methods and protocols between the organisation and its critical suppliers
  - Ex5: Conduct collaborative lessons learned sessions with critical suppliers
- **GV.SC-09** Supply chain security practices are integrated into cybersecurity and enterprise risk management programmes, and their performance is monitored throughout the technology product and service life cycle
  - Ex1: Policies and procedures require provenance records for all acquired technology products and services
  - Ex2: Periodically provide risk reporting to leaders about how acquired components are proven to be untampered and authentic
  - Ex3: Communicate regularly among cybersecurity risk managers and operations personnel about the need to acquire software patches, updates, and upgrades only from authenticated and trustworthy software providers
  - Ex4: Review policies to ensure that they require approved supplier personnel to perform maintenance on supplier products
  - Ex5: Policies and procedure require checking upgrades to critical hardware for unauthorised changes
- **GV.SC-10** Cybersecurity supply chain risk management plans include provisions for activities that occur after the conclusion of a partnership or service agreement
  - Ex1: Establish processes for terminating critical relationships under both normal and adverse circumstances
  - Ex2: Define and implement plans for component end-of-life maintenance support and obsolescence
  - Ex3: Verify that supplier access to organisation resources is deactivated promptly when it is no longer needed
  - Ex4: Verify that assets containing the organisation's data are returned or properly disposed of in a timely, controlled, and safe manner
  - Ex5: Develop and execute a plan for terminating or transitioning supplier relationships that takes supply chain security risk and resiliency into account
  - Ex6: Mitigate risks to data and systems created by supplier termination
  - Ex7: Manage data leakage risks associated with supplier termination

### ID: IDENTIFY

The organisation's current cybersecurity risks are understood

#### ID.AM: Asset Management

Assets (e.g., data, hardware, software, systems, facilities, services, people) that enable the organisation to achieve business purposes are identified and managed consistent with their relative importance to organisational objectives and the organisation's risk strategy

- **ID.AM-01** Inventories of hardware managed by the organisation are maintained
  - Ex1: Maintain inventories for all types of hardware, including IT, IoT, OT, and mobile devices
  - Ex2: Constantly monitor networks to detect new hardware and automatically update inventories
- **ID.AM-02** Inventories of software, services, and systems managed by the organisation are maintained
  - Ex1: Maintain inventories for all types of software and services, including commercial-off-the-shelf, open-source, custom applications, API services, and cloud-based applications and services
  - Ex2: Constantly monitor all platforms, including containers and virtual machines, for software and service inventory changes
  - Ex3: Maintain an inventory of the organisation's systems
- **ID.AM-03** Representations of the organisation's authorised network communication and internal and external network data flows are maintained
  - Ex1: Maintain baselines of communication and data flows within the organisation's wired and wireless networks
  - Ex2: Maintain baselines of communication and data flows between the organisation and third parties
  - Ex3: Maintain baselines of communication and data flows for the organisation's infrastructure-as-a-service (IaaS) usage
  - Ex4: Maintain documentation of expected network ports, protocols, and services that are typically used among authorised systems
- **ID.AM-04** Inventories of services provided by suppliers are maintained
  - Ex1: Inventory all external services used by the organisation, including third-party infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS), and software-as-a-service (SaaS) offerings; APIs; and other externally hosted application services
  - Ex2: Update the inventory when a new external service is going to be utilised to ensure adequate cybersecurity risk management monitoring of the organisation's use of that service
- **ID.AM-05** Assets are prioritised based on classification, criticality, resources, and impact on the mission
  - Ex1: Define criteria for prioritising each class of assets
  - Ex2: Apply the prioritisation criteria to assets
  - Ex3: Track the asset priorities and update them periodically or when significant changes to the organisation occur
- **ID.AM-07** Inventories of data and corresponding metadata for designated data types are maintained
  - Ex1: Maintain a list of the designated data types of interest (e.g., personally identifiable information, protected health information, financial account numbers, organisation intellectual property, operational technology data)
  - Ex2: Continuously discover and analyse ad hoc data to identify new instances of designated data types
  - Ex3: Assign data classifications to designated data types through tags or labels
  - Ex4: Track the provenance, data owner, and geolocation of each instance of designated data types
- **ID.AM-08** Systems, hardware, software, services, and data are managed throughout their life cycles
  - Ex1: Integrate cybersecurity considerations throughout the life cycles of systems, hardware, software, and services
  - Ex2: Integrate cybersecurity considerations into product life cycles
  - Ex3: Identify unofficial uses of technology to meet mission objectives (i.e., shadow IT)
  - Ex4: Periodically identify redundant systems, hardware, software, and services that unnecessarily increase the organisation's attack surface
  - Ex5: Properly configure and secure systems, hardware, software, and services prior to their deployment in production
  - Ex6: Update inventories when systems, hardware, software, and services are moved or transferred within the organisation
  - Ex7: Securely destroy stored data based on the organisation's data retention policy using the prescribed destruction method, and keep and manage a record of the destructions
  - Ex8: Securely sanitise data storage when hardware is being retired, decommissioned, reassigned, or sent for repairs or replacement
  - Ex9: Offer methods for destroying paper, storage media, and other physical forms of data storage

#### ID.IM: Improvement

Improvements to organisational cybersecurity risk management processes, procedures and activities are identified across all CSF Functions

- **ID.IM-01** Improvements are identified from evaluations
  - Ex1: Perform self-assessments of critical services that take current threats and TTPs into consideration
  - Ex2: Invest in third-party assessments or independent audits of the effectiveness of the organisation's cybersecurity programme to identify areas that need improvement
  - Ex3: Constantly evaluate compliance with selected cybersecurity requirements through automated means
- **ID.IM-02** Improvements are identified from security tests and exercises, including those done in coordination with suppliers and relevant third parties
  - Ex1: Identify improvements for future incident response activities based on findings from incident response assessments (e.g., tabletop exercises and simulations, tests, internal reviews, independent audits)
  - Ex2: Identify improvements for future business continuity, disaster recovery, and incident response activities based on exercises performed in coordination with critical service providers and product suppliers
  - Ex3: Involve internal stakeholders (e.g., senior executives, legal department, HR) in security tests and exercises as appropriate
  - Ex4: Perform penetration testing to identify opportunities to improve the security posture of selected high-risk systems as approved by leadership
  - Ex5: Exercise contingency plans for responding to and recovering from the discovery that products or services did not originate with the contracted supplier or partner or were altered before receipt
  - Ex6: Collect and analyse performance metrics using security tools and services to inform improvements to the cybersecurity programme
- **ID.IM-03** Improvements are identified from execution of operational processes, procedures, and activities
  - Ex1: Conduct collaborative lessons learned sessions with suppliers
  - Ex2: Annually review cybersecurity policies, processes, and procedures to take lessons learned into account
  - Ex3: Use metrics to assess operational cybersecurity performance over time
- **ID.IM-04** Incident response plans and other cybersecurity plans that affect operations are established, communicated, maintained, and improved
  - Ex1: Establish contingency plans (e.g., incident response, business continuity, disaster recovery) for responding to and recovering from adverse events that can interfere with operations, expose confidential information, or otherwise endanger the organisation's mission and viability
  - Ex2: Include contact and communication information, processes for handling common scenarios, and criteria for prioritisation, escalation, and elevation in all contingency plans
  - Ex3: Create a vulnerability management plan to identify and assess all types of vulnerabilities and to prioritise, test, and implement risk responses
  - Ex4: Communicate cybersecurity plans (including updates) to those responsible for carrying them out and to affected parties
  - Ex5: Review and update all cybersecurity plans annually or when a need for significant improvements is identified

#### ID.RA: Risk Assessment

The cybersecurity risk to the organisation, assets, and individuals is understood by the organisation

- **ID.RA-01** Vulnerabilities in assets are identified, validated, and recorded
  - Ex1: Use vulnerability management technologies to identify unpatched and misconfigured software
  - Ex2: Assess network and system architectures for design and implementation weaknesses that affect cybersecurity
  - Ex3: Review, analyse, or test organisation-developed software to identify design, coding, and default configuration vulnerabilities
  - Ex4: Assess facilities that house critical computing assets for physical vulnerabilities and resilience issues
  - Ex5: Monitor sources of cyber threat intelligence for information on new vulnerabilities in products and services
  - Ex6: Review processes and procedures for weaknesses that could be exploited to affect cybersecurity
- **ID.RA-02** Cyber threat intelligence is received from information sharing forums and sources
  - Ex1: Configure cybersecurity tools and technologies with detection or response capabilities to securely ingest cyber threat intelligence feeds
  - Ex2: Receive and review advisories from reputable third parties on current threat actors and their tactics, techniques, and procedures (TTPs)
  - Ex3: Monitor sources of cyber threat intelligence for information on the types of vulnerabilities that emerging technologies may have
- **ID.RA-03** Internal and external threats to the organisation are identified and recorded
  - Ex1: Use cyber threat intelligence to maintain awareness of the types of threat actors likely to target the organisation and the TTPs they are likely to use
  - Ex2: Perform threat hunting to look for signs of threat actors within the environment
  - Ex3: Implement processes for identifying internal threat actors
- **ID.RA-04** Potential impacts and likelihoods of threats exploiting vulnerabilities are identified and recorded
  - Ex1: Business leaders and cybersecurity risk management practitioners work together to estimate the likelihood and impact of risk scenarios and record them in risk registers
  - Ex2: Enumerate the potential business impacts of unauthorised access to the organisation's communications, systems, and data processed in or by those systems
  - Ex3: Account for the potential impacts of cascading failures for systems of systems
- **ID.RA-05** Threats, vulnerabilities, likelihoods, and impacts are used to understand inherent risk and inform risk response prioritisation
  - Ex1: Develop threat models to better understand risks to the data and identify appropriate risk responses
  - Ex2: Prioritise cybersecurity resource allocations and investments based on estimated likelihoods and impacts
- **ID.RA-06** Risk responses are chosen, prioritised, planned, tracked, and communicated
  - Ex1: Apply the vulnerability management plan's criteria for deciding whether to accept, transfer, mitigate, or avoid risk
  - Ex2: Apply the vulnerability management plan's criteria for selecting compensating controls to mitigate risk
  - Ex3: Track the progress of risk response implementation (e.g., plan of action and milestones [POA&M], risk register, risk detail report)
  - Ex4: Use risk assessment findings to inform risk response decisions and actions
  - Ex5: Communicate planned risk responses to affected stakeholders in priority order
- **ID.RA-07** Changes and exceptions are managed, assessed for risk impact, recorded, and tracked
  - Ex1: Implement and follow procedures for the formal documentation, review, testing, and approval of proposed changes and requested exceptions
  - Ex2: Document the possible risks of making or not making each proposed change, and provide guidance on rolling back changes
  - Ex3: Document the risks related to each requested exception and the plan for responding to those risks
  - Ex4: Periodically review risks that were accepted based upon planned future actions or milestones
- **ID.RA-08** Processes for receiving, analysing, and responding to vulnerability disclosures are established
  - Ex1: Conduct vulnerability information sharing between the organisation and its suppliers following the rules and protocols defined in contracts
  - Ex2: Assign responsibilities and verify the execution of procedures for processing, analysing the impact of, and responding to cybersecurity threat, vulnerability, or incident disclosures by suppliers, customers, partners, and government cybersecurity organisations
- **ID.RA-09** The authenticity and integrity of hardware and software are assessed prior to acquisition and use
  - Ex1: Assess the authenticity and cybersecurity of critical technology products and services prior to acquisition and use
- **ID.RA-10** Critical suppliers are assessed prior to acquisition
  - Ex1: Conduct supplier risk assessments against business and applicable cybersecurity requirements, including the supply chain

### PR: PROTECT

Safeguards to manage the organisation's cybersecurity risks are used

#### PR.AA: Identity Management, Authentication, and Access Control

Access to physical and logical assets is limited to authorised users, services, and hardware and managed commensurate with the assessed risk of unauthorised access

- **PR.AA-01** Identities and credentials for authorised users, services, and hardware are managed by the organisation
  - Ex1: Initiate requests for new access or additional access for employees, contractors, and others, and track, review, and fulfill the requests, with permission from system or data owners when needed
  - Ex2: Issue, manage, and revoke cryptographic certificates and identity tokens, cryptographic keys (i.e., key management), and other credentials
  - Ex3: Select a unique identifier for each device from immutable hardware characteristics or an identifier securely provisioned to the device
  - Ex4: Physically label authorised hardware with an identifier for inventory and servicing purposes
- **PR.AA-02** Identities are proofed and bound to credentials based on the context of interactions
  - Ex1: Verify a person's claimed identity at enrollment time using government-issued identity credentials (e.g., passport, visa, driver's license)
  - Ex2: Issue a different credential for each person (i.e., no credential sharing)
- **PR.AA-03** Users, services, and hardware are authenticated
  - Ex1: Require multifactor authentication
  - Ex2: Enforce policies for the minimum strength of passwords, PINs, and similar authenticators
  - Ex3: Periodically reauthenticate users, services, and hardware based on risk (e.g., in zero trust architectures)
  - Ex4: Ensure that authorised personnel can access accounts essential for protecting safety under emergency conditions
- **PR.AA-04** Identity assertions are protected, conveyed, and verified
  - Ex1: Protect identity assertions that are used to convey authentication and user information through single sign-on systems
  - Ex2: Protect identity assertions that are used to convey authentication and user information between federated systems
  - Ex3: Implement standards-based approaches for identity assertions in all contexts, and follow all guidance for the generation (e.g., data models, metadata), protection (e.g., digital signing, encryption), and verification (e.g., signature validation) of identity assertions
- **PR.AA-05** Access permissions, entitlements, and authorisations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties
  - Ex1: Review logical and physical access privileges periodically and whenever someone changes roles or leaves the organisation, and promptly rescind privileges that are no longer needed
  - Ex2: Take attributes of the requester and the requested resource into account for authorisation decisions (e.g., geolocation, day/time, requester endpoint's cyber health)
  - Ex3: Restrict access and privileges to the minimum necessary (e.g., zero trust architecture)
  - Ex4: Periodically review the privileges associated with critical business functions to confirm proper separation of duties
- **PR.AA-06** Physical access to assets is managed, monitored, and enforced commensurate with risk
  - Ex1: Use security guards, security cameras, locked entrances, alarm systems, and other physical controls to monitor facilities and restrict access
  - Ex2: Employ additional physical security controls for areas that contain high-risk assets
  - Ex3: Escort guests, vendors, and other third parties within areas that contain business-critical assets

#### PR.AT: Awareness and Training

The organisation's personnel are provided with cybersecurity awareness and training so that they can perform their cybersecurity-related tasks

- **PR.AT-01** Personnel are provided with awareness and training so that they possess the knowledge and skills to perform general tasks with cybersecurity risks in mind
  - Ex1: Provide basic cybersecurity awareness and training to employees, contractors, partners, suppliers, and all other users of the organisation's non-public resources
  - Ex2: Train personnel to recognise social engineering attempts and other common attacks, report attacks and suspicious activity, comply with acceptable use policies, and perform basic cyber hygiene tasks (e.g., patching software, choosing passwords, protecting credentials)
  - Ex3: Explain the consequences of cybersecurity policy violations, both to individual users and the organisation as a whole
  - Ex4: Periodically assess or test users on their understanding of basic cybersecurity practices
  - Ex5: Require annual refreshers to reinforce existing practices and introduce new practices
- **PR.AT-02** Individuals in specialised roles are provided with awareness and training so that they possess the knowledge and skills to perform relevant tasks with cybersecurity risks in mind
  - Ex1: Identify the specialised roles within the organisation that require additional cybersecurity training, such as physical and cybersecurity personnel, finance personnel, senior leadership, and anyone with access to business-critical data
  - Ex2: Provide role-based cybersecurity awareness and training to all those in specialised roles, including contractors, partners, suppliers, and other third parties
  - Ex3: Periodically assess or test users on their understanding of cybersecurity practices for their specialised roles
  - Ex4: Require annual refreshers to reinforce existing practices and introduce new practices

#### PR.DS: Data Security

Data are managed consistent with the organisation's risk strategy to protect the confidentiality, integrity, and availability of information

- **PR.DS-01** The confidentiality, integrity, and availability of data-at-rest are protected
  - Ex1: Use encryption, digital signatures, and cryptographic hashes to protect the confidentiality and integrity of stored data in files, databases, virtual machine disk images, container images, and other resources
  - Ex2: Use full disk encryption to protect data stored on user endpoints
  - Ex3: Confirm the integrity of software by validating signatures
  - Ex4: Restrict the use of removable media to prevent data exfiltration
  - Ex5: Physically secure removable media containing unencrypted sensitive information, such as within locked offices or file cabinets
- **PR.DS-02** The confidentiality, integrity, and availability of data-in-transit are protected
  - Ex1: Use encryption, digital signatures, and cryptographic hashes to protect the confidentiality and integrity of network communications
  - Ex2: Automatically encrypt or block outbound emails and other communications that contain sensitive data, depending on the data classification
  - Ex3: Block access to personal email, file sharing, file storage services, and other personal communications applications and services from organisational systems and networks
  - Ex4: Prevent reuse of sensitive data from production environments (e.g., customer records) in development, testing, and other non-production environments
- **PR.DS-10** The confidentiality, integrity, and availability of data-in-use are protected
  - Ex1: Remove data that must remain confidential (e.g., from processors and memory) as soon as it is no longer needed
  - Ex2: Protect data in use from access by other users and processes of the same platform
- **PR.DS-11** Backups of data are created, protected, maintained, and tested
  - Ex1: Continuously back up critical data in near-real-time, and back up other data frequently at agreed-upon schedules
  - Ex2: Test backups and restores for all types of data sources at least annually
  - Ex3: Securely store some backups offline and offsite so that an incident or disaster will not damage them
  - Ex4: Enforce geographic separation and geolocation restrictions for data backup storage

#### PR.IR: Technology Infrastructure Resilience

Security architectures are managed with the organisation's risk strategy to protect asset confidentiality, integrity, and availability, and organisational resilience

- **PR.IR-01** Networks and environments are protected from unauthorised logical access and usage
  - Ex1: Logically segment organisation networks and cloud-based platforms according to trust boundaries and platform types (e.g., IT, IoT, OT, mobile, guests), and permit required communications only between segments
  - Ex2: Logically segment organisation networks from external networks, and permit only necessary communications to enter the organisation's networks from the external networks
  - Ex3: Implement zero trust architectures to restrict network access to each resource to the minimum necessary
  - Ex4: Check the cyber health of endpoints before allowing them to access and use production resources
- **PR.IR-02** The organisation's technology assets are protected from environmental threats
  - Ex1: Protect organisational equipment from known environmental threats, such as flooding, fire, wind, and excessive heat and humidity
  - Ex2: Include protection from environmental threats and provisions for adequate operating infrastructure in requirements for service providers that operate systems on the organisation's behalf
- **PR.IR-03** Mechanisms are implemented to achieve resilience requirements in normal and adverse situations
  - Ex1: Avoid single points of failure in systems and infrastructure
  - Ex2: Use load balancing to increase capacity and improve reliability
  - Ex3: Use high-availability components like redundant storage and power supplies to improve system reliability
- **PR.IR-04** Adequate resource capacity to ensure availability is maintained
  - Ex1: Monitor usage of storage, power, compute, network bandwidth, and other resources
  - Ex2: Forecast future needs, and scale resources accordingly

#### PR.PS: Platform Security

The hardware, software (e.g., firmware, operating systems, applications), and services of physical and virtual platforms are managed consistent with the organisation's risk strategy to protect their confidentiality, integrity, and availability

- **PR.PS-01** Configuration management practices are established and applied
  - Ex1: Establish, test, deploy, and maintain hardened baselines that enforce the organisation's cybersecurity policies and provide only essential capabilities (i.e., principle of least functionality)
  - Ex2: Review all default configuration settings that may potentially impact cybersecurity when installing or upgrading software
  - Ex3: Monitor implemented software for deviations from approved baselines
- **PR.PS-02** Software is maintained, replaced, and removed commensurate with risk
  - Ex1: Perform routine and emergency patching within the timeframes specified in the vulnerability management plan
  - Ex2: Update container images, and deploy new container instances to replace rather than update existing instances
  - Ex3: Replace end-of-life software and service versions with supported, maintained versions
  - Ex4: Uninstall and remove unauthorised software and services that pose undue risks
  - Ex5: Uninstall and remove any unnecessary software components (e.g., operating system utilities) that attackers might misuse
  - Ex6: Define and implement plans for software and service end-of-life maintenance support and obsolescence
- **PR.PS-03** Hardware is maintained, replaced, and removed commensurate with risk
  - Ex1: Replace hardware when it lacks needed security capabilities or when it cannot support software with needed security capabilities
  - Ex2: Define and implement plans for hardware end-of-life maintenance support and obsolescence
  - Ex3: Perform hardware disposal in a secure, responsible, and auditable manner
- **PR.PS-04** Log records are generated and made available for continuous monitoring
  - Ex1: Configure all operating systems, applications, and services (including cloud-based services) to generate log records
  - Ex2: Configure log generators to securely share their logs with the organisation's logging infrastructure systems and services
  - Ex3: Configure log generators to record the data needed by zero-trust architectures
- **PR.PS-05** Installation and execution of unauthorised software are prevented
  - Ex1: When risk warrants it, restrict software execution to permitted products only or deny the execution of prohibited and unauthorised software
  - Ex2: Verify the source of new software and the software's integrity before installing it
  - Ex3: Configure platforms to use only approved DNS services that block access to known malicious domains
  - Ex4: Configure platforms to allow the installation of organisation-approved software only
- **PR.PS-06** Secure software development practices are integrated, and their performance is monitored throughout the software development life cycle
  - Ex1: Protect all components of organisation-developed software from tampering and unauthorised access
  - Ex2: Secure all software produced by the organisation, with minimal vulnerabilities in their releases
  - Ex3: Maintain the software used in production environments, and securely dispose of software once it is no longer needed

### DE: DETECT

Possible cybersecurity attacks and compromises are found and analysed

#### DE.AE: Adverse Event Analysis

Anomalies, indicators of compromise, and other potentially adverse events are analysed to characterise the events and detect cybersecurity incidents

- **DE.AE-02** Potentially adverse events are analysed to better understand associated activities
  - Ex1: Use security information and event management (SIEM) or other tools to continuously monitor log events for known malicious and suspicious activity
  - Ex2: Utilise up-to-date cyber threat intelligence in log analysis tools to improve detection accuracy and characterise threat actors, their methods, and indicators of compromise
  - Ex3: Regularly conduct manual reviews of log events for technologies that cannot be sufficiently monitored through automation
  - Ex4: Use log analysis tools to generate reports on their findings
- **DE.AE-03** Information is correlated from multiple sources
  - Ex1: Constantly transfer log data generated by other sources to a relatively small number of log servers
  - Ex2: Use event correlation technology (e.g., SIEM) to collect information captured by multiple sources
  - Ex3: Utilise cyber threat intelligence to help correlate events among log sources
- **DE.AE-04** The estimated impact and scope of adverse events are understood
  - Ex1: Use SIEMs or other tools to estimate impact and scope, and review and refine the estimates
  - Ex2: A person creates their own estimates of impact and scope
- **DE.AE-06** Information on adverse events is provided to authorised staff and tools
  - Ex1: Use cybersecurity software to generate alerts and provide them to the security operations centre (SOC), incident responders, and incident response tools
  - Ex2: Incident responders and other authorised personnel can access log analysis findings at all times
  - Ex3: Automatically create and assign tickets in the organisation's ticketing system when certain types of alerts occur
  - Ex4: Manually create and assign tickets in the organisation's ticketing system when technical staff discover indicators of compromise
- **DE.AE-07** Cyber threat intelligence and other contextual information are integrated into the analysis
  - Ex1: Securely provide cyber threat intelligence feeds to detection technologies, processes, and personnel
  - Ex2: Securely provide information from asset inventories to detection technologies, processes, and personnel
  - Ex3: Rapidly acquire and analyse vulnerability disclosures for the organisation's technologies from suppliers, vendors, and third-party security advisories
- **DE.AE-08** Incidents are declared when adverse events meet the defined incident criteria
  - Ex1: Apply incident criteria to known and assumed characteristics of activity in order to determine whether an incident should be declared
  - Ex2: Take known false positives into account when applying incident criteria

#### DE.CM: Continuous Monitoring

Assets are monitored to find anomalies, indicators of compromise, and other potentially adverse events

- **DE.CM-01** Networks and network services are monitored to find potentially adverse events
  - Ex1: Monitor DNS, BGP, and other network services for adverse events
  - Ex2: Monitor wired and wireless networks for connections from unauthorised endpoints
  - Ex3: Monitor facilities for unauthorised or rogue wireless networks
  - Ex4: Compare actual network flows against baselines to detect deviations
  - Ex5: Monitor network communications to identify changes in security postures for zero trust purposes
- **DE.CM-02** The physical environment is monitored to find potentially adverse events
  - Ex1: Monitor logs from physical access control systems (e.g., badge readers) to find unusual access patterns (e.g., deviations from the norm) and failed access attempts
  - Ex2: Review and monitor physical access records (e.g., from visitor registration, sign-in sheets)
  - Ex3: Monitor physical access controls (e.g., locks, latches, hinge pins, alarms) for signs of tampering
  - Ex4: Monitor the physical environment using alarm systems, cameras, and security guards
- **DE.CM-03** Personnel activity and technology usage are monitored to find potentially adverse events
  - Ex1: Use behaviour analytics software to detect anomalous user activity to mitigate insider threats
  - Ex2: Monitor logs from logical access control systems to find unusual access patterns and failed access attempts
  - Ex3: Continuously monitor deception technology, including user accounts, for any usage
- **DE.CM-06** External service provider activities and services are monitored to find potentially adverse events
  - Ex1: Monitor remote and onsite administration and maintenance activities that external providers perform on organisational systems
  - Ex2: Monitor activity from cloud-based services, internet service providers, and other service providers for deviations from expected behaviour
- **DE.CM-09** Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events
  - Ex1: Monitor email, web, file sharing, collaboration services, and other common attack vectors to detect malware, phishing, data leaks and exfiltration, and other adverse events
  - Ex2: Monitor authentication attempts to identify attacks against credentials and unauthorised credential reuse
  - Ex3: Monitor software configurations for deviations from security baselines
  - Ex4: Monitor hardware and software for signs of tampering
  - Ex5: Use technologies with a presence on endpoints to detect cyber health issues (e.g., missing patches, malware infections, unauthorised software), and redirect the endpoints to a remediation environment before access is authorised

### RS: RESPOND

Actions regarding a detected cybersecurity incident are taken

#### RS.AN: Incident Analysis

Investigations are conducted to ensure effective response and support forensics and recovery activities

- **RS.AN-03** Analysis is performed to establish what has taken place during an incident and the root cause of the incident
  - Ex1: Determine the sequence of events that occurred during the incident and which assets and resources were involved in each event
  - Ex2: Attempt to determine what vulnerabilities, threats, and threat actors were directly or indirectly involved in the incident
  - Ex3: Analyse the incident to find the underlying, systemic root causes
  - Ex4: Check any cyber deception technology for additional information on attacker behaviour
- **RS.AN-06** Actions performed during an investigation are recorded, and the records' integrity and provenance are preserved
  - Ex1: Require each incident responder and others (e.g., system administrators, cybersecurity engineers) who perform incident response tasks to record their actions and make the record immutable
  - Ex2: Require the incident lead to document the incident in detail and be responsible for preserving the integrity of the documentation and the sources of all information being reported
- **RS.AN-07** Incident data and metadata are collected, and their integrity and provenance are preserved
  - Ex1: Collect, preserve, and safeguard the integrity of all pertinent incident data and metadata (e.g., data source, date/time of collection) based on evidence preservation and chain-of-custody procedures
- **RS.AN-08** An incident's magnitude is estimated and validated
  - Ex1: Review other potential targets of the incident to search for indicators of compromise and evidence of persistence
  - Ex2: Automatically run tools on targets to look for indicators of compromise and evidence of persistence

#### RS.CO: Incident Response Reporting and Communication

Response activities are coordinated with internal and external stakeholders as required by laws, regulations, or policies

- **RS.CO-02** Internal and external stakeholders are notified of incidents
  - Ex1: Follow the organisation's breach notification procedures after discovering a data breach incident, including notifying affected customers
  - Ex2: Notify business partners and customers of incidents in accordance with contractual requirements
  - Ex3: Notify law enforcement agencies and regulatory bodies of incidents based on criteria in the incident response plan and management approval
- **RS.CO-03** Information is shared with designated internal and external stakeholders
  - Ex1: Securely share information consistent with response plans and information sharing agreements
  - Ex2: Voluntarily share information about an attacker's observed TTPs, with all sensitive data removed, with an Information Sharing and Analysis Center (ISAC)
  - Ex3: Notify HR when malicious insider activity occurs
  - Ex4: Regularly update senior leadership on the status of major incidents
  - Ex5: Follow the rules and protocols defined in contracts for incident information sharing between the organisation and its suppliers
  - Ex6: Coordinate crisis communication methods between the organisation and its critical suppliers

#### RS.MA: Incident Management

Responses to detected cybersecurity incidents are managed

- **RS.MA-01** The incident response plan is executed in coordination with relevant third parties once an incident is declared
  - Ex1: Detection technologies automatically report confirmed incidents
  - Ex2: Request incident response assistance from the organisation's incident response outsourcer
  - Ex3: Designate an incident lead for each incident
  - Ex4: Initiate execution of additional cybersecurity plans as needed to support incident response (for example, business continuity and disaster recovery)
- **RS.MA-02** Incident reports are triaged and validated
  - Ex1: Preliminarily review incident reports to confirm that they are cybersecurity-related and necessitate incident response activities
  - Ex2: Apply criteria to estimate the severity of an incident
- **RS.MA-03** Incidents are categorised and prioritised
  - Ex1: Further review and categorise incidents based on the type of incident (e.g., data breach, ransomware, DDoS, account compromise)
  - Ex2: Prioritise incidents based on their scope, likely impact, and time-critical nature
  - Ex3: Select incident response strategies for active incidents by balancing the need to quickly recover from an incident with the need to observe the attacker or conduct a more thorough investigation
- **RS.MA-04** Incidents are escalated or elevated as needed
  - Ex1: Track and validate the status of all ongoing incidents
  - Ex2: Coordinate incident escalation or elevation with designated internal and external stakeholders
- **RS.MA-05** The criteria for initiating incident recovery are applied
  - Ex1: Apply incident recovery criteria to known and assumed characteristics of the incident to determine whether incident recovery processes should be initiated
  - Ex2: Take the possible operational disruption of incident recovery activities into account

#### RS.MI: Incident Mitigation

Activities are performed to prevent expansion of an event and mitigate its effects

- **RS.MI-01** Incidents are contained
  - Ex1: Cybersecurity technologies (e.g., antivirus software) and cybersecurity features of other technologies (e.g., operating systems, network infrastructure devices) automatically perform containment actions
  - Ex2: Allow incident responders to manually select and perform containment actions
  - Ex3: Allow a third party (e.g., internet service provider, managed security service provider) to perform containment actions on behalf of the organisation
  - Ex4: Automatically transfer compromised endpoints to a remediation virtual local area network (VLAN)
- **RS.MI-02** Incidents are eradicated
  - Ex1: Cybersecurity technologies and cybersecurity features of other technologies (e.g., operating systems, network infrastructure devices) automatically perform eradication actions
  - Ex2: Allow incident responders to manually select and perform eradication actions
  - Ex3: Allow a third party (e.g., managed security service provider) to perform eradication actions on behalf of the organisation

### RC: RECOVER

Assets and operations affected by a cybersecurity incident are restored

#### RC.CO: Incident Recovery Communication

Restoration activities are coordinated with internal and external parties

- **RC.CO-03** Recovery activities and progress in restoring operational capabilities are communicated to designated internal and external stakeholders
  - Ex1: Securely share recovery information, including restoration progress, consistent with response plans and information sharing agreements
  - Ex2: Regularly update senior leadership on recovery status and restoration progress for major incidents
  - Ex3: Follow the rules and protocols defined in contracts for incident information sharing between the organisation and its suppliers
  - Ex4: Coordinate crisis communication between the organisation and its critical suppliers
- **RC.CO-04** Public updates on incident recovery are shared using approved methods and messaging
  - Ex1: Follow the organisation's breach notification procedures for recovering from a data breach incident
  - Ex2: Explain the steps being taken to recover from the incident and to prevent a recurrence

#### RC.RP: Incident Recovery Plan Execution

Restoration activities are performed to ensure operational availability of systems and services affected by cybersecurity incidents

- **RC.RP-01** The recovery portion of the incident response plan is executed once initiated from the incident response process
  - Ex1: Begin recovery procedures during or after incident response processes
  - Ex2: Make all individuals with recovery responsibilities aware of the plans for recovery and the authorisations required to implement each aspect of the plans
- **RC.RP-02** Recovery actions are selected, scoped, prioritised, and performed
  - Ex1: Select recovery actions based on the criteria defined in the incident response plan and available resources
  - Ex2: Change planned recovery actions based on a reassessment of organisational needs and resources
- **RC.RP-03** The integrity of backups and other restoration assets is verified before using them for restoration
  - Ex1: Check restoration assets for indicators of compromise, file corruption, and other integrity issues before use
- **RC.RP-04** Critical mission functions and cybersecurity risk management are considered to establish post-incident operational norms
  - Ex1: Use business impact and system categorisation records (including service delivery objectives) to validate that essential services are restored in the appropriate order
  - Ex2: Work with system owners to confirm the successful restoration of systems and the return to normal operations
  - Ex3: Monitor the performance of restored systems to verify the adequacy of the restoration
- **RC.RP-05** The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed
  - Ex1: Check restored assets for indicators of compromise and remediation of root causes of the incident before production use
  - Ex2: Verify the correctness and adequacy of the restoration actions taken before putting a restored system online
- **RC.RP-06** The end of incident recovery is declared based on criteria, and incident-related documentation is completed
  - Ex1: Prepare an after-action report that documents the incident itself, the response and recovery actions taken, and lessons learned
  - Ex2: Declare the end of incident recovery once the criteria are met

## NIST AI Risk Management Framework (AI RMF 1.0)

### GOVERN

A culture of risk management is cultivated and present.

#### GOVERN 1

Policies, processes, procedures and practices across the organisation related to the mapping, measuring and managing of AI risks are in place, transparent, and implemented effectively.

- **GOVERN 1.1** Legal and regulatory requirements involving AI are understood, managed, and documented.
  - Maintain awareness of the applicable legal and regulatory considerations and requirements specific to industry, sector, and business purpose, as well as the application context of the deployed AI system.
  - Align risk management efforts with applicable legal standards.
  - Maintain policies for training (and re-training) organisational staff about necessary legal or regulatory considerations that may impact AI-related design, development and deployment activities.
- **GOVERN 1.2** The characteristics of trustworthy AI are integrated into organisational policies, processes, and procedures.
  - Organisational AI risk management policies should be designed to:
  - Define key terms and concepts related to AI systems and the scope of their purposes and intended uses.
  - Connect AI governance to existing organisational governance and risk controls.
  - Align to broader data governance policies and practices, particularly the use of sensitive or otherwise risky data.
  - Detail standards for experimental design, data quality, and model training.
  - Outline and document risk mapping and measurement processes and standards.
  - Detail model testing and validation processes.
  - Detail review processes for legal and risk functions.
  - Establish the frequency of and detail for monitoring, auditing and review processes.
  - Outline change management requirements.
  - Outline processes for internal and external stakeholder engagement.
  - Establish whistleblower policies to facilitate reporting of serious AI system concerns.
  - Detail and test incident response plans.
  - Verify that formal AI risk management policies align to existing legal standards, and industry best practices and norms.
  - Establish AI risk management policies that broadly align to AI system trustworthy characteristics.
  - Verify that formal AI risk management policies include currently deployed and third-party AI systems.
- **GOVERN 1.3** Processes and procedures are in place to determine the needed level of risk management activities based on the organisation's risk tolerance.
  - Establish policies to define mechanisms for measuring or understanding an AI system’s potential impacts, e.g., via regular impact assessments at key stages in the AI lifecycle, connected to system impacts and frequency of system updates.
  - Establish policies to define mechanisms for measuring or understanding the likelihood of an AI system’s impacts and their magnitude at key stages in the AI lifecycle.
  - Establish policies that define assessment scales for measuring potential AI system impact. Scales may be qualitative, such as red-amber-green (RAG), or may entail simulations or econometric approaches.
  - Establish policies for assigning an overall risk measurement approach for an AI system, or its important components, e.g., via multiplication or combination of a mapped risk’s impact and likelihood (risk ≈ impact x likelihood).
  - Establish policies to assign systems to uniform risk scales that are valid across the organisation’s AI portfolio (e.g. documentation templates), and acknowledge risk tolerance and risk levels may change over the lifecycle of an AI system.
- **GOVERN 1.4** The risk management process and its outcomes are established through transparent policies, procedures, and other controls based on organisational risk priorities.
  - Establish and regularly review documentation policies that, among others, address information related to:
    - AI actors contact informations
    - Business justification
    - Scope and usages
    - Expected and potential risks and impacts
    - Assumptions and limitations
    - Description and characterisation of training data
    - Algorithmic methodology
    - Evaluated alternative approaches
    - Description of output data
    - Testing and validation results (including explanatory visualisations and information)
    - Down- and up-stream dependencies
    - Plans for deployment, monitoring, and change management
    - Stakeholder engagement plans
  - Verify documentation policies for AI systems are standardised across the organisation and remain current.
  - Establish policies for a model documentation inventory system and regularly review its completeness, usability, and efficacy.
  - Establish mechanisms to regularly review the efficacy of risk management processes.
  - Identify AI actors responsible for evaluating efficacy of risk management processes and approaches, and for course-correction based on results.
  - Establish policies and processes regarding public disclosure of the use of AI and risk management material such as impact assessments, audits, model documentation and validation and testing results.
  - Document and review the use and efficacy of different types of transparency tools and follow industry standards at the time a model is in use.
- **GOVERN 1.5** Ongoing monitoring and periodic review of the risk management process and its outcomes are planned, organisational roles and responsibilities are clearly defined, including determining the frequency of periodic review.
  - Establish policies to allocate appropriate resources and capacity for assessing impacts of AI systems on individuals, communities and society.
  - Establish policies and procedures for monitoring and addressing AI system performance and trustworthiness, including bias and security problems, across the lifecycle of the system.
  - Establish policies for AI system incident response, or confirm that existing incident response policies apply to AI systems.
  - Establish policies to define organisational functions and personnel responsible for AI system monitoring and incident response activities.
  - Establish mechanisms to enable the sharing of feedback from impacted individuals or communities about negative impacts from AI systems.
  - Establish mechanisms to provide recourse for impacted individuals or communities to contest problematic AI system outcomes.
  - Establish opt-out mechanisms.
- **GOVERN 1.6** Mechanisms are in place to inventory AI systems and are resourced according to organisational risk priorities.
  - Establish policies that define the creation and maintenance of AI system inventories.
  - Establish policies that define a specific individual or team that is responsible for maintaining the inventory.
  - Establish policies that define which models or systems are inventoried, with preference to inventorying all models or systems, or minimally, to high risk models or systems, or systems deployed in high-stakes settings.
  - Establish policies that define model or system attributes to be inventoried, e.g, documentation, links to source code, incident response plans, data dictionaries, AI actor contact information.
- **GOVERN 1.7** Processes and procedures are in place for decommissioning and phasing out of AI systems safely and in a manner that does not increase risks or decrease the organisation’s trustworthiness.
  - Establish policies for decommissioning AI systems. Such policies typically address:
    - User and community concerns, and reputational risks.
    - Business continuity and financial risks.
    - Up and downstream system dependencies.
    - Regulatory requirements (e.g., data retention).
    - Potential future legal, regulatory, security or forensic investigations.
    - Migration to the replacement system, if appropriate.
  - Establish policies that delineate where and for how long decommissioned systems, models and related artifacts are stored.
  - Establish practices to track accountability and consider how decommission and other adaptations or changes in system deployment contribute to downstream impacts for individuals, groups and communities.
  - Establish policies that address ancillary data or artifacts that must be preserved for fulsome understanding or execution of the decommissioned AI system, e.g., predictions, explanations, intermediate input feature representations, usernames and passwords, etc.

#### GOVERN 2

Accountability structures are in place so that the appropriate teams and individuals are empowered, responsible, and trained for mapping, measuring, and managing AI risks.

- **GOVERN 2.1** Roles and responsibilities and lines of communication related to mapping, measuring, and managing AI risks are documented and are clear to individuals and teams throughout the organisation.
  - Establish policies that define the AI risk management roles and responsibilities for positions directly and indirectly related to AI systems, including, but not limited to
    - Boards of directors or advisory committees
    - Senior management
    - AI audit functions
    - Product management
    - Project management
    - AI design
    - AI development
    - Human-AI interaction
    - AI testing and evaluation
    - AI acquisition and procurement
    - Impact assessment functions
    - Oversight functions
  - Establish policies that promote regular communication among AI actors participating in AI risk management efforts.
  - Establish policies that separate management of AI system development functions from AI system testing functions, to enable independent course-correction of AI systems.
  - Establish policies to identify, increase the transparency of, and prevent conflicts of interest in AI risk management efforts.
  - Establish policies to counteract confirmation bias and market incentives that may hinder AI risk management efforts.
  - Establish policies that incentivise AI actors to collaborate with existing legal, oversight, compliance, or enterprise risk functions in their AI risk management activities.
- **GOVERN 2.2** The organisation’s personnel and partners receive AI risk management training to enable them to perform their duties and responsibilities consistent with related policies, procedures, and agreements.
  - Establish policies for personnel addressing ongoing education about:
    - Applicable laws and regulations for AI systems.
    - Potential negative impacts that may arise from AI systems.
    - Organisational AI policies.
    - Trustworthy AI characteristics.
  - Ensure that trainings are suitable across AI actor sub-groups - for AI actors carrying out technical tasks (e.g., developers, operators, etc.) as compared to AI actors in oversight roles (e.g., legal, compliance, audit, etc.).
  - Ensure that trainings comprehensively address technical and socio-technical aspects of AI risk management.
  - Verify that organisational AI policies include mechanisms for internal AI personnel to acknowledge and commit to their roles and responsibilities.
  - Verify that organisational policies address change management and include mechanisms to communicate and acknowledge substantial AI system changes.
  - Define paths along internal and external chains of accountability to escalate risk concerns.
- **GOVERN 2.3** Executive leadership of the organisation takes responsibility for decisions about risks associated with AI system development and deployment.
  - Organisational management can:
    - Declare risk tolerances for developing or using AI systems.
    - Support AI risk management efforts, and play an active role in such efforts.
    - Integrate a risk and harm prevention mindset throughout the AI lifecycle as part of organisational culture
    - Support competent risk management executives.
    - Delegate the power, resources, and authorisation to perform risk management to each appropriate level throughout the management chain.
  - Organisations can establish board committees for AI risk management and oversight functions and integrate those functions within the organisation’s broader enterprise risk management approaches.

#### GOVERN 3

Workforce diversity, equity, inclusion, and accessibility processes are prioritised in the mapping, measuring, and managing of AI risks throughout the lifecycle.

- **GOVERN 3.1** Decision-makings related to mapping, measuring, and managing AI risks throughout the lifecycle is informed by a diverse team (e.g., diversity of demographics, disciplines, experience, expertise, and backgrounds).
  - Organisational management can:
  - Define policies and hiring practices at the outset that promote interdisciplinary roles, competencies, skills, and capacity for AI efforts.
  - Define policies and hiring practices that lead to demographic and domain expertise diversity; empower staff with necessary resources and support, and facilitate the contribution of staff feedback and concerns without fear of reprisal.
  - Establish policies that facilitate inclusivity and the integration of new insights into existing practice.
  - Seek external expertise to supplement organisational diversity, equity, inclusion, and accessibility where internal expertise is lacking.
  - Establish policies that incentivise AI actors to collaborate with existing nondiscrimination, accessibility and accommodation, and human resource functions, employee resource group (ERGs), and diversity, equity, inclusion, and accessibility (DEIA) initiatives.
- **GOVERN 3.2** Policies and procedures are in place to define and differentiate roles and responsibilities for human-AI configurations and oversight of AI systems.
  - Establish policies and procedures that define and differentiate the various human roles and responsibilities when using, interacting with, or monitoring AI systems.
  - Establish procedures for capturing and tracking risk information related to human-AI configurations and associated outcomes.
  - Establish policies for the development of proficiency standards for AI actors carrying out system operation tasks and system oversight tasks.
  - Establish specified risk management training protocols for AI actors carrying out system operation tasks and system oversight tasks.
  - Establish policies and procedures regarding AI actor roles, and responsibilities for human oversight of deployed systems.
  - Establish policies and procedures defining human-AI configurations (configurations where AI systems are explicitly designated and treated as team members in primarily human teams) in relation to organisational risk tolerances, and associated documentation.
  - Establish policies to enhance the explanation, interpretation, and overall transparency of AI systems.
  - Establish policies for managing risks regarding known difficulties in human-AI configurations, human-AI teaming, and AI system user experience and user interactions (UI/UX).

#### GOVERN 4

Organisational teams are committed to a culture that considers and communicates AI risk.

- **GOVERN 4.1** Organisational policies, and practices are in place to foster a critical thinking and safety-first mindset in the design, development, deployment, and uses of AI systems to minimise negative impacts.
  - Establish policies that require inclusion of oversight functions (legal, compliance, risk management) from the outset of the system design process.
  - Establish policies that promote effective challenge of AI system design, implementation, and deployment decisions, via mechanisms such as the three lines of defence, model audits, or red-teaming – to minimise workplace risks such as groupthink.
  - Establish policies that incentivise safety-first mindset and general critical thinking and review at an organisational and procedural level.
  - Establish whistleblower protections for insiders who report on perceived serious problems with AI systems.
  - Establish policies to integrate a harm and risk prevention mindset throughout the AI lifecycle.
- **GOVERN 4.2** Organisational teams document the risks and potential impacts of the AI technology they design, develop, deploy, evaluate and use, and communicate about the impacts more broadly.
  - Establish impact assessment policies and processes for AI systems used by the organisation.
  - Align organisational impact assessment activities with relevant regulatory or legal requirements.
  - Verify that impact assessment activities are appropriate to evaluate the potential negative impact of a system and how quickly a system changes, and that assessments are applied on a regular basis.
  - Utilise impact assessments to inform broader evaluations of AI system risk.
- **GOVERN 4.3** Organisational practices are in place to enable AI testing, identification of incidents, and information sharing.
  - Establish policies and procedures to facilitate and equip AI system testing.
  - Establish organisational commitment to identifying AI system limitations and sharing of insights about limitations within appropriate AI actor groups.
  - Establish policies for reporting and documenting incident response.
  - Establish policies and processes regarding public disclosure of incidents and information sharing.
  - Establish guidelines for incident handling related to AI system risks and performance.

#### GOVERN 5

Processes are in place for robust engagement with relevant AI actors.

- **GOVERN 5.1** Organisational policies and practices are in place to collect, consider, prioritise, and integrate feedback from those external to the team that developed or deployed the AI system regarding the potential individual and societal impacts related to AI risks.
  - Establish AI risk management policies that explicitly address mechanisms for collecting, evaluating, and incorporating stakeholder and user feedback that could include:
    - Recourse mechanisms for faulty AI system outputs.
    - Bug bounties.
    - Human-centred design.
    - User-interaction and experience research.
    - Participatory stakeholder engagement with individuals and communities that may experience negative impacts.
  - Verify that stakeholder feedback is considered and addressed, including environmental concerns, and across the entire population of intended users, including historically excluded populations, people with disabilities, older people, and those with limited access to the internet and other basic technologies.
  - Clarify the organisation’s principles as they apply to AI systems – considering those which have been proposed publicly – to inform external stakeholders of the organisation’s values. Consider publishing or adopting AI principles.
- **GOVERN 5.2** Mechanisms are established to enable AI actors to regularly incorporate adjudicated feedback from relevant AI actors into system design and implementation.
  - Explicitly acknowledge that AI systems, and the use of AI, present inherent costs and risks along with potential benefits.
  - Define reasonable risk tolerances for AI systems informed by laws, regulation, best practices, or industry standards.
  - Establish policies that ensure all relevant AI actors are provided with meaningful opportunities to provide feedback on system design and implementation.
  - Establish policies that define how to assign AI systems to established risk tolerance levels by combining system impact assessments with the likelihood that an impact occurs. Such assessment often entails some combination of:
    - Econometric evaluations of impacts and impact likelihoods to assess AI system risk.
    - Red-amber-green (RAG) scales for impact severity and likelihood to assess AI system risk.
    - Establishment of policies for allocating risk management resources along established risk tolerance levels, with higher-risk systems receiving more risk management resources and oversight.
    - Establishment of policies for approval, conditional approval, and disapproval of the design, implementation, and deployment of AI systems.
  - Establish policies facilitating the early decommissioning of AI systems that surpass an organisation’s ability to reasonably mitigate risks.

#### GOVERN 6

Policies and procedures are in place to address AI risks and benefits arising from third-party software and data and other supply chain issues.

- **GOVERN 6.1** Policies and procedures are in place that address AI risks associated with third-party entities, including risks of infringement of a third party's intellectual property or other rights.
  - Collaboratively establish policies that address third-party AI systems and data.
  - Establish policies related to:
    - Transparency into third-party system functions, including knowledge about training data, training and inference algorithms, and assumptions and limitations.
    - Thorough testing of third-party AI systems. (See MEASURE for more detail)
    - Requirements for clear and complete instructions for third-party system usage.
  - Evaluate policies for third-party technology.
  - Establish policies that address supply chain, full product lifecycle and associated processes, including legal, ethical, and other issues concerning procurement and use of third-party software or hardware systems and data.
- **GOVERN 6.2** Contingency processes are in place to handle failures or incidents in third-party data or AI systems deemed to be high-risk.
  - Establish policies for handling third-party system failures to include consideration of redundancy mechanisms for vital third-party AI systems.
  - Verify that incident response plans address third-party AI systems.

### MAP

Context is recognised and risks related to context are identified.

#### MAP 1

Context is established and understood.

- **MAP 1.1** Intended purpose, potentially beneficial uses, context-specific laws, norms and expectations, and prospective settings in which the AI system will be deployed are understood and documented. Considerations include: specific set or types of users along with their expectations; potential positive and negative impacts of system uses to individuals, communities, organisations, society, and the planet; assumptions and related limitations about AI system purposes; uses and risks across the development or product AI lifecycle; TEVV and system metrics.
  - Maintain awareness of industry, technical, and applicable legal standards.
  - Examine trustworthiness of AI system design and consider, non-AI solutions
  - Consider intended AI system design tasks along with unanticipated purposes in collaboration with human factors and socio-technical domain experts.
  - Define and document the task, purpose, minimum functionality, and benefits of the AI system to inform considerations about whether the utility of the project or its lack of.
  - Identify whether there are non-AI or non-technology alternatives that will lead to more trustworthy outcomes.
  - Examine how changes in system performance affect downstream events such as decision-making (e.g: changes in an AI model objective function create what types of impacts in how many candidates do/do not get a job interview).
  - Determine actions to map and track post-decommissioning stages of AI deployment and potential negative or positive impacts to individuals, groups and communities.
  - Determine the end user and organisational requirements, including business and technical requirements.
  - Determine and delineate the expected and acceptable AI system context of use, including:
    - social norms
    - Impacted individuals, groups, and communities
    - potential positive and negative impacts to individuals, groups, communities, organisations, and society
    - operational environment
  - Perform context analysis related to time frame, safety concerns, geographic area, physical environment, ecosystems, social environment, and cultural norms within the intended setting (or conditions that closely approximate the intended setting.
  - Gain and maintain awareness about evaluating scientific claims related to AI system performance and benefits before launching into system design.
  - Identify human-AI interaction and/or roles, such as whether the application will support or replace human decision making.
  - Plan for risks related to human-AI configurations, and document requirements, roles, and responsibilities for human oversight of deployed systems.
- **MAP 1.2** Inter-disciplinary AI actors, competencies, skills and capacities for establishing context reflect demographic diversity and broad domain and user experience expertise, and their participation is documented. Opportunities for interdisciplinary collaboration are prioritised.
  - Establish interdisciplinary teams to reflect a wide range of skills, competencies, and capabilities for AI efforts. Verify that team membership includes demographic diversity, broad domain expertise, and lived experiences. Document team composition.
  - Create and empower interdisciplinary expert teams to capture, learn, and engage the interdependencies of deployed AI systems and related terminologies and concepts from disciplines outside of AI practice such as law, sociology, psychology, anthropology, public policy, systems design, and engineering.
- **MAP 1.3** The organisation’s mission and relevant goals for the AI technology are understood and documented.
  - Build transparent practices into AI system development processes.
  - Review the documented system purpose from a socio-technical perspective and in consideration of societal values.
  - Determine possible misalignment between societal values and stated organisational principles and code of ethics.
  - Flag latent incentives that may contribute to negative impacts.
  - Evaluate AI system purpose in consideration of potential risks, societal values, and stated organisational principles.
- **MAP 1.4** The business value or context of business use has been clearly defined or– in the case of assessing existing AI systems – re-evaluated.
  - Document business value or context of business use
  - Reconcile documented concerns about the system’s purpose within the business context of use compared to the organisation’s stated values, mission statements, social responsibility commitments, and AI principles.
  - Reconsider the design, implementation strategy, or deployment of AI systems with potential impacts that do not reflect institutional values.
- **MAP 1.5** Organisational risk tolerances are determined and documented.
  - Utilise existing regulations and guidelines for risk criteria, tolerance and response established by organisational, domain, discipline, sector, or professional requirements.
  - Establish risk tolerance levels for AI systems and allocate the appropriate oversight resources to each level.
  - Establish risk criteria in consideration of different sources of risk, (e.g., financial, operational, safety and wellbeing, business, reputational, and model risks) and different levels of risk (e.g., from negligible to critical).
  - Identify maximum allowable risk tolerance above which the system will not be deployed, or will need to be prematurely decommissioned, within the contextual or application setting.
  - Articulate and analyse tradeoffs across trustworthiness characteristics as relevant to proposed context of use. When tradeoffs arise, document them and plan for traceable actions (e.g.: impact mitigation, removal of system from development or use) to inform management decisions.
  - Review uses of AI systems for “off-label” purposes, especially in settings that organisations have deemed as high-risk. Document decisions, risk-related trade-offs, and system limitations.
- **MAP 1.6** System requirements (e.g., “the system shall respect the privacy of its users”) are elicited from and understood by relevant AI actors. Design decisions take socio-technical implications into account to address AI risks.
  - Proactively incorporate trustworthy characteristics into system requirements.
  - Establish mechanisms for regular communication and feedback between relevant AI actors and internal or external stakeholders related to system design or deployment decisions.
  - Develop and standardise practices to assess potential impacts at all stages of the AI lifecycle, and in collaboration with interdisciplinary experts, actors external to the team that developed or deployed the AI system, and potentially impacted communities .
  - Include potentially impacted groups, communities and external entities (e.g. civil society organisations, research institutes, local community groups, and trade associations) in the formulation of priorities, definitions and outcomes during impact assessment activities.
  - Conduct qualitative interviews with end user(s) to regularly evaluate expectations and design plans related to Human-AI configurations and tasks.
  - Analyse dependencies between contextual factors and system requirements. List potential impacts that may arise from not fully considering the importance of trustworthiness characteristics in any decision making.
  - Follow responsible design techniques in tasks such as software engineering, product management, and participatory engagement. Some examples for eliciting and documenting stakeholder requirements include product requirement documents (PRDs), user stories, user interaction/user experience (UI/UX) research, systems engineering, ethnography and related field methods.
  - Conduct user research to understand individuals, groups and communities that will be impacted by the AI, their values & context, and the role of systemic and historical biases. Integrate learnings into decisions about data selection and representation.

#### MAP 2

Categorisation of the AI system is performed.

- **MAP 2.1** The specific task, and methods used to implement the task, that the AI system will support is defined (e.g., classifiers, generative models, recommenders).
  - Define and document AI system’s existing and potential learning task(s) along with known assumptions and limitations.
- **MAP 2.2** Information about the AI system’s knowledge limits and how system output may be utilised and overseen by humans is documented. Documentation provides sufficient information to assist relevant AI actors when making informed decisions and taking subsequent actions.
  - Document settings, environments and conditions that are outside the AI system’s intended use.
  - Design for end user workflows and toolsets, concept of operations, and explainability and interpretability criteria in conjunction with end user(s) and associated qualitative feedback.
  - Plan and test human-AI configurations under close to real-world conditions and document results.
  - Follow stakeholder feedback processes to determine whether a system achieved its documented purpose within a given use context, and whether end users can correctly comprehend system outputs or results.
  - Document dependencies on upstream data and other AI systems, including if the specified system is an upstream dependency for another AI system or other data.
  - Document connections the AI system or data will have to external networks (including the internet), financial markets, and critical infrastructure that have potential for negative externalities. Identify and document negative impacts as part of considering the broader risk thresholds and subsequent go/no-go deployment as well as post-deployment decommissioning decisions.
- **MAP 2.3** Scientific integrity and TEVV considerations are identified and documented, including those related to experimental design, data collection and selection(e.g., availability, representativeness, suitability), system trustworthiness, and construct validation.
  - Identify and document experiment design and statistical techniques that are valid for testing complex socio-technical systems like AI, which involve human factors, emergent properties, and dynamic context(s) of use.
  - Develop and apply TEVV protocols for models, system and its subcomponents, deployment, and operation.
  - Demonstrate and document that AI system performance and validation metrics are interpretable and unambiguous for downstream decision making tasks, and take socio-technical factors such as context of use into consideration.
  - Identify and document assumptions, techniques, and metrics used for testing and evaluation throughout the AI lifecycle including experimental design techniques for data collection, selection, and management practices in accordance with data governance policies established in GOVERN.
  - Identify testing modules that can be incorporated throughout the AI lifecycle, and verify that processes enable corroboration by independent evaluators.
  - Establish mechanisms for regular communication and feedback among relevant AI actors and internal or external stakeholders related to the validity of design and deployment assumptions.
  - Establish mechanisms for regular communication and feedback between relevant AI actors and internal or external stakeholders related to the development of TEVV approaches throughout the lifecycle to detect and assess potentially harmful impacts
  - Document assumptions made and techniques used in data selection, curation, preparation and analysis, including:
    - identification of constructs and proxy targets,
    - development of indices – especially those operationalising concepts that are inherently unobservable (e.g. “hireability,” “criminality.” “lendability”).
  - Map adherence to policies that address data and construct validity, bias, privacy and security for AI systems and verify documentation, oversight, and processes.
  - Identify and document transparent methods (e.g. causal discovery methods) for inferring causal relationships between constructs being modeled and dataset attributes or proxies.
  - Identify and document processes to understand and trace test and training data lineage and its metadata resources for mapping risks.
  - Document known limitations, risk mitigation efforts associated with, and methods used for, training data collection, selection, labeling, cleaning, and analysis (e.g. treatment of missing, spurious, or outlier data; biased estimators).
  - Establish and document practices to check for capabilities that are in excess of those that are planned for, such as emergent properties, and to revisit prior risk management steps in light of any new capabilities.
  - Establish processes to test and verify that design assumptions about the set of deployment contexts continue to be accurate and sufficiently complete.
  - Work with domain experts and other external AI actors to:
    - Gain and maintain contextual awareness and knowledge about how human behaviour, organisational factors and dynamics, and society influence, and are represented in, datasets, processes, models, and system output.
    - Identify participatory approaches for responsible Human-AI configurations and oversight tasks, taking into account sources of cognitive bias.
    - Identify techniques to manage and mitigate sources of bias (systemic, computational, human- cognitive) in computational models and systems, and the assumptions and decisions in their development..
  - Investigate and document potential negative impacts due related to the full product lifecycle and associated processes that may conflict with organisational values and principles.

#### MAP 3

AI capabilities, targeted usage, goals, and expected benefits and costs compared with appropriate benchmarks are understood.

- **MAP 3.1** Potential benefits of intended AI system functionality and performance are examined and documented.
  - Utilise participatory approaches and engage with system end users to understand and document AI systems’ potential benefits, efficacy and interpretability of AI task output.
  - Maintain awareness and documentation of the individuals, groups, or communities who make up the system’s internal and external stakeholders.
  - Verify that appropriate skills and practices are available in-house for carrying out participatory activities such as eliciting, capturing, and synthesising user, operator and external feedback, and translating it for AI design and development functions.
  - Establish mechanisms for regular communication and feedback between relevant AI actors and internal or external stakeholders related to system design or deployment decisions.
  - Consider performance to human baseline metrics or other standard benchmarks.
  - Incorporate feedback from end users, and potentially impacted individuals and communities about perceived system benefits .
- **MAP 3.2** Potential costs, including non-monetary costs, which result from expected or realised AI errors or system functionality and trustworthiness - as connected to organisational risk tolerance - are examined and documented.
  - Perform context analysis to map potential negative impacts arising from not integrating trustworthiness characteristics. When negative impacts are not direct or obvious, AI actors can engage with stakeholders external to the team that developed or deployed the AI system, and potentially impacted communities, to examine and document:
    - Who could be harmed?
    - What could be harmed?
    - When could harm arise?
    - How could harm arise?
  - Identify and implement procedures for regularly evaluating the qualitative and quantitative costs of internal and external AI system failures. Develop actions to prevent, detect, and/or correct potential risks and related impacts. Regularly evaluate failure costs to inform go/no-go deployment decisions throughout the AI system lifecycle.
- **MAP 3.3** Targeted application scope is specified and documented based on the system's capability, established context, and AI system categorisation.
  - Consider narrowing contexts for system deployment, including factors related to:
    - How outcomes may directly or indirectly affect users, groups, communities and the environment.
    - Length of time the system is deployed in between re-trainings.
    - Geographical regions in which the system operates.
    - Dynamics related to community standards or likelihood of system misuse or abuses (either purposeful or unanticipated).
    - How AI system features and capabilities can be utilised within other applications, or in place of other existing processes.
  - Engage AI actors from legal and procurement functions when specifying target application scope.
- **MAP 3.4** Processes for operator and practitioner proficiency with AI system performance and trustworthiness – and relevant technical standards and certifications – are defined, assessed and documented.
  - Identify and declare AI system features and capabilities that may affect downstream AI actors’ decision-making in deployment and operational settings for example how system features and capabilities may activate known risks in various human-AI configurations, such as selective adherence.
  - Identify skills and proficiency requirements for operators, practitioners and other domain experts that interact with AI systems,Develop AI system operational documentation for AI actors in deployed and operational environments, including information about known risks, mitigation criteria, and trustworthy characteristics enumerated in Map-1.
  - Define and develop training materials for proposed end users, practitioners and operators about AI system use and known limitations.
  - Define and develop certification procedures for operating AI systems within defined contexts of use, and information about what exceeds operational boundaries.
  - Include operators, practitioners and end users in AI system prototyping and testing activities to help inform operational boundaries and acceptable performance. Conduct testing activities under scenarios similar to deployment conditions.
  - Verify model output provided to AI system operators, practitioners and end users is interactive, and specified to context and user requirements defined in MAP-1.
  - Verify AI system output is interpretable and unambiguous for downstream decision making tasks.
  - Design AI system explanation complexity to match the level of problem and context complexity.
  - Verify that design principles are in place for safe operation by AI actors in decision-making environments.
  - Develop approaches to track human-AI configurations, operator, and practitioner outcomes for integration into continual improvement.
- **MAP 3.5** Processes for human oversight are defined, assessed, and documented in accordance with organisational policies from GOVERN function.
  - Identify and document AI systems’ features and capabilities that require human oversight, in relation to operational and societal contexts, trustworthy characteristics, and risks identified in MAP-1.
  - Establish practices for AI systems’ oversight in accordance with policies developed in GOVERN-1.
  - Define and develop training materials for relevant AI Actors about AI system performance, context of use, known limitations and negative impacts, and suggested warning labels.
  - Include relevant AI Actors in AI system prototyping and testing activities. Conduct testing activities under scenarios similar to deployment conditions.
  - Evaluate AI system oversight practices for validity and reliability. When oversight practices undergo extensive updates or adaptations, retest, evaluate results, and course correct as necessary.
  - Verify that model documents contain interpretable descriptions of system mechanisms, enabling oversight personnel to make informed, risk-based decisions about system risks.

#### MAP 4

Risks and benefits are mapped for all components of the AI system including third-party software and data.

- **MAP 4.1** Approaches for mapping AI technology and legal risks of its components –including the use of third-party data or software – are in place, followed, and documented, as are risks of infringement of a third-party’s intellectual property or other rights.
  - Review audit reports, testing results, product roadmaps, warranties, terms of service, end user license agreements, contracts, and other documentation related to third-party entities to assist in value assessment and risk management activities.
  - Review third-party software release schedules and software change management plans (hotfixes, patches, updates, forward- and backward- compatibility guarantees) for irregularities that may contribute to AI system risks.
  - Inventory third-party material (hardware, open-source software, foundation models, open source data, proprietary software, proprietary data, etc.) required for system implementation and maintenance.
  - Review redundancies related to third-party technology and personnel to assess potential risks due to lack of adequate support.
- **MAP 4.2** Internal risk controls for components of the AI system including third-party AI technologies are identified and documented.
  - Track third-parties preventing or hampering risk-mapping as indications of increased risk.
  - Supply resources such as model documentation templates and software safelists to assist in third-party technology inventory and approval activities.
  - Review third-party material (including data and models) for risks related to bias, data privacy, and security vulnerabilities.
  - Apply traditional technology risk controls – such as procurement, security, and data privacy controls – to all acquired third-party technologies.

#### MAP 5

Impacts to individuals, groups, communities, organisations, and society are characterised.

- **MAP 5.1** Likelihood and magnitude of each identified impact (both potentially beneficial and harmful) based on expected use, past uses of AI systems in similar contexts, public incident reports, feedback from those external to the team that developed or deployed the AI system, or other data are identified and documented.
  - Establish assessment scales for measuring AI systems’ impact. Scales may be qualitative, such as red-amber-green (RAG), or may entail simulations or econometric approaches. Document and apply scales uniformly across the organisation’s AI portfolio.
  - Apply TEVV regularly at key stages in the AI lifecycle, connected to system impacts and frequency of system updates.
  - Identify and document likelihood and magnitude of system benefits and negative impacts in relation to trustworthiness characteristics.
  - Establish processes for red teaming to identify and connect system limitations to AI lifecycle stage(s) and potential downstream impacts
- **MAP 5.2** Practices and personnel for supporting regular engagement with relevant AI actors and integrating feedback about positive, negative, and unanticipated impacts are in place and documented.
  - Establish and document stakeholder engagement processes at the earliest stages of system formulation to identify potential impacts from the AI system on individuals, groups, communities, organisations, and society.
  - Employ methods such as value sensitive design (VSD) to identify misalignments between organisational and societal values, and system implementation and impact.
  - Identify approaches to engage, capture, and incorporate input from system end users and other key stakeholders to assist with continuous monitoring for potential impacts and emergent risks.
  - Incorporate quantitative, qualitative, and mixed methods in the assessment and documentation of potential impacts to individuals, groups, communities, organisations, and society.
  - Identify a team (internal or external) that is independent of AI design and development functions to assess AI system benefits, positive and negative impacts and their likelihood and magnitude.
  - Evaluate and document stakeholder feedback to assess potential impacts for actionable insights regarding trustworthiness characteristics and changes in design approaches and principles.
  - Develop TEVV procedures that incorporate socio-technical elements and methods and plan to normalise across organisational culture. Regularly review and refine TEVV processes.

### MEASURE

Identified risks are assessed, analysed, or tracked.

#### MEASURE 1

Appropriate methods and metrics are identified and applied.

- **MEASURE 1.1** Approaches and metrics for measurement of AI risks enumerated during the Map function are selected for implementation starting with the most significant AI risks. The risks or trustworthiness characteristics that will not –or cannot – be measured are properly documented.
  - Establish approaches for detecting, tracking and measuring known risks, errors, incidents or negative impacts.
  - Identify testing procedures and metrics to demonstrate whether or not the system is fit for purpose and functioning as claimed.
  - Identify testing procedures and metrics to demonstrate AI system trustworthiness
  - Define acceptable limits for system performance (e.g. distribution of errors), and include course correction suggestions if/when the system performs beyond acceptable limits.
  - Define metrics for, and regularly assess, AI actor competency for effective system operation,
  - Identify transparency metrics to assess whether stakeholders have access to necessary information about system design, development, deployment, use, and evaluation.
  - Utilise accountability metrics to determine whether AI designers, developers, and deployers maintain clear and transparent lines of responsibility and are open to inquiries.
  - Document metric selection criteria and include considered but unused metrics.
  - Monitor AI system external inputs including training data, models developed for other contexts, system components reused from other contexts, and third-party tools and resources.
  - Report metrics to inform assessments of system generalisability and reliability.
  - Assess and document pre- vs post-deployment system performance. Include existing and emergent risks.
  - Document risks or trustworthiness characteristics identified in the Map function that will not be measured, including justification for non- measurement.
- **MEASURE 1.2** Appropriateness of AI metrics and effectiveness of existing controls is regularly assessed and updated including reports of errors and impacts on affected communities.
  - Assess external validity of all measurements (e.g., the degree to which measurements taken in one context can generalise to other contexts).
  - Assess effectiveness of existing metrics and controls on a regular basis throughout the AI system lifecycle.
  - Document reports of errors, incidents and negative impacts and assess sufficiency and efficacy of existing metrics for repairs, and upgrades
  - Develop new metrics when existing metrics are insufficient or ineffective for implementing repairs and upgrades.
  - Develop and utilise metrics to monitor, characterise and track external inputs, including any third-party tools.
  - Determine frequency and scope for sharing metrics and related information with stakeholders and impacted communities.
  - Utilise stakeholder feedback processes established in the Map function to capture, act upon and share feedback from end users and potentially impacted communities.
  - Collect and report software quality metrics such as rates of bug occurrence and severity, time to response, and time to repair (See Manage 4.3).
- **MEASURE 1.3** Internal experts who did not serve as front-line developers for the system and/or independent assessors are involved in regular assessments and updates. Domain experts, users, AI actors external to the team that developed or deployed the AI system, and affected communities are consulted in support of assessments as necessary per organisational risk tolerance.
  - Evaluate TEVV processes regarding incentives to identify risks and impacts.
  - Utilise separate testing teams established in the Govern function (2.1 and 4.1) to enable independent decisions and course-correction for AI systems. Track processes and measure and document change in performance.
  - Plan and evaluate AI system prototypes with end user populations early and continuously in the AI lifecycle. Document test outcomes and course correct.
  - Assess independence and stature of TEVV and oversight AI actors, to ensure they have the required levels of independence and resources to perform assurance, compliance, and feedback tasks effectively
  - Evaluate interdisciplinary and demographically diverse internal team established in Map 1.2
  - Evaluate effectiveness of external stakeholder feedback mechanisms, specifically related to processes for eliciting, evaluating and integrating input from diverse groups.
  - Evaluate effectiveness of external stakeholder feedback mechanisms for enhancing AI actor visibility and decision making regarding AI system risks and trustworthy characteristics.
  - Identify and utilise participatory approaches for assessing impacts that may arise from changes in system deployment (e.g., introducing new technology, decommissioning algorithms and models, adapting system, model or algorithm)

#### MEASURE 2

AI systems are evaluated for trustworthy characteristics.

- **MEASURE 2.1** Test sets, metrics, and details about the tools used during test, evaluation, validation, and verification (TEVV) are documented.
  - Leverage existing industry best practices for transparency and documentation of all possible aspects of measurements. Examples include: data sheet for data sets, model cards
  - Regularly assess the effectiveness of tools used to document measurement approaches, test sets, metrics, processes and materials used
  - Update the tools as needed
- **MEASURE 2.2** Evaluations involving human subjects meet applicable requirements(including human subject protection) and are representative of the relevant population.
  - Follow human subjects research requirements as established by organisational and disciplinary requirements, including informed consent and compensation, during dataset collection activities.
  - Analyse differences between intended and actual population of users or data subjects, including likelihood for errors, incidents or negative impacts.
  - Utilise disaggregated evaluation methods (e.g. by race, age, gender, ethnicity, ability, region) to improve AI system performance when deployed in real world settings.
  - Establish thresholds and alert procedures for dataset representativeness within the context of use.
  - Construct datasets in close collaboration with experts with knowledge of the context of use.
  - Follow intellectual property and privacy rights related to datasets and their use, including for the subjects represented in the data.
  - Evaluate data representativeness through
    - investigating known failure modes,
    - assessing data quality and diverse sourcing,
    - applying public benchmarks,
    - traditional bias testing,
    - chaos engineering,
    - stakeholder feedback
  - Use informed consent for individuals providing data used in system testing and evaluation.
- **MEASURE 2.3** AI system performance or assurance criteria are measured qualitatively or quantitatively and demonstrated for conditions similar to deployment setting(s). measures are documented.
  - Conduct regular and sustained engagement with potentially impacted communities
  - Maintain a demographically diverse and multidisciplinary and collaborative internal team
  - Regularly test and evaluate systems in non-optimised conditions, and in collaboration with AI actors in user interaction and user experience (UI/UX) roles.
  - Evaluate feedback from stakeholder engagement activities, in collaboration with human factors and socio-technical experts.
  - Collaborate with socio-technical, human factors, and UI/UX experts to identify notable characteristics in context of use that can be translated into system testing scenarios.
  - Measure AI systems prior to deployment in conditions similar to expected scenarios.
  - Measure and document performance criteria such as validity (false positive rate, false negative rate, etc.) and efficiency (training times, prediction latency, etc.) related to ground truth within the deployment context of use.
  - Measure assurance criteria such as AI actor competency and experience.
  - Document differences between measurement setting and the deployment environment(s).
- **MEASURE 2.4** The functionality and behaviour of the AI system and its components – as identified in the MAP function – are monitored when in production.
  - Monitor and document how metrics and performance indicators observed in production differ from the same metrics collected during pre-deployment testing. When differences are observed, consider error propagation and feedback loop risks.
  - Utilise hypothesis testing or human domain expertise to measure monitored distribution differences in new input or output data relative to test environments
  - Monitor for anomalies using approaches such as control limits, confidence intervals, integrity constraints and ML algorithms. When anomalies are observed, consider error propagation and feedback loop risks.
  - Verify alerts are in place for when distributions in new input data or generated predictions observed in production differ from pre-deployment test outcomes, or when anomalies are detected.
  - Assess the accuracy and quality of generated outputs against new collected ground-truth information as it becomes available.
  - Utilise human review to track processing of unexpected data and reliability of generated outputs; warn system users when outputs may be unreliable. Verify that human overseers responsible for these processes have clearly defined responsibilities and training for specified tasks.
  - Collect uses cases from the operational environment for system testing and monitoring activities in accordance with organisational policies and regulatory or disciplinary requirements (e.g. informed consent, institutional review board approval, human research protections),
- **MEASURE 2.5** The AI system to be deployed is demonstrated to be valid and reliable. Limitations of the generalisability beyond the conditions under which the technology was developed are documented.
  - Define the operating conditions and socio-technical context under which the AI system will be validated.
  - Define and document processes to establish the system’s operational conditions and limits.
  - Establish or identify, and document approaches to measure forms of validity, including:
    - construct validity (the test is measuring the concept it claims to measure)
    - internal validity (relationship being tested is not influenced by other factors or variables)
    - external validity (results are generalisable beyond the training condition)
    - the use of experimental design principles and statistical analyses and modeling.
  - Assess and document system variance. Standard approaches include confidence intervals, standard deviation, standard error, bootstrapping, or cross-validation.
  - Establish or identify, and document robustness measures.
  - Establish or identify, and document reliability measures.
  - Establish practices to specify and document the assumptions underlying measurement models to ensure proxies accurately reflect the concept being measured.
  - Utilise standard software testing approaches (e.g. unit, integration, functional and chaos testing, computer-generated test cases, etc.)
  - Utilise standard statistical methods to test bias, inferential associations, correlation, and covariance in adopted measurement models.
  - Utilise standard statistical methods to test variance and reliability of system outcomes.
  - Monitor operating conditions for system performance outside of defined limits.
  - Identify TEVV approaches for exploring AI system limitations, including testing scenarios that differ from the operational environment. Consult experts with knowledge of specific context of use.
  - Define post-alert actions. Possible actions may include:
    - alerting other relevant AI actors before action,
    - requesting subsequent human review of action,
    - alerting downstream users and stakeholder that the system is operating outside it’s defined validity limits,
    - tracking and mitigating possible error propagation
    - action logging
  - Log input data and relevant system configuration information whenever there is an attempt to use the system beyond its well-defined range of system validity.
  - Modify the system over time to extend its range of system validity to new operating conditions.
- **MEASURE 2.6** AI system is evaluated regularly for safety risks – as identified in the MAP function. The AI system to be deployed is demonstrated to be safe, its residual negative risk does not exceed the risk tolerance, and can fail safely, particularly if made to operate beyond its knowledge limits. Safety metrics implicate system reliability and robustness, real-time monitoring, and response times for AI system failures.
  - Thoroughly measure system performance in development and deployment contexts, and under stress conditions.
    - Employ test data assessments and simulations before proceeding to production testing. Track multiple performance quality and error metrics.
    - Stress-test system performance under likely scenarios (e.g., concept drift, high load) and beyond known limitations, in consultation with domain experts.
    - Test the system under conditions similar to those related to past known incidents or near-misses and measure system performance and safety characteristics
    - Apply chaos engineering approaches to test systems in extreme conditions and gauge unexpected responses.
    - Document the range of conditions under which the system has been tested and demonstrated to fail safely.
  - Measure and monitor system performance in real-time to enable rapid response when AI system incidents are detected.
  - Collect pertinent safety statistics (e.g., out-of-range performance, incident response times, system down time, injuries, etc.) in anticipation of potential information sharing with impacted communities or as required by AI system oversight personnel.
  - Align measurement to the goal of continuous improvement. Seek to increase the range of conditions under which the system is able to fail safely through system modifications in response to in-production testing and events.
  - Document, practice and measure incident response plans for AI system incidents, including measuring response and down times.
  - Compare documented safety testing and monitoring information with established risk tolerances on an on-going basis.
  - Consult MANAGE for detailed information related to managing safety risks.
- **MEASURE 2.7** AI system security and resilience – as identified in the MAP function – are evaluated and documented.
  - Establish and track AI system security tests and metrics (e.g., red-teaming activities, frequency and rate of anomalous events, system down-time, incident response times, time-to-bypass, etc.).
  - Use red-team exercises to actively test the system under adversarial or stress conditions, measure system response, assess failure modes or determine if system can return to normal function after an unexpected adverse event.
  - Document red-team exercise results as part of continuous improvement efforts, including the range of security test conditions and results.
  - Use red-teaming exercises to evaluate potential mismatches between claimed and actual system performance.
  - Use countermeasures (e.g, authentication, throttling, differential privacy, robust ML approaches) to increase the range of security conditions under which the system is able to return to normal function.
  - Modify system security procedures and countermeasures to increase robustness and resilience to attacks in response to testing and events experienced in production.
  - Verify that information about errors and attack patterns is shared with incident databases, other organisations with similar systems, and system users and stakeholders (MANAGE-4.1).
  - Develop and maintain information sharing practices with AI actors from other organisations to learn from common attacks.
  - Verify that third party AI resources and personnel undergo security audits and screenings. Risk indicators may include failure of third parties to provide relevant security information.
  - Utilise watermarking technologies as a deterrent to data and model extraction attacks.
- **MEASURE 2.8** Risks associated with transparency and accountability – as identified in the MAP function – are examined and documented.
  - Instrument the system for measurement and tracking, e.g., by maintaining histories, audit logs and other information that can be used by AI actors to review and evaluate possible sources of error, bias, or vulnerability.
  - Calibrate controls for users in close collaboration with experts in user interaction and user experience (UI/UX), human computer interaction (HCI), and/or human-AI teaming.
  - Test provided explanations for calibration with different audiences including operators, end users, decision makers and decision subjects (individuals for whom decisions are being made), and to enable recourse for consequential system decisions that affect end users or subjects.
  - Measure and document human oversight of AI systems:
    - Document the degree of oversight that is provided by specified AI actors regarding AI system output.
    - Maintain statistics about downstream actions by end users and operators such as system overrides.
    - Maintain statistics about and document reported errors or complaints, time to respond, and response types.
    - Maintain and report statistics about adjudication activities.
  - Track, document, and measure organisational accountability regarding AI systems via policy exceptions and escalations, and document “go” and “no/go” decisions made by accountable parties.
  - Track and audit the effectiveness of organisational mechanisms related to AI risk management, including:
    - Lines of communication between AI actors, executive leadership, users and impacted communities.
    - Roles and responsibilities for AI actors and executive leadership.
    - Organisational accountability roles, e.g., chief model risk officers, AI oversight committees, responsible or ethical AI directors, etc.
- **MEASURE 2.9** The AI model is explained, validated, and documented, and an AI system output is interpreted within its context – as identified in the MAP function –and to inform responsible use and governance.
  - Verify systems are developed to produce explainable models, post-hoc explanations and audit logs.
  - When possible or available, utilise approaches that are inherently explainable, such as traditional and penalised generalised linear models , decision trees, nearest-neighbour and prototype-based approaches, rule-based models, generalised additive models , explainable boosting machines and neural additive models.
  - Test explanation methods and resulting explanations prior to deployment to gain feedback from relevant AI actors, end users, and potentially impacted individuals or groups about whether explanations are accurate, clear, and understandable.
  - Document AI model details including model type (e.g., convolutional neural network, reinforcement learning, decision tree, random forest, etc.) data features, training algorithms, proposed uses, decision thresholds, training data, evaluation data, and ethical considerations.
  - Establish, document, and report performance and error metrics across demographic groups and other segments relevant to the deployment context.
  - Explain systems using a variety of methods, e.g., visualisations, model extraction, feature importance, and others. Since explanations may not accurately summarise complex systems, test explanations according to properties such as fidelity, consistency, robustness, and interpretability.
  - Assess the characteristics of system explanations according to properties such as fidelity (local and global), ambiguity, interpretability, interactivity, consistency, and resilience to attack/manipulation.
  - Test the quality of system explanations with end-users and other groups.
  - Secure model development processes to avoid vulnerability to external manipulation such as gaming explanation processes.
  - Test for changes in models over time, including for models that adjust in response to production data.
  - Use transparency tools such as data statements and model cards to document explanatory and validation information.
- **MEASURE 2.10** Privacy risk of the AI system – as identified in the MAP function – is examined and documented.
  - Specify privacy-related values, frameworks, and attributes that are applicable in the context of use through direct engagement with end users and potentially impacted groups and communities.
  - Document collection, use, management, and disclosure of personally sensitive information in datasets, in accordance with privacy and data governance policies
  - Quantify privacy-level data aspects such as the ability to identify individuals or groups (e.g. k-anonymity metrics, l-diversity, t-closeness).
  - Establish and document protocols (authorisation, duration, type) and access controls for training sets or production data containing personally sensitive information, in accordance with privacy and data governance policies.
  - Monitor internal queries to production data for detecting patterns that isolate personal records.
  - Monitor PSI disclosures and inference of sensitive or legally protected attributes
    - Assess the risk of manipulation from overly customised content. Evaluate information presented to representative users at various points along axes of difference between individuals (e.g. individuals of different ages, genders, races, political affiliation, etc.).
  - Use privacy-enhancing techniques such as differential privacy, when publicly sharing dataset information.
  - Collaborate with privacy experts, AI end users and operators, and other domain experts to determine optimal differential privacy metrics within contexts of use.
- **MEASURE 2.11** Fairness and bias – as identified in the MAP function – is evaluated and results are documented.
  - Conduct fairness assessments to manage computational and statistical forms of bias which include the following steps:
    - Identify types of harms, including allocational, representational, quality of service, stereotyping, or erasure
    - Identify across, within, and intersecting groups that might be harmed
    - Quantify harms using both a general fairness metric, if appropriate (e.g. demographic parity, equalised odds, equal opportunity, statistical hypothesis tests), and custom, context-specific metrics developed in collaboration with affected communities
    - Analyse quantified harms for contextually significant differences across groups, within groups, and among intersecting groups
    - Refine identification of within-group and intersectional group disparities.
    - Evaluate underlying data distributions and employ sensitivity analysis during the analysis of quantified harms.
    - Evaluate quality metrics including false positive rates and false negative rates.
    - Consider biases affecting small groups, within-group or intersectional communities, or single individuals.
  - Understand and consider sources of bias in training and TEVV data:
    - Differences in distributions of outcomes across and within groups, including intersecting groups.
    - Completeness, representativeness and balance of data sources.
    - Identify input data features that may serve as proxies for demographic group membership (i.e., credit score, ZIP code) or otherwise give rise to emergent bias within AI systems.
    - Forms of systemic bias in images, text (or word embeddings), audio or other complex or unstructured data.
  - Leverage impact assessments to identify and classify system impacts and harms to end users, other individuals, and groups with input from potentially impacted communities.
  - Identify the classes of individuals, groups, or environmental ecosystems which might be impacted through direct engagement with potentially impacted communities.
  - Evaluate systems in regards to disability inclusion, including consideration of disability status in bias testing, and discriminatory screen out processes that may arise from non-inclusive design or deployment decisions.
  - Develop objective functions in consideration of systemic biases, in-group/out-group dynamics.
  - Use context-specific fairness metrics to examine how system performance varies across groups, within groups, and/or for intersecting groups. Metrics may include statistical parity, error-rate equality, statistical parity difference, equal opportunity difference, average absolute odds difference, standardised mean difference, percentage point differences.
  - Customise fairness metrics to specific context of use to examine how system performance and potential harms vary within contextual norms.
  - Define acceptable levels of difference in performance in accordance with established organisational governance policies, business requirements, regulatory compliance, legal frameworks, and ethical standards within the context of use
  - Define the actions to be taken if disparity levels rise above acceptable levels.
  - Identify groups within the expected population that may require disaggregated analysis, in collaboration with impacted communities.
  - Leverage experts with knowledge in the specific context of use to investigate substantial measurement differences and identify root causes for those differences.
  - Monitor system outputs for performance or bias issues that exceed established tolerance levels.
  - Ensure periodic model updates; test and recalibrate with updated and more representative data to stay within acceptable levels of difference.
  - Apply pre-processing data transformations to address factors related to demographic balance and data representativeness.
  - Apply in-processing to balance model performance quality with bias considerations.
  - Apply post-processing mathematical/computational techniques to model results in close collaboration with impact assessors, socio-technical experts, and other AI actors with expertise in the context of use.
  - Apply model selection approaches with transparent and deliberate consideration of bias management and other trustworthy characteristics.
  - Collect and share information about differences in outcomes for the identified groups.
  - Consider mediations to mitigate differences, especially those that can be traced to past patterns of unfair or biased human decision making.
  - Utilise human-centred design practices to generate deeper focus on societal impacts and counter human-cognitive biases within the AI lifecycle.
  - Evaluate practices along the lifecycle to identify potential sources of human-cognitive bias such as availability, observational, and confirmation bias, and to make implicit decision making processes more explicit and open to investigation.
  - Work with human factors experts to evaluate biases in the presentation of system output to end users, operators and practitioners.
  - Utilise processes to enhance contextual awareness, such as diverse internal staff and stakeholder engagement.
- **MEASURE 2.12** Environmental impact and sustainability of AI model training and management activities – as identified in the MAP function – are assessed and documented.
  - Include environmental impact indicators in AI system design and development plans, including reducing consumption and improving efficiencies.
  - Identify and implement key indicators of AI system energy and water consumption and efficiency, and/or GHG emissions.
  - Establish measurable baselines for sustainable AI system operation in accordance with organisational policies, regulatory compliance, legal frameworks, and environmental protection and sustainability norms.
  - Assess tradeoffs between AI system performance and sustainable operations in accordance with organisational principles and policies, regulatory compliance, legal frameworks, and environmental protection and sustainability norms.
  - Identify and establish acceptable resource consumption and efficiency, and GHG emissions levels, along with actions to be taken if indicators rise above acceptable levels.
  - Estimate AI system emissions levels throughout the AI lifecycle via carbon calculators or similar process.
- **MEASURE 2.13** Effectiveness of the employed TEVV metrics and processes in the measure function are evaluated and documented.
  - Review selected system metrics and associated TEVV processes to determine if they are able to sustain system improvements, including the identification and removal of errors.
  - Regularly evaluate system metrics for utility, and consider descriptive approaches in place of overly complex methods.
  - Review selected system metrics for acceptability within the end user and impacted community of interest.
  - Assess effectiveness of metrics for identifying and measuring risks.

#### MEASURE 3

Mechanisms for tracking identified AI risks over time are in place.

- **MEASURE 3.1** Approaches, personnel, and documentation are in place to regularly identify and track existing, unanticipated, and emergent AI risks based on factors such as intended and actual performance in deployed contexts.
  - Compare AI system risks with:
    - simpler or traditional models
    - human baseline performance
    - other manual performance benchmarks
  - Compare end user and community feedback about deployed AI systems to internal measures of system performance.
  - Assess effectiveness of metrics for identifying and measuring emergent risks.
  - Measure error response times and track response quality.
  - Elicit and track feedback from AI actors in user support roles about the type of metrics, explanations and other system information required for fulsome resolution of system issues. Consider:
    - Instances where explanations are insufficient for investigating possible error sources or identifying responses.
    - System metrics, including system logs and explanations, for identifying and diagnosing sources of system error.
  - Elicit and track feedback from AI actors in incident response and support roles about the adequacy of staffing and resources to perform their duties in an effective and timely manner.
- **MEASURE 3.2** Risk tracking approaches are considered for settings where AI risks are difficult to assess using currently available measurement techniques or where metrics are not yet available.
  - Establish processes for tracking emergent risks that may not be measurable with current approaches. Some processes may include:
    - Recourse mechanisms for faulty AI system outputs.
    - Bug bounties.
    - Human-centred design approaches.
    - User-interaction and experience research.
    - Participatory stakeholder engagement with affected or potentially impacted individuals and communities.
  - Identify AI actors responsible for tracking emergent risks and inventory methods.
  - Determine and document the rate of occurrence and severity level for complex or difficult-to-measure risks when:
    - Prioritising new measurement approaches for deployment tasks.
    - Allocating AI system risk management resources.
    - Evaluating AI system improvements.
    - Making go/no-go decisions for subsequent system iterations.
- **MEASURE 3.3** Feedback processes for end users and impacted communities to report problems and appeal system outcomes are established and integrated into AI system evaluation metrics.
  - Measure efficacy of end user and operator error reporting processes.
  - Categorise and analyse type and rate of end user appeal requests and results.
  - Measure feedback activity participation rates and awareness of feedback activity availability.
  - Utilise feedback to analyse measurement approaches and determine subsequent courses of action.
  - Evaluate measurement approaches to determine efficacy for enhancing organisational understanding of real world impacts.
  - Analyse end user and community feedback in close collaboration with domain experts.

#### MEASURE 4

Feedback about efficacy of measurement is gathered and assessed.

- **MEASURE 4.1** measurement approaches for identifying AI risks are connected to deployment context(s) and informed through consultation with domain experts and other end users. Approaches are documented.
  - Support mechanisms for capturing feedback from system end users (including domain experts, operators, and practitioners). Successful approaches are:
    - conducted in settings where end users are able to openly share their doubts and insights about AI system output, and in connection to their specific context of use (including setting and task-specific lines of inquiry)
    - developed and implemented by human-factors and socio-technical domain experts and researchers
    - designed to ensure control of interviewer and end user subjectivity and biases
  - Identify and document approaches
    - for evaluating and integrating elicited feedback from system end users
    - in collaboration with human-factors and socio-technical domain experts,
    - to actively inform a process of continual improvement.
  - Evaluate feedback from end users alongside evaluated feedback from impacted communities (MEASURE 3.3).
  - Utilise end user feedback to investigate how selected metrics and measurement approaches interact with organisational and operational contexts.
  - Analyse and document system-internal measurement processes in comparison to collected end user feedback.
  - Identify and implement approaches to measure effectiveness and satisfaction with end user elicitation techniques, and document results.
- **MEASURE 4.2** measurement results regarding AI system trustworthiness in deployment context(s) and across AI lifecycle are informed by input from domain experts and other relevant AI actors to validate whether the system is performing consistently as intended. Results are documented.
  - Integrate feedback from end users, operators, and affected individuals and communities from Map function as inputs to assess AI system trustworthiness characteristics. Ensure both positive and negative feedback is being assessed.
  - Evaluate feedback in connection with AI system trustworthiness characteristics from Measure 2.5 to 2.11.
  - Evaluate feedback regarding end user satisfaction with, and confidence in, AI system performance including whether output is considered valid and reliable, and explainable and interpretable.
  - Identify mechanisms to confirm/support AI system output (e.g. recommendations), and end user perspectives about that output.
  - Measure frequency of AI systems’ override decisions, evaluate and document results, and feed insights back into continual improvement processes.
  - Consult AI actors in impact assessment, human factors and socio-technical tasks to assist with analysis and interpretation of results.
- **MEASURE 4.3** Measurable performance improvements or declines based on consultations with relevant AI actors including affected communities, and field data about context-relevant risks and trustworthiness characteristics, are identified and documented.
  - Develop baseline quantitative measures for trustworthy characteristics.
  - Delimit and characterise baseline operation values and states.
  - Utilise qualitative approaches to augment and complement quantitative baseline measures, in close coordination with impact assessment, human factors and socio-technical AI actors.
  - Monitor and assess measurements as part of continual improvement to identify potential system adjustments or modifications
  - Perform and document sensitivity analysis to characterise actual and expected variance in performance after applying system or procedural updates.
  - Document decisions related to the sensitivity analysis and record expected influence on system performance and identified risks.

### MANAGE

Risks are prioritised and acted upon based on a projected impact.

#### MANAGE 1

AI risks based on assessments and other analytical output from the Map and measure functions are prioritised, responded to, and managed.

- **MANAGE 1.1** A determination is made as to whether the AI system achieves its intended purpose and stated objectives and whether its development or deployment should proceed.
  - Consider trustworthiness characteristics when evaluating AI systems’ negative risks and benefits.
  - Utilise TEVV outputs from map and measure functions when considering risk treatment.
  - Regularly track and monitor negative risks and benefits throughout the AI system lifecycle including in post-deployment monitoring.
  - Regularly assess and document system performance relative to trustworthiness characteristics and tradeoffs between negative risks and opportunities.
  - Evaluate tradeoffs in connection with real-world use cases and impacts and as enumerated in Map function outcomes.
- **MANAGE 1.2** Treatment of documented AI risks is prioritised based on impact, likelihood, or available resources or methods.
  - Assign risk management resources relative to established risk tolerance. AI systems with lower risk tolerances receive greater oversight, mitigation and management resources.
  - Document AI risk tolerance determination practices and resource decisions.
  - Regularly review risk tolerances and re-calibrate, as needed, in accordance with information from AI system monitoring and assessment .
- **MANAGE 1.3** Responses to the AI risks deemed high priority as identified by the Map function, are developed, planned, and documented. Risk response options can include mitigating, transferring, avoiding, or accepting.
  - Observe regulatory and established organisational, sector, discipline, or professional standards and requirements for applying risk tolerances within the organisation.
  - Document procedures for acting on AI system risks related to trustworthiness characteristics.
  - Prioritise risks involving physical safety, legal liabilities, regulatory compliance, and negative impacts on individuals, groups, or society.
  - Identify risk response plans and resources and organisational teams for carrying out response functions.
  - Store risk management and system documentation in an organised, secure repository that is accessible by relevant AI Actors and appropriate personnel.
- **MANAGE 1.4** Negative residual risks (defined as the sum of all unmitigated risks) to both downstream acquirers of AI systems and end users are documented.
  - Document residual risks within risk response plans, denoting risks that have been accepted, transferred, or subject to minimal mitigation.
  - Establish procedures for disclosing residual risks to relevant downstream AI actors .
  - Inform relevant downstream AI actors of requirements for safe operation, known limitations, and suggested warning labels as identified in MAP 3.4.

#### MANAGE 2

Strategies to maximise AI benefits and minimise negative impacts are planned, prepared, implemented, and documented, and informed by input from relevant AI actors.

- **MANAGE 2.1** Resources required to manage AI risks are taken into account, along with viable non-AI alternative systems, approaches, or methods – to reduce the magnitude or likelihood of potential impacts.
  - Plan and implement risk management practices in accordance with established organisational risk tolerances.
  - Verify risk management teams are resourced to carry out functions, including
    - Establishing processes for considering methods that are not automated; semi-automated; or other procedural alternatives for AI functions.
    - Enhance AI system transparency mechanisms for AI teams.
    - Enable exploration of AI system limitations by AI teams.
    - Identify, assess, and catalogue past failed designs and negative impacts or outcomes to avoid known failure modes.
  - Identify resource allocation approaches for managing risks in systems:
    - deemed high-risk,
    - that self-update (adaptive, online, reinforcement self-supervised learning or similar),
    - trained without access to ground truth (unsupervised, semi-supervised, learning or similar),
    - with high uncertainty or where risk management is insufficient.
  - Regularly seek and integrate external expertise and perspectives to supplement organisational diversity (e.g. demographic, disciplinary), equity, inclusion, and accessibility where internal capacity is lacking.
  - Enable and encourage regular, open communication and feedback among AI actors and internal or external stakeholders related to system design or deployment decisions.
  - Prepare and document plans for continuous monitoring and feedback mechanisms.
- **MANAGE 2.2** Mechanisms are in place and applied to sustain the value of deployed AI systems.
  - Establish risk controls considering trustworthiness characteristics, including:
    - Data management, quality, and privacy (e.g. minimisation, rectification or deletion requests) controls as part of organisational data governance policies.
    - Machine learning and end-point security countermeasures (e.g., robust models, differential privacy, authentication, throttling).
    - Business rules that augment, limit or restrict AI system outputs within certain contexts
    - Utilising domain expertise related to deployment context for continuous improvement and TEVV across the AI lifecycle.
    - Development and regular tracking of human-AI teaming configurations.
    - Model assessment and test, evaluation, validation and verification (TEVV) protocols.
    - Use of standardised documentation and transparency mechanisms.
    - Software quality assurance practices across AI lifecycle.
    - Mechanisms to explore system limitations and avoid past failed designs or deployments.
  - Establish mechanisms to capture feedback from system end users and potentially impacted groups while system is in deployment.
  - Establish mechanisms to capture feedback from system end users and potentially impacted groups about how changes in system deployment (e.g., introducing new technology, decommissioning algorithms and models, adapting system, model or algorithm) may create negative impacts that are not visible along the AI lifecycle.
  - Review insurance policies, warranties, or contracts for legal or oversight requirements for risk transfer procedures.
  - Document risk tolerance decisions and risk acceptance procedures.
- **MANAGE 2.3** Procedures are followed to respond to and recover from a previously unknown risk when it is identified.
  - Protocols, resources, and metrics are in place for continual monitoring of AI systems’ performance, trustworthiness, and alignment with contextual norms and values
  - Establish and regularly review treatment and response plans for incidents, negative impacts, or outcomes.
  - Establish and maintain procedures to regularly monitor system components for drift, decontextualisation, or other AI system behaviour factors,
  - Establish and maintain procedures for capturing feedback about negative impacts.
  - Verify contingency processes to handle any negative impacts associated with mission-critical AI systems, and to deactivate systems.
  - Enable preventive and post-hoc exploration of AI system limitations by relevant AI actor groups.
  - Decommission systems that exceed risk tolerances.
- **MANAGE 2.4** Mechanisms are in place and applied, responsibilities are assigned and understood to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use.
  - Regularly review established procedures for AI system bypass actions, including plans for redundant or backup systems to ensure continuity of operational and/or business functionality.
  - Regularly review Identify system incident thresholds for activating bypass or deactivation responses.
  - Apply change management processes to understand the upstream and downstream consequences of bypassing or deactivating an AI system or AI system components.
  - Apply protocols, resources and metrics for decisions to supersede, bypass or deactivate AI systems or AI system components.
  - Preserve materials for forensic, regulatory, and legal review.
  - Conduct internal root cause analysis and process reviews of bypass or deactivation events.
  - Decommission and preserve system components that cannot be updated to meet criteria for redeployment.
  - Establish criteria for redeploying updated system components, in consideration of trustworthy characteristics

#### MANAGE 3

AI risks and benefits from third-party entities are managed.

- **MANAGE 3.1** AI risks and benefits from third-party resources are regularly monitored, and risk controls are applied and documented.
  - Have legal requirements been addressed?
  - Apply organisational risk tolerance to third-party AI systems.
  - Apply and document organisational risk management plans and practices to third-party AI technology, personnel, or other resources.
  - Identify and maintain documentation for third-party AI systems and components.
  - Establish testing, evaluation, validation and verification processes for third-party AI systems which address the needs for transparency without exposing proprietary algorithms .
  - Establish processes to identify beneficial use and risk indicators in third-party systems or components, such as inconsistent software release schedule, sparse documentation, and incomplete software change management (e.g., lack of forward or backward compatibility).
  - Organisations can establish processes for third parties to report known and potential vulnerabilities, risks or biases in supplied resources.
  - Verify contingency processes for handling negative impacts associated with mission-critical third-party AI systems.
  - Monitor third-party AI systems for potential negative impacts and risks associated with trustworthiness characteristics.
  - Decommission third-party systems that exceed risk tolerances.
- **MANAGE 3.2** Pre-trained models which are used for development are monitored as part of AI system regular monitoring and maintenance.
  - Identify pre-trained models within AI system inventory for risk tracking.
  - Establish processes to independently and continually monitor performance and trustworthiness of pre-trained models, and as part of third-party risk tracking.
  - Monitor performance and trustworthiness of AI system components connected to pre-trained models, and as part of third-party risk tracking.
  - Identify, document and remediate risks arising from AI system components and pre-trained models per organisational risk management procedures, and as part of third-party risk tracking.
  - Decommission AI system components and pre-trained models which exceed risk tolerances, and as part of third-party risk tracking.

#### MANAGE 4

Risk treatments including response and recovery, and communication plans to the identified and measured AI risks are documented and monitored regularly.

- **MANAGE 4.1** Post-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other relevant AI actors, appeal and override, decommissioning, incident response, recovery, and change management.
  - Establish and maintain procedures to monitor AI system performance for risks and negative and positive impacts associated with trustworthiness characteristics.
  - Perform post-deployment TEVV tasks to evaluate AI system validity and reliability, bias and fairness, privacy, and security and resilience.
  - Evaluate AI system trustworthiness in conditions similar to deployment context of use, and prior to deployment.
  - Establish and implement red-teaming exercises at a prescribed cadence, and evaluate their efficacy.
  - Establish procedures for tracking dataset modifications such as data deletion or rectification requests.
  - Establish mechanisms for regular communication and feedback between relevant AI actors and internal or external stakeholders to capture information about system performance, trustworthiness and impact.
  - Share information about errors, near-misses, and attack patterns with incident databases, other organisations with similar systems, and system users and stakeholders.
  - Respond to and document detected or reported negative impacts or issues in AI system performance and trustworthiness.
  - Decommission systems that exceed establish risk tolerances.
- **MANAGE 4.2** Measurable activities for continual improvements are integrated into AI system updates and include regular engagement with interested parties, including relevant AI actors.
  - Integrate trustworthiness characteristics into protocols and metrics used for continual improvement.
  - Establish processes for evaluating and integrating feedback into AI system improvements.
  - Assess and evaluate alignment of proposed improvements with relevant regulatory and legal frameworks
  - Assess and evaluate alignment of proposed improvements connected to the values and norms within the context of use.
  - Document the basis for decisions made relative to tradeoffs between trustworthy characteristics, system risks, and system opportunities
- **MANAGE 4.3** Incidents and errors are communicated to relevant AI actors including affected communities. Processes for tracking, responding to, and recovering from incidents and errors are followed and documented.
  - Establish procedures to regularly share information about errors, incidents and negative impacts with relevant stakeholders, operators, practitioners and users, and impacted parties.
  - Maintain a database of reported errors, near-misses, incidents and negative impacts including date reported, number of reports, assessment of impact and severity, and responses.
  - Maintain a database of system changes, reason for change, and details of how the change was made, tested and deployed.
  - Maintain version history information and metadata to enable continuous improvement processes.
  - Verify that relevant AI actors responsible for identifying complex or emergent risks are properly resourced and empowered.

## Sources and counts

The text of every element shown is NIST's own, taken from the exports listed below. Only American spellings have been changed to British English, by a fixed word table, and the CSF 1.1 legacy elements in the CSF 2.0 export are left out. Times are Europe/London.

### Sources

- NIST CSF 2.0 Core with Implementation Examples Cybersecurity and Privacy Reference Tool (CPRT) JSON export, framework version CSF_2_0_0 [https://csrc.nist.gov/extensions/nudp/services/json/nudp/framework/version/csf_2_0_0/export/json?element=all](https://csrc.nist.gov/extensions/nudp/services/json/nudp/framework/version/csf_2_0_0/export/json?element=all) Downloaded 6 October 2026 01:31:21 BST (2026-10-06 00:31:21 UTC), HTTP 200, 753,380 bytes, sha256 `28ba53c5ea2f57fd7fcb56d7f512ab8b28c19516af411dffac6c782debc6c7e1`
- NIST AI RMF 1.0 Core CPRT JSON export, framework version AI_100_1_0_0 (NIST AI 100-1; CPRT data version 1.1.0) [https://csrc.nist.gov/extensions/nudp/services/json/nudp/framework/version/ai_100_1_0_0/export/json?element=all](https://csrc.nist.gov/extensions/nudp/services/json/nudp/framework/version/ai_100_1_0_0/export/json?element=all) Downloaded 6 October 2026 01:37:21 BST (2026-10-06 00:37:21 UTC), HTTP 200, 1,401,322 bytes, sha256 `169a9c5b586dca21225f1cc4d235502e2e27cdf6321cfc47c1ffc93c5eaa673d`
- NIST AI RMF Playbook NIST AI Resource Center JSON download (suggested actions per subcategory) [https://airc.nist.gov/docs/playbook.json](https://airc.nist.gov/docs/playbook.json) Downloaded 6 October 2026 01:33:35 BST (2026-10-06 00:33:35 UTC), HTTP 200, 413,720 bytes, sha256 `aecbee3d3c8820816d295b11d10fb61324b17c25c2ff39ee95e2aa5654555bba`

### Counts

| Framework | Functions | Categories | Subcategories | Examples | Notes |
| --- | --- | --- | --- | --- | --- |
| CSF 2.0 | 6 | 22 | 106 | 363 implementation examples | 91 CSF 1.1 legacy elements removed from the NIST export (12 categories, 79 subcategories marked withdrawn, moved or incorporated into CSF 2.0 elements). |
| AI RMF 1.0 | 4 | 19 | 72 | 462 Playbook suggested actions | First level actions only; nested points are listed under the action they belong to. |

The framework text is published by the National Institute of Standards and Technology.

Vikram Mohan is not a solicitor or barrister. Nothing on this page is legal advice. For legal advice, speak to a regulated legal professional.

© Vikram Mohan. [vikrammohan.com](https://vikrammohan.com/)