HITRUST CSF requirement statement [?] (17.03bAISecOrganizational.4)

The organization identifies the relevant AI-specific security threats (e.g., evasion, 
poisoning, prompt injection) to the deployed AI system
(1) prior to deployment of new models, 
(2) regularly (at least semiannually) thereafter, and
(3) when security incidents related to the AI system occur. 
The organization documents identified AI threat scenarios in a threat register which 
minimally contains
(4) a description of the identified AI security threat and 
(5) the associated component(s) of the AI system (e.g., training data, models, APIs). 

Evaluative elements in this requirement statement [?]

1. The organization identifies the relevant AI-specific security threats (e.g., evasion, 
poisoning, prompt injection) to the deployed AI system prior to deployment of new models.

2. The organization identifies the relevant AI-specific security threats (e.g., evasion, 
poisoning, prompt injection) to the deployed AI system regularly (at least semiannually).

3. The organization identifies the relevant AI-specific security threats (e.g., evasion, 
poisoning, prompt injection) to the deployed AI system when security incidents related 
to the AI system occur.

4. The organization documents identified AI threat scenarios in a threat register which 
minimally contains a description of the identified AI security threat.

5. The organization documents identified AI threat scenarios in a threat register which 
minimally contains the associated component(s) of the AI system (e.g., training data, 
models, APIs).

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample-based test where possible for each evaluative element.
  Example test(s):
  • For example, select a sample from the threat register to confirm all AI-specific security threats are identified and documented. Further, confirm that the threat register contains a detailed description of the identified AI security threat and the associated component(s) of the AI system (e.g., training data, models, APIs). Further, confirm that the threat register was reviewed and updated if needed at least at the frequency mandated in the requirement statement.
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate the percentage of the organization’s AI-specific security threats that are correctly documented in the threat register. Reviews, tests, or audits are completed by the organization to measure the effectiveness of the implemented controls and to confirm that relevant AI-specific security threats (e.g., evasion, poisoning, prompt injection) to the deployed AI system are identified prior to deployment of new models, regularly (at least at the frequency mandated in the requirement statement) thereafter, and when security incidents related to the AI system occur.
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 17 Risk Management
• Control category: 03.0 – Risk Management
• Control reference: 03.b – Performing Risk Assessments
  
  

Specific to which parts of the overall AI system? [?]

• N/A, not AI component-specific
  
  

Discussed in which authoritative AI security sources? [?]

• ISO/IEC 23894:2023 Information technology — Artificial intelligence — Guidance on risk management
  2023, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • Part 6. Risk management process > 6.4 Risk assessment > 6.4.2 Risk identification > 6.4.2.3 Identification of risk sources
    • Part 6. Risk management process > 6.4 Risk assessment > 6.4.2 Risk identification > 6.4.2.4 Identification of potential events and outcomes
      
      

• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #SECDEVPROGRAM
    • #how-to-select-relevant-threats-and-controls-risk-analysis
      
      

• LLM AI Cybersecurity & Governance Checklist
  Feb. 2024, © The OWASP Foundation
  • Where:
    • 3. Checklist > 3.9. Using or implementing large language models > Bullet #9
    • 3. Checklist > 3.9. Using or implementing large language models > Bullet #10
      
      

• Guidelines for Secure AI System Development
  Nov. 2023, Cybersecurity & Infrastructure Security Agency (CISA)
  • Where:
    • 1. Secure design > Model the threats to your system
      
      

• Deploying AI Systems Securely: Best Practices for Deploying Secure and Resilient AI Systems
  Apr 2024, National Security Agency (NSA)
  • Where:
    • Secure the deployment environment > Manage deployment environment governance > Bullet 1, sub-bullet 1
      
      

• Generative AI framework for HM Government
  2023, Central Digital and Data Office, UK Government
  • Where:
    • Using generative AI safely and responsibly > Security > Security Risks > Practical security recommendations > Bullet 1
      
      

• Securing Machine Learning Algorithms
  2021, © European Union Agency for Cybersecurity (ENISA)
  • Where:
    • 4.1- Security Controls > Specific ML > Implement processes to maintain security levels of ML components over time
      
      

Discussed in which commercial AI security sources? [?]

• Databricks AI Security Framework
  Sept. 2024, © Databricks
  • Where:
    • Control DASF 38: Platform security — vulnerability management (Operations and Platform)
      
      
• Google Secure AI Framework
  June 2023, © Google
  • Where:
    • Step 4. Apply the six core elements of the SAIF > Extend detection and response to bring AI into an organization’s threat universe > Develop understanding of threats that matter for AI usage scenarios, the types of AI used, etc.
    • Step 4. Apply the six core elements of the SAIF > Adapt controls to adjust mitigations and create faster feedback loops for AI deployment > Stay on top of novel attacks including prompt injection, data poisoning and evasion attacks
    • Step 4. Apply the six core elements of the SAIF > Contextualize AI system risks in surrounding business processes > Establish a model risk management framework and build a team that understands AI-related risks
      
      
• HiddenLayer’s 2024 AI Threat Landscape Report
  2024, © HiddenLayer
  • Where:
    • Part 4: Predictions and recommendations > 2. Risk assessment and threat modeling
      
      

Control functions against which AI security threats? [?]

• Control function: Decision support
  • Denial of AI service
  • Prompt injection
  • Evasion
  • Model inversion
  • Model extraction and theft
  • Data poisoning
  • Model poisoning
  • Compromised 3rd-party training datasets
  • Compromised 3rd-party models or code
  • Confabulation
  • Excessive agency
  • Sensitive information disclosed in output

Additional information

• Q: When will this requirement included in an assessment? [?]
  • This requirement will always be added to HITRUST assessments which include the
    Security for AI systems regulatory factor.
  • No other assessment tailoring factors affect this requirement.
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • No (dual responsibility). The AI application provider and its AI service providers (if used) are responsible for independently performing this requirement outside of the AI system’s technology stack.

HITRUST CSF requirement statement [?] (17.03bAISecOrganizational.5)

The organization performs threat modeling for the AI system to 
(1) evaluate its exposure to identified AI security threats, 
(2) identify countermeasures currently in place to mitigate those threats, and 
(3) identify any additional countermeasures deemed necessary considering the 
organization’s overall risk tolerance and the risk categorization of the AI system. 
This activity is performed 
(4) upon identification of new AI security threats, 
(5) prior to deployment of new models, 
(6) regularly (at least semiannually) thereafter, and 
(7) when security incidents related to the AI system occur.

Evaluative elements in this requirement statement [?]

1. The organization performs threat modeling for the AI system 
to evaluate its exposure to identified AI security threats.

2. The organization performs threat modeling for the AI system 
to identify countermeasures currently in place to mitigate AI security threats.

3. The organization performs threat modeling for the AI system 
to identify any additional countermeasures deemed necessary considering the 
organization’s overall risk tolerance and the risk categorization of the AI system.

4. Threat modeling for the AI system is performed upon 
identification of new AI security threats.

5. Threat modeling for the AI system is performed prior to 
deployment of new models.

6. Threat modeling for the AI system is performed regularly 
(at least semiannually).

7. Threat modeling for the AI system is performed when security 
incidents related to the AI system occur.

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample based test where possible for each evaluative element. Example test(s):
  • For example, select a sample of newly identified AI security threats and security incidents related to the AI system and examine evidence to confirm threat modeling was performed for the AI system. Additionally, examine evidence to confirm threat modeling was performed for the AI system prior to deployment of new models and at least at the frequency mandated in the requirement statement. Further, confirm that the modeling evaluated the exposure to identified AI security threats, identified countermeasures currently in place to mitigate those threats, and identified any additional countermeasures deemed necessary considering the organization’s overall risk tolerance and the risk categorization of the AI system.
  • For example, select a sample of the documented AI system threat modeling to confirm AI security threats are identified. Further, confirm that the modeling evaluates the exposure to identified AI security threats, identifies countermeasures currently in place to mitigate those threats, and identifies any additional countermeasures deemed necessary considering the organization’s overall risk tolerance and the risk categorization of the AI system.
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate the percentage of threats and security incidents for which threat modeling was not performed. Reviews, tests, or audits are completed by the organization to measure the effectiveness of the implemented controls and confirm the organization performs threat modeling for the AI system.
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 17 Risk Management
• Control category: 03.0 – Risk Management
• Control reference: 03.b – Performing Risk Assessments
  
  

Specific to which parts of the overall AI system? [?]

• N/A, not AI component-specific
  
  

Discussed in which authoritative AI security sources? [?]

• ISO/IEC 23894:2023 Information technology — Artificial intelligence — Guidance on risk management
  2023, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • Part 6. Risk management process > 6.4 Risk assessment > 6.4.2 Risk identification > 6.4.2.5 Identification of controls
    • Part 6. Risk management process > 6.4 Risk assessment > 6.4.2 Risk identification > 6.5.2 Selection of risk treatment options
      
      

• ISO/IEC 38507:2022- Governance implications of the use of artificial intelligence by organizations
  2022, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • 4. Governance implications of the organizational use of AI > 4.2. Maintaining governance when introducing AI
    • 5. Overview of AI and AI systems > 5.1. General
      
      

• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #how-to-select-relevant-threats-and-controls-risk-analysis
    • #SECDEVPROGRAM
      
      

• Guidelines for Secure AI System Development
  Nov. 2023, Cybersecurity & Infrastructure Security Agency (CISA)
  • Where:
    • 1. Secure design > Model the threats to your system
    • 2. Secure development > Identify, track, and protect your assets
      
      

• Deploying AI Systems Securely: Best Practices for Deploying Secure and Resilient AI Systems
  Apr 2024, National Security Agency (NSA)
  • Where:
    • Secure the deployment environment > Manage deployment environment governance > Bullet 1, sub-bullet 1
    • Secure the deployment environment > Manage deployment environment governance > Bullet 2
      
      

• Generative AI framework for HM Government
  2023, Central Digital and Data Office, UK Government
  • Where:
    • Using generative AI safely and responsibly > Security > Security Risks > Practical Security Recommendations > Bullet 2
      
      

• Securing Machine Learning Algorithms
  2021, © European Union Agency for Cybersecurity (ENISA)
  • Where:
    • 4.1- Security Controls > Technical > Ensure ML projects follow the global process for integrating security into projects
    • 4.1- Security Controls > Technical > Conduct a risk analysis of the ML application
      
      

Discussed in which commercial AI security sources? [?]

• The anecdotes AI GRC Toolkit
  2024, © Anecdotes A.I Ltd.
  • Where: Control 6.2: Threat Modeling
    
    
• Google Secure AI Framework
  June 2023, © Google
  • Where:
    • Step 4. Apply the six core elements of the SAIF > Expand strong security foundations to the AI ecosystem > Perform an analysis to determine what security controls needed to be added due to specific threats, regulations, etc.
    • Step 4. Apply the six core elements of the SAIF > Automate defenses to keep pace with existing and new threats > Identify the list of AI security capabilities focused on securing AI systems, training data pipelines, etc.
    • Step 4. Apply the six core elements of the SAIF > Adapt controls to adjust mitigations and create faster feedback loops for AI deployment > Create a feedback loop
      
      
• HiddenLayer’s 2024 AI Threat Landscape Report
  2024, © HiddenLayer
  • Where:
    • Part 4: Predictions and recommendations > 2. Risk assessment and threat modeling
      
      

Control functions against which AI security threats? [?]

• Control function: Decision support
  • Denial of AI service
  • Prompt injection
  • Evasion
  • Model inversion
  • Model extraction and theft
  • Data poisoning
  • Model poisoning
  • Compromised 3rd-party training datasets
  • Compromised 3rd-party models or code
  • Confabulation
  • Excessive agency
  • Sensitive information disclosed in output

Additional information

• Q: When will this requirement included in an assessment? [?]
  • This requirement will always be added to HITRUST assessments which include the
    Security for AI systems regulatory factor.
  • No other assessment tailoring factors affect this requirement.
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • No (dual responsibility). The AI application provider and its AI service providers (if used) are responsible for independently performing this requirement outside of the AI system’s technology stack.

HITRUST CSF requirement statement [?] (07.06hAISecOrganizational.1)

The organization performs security assessments (e.g., AI red teaming, penetration 
testing) of the AI system which include consideration of AI-specific security threats (e.g., 
poisoning, model inversion)
(1) prior to deployment of new models, 
(2) prior to deployment of new or significantly modified supporting infrastructure (e.g., 
migration to a new cloud-based AI platform), 
(3) regularly (at least annually) thereafter.
The organization 
(4) takes appropriate risk treatment measures (including implementing any additional 
countermeasures) deemed necessary based on the results. 

Evaluative elements in this requirement statement [?]

1. The organization performs security assessments (e.g., AI red teaming, penetration 
testing) of the AI system which include consideration of AI-specific security threats (e.g., 
poisoning, model inversion) prior to deployment of new models.

2. The organization performs security assessments (e.g., AI red teaming, penetration 
testing) of the AI system which include consideration of AI-specific security threats (e.g., 
poisoning, model inversion) prior to deployment of new or significantly modified supporting 
infrastructure (e.g., migration to a new cloud-based AI platform),

3. The organization performs security assessments (e.g., AI red teaming, penetration 
testing) of the AI system which include consideration of AI-specific security threats (e.g., 
poisoning, model inversion) regularly (at least annually).

4. The organization takes appropriate risk treatment measures (including implementing 
any additional countermeasures) deemed necessary based on the results.

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample based test where possible for each evaluative element. Example test(s):
  • For example, select a sample of security reports to confirm that security assessments (e.g., AI red teaming, penetration testing) of the AI system which include consideration of AI-specific security threats (e.g., poisoning, model inversion), are conducted at least annually. Further, confirm that assessments are conducted prior to deployment of new models, and that appropriate risk treatment measures (including implementing any additional countermeasures) deemed necessary based on the results, are implemented.
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate the frequency and specifications of the security assessments performed on the AI system. Reviews, tests, or audits are completed by the organization to confirm that the requirements for AI system security testing are completed, and measure the effectiveness of the implemented counter measures.
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 07 Vulnerability Management
• Control category: 06 – Compliance
• Control reference: 06.h – Technical Compliance Checking
  
  

Specific to which parts of the overall AI system? [?]

• N/A, not AI component-specific
  
  

Discussed in which authoritative AI security sources? [?]

• ISO/IEC 23894:2023 Information technology — Artificial intelligence — Guidance on risk management
  2023, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • Part 6. Risk management process > 6.6 Monitoring and review
      
      

• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #SECDEVPROGRAM
      
      

• ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system
  2023, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • 8. Operation > Operational planning and control > Paragraph 3
      
      

• OWASP 2023 Top 10 for LLM Applications
  Oct. 2023, © The OWASP Foundation
  • Where:
    • LLM03: Training data poisoning > Prevention and mitigation strategies > Bullet #7
    • LLM05: Supply chain vulnerabilities > Prevention and mitigation strategies > Bullet #7
    • LLM05: Supply chain vulnerabilities > Prevention and mitigation strategies > Bullet #8
      
      

• OWASP 2025 Top 10 for LLM Applications
  2025, © The OWASP Foundation
  • Where:
    • LLM01: Prompt Injection > Prevention and Mitigation Strategies > Bullet #7
    • LLM03: Supply Chain > Prevention and Mitigation Strategies > Bullet #3
    • LLM04: Data and Model Poisoning > Prevention and Mitigation Strategies > Bullet #8
      
      

• OWASP Machine Learning Security Top 10
  2023, © The OWASP Foundation
  • Where:
    • ML04:2023 Membership inference attack > How to prevent > Bullet #5
    • ML07:2023 Transfer learning attack > How to prevent > Bullet #5
      
      

• LLM AI Cybersecurity & Governance Checklist
  Feb. 2024, © The OWASP Foundation
  • Where:
    • 3. Checklist > 3.3. AI Asset Inventory > Bullet #4
    • 3. Checklist > 3.9. Using or implementing large language models > Bullet #7
    • 3. Checklist > 3.9. Using or implementing large language models > Bullet #8
    • 3. Checklist > 3.13. AI Red Teaming > Bullet #1
      
      

• MITRE ATLAS
  2024, © The MITRE Corporation
  • Where:
    • AML.M0008
    • AML.M0016
      
      

• Guidelines for Secure AI System Development
  Nov. 2023, Cybersecurity & Infrastructure Security Agency (CISA)
  • Where:
    • 3. Secure deployment > Release AI responsibly
      
      

• Deploying AI Systems Securely: Best Practices for Deploying Secure and Resilient AI Systems
  Apr 2024, National Security Agency (NSA)
  • Where:
    • Continuously protect the AI system > Validate the AI system before and during use > Bullet 4
    • Continuously protect the AI system > Validate the AI system before and during use > Bullet 7
    • Continuously protect the AI system > Validate the AI system before and during use > Bullet 8
    • Secure AI operation and maintenance > Update and patch regularly > Bullet 1
    • Secure AI operation and maintenance > Conduct audits and penetration testing > Bullet 1
      
      

• Securing Machine Learning Algorithms
  2021, © European Union Agency for Cybersecurity (ENISA)
  • Where:
    • 4.1- Security Controls > Specific ML > Integrate poisoning control after the “model evaluation” phase
    • 4.1- Security Controls > Technical > Ensure ML projects follow the global process for integrating security into projects
    • 4.1- Security Controls > Technical > Assess the exposure level of the model used
      
      

Discussed in which commercial AI security sources? [?]

• Google Secure AI Framework
  June 2023, © Google
  • Where:
    • Step 4. Apply the six core elements of the SAIF > Adapt controls to adjust mitigations and create faster feedback loops for AI deployment > Conduct Red Team exercises to improve safety and security for AI-powered products and capabilities
    • Step 4. Apply the six core elements of the SAIF > Adapt controls to adjust mitigations and create faster feedback loops for AI deployment > Create a feedback loop
      
      
• HiddenLayer’s 2024 AI Threat Landscape Report
  2024, © HiddenLayer
  • Where:
    • Part 4: Predictions and recommendations > 4. Model robustness and validation
      
      
• Snowflake AI Security Framework
  2024, © Snowflake Inc.
  • Where:
    • Attacks on the infrastructure hosting AI services > Mitigations > Security testing and penetration testing
      
      

Control functions against which AI security threats? [?]

• Control function: Decision support
  • Denial of AI service
  • Prompt injection
  • Evasion
  • Model inversion
  • Model extraction and theft
  • Data poisoning
  • Model poisoning
  • Compromised 3rd-party training datasets
  • Compromised 3rd-party models or code
  • Confabulation
  • Excessive agency
  • Sensitive information disclosed in output
  • Harmful code generation
    
    
• Control function: Detective
  • Data poisoning
  • Model poisoning
  • Compromised 3rd-party training datasets
  • Compromised 3rd-party models or code
  • Confabulation
  • Sensitive information disclosed in output

Additional information

• Q: When will this requirement included in an assessment? [?]
  • This requirement will always be added to HITRUST assessments which include the
    Security for AI systems regulatory factor.
  • No other assessment tailoring factors affect this requirement.
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • No (dual responsibility). The AI application provider and its AI service providers (if used) are responsible for independently performing this requirement outside of the AI system’s technology stack.

HITRUST CSF requirement statement [?] (01.02aAISecOrganizational.1)

The organization formally defines the roles and responsibilities for the
(1) governance, 
(2) security, and 
(3) risk management 
of the organization's deployed AI systems within the organization (e.g., by extending 
a pre-existing RACI chart or creating a new one specific to AI). 
The organization formally
(4) assigns human accountability for the actions performed by, outputs produced by, 
and decisions made by the organization’s deployed AI systems.

Evaluative elements in this requirement statement [?]

1. The organization formally defines the roles and responsibilities for AI governance 
of the organization's deployed AI systems within the organization (e.g., by extending a 
pre-existing RACI chart or creating a new one specific to AI).

2. The organization formally defines the roles and responsibilities for AI security 
of the organization's deployed AI systems within the organization (e.g., by extending a 
pre-existing RACI chart or creating a new one specific to AI).

3. The organization formally defines the roles and responsibilities for AI risk 
of the organization's deployed AI systems management within the organization (e.g., 
by extending a pre-existing RACI chart or creating a new one specific to AI).

4. The organization formally assigns human accountability for the actions performed 
by, outputs produced by, and decisions made by the organization’s deployed AI systems.

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample based test where possible for each evaluative element. Example test(s):
  • For example, review AI systems policy and procedure documentation to determine if roles and responsibilities for the governance, security, and risk management of the organization’s deployed AI systems is in place. Further, confirm that the organization assigns human accountability for the actions performed by, outputs produced by, and decisions made by the organization’s deployed AI systems.
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate the completeness of the organization’s AI system documentation. Reviews, tests, or audits are completed by the organization to measure the effectiveness of the implemented controls and to confirm that requirements for AI system documentation is maintained.
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 01 Information Protection Program
• Control category: 02.0 – Human Resources Security
• Control reference: 02.a – Roles and Responsibilities
  
  

Specific to which parts of the overall AI system? [?]

• N/A, not AI component-specific
  
  

Discussed in which authoritative AI security sources? [?]

• ISO/IEC 23894:2023 Information technology — Artificial intelligence — Guidance on risk management
  2023, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • Part 5. Framework > 5.4 Design > 5.4.3 Assigning organizational roles, authorities, responsibilities and accountabilities
    • Annex A > A.2- Accountability > Last paragraph > First two sentences
      
      
• ISO/IEC 38507:2022- Governance implications of the use of artificial intelligence by organizations
  2022, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • 4. Governance implications of the organizational use of AI > 4.3. Maintaining accountability when introducing AI
    • 5. Overview of AI and AI systems > 5.5. Constraints on the use of AI
    • 6. Policies to address the use of AI > 6.2. Governance oversight of AI
    • 6. Policies to address the use of AI > 6.3. Governance of decision-making
    • 6. Policies to address the use of AI > 6.7. Risk > 6.7.3. Objectives
      
      
• ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system
  2023, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • 5. Leadership > 5.3. Roles, responsibilities, and authorities
    • Annex A > A.3. Internal organization > A.3.2. AI roles and responsibilities
      
      
• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #AIPROGRAM
      
      

• LLM AI Cybersecurity & Governance Checklist
  Feb. 2024, © The OWASP Foundation
  • Where:
    • 3. Checklist > 3.6. Governance > Bullet #1
    • 3. Checklist > 3.6. Governance > Bullet #2
      
      

• Generative AI framework for HM Government
  2023, Central Digital and Data Office, UK Government
  • Where:
    • Using generative AI safely and responsibly > Ethics > Accountability and responsibility
    • Using generative AI safely and responsibly > Ethics > Accountability and responsibility > Practical recommendations > Bullet 4
    • Using generative AI safely and responsibly > Ethics > Accountability and responsibility > Practical recommendations > Bullet 3
    • Using generative AI safely and responsibly > Data protection and privacy > Accountability > Practical recommendations > Bullet 1
      
      

Control functions against which AI security threats? [?]

• Control function: Variance reduction
  • Denial of AI service
  • Prompt injection
  • Evasion
  • Model inversion
  • Model extraction and theft
  • Data poisoning
  • Model poisoning
  • Compromised 3rd-party training datasets
  • Compromised 3rd-party models or code
  • Confabulation
  • Excessive agency
  • Sensitive information disclosed in output
  • Harmful code generation

Additional information

• Q: When will this requirement included in an assessment? [?]
  • This requirement will always be added to HITRUST assessments which include the
    Security for AI systems regulatory factor.
  • No other assessment tailoring factors affect this requirement.
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • No (dual responsibility). The AI application provider and its AI service providers (if used) are responsible for independently performing this requirement outside of the AI system’s technology stack.

HITRUST CSF requirement statement [?] (01.00aAISecOrganizational.1)

As appropriate to the organization’s AI deployment context, the stated scope and 
contents of the organization’s written policies—in areas including but not limited to 
(1) security administration, 
(2) data governance, 
(3) software development, 
(4) risk management,
(5) incident management, 
(6) business continuity, and 
(7) disaster recovery
—explicitly includes the organization’s AI systems and their AI specificities.

Evaluative elements in this requirement statement [?]

1. As appropriate to the organization’s AI deployment context, the stated scope and 
contents of the organization’s written policies related to security administration to 
explicitly include the organization’s AI systems and their AI specificities.

2. As appropriate to the organization’s AI deployment context, the stated scope and 
contents of the organization’s written policies related to data governance to explicitly 
include the organization’s AI systems and their AI specificities.

3. As appropriate to the organization’s AI deployment context, the stated scope and 
contents of the organization’s written policies related to software development to 
explicitly include the organization’s AI systems and their AI specificities.

4. As appropriate to the organization’s AI deployment context, the stated scope and 
contents of the organization’s written policies related to risk management to explicitly 
include the organization’s AI systems and their AI specificities.

5.As appropriate to the organization’s AI deployment context, the stated scope and 
contents of the organization’s written policies related to incident management to 
explicitly include the organization’s AI systems and their AI specificities.

6. As appropriate to the organization’s AI deployment context, the stated scope and 
contents of the organization’s written policies related to business continuity to explicitly 
include the organization’s AI systems and their AI specificities.

7. As appropriate to the organization’s AI deployment context, the stated scope and 
contents of the organization’s written policies related to disaster recovery to explicitly 
include the organization’s AI systems and their AI specificities.

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample based test where possible for each evaluative element. Example test(s):
  • For example, review the organizations written policies for AI systems to confirm their completeness. Further, confirm that the AI system policies contain security administration, data governance, software development, risk management, incident management, business continuity, and disaster recovery, explicitly to AI systems and their AI specificities.
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate the completeness of the organization’s AI system documentation. Reviews, tests, or audits are completed by the organization to measure the effectiveness of the implemented controls and to confirm that requirements for AI system documentation is maintained.
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 01 Information Protection Program
• Control category: 00.0 – Information Security Management Program
• Control reference: 00.a – Information Security Management Program
  
  

Specific to which parts of the overall AI system? [?]

• N/A, not AI component-specific
  
  

Discussed in which authoritative AI security sources? [?]

• ISO/IEC 38507:2022- Governance implications of the use of artificial intelligence by organizations
  2022, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • 4. Governance implications of the organizational use of AI > 4.3. Maintaining accountability when introducing AI
    • 5. Overview of AI and AI systems > 5.2. How AI systems differ from other information technologies > 5.2.3. Adaptive systems
    • 6. Policies to address the use of AI > 6.2. Governance oversight of AI
    • 6. Policies to address the use of AI > 6.4. Governance of data use
    • 6. Policies to address the use of AI > 6.7. Risk > 6.7.2. Risk management
      
      
• ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system
  2023, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • 5. Leadership > 5.2. AI policy
    • Annex A > A.2. Policies related to AI > A.2.2. AI policy
    • Annex A > A.2. Policies related to AI > A.2.3. Alignment with other organizational policies
      
      
• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #AIPROGRAM
    • #SECPROGRAM
    • #SECDEVPROGRAM
      
      

• LLM AI Cybersecurity & Governance Checklist
  Feb. 2024, © The OWASP Foundation
  • Where:
    • 3. Checklist > 3.6. Governance > Bullet #3
    • 3. Checklist > 3.6. Governance > Bullet #4
      
      

• Guidelines for Secure AI System Development
  Nov. 2023, Cybersecurity & Infrastructure Security Agency (CISA)
  • Where:
    • 1. Secure design > Design your system for security as well as functionality and performance
      
      

• Managing Artificial Intelligence-Specific Cybersecurity Risks in the Financial Services Sector
  March 2024, U.S. Department of the Treasury
  • Where:
    • 5. Best practices for managing AI-specific security risks > 5.1. Situating AI risk management within existing enterprise risk management programs
      
      

• Generative AI framework for HM Government
  2023, Central Digital and Data Office, UK Government
  • Where:
    • Using generative AI safely and responsibly > Accountability > Practical recommendations > Bullet 1
    • Using generative AI safely and responsibly > Accountability > Practical recommendations > Bullet 2
    • Building generative AI solutions > Building the solution >Patterns > Practical recommendations > Bullet 2
      
      

• Securing Machine Learning Algorithms
  2021, © European Union Agency for Cybersecurity (ENISA)
  • Where:
    • 4.1- Security Controls > Organizational > Integrate ML specificities to existing security policies
    • 4.1- Security Controls > Organizational > Ensure ML applications comply with security policies
    • 4.1- Security Controls > Organizational > Ensure ML applications comply with protection policies and are integrated to security operations processes
    • 4.1- Security Controls > Organizational > Ensure ML applications comply with identity management, authentication, and access control policies
    • 4.1- Security Controls > Technical > Ensure ML projects follow the global process for integrating security into projects
      
      

Discussed in which commercial AI security sources? [?]

• The anecdotes AI GRC Toolkit
  2024, © Anecdotes A.I Ltd.
  • Where:
    • Control 1.2: Policy Augmentation
    • Control 8.2: Recovery and Continuity
      
      
• Google Secure AI Framework
  June 2023, © Google
  • Where:
    • Step 4. Apply the six core elements of the SAIF > Expand strong security foundations to the AI ecosystem > Review what existing security controls across the security domains apply to AI systems
      
      

Control functions against which AI security threats? [?]

• Control function: Directive
  • Denial of AI service
  • Prompt injection
  • Evasion
  • Model inversion
  • Model extraction and theft
  • Data poisoning
  • Model poisoning
  • Compromised 3rd-party training datasets
  • Compromised 3rd-party models or code
  • Confabulation
  • Excessive agency
  • Sensitive information disclosed in output
  • Harmful code generation

Additional information

• Q: When will this requirement included in an assessment? [?]
  • This requirement will always be added to HITRUST assessments which include the
    Security for AI systems regulatory factor.
  • No other assessment tailoring factors affect this requirement.
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • No (dual responsibility). The AI application provider and its AI service providers are responsible for independently performing this requirement outside of the AI system’s technology stack.

HITRUST CSF requirement statement [?] (12.09abAISecSystem.3)

The design of the AI application allows its human operators the ability to 
(1) evaluate AI model outputs before relying on them and 
(2) intervene in AI model-initiated actions (e.g., sending emails, modifying records) if 
deemed necessary.

Evaluative elements in this requirement statement [?]

1. The design of the AI system allows its human operators the ability to evaluate AI 
model outputs before relying on.

2. The design of the AI system allows its human operators the ability to intervene in 
AI model-initiated actions (e.g., sending emails, modifying records) if deemed necessary.

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample based test where possible for each evaluative element. Example test(s):
  • For example, review the AI application to confirm it allows a human operator to evaluate AI model outputs. Further, confirm the ability for human operators to intervene in AI model-initiated actions when necessary.
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate if the AI application allows human operators to evaluate AI model outputs and intervene in AI model-initiated actions when necessary. Reviews, tests, or audits are completed by the organization to measure the effectiveness of the implemented controls.
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 12 Audit Logging & Monitoring
• Control category: 09.0 – Communications and Operations Management
• Control reference: 09.ab – Monitoring System Use
  
  

Specific to which parts of the overall AI system? [?]

• AI application layer:
  • Application AI safety and security systems
    
    

Discussed in which authoritative AI security sources? [?]

• ISO/IEC 22989:2022: Information technology — Artificial intelligence — Artificial intelligence concepts and terminology
  2022, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • 5. AI Concepts > 5.15 Trustworthiness > 5.15.5. AI controllability
      
      

• ISO/IEC 38507:2022- Governance implications of the use of artificial intelligence by organizations
  2022, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • 5. Overview of AI and AI systems > 5.1. General
    • 6. Policies to address the use of AI > 6.2. Governance oversight of AI
      
      

• OWASP 2023 Top 10 for LLM Applications
  Oct. 2023, © The OWASP Foundation
  • Where:
    • LLM01: Prompt injection > Prevention and mitigation strategies > Bullet #2
    • LLM03: Training data poisoning > Prevention and mitigation strategies > Bullet #7
    • LLM07: Insecure plugin design > Prevention and mitigation strategies > Bullet #6
    • LLM08: Excessive agency > Prevention and mitigation strategies > Bullet #6
    • LLM09: Overreliance > Prevention and mitigation strategies > Bullet #1
      
      

• OWASP 2025 Top 10 for LLM Applications
  2025, © The OWASP Foundation
  • Where:
    • LLM01: Prompt Injection > Prevention and Mitigation Strategies > Bullet #5
    • LLM06: Excessive Agency > Prevention and Mitigation Strategies > Bullet #6
    • LLM09: Misinformation > Prevention and Mitigation Strategies > Bullet #3
      
      

• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #OVERSIGHT
      
      

• Deploying AI Systems Securely: Best Practices for Deploying Secure and Resilient AI Systems
  Apr 2024, National Security Agency (NSA)
  • Where:
    • Continuously protect the AI system > Validate the AI system before and during use > Bullet 5
    • Continuously protect the AI system > Validate the AI system before and during use > Bullet 8 > Sub-bullet 1
      
      

• Generative AI framework for HM Government
  2023, Central Digital and Data Office, UK Government
  • Where:
    • Building generative AI solutions > Building the solution > Getting reliable results > Bullet 9
    • Building generative AI solutions > Building the solution > Getting reliable results > Bullet 10
    • Using generative AI safely and responsibly > Ethics > Accountability and responsibility > Practical recommendations > Bullet 6
    • Using generative AI safely and responsibly > Ethics > Accountability and responsibility > Practical recommendations > Bullet 5
    • Using generative AI safely and responsibly > Ethics > Maintaining appropriate human involvement in automated processes > Bullet 3
    • Using generative AI safely and responsibly > Ethics > Maintaining appropriate human involvement in automated processes > Bullet 5
    • Building generative AI solutions > Building the solution > Data management > Practical recommendations > Bullet 2
      
      

• ISO/IEC TR 24028:2020: Information technology — Artificial intelligence — Overview of trustworthiness in artificial intelligence
  2020, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • 9. Mitigation measures > 9.4. Controllability > 9.4.2. Human-in-the-loop control points
      
      

Discussed in which commercial AI security sources? [?]

• Databricks AI Security Framework
  Sept. 2024, © Databricks
  • Where:
    • DASF 29: Build MLOps workflows with human-in-the-loop (HILP) with permissions, versions and approvals to promote models to production
      
      
• Snowflake AI Security Framework
  2024, © Snowflake Inc.
  • Where:
    • Prompt injection > Mitigations > Human-in-the-loop systems
    • Indirect prompt injection > Mitigations > Human-in-the-loop systems
      
      

Control functions against which AI security threats? [?]

• Control function: Corrective
  • Confabulation
    
    
• Control function: Preventative
  • Excessive agency

Additional information

• Q: When will this requirement included in an assessment? [?]
  • This requirement will always be added to HITRUST assessments which include the
    Security for AI systems regulatory factor.
  • No other assessment tailoring factors affect this requirement.
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • No. Implementing and/or configuring this requirement is the AI application provider’s sole responsibility.

HITRUST CSF requirement statement [?] (13.02eAISecOrganizational.1)

The organization provides training no less than annually on AI security topics (e.g., 
vulnerabilities, threats, organizational policy requirements) for all teams involved in 
AI software and model creation and deployment, including (as applicable) 
(1) development, 
(2) data science, and 
(3) cybersecurity 
personnel.

Evaluative elements in this requirement statement [?]

1. The organization provides training no less than annually on AI security topics 
(e.g., vulnerabilities, threats, organizational policy requirements) to development 
personnel.

2. The organization provides training no less than annually on AI security topics 
(e.g., vulnerabilities, threats, organizational policy requirements) to data science 
personnel.

3. The organization provides training no less than annually on AI security topics 
(e.g., vulnerabilities, threats, organizational policy requirements) to cybersecurity 
personnel.

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample based test where possible for each evaluative element. Example test(s):
  • For example, review the AI security training documentation to confirm that training is conducted no less than annually on AI security topics (e.g., vulnerabilities, threats, organizational policy requirements) for all teams involved in AI software and model creation and deployment. Further, confirm the training includes all development, data science, and cybersecurity personnel.
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate the percentage of personnel in AI system roles who have received AI security training. Reviews, tests, or audits are completed by the organization to measure the effectiveness of the implemented controls and confirm that all personnel in AI system roles receive AI security training no less than annually.
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 13 Education, Training and Awareness
• Control category: 02.0 – Human Resources Security
• Control reference: 02.e – Information Security Awareness, Education, and Training
  
  

Specific to which parts of the overall AI system? [?]

• N/A, not AI component-specific
  
  

Discussed in which authoritative AI security sources? [?]

• ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system
  2023, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • 7. Support > 7.2. Competence
    • 7. Support > 7.3. Awareness
      
      
• OWASP 2023 Top 10 for LLM Applications
  Oct. 2023, © The OWASP Foundation
  • Where:
    • LLM04: Model denial of service > Prevention and mitigation strategies > Bullet #7
      
      

• OWASP Machine Learning Security Top 10
  2023, © The OWASP Foundation
  • Where:
    • ML06:2023 AI supply chain attacks > How to prevent > Bullet #7
      
      

• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #SECEDUCATE
    • #SECDEVPROGRAM
      
      

• LLM AI Cybersecurity & Governance Checklist
  Feb. 2024, © The OWASP Foundation
  • Where:
    • 3. Checklist > 3.3. AI Asset Inventory > Bullet #6
    • 3. Checklist > 3.4. AI Security and Privacy Training > Bullet #5
      
      

• MITRE ATLAS
  2024, © The MITRE Corporation
  • Where:
    • AML.M0018
      
      

• Guidelines for Secure AI System Development
  Nov. 2023, Cybersecurity & Infrastructure Security Agency (CISA)
  • Where:
    • 1. Secure design > Raise staff awareness of threats and risks
      
      

• Deploying AI Systems Securely: Best Practices for Deploying Secure and Resilient AI Systems
  Apr 2024, National Security Agency (NSA)
  • Where:
    • Secure AI operation and maintenance > Ensure user awareness and training
      
      

• Managing Artificial Intelligence-Specific Cybersecurity Risks in the Financial Services Sector
  March 2024, U.S. Department of the Treasury
  • Where:
    • 5. Best practices for managing AI-specific security risks > 5.9. Cybersecurity best practices closely apply to AI systems
      
      

• Securing Machine Learning Algorithms
  2021, © European Union Agency for Cybersecurity (ENISA)
  • Where:
    • 4.1- Security Controls > Specific ML > Integrate ML specificities to awareness strategy and ensure all ML stakeholders are receiving it
      
      

Discussed in which commercial AI security sources? [?]

• The anecdotes AI GRC Toolkit
  2024, © Anecdotes A.I Ltd.
  • Where:
    • Control 6.1: Training
      
      
• Databricks AI Security Framework
  Sept. 2024, © Databricks
  • Where:
    • Control DASF 41: Platform security — secure SDLC
    • Resources and Further Reading > AI and Machine Learning on Databricks
      
      
• Google Secure AI Framework
  June 2023, © Google
  • Where:
    • Step 4. Apply the six core elements of the SAIF > Expand strong security foundations to the AI ecosystem > Retrain and retain
      
      
• HiddenLayer’s 2024 AI Threat Landscape Report
  2024, © HiddenLayer
  • Where:
    • Part 4: Predictions and recommendations > 5. Secure development practices > Bullet 1
      
      
• Snowflake AI Security Framework
  2024, © Snowflake Inc.
  • Where:
    • Backdooring models (insider attacks) > Mitigations > Secure development practices
    • Attacks on the infrastructure hosting AI services > Mitigations > Security awareness training
      
      

Control functions against which AI security threats? [?]

• Control function: Variance reduction
  • Denial of AI service
  • Prompt injection
  • Evasion
  • Model inversion
  • Model extraction and theft
  • Data poisoning
  • Model poisoning
  • Compromised 3rd-party training datasets
  • Compromised 3rd-party models or code
  • Confabulation
  • Excessive agency
  • Sensitive information disclosed in output
  • Harmful code generation

Additional information

• Q: When will this requirement included in an assessment? [?]
  • This requirement will always be added to HITRUST assessments which include the
    Security for AI systems regulatory factor.
  • No other assessment tailoring factors affect this requirement.
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • No (dual responsibility). The AI application provider and its AI service providers (if used) are responsible for independently performing this requirement outside of the AI system’s technology stack.

HITRUST CSF requirement statement [?] (06.10jAISecSystem.1)

AI assets, including
(1) code to create, train, and/or deploy AI models;
(2) training datasets;
(3) fine-tuning datasets;
(4) RAG datasets (if used);
(5) configurations of pipelines used to create, train, and/or deploy AI models;
(6) code used by language model tools such as agents and plugins (if used); and 
(7) models
are versioned and tracked.

Evaluative elements in this requirement statement [?]

1. Code used to create, train, and/or deploy AI models is versioned and tracked.

2. Training datasets are versioned and tracked.

3. Fine-tuning datasets are versioned and tracked.

4. RAG datasets versioned and tracked.

5. Configurations of pipelines used to create, train, and/or deploy AI models are versioned and tracked.

6. Code used by language model tools such as agents and plugins is versioned and tracked.

7. AI models are versioned and tracked.

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample based test where possible for each evaluative element. Example test(s):
  • For example, evidence that the AI assets listed in the requirement statement are each versioned and tracked (as applicable).
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate percentage of the organization’s AI assets which are versioned and tracked of total. Reviews, tests, or audits are completed by the organization to measure the effectiveness of the implemented controls.
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 06 Configuration Management
• Control category: 10.0 – Information Systems Acquisition, Development, and Maintenance
• Control reference: 10.j Access Control to Program Source Code
  
  

Specific to which parts of the overall AI system? [?]

AI application layer:

• AI plugins and agents
• The deployed AI application (Considered in the associated HITRUST e1, i1, or r2 assessment)

AI platform layer

• The AI platform and associated APIs (Considered in the associated HITRUST e1, i1, or r2 assessment)
• Model engineering environment and model pipeline
  
  

Discussed in which authoritative AI security sources? [?]

• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #DEVPROGRAM
    • #DEVSECURITY
      
      

• OWASP 2025 Top 10 for LLM Applications
  2025, © The OWASP Foundation
  • Where:
    • LLM04: Data and Model Poisoning > Prevention and Mitigation Strategies > Bullet #6
      
      

• Guidelines for Secure AI System Development
  Nov. 2023, Cybersecurity & Infrastructure Security Agency (CISA)
  • Where:
    • 2. Secure development > Identify, track and protect your assets
      
      

• Deploying AI Systems Securely: Best Practices for Deploying Secure and Resilient AI Systems
  Apr 2024, National Security Agency (NSA)
  • Where:
    • Continuously protect the AI system > Validate the AI system before and during use > Bullet 3
      
      

Discussed in which commercial AI security sources? [?]

• Databricks AI Security Framework
  Sept. 2024, © Databricks
  • Where:
    • Control DASF 10: Version data
    • Control DASF 17: Track and reproduce the training data used for ML model training
    • Control DASF 52: Source code control
      
      

Control functions against which AI security threats? [?]

• Control function: Variance reduction
  • Denial of AI service
  • Prompt injection
  • Evasion
  • Model inversion
  • Model extraction and theft
  • Data poisoning
  • Model poisoning
  • Compromised 3rd-party training datasets
  • Compromised 3rd-party models or code
  • Confabulation
  • Excessive agency
  • Sensitive information disclosed in output

Additional information

• Q: When will this requirement included in an assessment? [?]
  • This requirement will always be added to HITRUST assessments which include the
    Security for AI systems regulatory factor.
  • No other assessment tailoring factors affect this requirement.
    
    

• Q: When is this requirement applicable, and when could it be inapplicable?
  • This requirement applies regardless of the model’s provenance and regardless of the AI system architecture.
  • Element #2 is only applicable when language model tools such as agents or plugins are used.
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • Yes, fully. This requirement may be the sole responsibility of the AI platform provider and/or model creator. Or, depending on the AI system’s architecture, only evaluative elements that are the sole responsibility of the AI platform provider and/or model creator apply.

HITRUST CSF requirement statement [?] (07.10mAISecOrganizational.6)

To find potentially exploitable vulnerabilities, the organization inspects downloaded AI software assets 
before use—including 
(1) models (e.g., such as those sourced from online model zoos); 
(2) software packages used to create, train, and/or deploy models (e.g., python packages); and
(3) language model tools such as agents and plugins (if used). 
The organization 
(4) acts upon the results, as necessary.

Evaluative elements in this requirement statement [?]

1. To find potentially exploitable vulnerabilities, the organization inspects downloaded AI models 
before use (e.g., such as those sourced from online model zoos).

2. To find potentially exploitable vulnerabilities, the organization inspects downloaded software 
packages (e.g., python packages) used to create, train, and/or deploy models before use.

3. To find potentially exploitable vulnerabilities, the organization inspects downloaded 
language model tools such as agents and plugins before use (if used).

4. The organization acts upon the results, as necessary.

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample based test where possible for each evaluative element. Example test(s):
  • For example, select a sample of downloaded AI software assets and confirm they were inspected before use. Further, confirm that the organization acts upon the inspection results, as necessary.
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate percentage of the organization’s downloaded AI software assets that were not inspected before use. Reviews, tests, or audits are completed by the organization to measure the effectiveness of the implemented controls and to confirm that all AI software assets are inspected before use.
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 07 Vulnerability Management
• Control category: 10.0 – Information Systems Acquisition, Development, and Maintenance
• Control reference: 10.m – Control of Technical Vulnerabilities
  
  

Specific to which parts of the overall AI system? [?]

AI application layer:

• The deployed AI application (Considered in the associated HITRUST e1, i1, or r2 assessment)

AI platform layer:

• The deployed AI model
• Model engineering environment and model pipeline
  
  

Discussed in which authoritative AI security sources? [?]

• Deploying AI Systems Securely: Best Practices for Deploying Secure and Resilient AI Systems
  Apr 2024, National Security Agency (NSA)
  • Where:
    • Continuously protect the AI system > Validate the AI system before and during use > Bullet 7
      
      

• LLM AI Cybersecurity & Governance Checklist
  Feb. 2024, © The OWASP Foundation
  • Where:
    • 3. Checklist > 3.9. Using or implementing large language model solutions > Bullet #8
      
      

• MITRE ATLAS
  2024, © The MITRE Corporation
  • Where: AML.M0016
    
    

• NIST AI 100-2 E2023: Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations
  Jan. 2024, National Institute of Standards and Technology (NIST)
  • Where:
    • 2. Predictive AI taxonomy > 2.3. Poisoning attacks and mitigations > 2.3.3. Backdoor poisoning
    • 3. Generative AI taxonomy > 3.2. AI supply chain attacks and mitigations > 3.2.2. Poisoning attacks
      
      

• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #SECDEVPROGRAM
      
      

• OWASP 2023 Top 10 for LLM Applications
  Oct. 2023, © The OWASP Foundation
  • Where:
    • LLM05: Supply chain vulnerabilities > Prevention and mitigation strategies > Bullet #8
    • LLM07: Insecure plugin design > Prevention and mitigation strategies > Bullet #3
      
      

• OWASP 2025 Top 10 for LLM Applications
  2025, © The OWASP Foundation
  • Where:
    • LLM03: Supply Chain > Prevention and Mitigation Strategies > Bullet #2
    • LLM03: Supply Chain > Prevention and Mitigation Strategies > Bullet #7
    • LLM03: Supply Chain > Prevention and Mitigation Strategies > Bullet #8
      
      

• OWASP Machine Learning Security Top 10
  2023, © The OWASP Foundation
  • Where:
    • ML06:2023 AI supply chain attacks > How to prevent > Bullet #5
      
      
• Securing Machine Learning Algorithms
  2021, © European Union Agency for Cybersecurity (ENISA)
  • Where:
    • 4.1- Security Controls > Technical > Check the vulnerabilities of the components used so that they have an appropriate security level
      
      

Discussed in which commercial AI security sources? [?]

• Databricks AI Security Framework
  Sept. 2024, © Databricks
  • Where:
    • Control DASF 41: Platform security – Secure SDLC
    • Control DASF 53: Third-party library control
      
      

• Snowflake AI Security Framework
  2024, © Snowflake Inc.
  • Where:
    • Backdooring models (insider attacks) > Mitigations > Secure development practices
      
      

Control functions against which AI security threats? [?]

• Control function: Preventative
  • Compromised 3rd-party models or code
  • Model poisoning

Additional information

• Q: When will this requirement included in an assessment? [?]
  • This requirement will always be added to HITRUST assessments which include the
    Security for AI systems regulatory factor.
  • No other assessment tailoring factors affect this requirement.
    
    

• Q: When is this requirement applicable, and when could it be inapplicable?
  • This requirement applies regardless of the model’s provenance and regardless of the AI system architecture.
  • Element #1 is only applicable when the AI system uses an AI model sourced from an online model zoo / model hub.
  • Element #2 is only applicable when the organization uses software packages downloaded from online package repositories.
  • Element #3 is only applicable when language model tools such as agents or plugins are used.
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • Yes, fully. This requirement may be the sole responsibility of the AI platform provider and/or model creator. Or, depending on the AI system’s architecture, only evaluative elements that are the sole responsibility of the AI platform provider and/or model creator provider apply.

HITRUST CSF requirement statement [?] (06.09bAISecSystem.1)

Changes to AI models (including upgrading to new model versions and moving to 
completely different models) are consistently 
(1) documented, 
(2) tested, and
(3) approved 
in accordance with the organization’s software change control policy prior to deployment.
When upgrading to a newer version of an externally developed model, the organization
(4) obtains and reviews the release notes describing the model's update.

Evaluative elements in this requirement statement [?]

1. Changes to AI models (including upgrading to new model versions and moving to 
completely different models) are consistently documented in accordance with the 
organization’s software change control policy prior to deployment.

2. Changes to AI models (including upgrading to new model versions and moving to 
completely different models) are consistently tested in accordance with the organization’s 
software change control policy prior to deployment.

3. Changes to AI models (including upgrading to new model versions and moving to 
completely different models) are consistently approved in accordance with the organization’s 
software change control policy prior to deployment.

4. When upgrading to a newer version of an externally developed model, the organization 
obtains and reviews the release notes describing the model's update.

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample based test where possible for each evaluative element. Example test(s):
  • For example, select a sample of the AI models change documentation to confirm all changes were documented. Further, confirm that the AI models change documentation includes testing and approval information in accordance with the organization’s software change control policy, prior to deployment.
  • Further, confirm that the organization obtained and reviewed the release notes when upgrading to newer versions of externally developed models.
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate percentage of the organization’s AI models that received changes without documentation. Reviews, tests, or audits are completed by the organization to measure the effectiveness of the implemented controls and to confirm that all AI model changes are consistently documented, tested, and approved in accordance with the organization’s software change control policy prior to deployment.
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 06 Configuration Management
• Control category: 09.0 – Communications and Operations Management
• Control reference: 09.b – Change Management
  
  

Specific to which parts of the overall AI system? [?]

AI platform layer:

• The deployed AI model
  
  

Discussed in which authoritative AI security sources? [?]

• ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system
  2023, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • 8. Operation > Operational planning and control > Paragraph 5
    • Annex A > A.6. AI system life cycle > A.6.2.2. AI system requirements and specification
    • Annex A > A.6. AI system life cycle > A.6.2.3. Documentation of AI system design and development
    • Annex A > A.6. AI system life cycle > A.6.2.4. AI system verification and validation
    • Annex A > A.6. AI system life cycle > A.6.2.5. AI system deployment
      
      
• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #DEVPROGRAM
      
      
• Guidelines for Secure AI System Development
  Nov. 2023, Cybersecurity & Infrastructure Security Agency (CISA)
  • Where:
    • 4. Secure operation and maintenance > Follow a secure by design approach to updates
      
      
• Deploying AI Systems Securely: Best Practices for Deploying Secure and Resilient AI Systems
  Apr 2024, National Security Agency (NSA)
  • Where:
    • Continuously protect the AI system > Validate the AI system before and during use > Bullet 3
    • Continuously protect the AI system > Validate the AI system before and during use > Bullet 4
    • Secure AI operation and maintenance > Update and patch regularly > Bullet 1
      
      
• Securing Machine Learning Algorithms
  2021, © European Union Agency for Cybersecurity (ENISA)
  • Where:
    • 4.1- Security Controls > Organizational > Apply documentation requirements to AI projects
      
      

Discussed in which commercial AI security sources? [?]

• Databricks AI Security Framework
  Sept. 2024, © Databricks
  • Where:
    • Control DASF 19: Manage end-to-end machine learning lifecycle
    • Control DASF 23: Register, version, approve, promote, and deploy model
    • Control DASF 29: Build MLOps workflows
    • Control DASF 41: Platform security – Secure SDLC
    • Control DASF 42: Employ data-centric MLOps and LLMOps
    • Control DASF 45: Evaluate models
    • Control DASF 49: Automate LLM evaluation
      
      

• Snowflake AI Security Framework
  2024, © Snowflake Inc.
  • Where:
    • Self-hosted OSS LLMs Security > Mitigations > Model testing
      
      

Control functions against which AI security threats? [?]

• Control function: Preventative
  • Model poisoning
    
    
• Control function: Variance reduction
  • Prompt injection
  • Evasion
  • Model inversion
  • Model extraction and theft
  • Model poisoning
  • Confabulation
  • Excessive agency
  • Sensitive information disclosed in output

Additional information

• Q: When will this requirement included in an assessment? [?]
  • This requirement will always be added to HITRUST assessments which include the
    Security for AI systems regulatory factor.
  • No other assessment tailoring factors affect this requirement.
    
    

• Q: When is this requirement applicable, and when could it be inapplicable?
  • This requirement applies regardless of the model’s provenance and regardless of the AI system architecture.
  • This requirement may be inapplicable if no new models or model versions were deployed during the past 12 months.
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • Yes, partially. This may be a responsibility shared between an AI application provider and their AI platform provider (if used), performed independently on separate layers/components of the overall AI system.

HITRUST CSF requirement statement [?] (06.10hAISecSystem.5)

Changes to language model tools such as agents and plugins are consistently
(1) documented, 
(2) tested, and 
(3) approved 
in accordance with the organization’s software change control policy prior to deployment.

Evaluative elements in this requirement statement [?]

1. Changes to language model tools such as agents and plugins are consistently 
documented in accordance with the organization’s software change control policy prior 
to deployment.

2. Changes to language model tools such as agents and plugins are consistently 
tested in accordance with the organization’s software change control policy prior to 
deployment.

3. Changes to language model tools such as agents and plugins are consistently 
approved in accordance with the organization’s software change control policy prior 
to deployment.

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample-based test where possible for each evaluative element. Example test(s):
  • For example, select a sample of the language model change documentation to confirm all changes were documented. Further, confirm that the change documentation includes testing and approval information in accordance with the organization’s software change control policy, prior to deployment.
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate percentage of the organization’s language model that received changes without documentation. Reviews, tests, or audits are completed by the organization to measure the effectiveness of the implemented controls and to confirm that all changes to language model tools such as agents and plugins are consistently documented, tested, and approved in accordance with the organization’s software change control policy prior to deployment.
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 06 Configuration Management
• Control category: 10.0 – Information Systems Acquisition, Development, and Maintenance
• Control reference: 10h- Control of Operational Software
  
  

Specific to which parts of the overall AI system? [?]

AI application layer:

• AI plugins and agents
  
  

Discussed in which authoritative AI security sources? [?]

• ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system
  2023, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • 8. Operation > Operational planning and control > Paragraph 5
    • Annex A > A.6. AI system life cycle > A.6.2.2. AI system requirements and specification
    • Annex A > A.6. AI system life cycle > A.6.2.3. Documentation of AI system design and development
    • Annex A > A.6. AI system life cycle > A.6.2.4. AI system verification and validation
    • Annex A > A.6. AI system life cycle > A.6.2.5. AI system deployment
      
      

• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #DEVPROGRAM
      
      

• Guidelines for Secure AI System Development
  Nov. 2023, Cybersecurity & Infrastructure Security Agency (CISA)
  • Where:
    • 4. Secure operation and maintenance > Follow a secure by design approach to updates
      
      

• Deploying AI Systems Securely: Best Practices for Deploying Secure and Resilient AI Systems
  Apr 2024, National Security Agency (NSA)
  • Where:
    • Continuously protect the AI system > Validate the AI system before and during use > Bullet 3
    • Continuously protect the AI system > Validate the AI system before and during use > Bullet 4
    • Secure AI operation and maintenance > Update and patch regularly > Bullet 1
      
      

• Securing Machine Learning Algorithms
  2021, © European Union Agency for Cybersecurity (ENISA)
  • Where:
    • 4.1- Security Controls > Organizational > Apply documentation requirements to AI projects_
      
      

Control functions against which AI security threats? [?]

• Control function: Preventative
  • Excessive agency

Additional information

• Q: When will this requirement included in an assessment? [?]
  • This requirement is only included when the assessment’s in-scope AI system leverages a generative AI model.
  • The Security for AI systems regulatory factor must also be present in the assessment.
    
    

• Q: When is this requirement applicable, and when could it be inapplicable?
  • This requirement is only applicable when language model tools such as agents or plugins are used.
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • No. Implementing and/or configuring this requirement is the AI application provider’s sole responsibility.

HITRUST CSF requirement statement [?] (06.10hAISecSystem.6)

Documentation of the overall AI system discusses the creation, operation, and lifecycle 
management of any 
(1) models, 
(2) datasets (including data used for training, tuning, and prompt enhancement via RAG), 
(3) configurations (e.g., metaprompts),
(4) language model tools such as agents and plugins
maintained by the organization, as applicable.
Documentation of the overall AI system also describes the
(5) tooling resources (e.g., AI platforms, model engineering environments, pipeline configurations), 
(6) system and computing resources, and
(7) human resources
needed for the development and operation of the AI system.

Evaluative elements in this requirement statement [?]

1. Documentation of the overall AI system discusses the creation, operation, and 
lifecycle management of any models maintained by the organization, as applicable.

2. Documentation of the overall AI system discusses the creation, operation, and 
lifecycle management of any datasets maintained by the organization (including data 
used for training, tuning, and prompt enhancement via RAG), as applicable.

3. Documentation of the overall AI system discusses the creation, operation, and 
lifecycle management of any AI-relevant configurations (e.g., metaprompts) maintained by the 
organization, as applicable.

4. Documentation of the overall AI system discusses the creation, operation, and 
lifecycle management of any language model tools such as agents and plugins maintained 
by the organization, as applicable.

5. Documentation of the overall AI system describes the tooling resources (e.g., AI 
platforms, model engineering environments, pipeline configurations) needed for the development and operation 
of the AI system.

6. Documentation of the overall AI system describes the system and computing resources
needed for the development and operation of the AI system.

7. Documentation of the overall AI system describes the human resources needed for the
development and operation of the AI system.

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample based test where possible for each evaluative element. Example test(s):
  • For example, review the overall AI system documentation to confirm it discusses the creation, operation, and lifecycle management of any models, datasets (including data used for training, tuning, and prompt enhancement via RAG), configurations (e.g., metaprompts), language model tools such as agents and plugins maintained by the organization, as applicable. Further, confirm the documentation of the overall AI system also describes the tooling resources (e.g., AI platforms, model engineering environments), system and computing resources, and human resources needed for the development and operation of the AI system.
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate completeness of the organization’s overall AI system documentation that discusses the required elements in the requirement statement. Reviews, tests, or audits are completed by the organization to measure the effectiveness of the implemented controls and to confirm that all the required elements are included in the overall AI system documentation.
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 06 Configuration Management
• Control category: 10.0 – Information Systems Acquisition, Development, and Maintenance
• Control reference: 10h- Control of Operational Software
  
  

Specific to which parts of the overall AI system? [?]

AI application layer:

• AI plugins and agents
• Prompt augmentations (e.g., via RAG) and associated data sources
• Application AI safety and security systems
• The deployed AI application (Considered in the associated HITRUST e1, i1, or r2 assessment)

AI platform layer:

• The AI platform and associated APIs (Considered in the associated HITRUST e1, i1, or r2 assessment)
• Model safety and security systems
• Model tuning and associated datasets
• The deployed AI model
• Model engineering environment and model pipeline
• AI datasets and data pipelines
  
  

Discussed in which authoritative AI security sources? [?]

• ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system
  2023, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • Annex A > A.4. Resources for AI systems > A.4. Resources for AI systems (all items)
      
      
• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #DEVPROGRAM
      
      

• Guidelines for Secure AI System Development
  Nov. 2023, Cybersecurity & Infrastructure Security Agency (CISA)
  • Where:
    • 2. Secure development > Document your data, models and prompts
      
      

• Generative AI framework for HM Government
  2023, Central Digital and Data Office, UK Government
  • Where:
    • Building generative AI solutions > Building the solution > Data Management > Bullet 2
      
      

• Securing Machine Learning Algorithms
  2021, © European Union Agency for Cybersecurity (ENISA)
  • Where:
    • 4.1- Security Controls > Technical > Ensure ML projects follow the global process for integrating security into projects
    • 4.1- Security Controls > Organizational > Apply documentation requirements to AI projects
      
      

Discussed in which commercial AI security sources? [?]

• Snowflake AI Security Framework
  2024, © Snowflake Inc.
  • Where:
    • Lack of explainability / transparency > Mitigations > Model transparency and documentation
      
      

Control functions against which AI security threats? [?]

• Control function: Directive
  • Denial of AI service
  • Prompt injection
  • Evasion
  • Model inversion
  • Model extraction and theft
  • Data poisoning
  • Model poisoning
  • Compromised 3rd-party training datasets
  • Compromised 3rd-party models or code
  • Confabulation
  • Excessive agency
  • Sensitive information disclosed in output

Additional information

• Q: When will this requirement included in an assessment? [?]
  • This requirement will always be added to HITRUST assessments which include the
    Security for AI systems regulatory factor.
  • No other assessment tailoring factors affect this requirement.
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • Yes, partially. This may be a responsibility shared between an AI application provider and their AI platform provider (if used), performed independently on separate layers/components of the overall AI system.

HITRUST CSF requirement statement [?] (06.10hAISecSystem.7)

When creating machine learning-based AI models, the organization 
(1) explicitly documents a linkage between the versions of the training dataset used, the pipeline 
configuration used, and resulting AI model. 

Evaluative elements in this requirement statement [?]

1. When creating machine learning-based AI models, the organization explicitly documents a 
linkage between the versions of the training dataset used, the pipeline configuration used, and 
resulting AI model.

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample based test where possible for each evaluative element. Example test(s):
  • For example, select a sample of machine learning-based AI model versions released by the organization during the past year and ensure that the associated documentation contains an explicit linkage between the versions of the training dataset used, the pipeline configuration used, and the resulting AI model.
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate the percentage of ML-based AI models produced by the organization with this linkage documented as a percentage of total.
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 06 Configuration Management
• Control category: 10.0 – Information Systems Acquisition, Development, and Maintenance
• Control reference: 10h- Control of Operational Software

Specific to which parts of the overall AI system? [?]

• AI platform layer:
  • AI datasets and data pipelines
  • The AI model itself
  • Model-serving infrastructure and APIs
  • Model pipeline and model engineering environment
  • Model-level configurations (e.g., hyperparameters)

Discussed in which authoritative AI security sources? [?]

• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #DEVPROGRAM
    • #DEVSECURITY
      
      

• Guidelines for Secure AI System Development
  Nov. 2023, Cybersecurity & Infrastructure Security Agency (CISA)
  • Where:
    • 2. Secure development > Identify, track and protect your assets
      
      

• Deploying AI Systems Securely: Best Practices for Deploying Secure and Resilient AI Systems
  Apr 2024, National Security Agency (NSA)
  • Where:
    • Continuously protect the AI system > Validate the AI system before and during use > Bullet 3
      
      

Discussed in which commercial AI security sources? [?]

• Databricks AI Security Framework
  Sept. 2024, © Databricks
  • Where:
    • Control DASF 10: Version data
    • Control DASF 17: Track and reproduce the training data used for ML model training
    • Control DASF 52: Source code control
      
      

Control functions against which AI security threats? [?]

• Control function: Decision support
  • Prompt injection
  • Evasion
  • Model inversion
  • Model extraction and theft
  • Data poisoning
  • Model poisoning
  • Compromised 3rd-party training datasets
  • Compromised 3rd-party models or code
  • Confabulation
  • Excessive agency
  • Sensitive information disclosed in output

Additional information

• Q: When will this requirement included in an assessment? [?]
  • The Security for AI systems regulatory factor must be present in the assessment.
  • This requirement only applies when machine learning-based AI models are in use (generative, predictive).
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • Yes, fully. This requirement may be the sole responsibility of the AI model creator. Or, depending on the AI system’s architecture, only evaluative elements that are the sole responsibility of the AI model creator apply.

HITRUST CSF requirement statement [?] (07.10mAISecOrganizational.2)

To help ensure that unsafe assets are not introduced into the AI system, the 
organization checks the cryptographic hashes and/or digital signatures on downloaded AI
(1) models; 
(2) software packages (e.g., those for model creation, training, and/or deployment); 
(3) datasets (e.g., training datasets); and
(4) language model tools (e.g., agents, plugins)
before use, as applicable.

Evaluative elements in this requirement statement [?]

1. To help ensure that unsafe assets are not introduced into the AI system, the 
organization checks the cryptographic hashes and/or digital signatures on downloaded 
AI models before use, if applicable.

2. To help ensure that unsafe assets are not introduced into the AI system, the 
organization checks the cryptographic hashes and/or digital signatures on 
downloaded AI software packages (e.g., those used for model creation, training, and/or 
deployment) before use, if applicable.

3. To help ensure that unsafe assets are not introduced into the AI system, the 
organization checks the cryptographic hashes and/or digital signatures on 
downloaded AI datasets (e.g., training datasets) before use, if applicable.

4. To help ensure that unsafe assets are not introduced into the AI system, the 
organization checks the cryptographic hashes and/or digital signatures on 
downloaded language model tools (e.g., agents, plugins) before use, if applicable.

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample based test where possible for each evaluative element. Example test(s):
  • For example, review the AI system to ensure the organization verifies the cryptographic hashes and/or digital signatures on downloaded AI models, software packages (e.g., those for model creation, training, and/or deployment), datasets (e.g., training datasets), and language model tools (e.g., agents, plugins) before use, as applicable.
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate if the organization verifies the cryptographic hashes and/or digital signatures on downloaded AI models, software packages (e.g., those for model creation, training, and/or deployment), datasets (e.g., training datasets), and language model tools (e.g., agents, plugins) before use, as applicable.
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 07 Vulnerability Management
• Control category: 10.0 – Information Systems Acquisition, Development, and Maintenance
• Control reference: 10.m – Control of Technical Vulnerabilities
  
  

Specific to which parts of the overall AI system? [?]

AI application layer:

• AI plugins and agents

AI platform layer:

• The deployed AI model
• Model engineering environment and model pipeline
• AI datasets and data pipelines
  
  

Discussed in which authoritative AI security sources? [?]

• OWASP 2023 Top 10 for LLM Applications
  Oct. 2023, © The OWASP Foundation
  • Where:
    • LLM03: Training data poisoning > Prevention and mitigation strategies > Bullet #2
      
      

• OWASP 2025 Top 10 for LLM Applications
  2025, © The OWASP Foundation
  • Where:
    • LLM03: Supply Chain > Prevention and Mitigation Strategies > Bullet #6
      
      

• OWASP Machine Learning Security Top 10
  2023, © The OWASP Foundation
  • Where:
    • ML06:2023 AI supply chain attacks > How to prevent > Bullet #1
    • ML06:2023 AI supply chain attack > How to prevent > Bullet #6
      
      

• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #RUNTIMEMODELINTEGRITY
    • #SUPPLYCHAINMANAGE
    • #DEVSECURITY
      
      

• MITRE ATLAS
  2024, © The MITRE Corporation
  • Where:
    • AML.M0014
      
      

• NIST AI 100-2 E2023: Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations
  Jan. 2024, National Institute of Standards and Technology (NIST)
  • Where:
    • 3. Generative AI taxonomy > 3.2. AI supply chain attacks and mitigations > 3.2.2. Poisoning attacks
      
      

• Deploying AI Systems Securely: Best Practices for Deploying Secure and Resilient AI Systems
  Apr 2024, National Security Agency (NSA)
  • Where:
    • Continuously protect the AI system > Validate the AI system before and during use > Bullet 1
    • Continuously protect the AI system > Validate the AI system before and during use > Bullet 2
      
      

Discussed in which commercial AI security sources? [?]

• Databricks AI Security Framework
  Sept. 2024, © Databricks
  • Where:
    • DASF 10: Version data
    • DASF 11: Capture and view data lineage
    • DASF 22: Build models with all representative, accurate and relevant data sources to minimize third-party dependencies for models and data where possible
    • DASF 27: Pretrain a large language model (LLM) on your own IP
    • DASF 53: Third-party library control
    • DASF 42: Data-centric MLOps and LLMOps promote models as code using CI/CD.
      
      
• Snowflake AI Security Framework
  2024, © Snowflake Inc.
  • Where:
    • Model poisoning > Mitigations > Bullet 1
    • Self-hosted OSS LLMs Security > Mitigations > Cryptographic signing
      
      

Control functions against which AI security threats? [?]

• Control function: Preventative
  • Compromised 3rd-party training datasets
  • Compromised 3rd-party models or code
  • Data poisoning
  • Model poisoning

Additional information

• Q: When will this requirement included in an assessment? [?]
  • This requirement will always be added to HITRUST assessments which include the
    Security for AI systems regulatory factor.
  • No other assessment tailoring factors affect this requirement.
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • Yes, fully. This requirement may be the sole responsibility of the AI platform provider and/or model creator. Or, depending on the AI system’s architecture, only evaluative elements that are the sole responsibility of the AI platform provider and/or model creator apply.

HITRUST CSF requirement statement [?] (19.06aAISecOrganizational.1)

The organization 
(1) performs an assessment to identify and evaluate its compliance with applicable legal 
and regulatory requirements addressing the development and deployment of AI systems, 
including potential liability for harmful, infringing, or damaging outputs or behaviors. 
This assessment is performed 
(2) prior to deployment of the AI system and
(3) regularly (at least annually) thereafter.

Evaluative elements in this requirement statement [?]

1. The organization performs an assessment to identify and evaluate its compliance 
with applicable legal and regulatory requirements addressing the development and 
deployment of AI systems, including potential liability for harmful, infringing, or damaging 
outputs or behaviors.

2. This assessment is performed prior to the deployment of the AI system.

3. This assessment is performed regularly (at least annually).

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample based test where possible for each evaluative element. Example test(s):
  • For example, review the organizations assessment documentation to evaluate its compliance with applicable legal and regulatory requirements addressing the development and deployment of AI systems, including potential liability for harmful, infringing, or damaging outputs or behaviors. Further, confirm that the assessment was performed prior to the deployment of the AI system (if within the past year) and that one is performed regularly (at least annually).
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate completeness of the organization’s assessment to identify and evaluate its compliance with applicable legal and regulatory requirements addressing the development and deployment of AI systems. Reviews, tests, or audits are completed by the organization to measure the effectiveness of the implemented controls and to confirm that an assessment is performed regularly (at least annually).
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 19 Data Protection & Privacy
• Control category: 06 Compliance
• Control reference: 06.a – Identification of Applicable Legislation
  
  

Specific to which parts of the overall AI system? [?]

N/A, not AI component-specific

Discussed in which authoritative AI security sources? [?]

• ISO/IEC 22989:2022: Information technology — Artificial intelligence — Artificial intelligence concepts and terminology
  2022, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • 5. AI Concepts > 5.17. Jurisdictional issues
      
      

• ISO/IEC 23894:2023 Information technology — Artificial intelligence — Guidance on risk management
  2023, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • Annex A > A.2- Accountability > Last paragraph > Last sentence
      
      

• ISO/IEC 38507:2022 Information technology — Governance of IT — Governance implications of the use of artificial intelligence by organizations
  2022, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • 5. Overview of AI and AI systems > 5.5. Constraints on the use of AI
    • 6. Policies to address the use of AI > 6.6. Compliance > 6.6.1. Compliance obligations
    • 6. Policies to address the use of AI > 6.7. Risk > 6.7.3. Objectives
      
      

• ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system
  2023, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • 4. Context of the organization > 4.1. Understanding the organization and its context > Note 2, bullet a, sub-bullet 1
      
      

• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #CHECKCOMPLIANCE
      
      

• LLM AI Cybersecurity & Governance Checklist
  Feb. 2024, © The OWASP Foundation
  • Where:
    • 3. Checklist > 3.7. Legal > Bullet #7
    • 3. Checklist > 3.7. Legal > Bullet #8
    • 3. Checklist > 3.8. Regulatory > Bullet #1
    • 3. Checklist > 3.8. Regulatory > Bullet #10
      
      

• Generative AI framework for HM Government
  2023, Central Digital and Data Office, UK Government
  • Where:
    • Using generative AI safely and responsibly > Ethics > Accountability and responsibility > Practical recommendations > Bullet 1
    • Using generative AI safely and responsibly > Legal considerations > Paragraph 1
      
      

• Securing Machine Learning Algorithms
  2021, © European Union Agency for Cybersecurity (ENISA)
  • Where:
    • 4.1- Security Controls > Organizational > Assess the regulations and laws the ML application must comply with
      
      

Discussed in which commercial AI security sources? [?]

• Databricks AI Security Framework
  Sept. 2024, © Databricks
  • Where:
    • DASF 12: Delete records from datasets and retrain models to forget data subjects
    • DASF 29: Build MLOps workflows to track models and trace data sources and lineage to retrain models with the updated dataset by following legal constraints
    • DASF 27: Pretrain a large language model (LLM) to only use the data that is allowed with LLMs for inference
      
      

Control functions against which AI security threats? [?]

• Control function: Decision support
  • Denial of AI service
  • Prompt injection
  • Evasion
  • Model inversion
  • Model extraction and theft
  • Data poisoning
  • Model poisoning
  • Compromised 3rd-party training datasets
  • Compromised 3rd-party models or code
  • Confabulation
  • Excessive agency
  • Sensitive information disclosed in output

Additional information

• Q: When will this requirement included in an assessment? [?]
  • This requirement will always be added to HITRUST assessments which include the
    Security for AI systems regulatory factor.
  • No other assessment tailoring factors affect this requirement.
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • No (dual responsibility). The AI application provider and its AI service providers (if used) are responsible for independently performing this requirement outside of the AI system’s technology stack.

HITRUST CSF requirement statement [?] (19.06cAISecOrganizational.1)

The organization performs an assessment to identify and evaluate its compliance with 
constraints on the data used for AI efforts (i.e., data used for training, validating, tuning, 
and augmenting the prompts of AI systems via RAG), including those related to 
(1) applicable laws, 
(2) applicable regulatory requirements, 
(3) applicable contractual obligations, 
(4) the organization’s self-imposed data governance requirements, and 
(5) copyrights or commercial interests. 
The organization 
(6) acts based on the results of this assessment, if deemed necessary. 
This assessment performed 
(7) prior to using the data for AI efforts and
(8) regularly (at least annually) thereafter.

Evaluative elements in this requirement statement [?]

1. The organization performs an assessment to identify and evaluate its compliance 
with applicable laws related the data used for AI efforts (i.e., data used for training, 
validating, tuning, and augmenting the prompts of AI systems).

2. The organization performs an assessment to identify and evaluate its compliance 
with applicable regulatory requirements on the data used for AI efforts (i.e., data used for 
training, validating, tuning, and augmenting the prompts of AI systems).

3. The organization performs an assessment to identify and evaluate its compliance 
with applicable contractual obligations on the data used for AI efforts (i.e., data used for 
training, validating, tuning, and augmenting the prompts of AI systems).

4. The organization performs an assessment to identify and evaluate its compliance 
with the organization’s self-imposed data governance requirements on the data used for 
AI efforts (i.e., data used for training, validating, tuning, and augmenting the prompts of 
AI systems).

5. The organization performs an assessment to identify and evaluate its compliance 
with copyrights or other commercial constraints on the data used for AI efforts (i.e., data 
used for training, validating, tuning, and augmenting the prompts of AI systems).

6. The organization acts based on the results of this assessment, if deemed necessary.

7. This assessment is performed prior to using the data for AI efforts.

8. This assessment is performed regularly (at least annually) thereafter.

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample-based test where possible for each evaluative element. Example test(s):
  • For example, review the organizations assessment documentation to evaluate its compliance with constraints on the data used for AI efforts (i.e., data used for training, validating, tuning, and augmenting the prompts of AI systems via RAG), including those related to applicable laws, applicable contractual obligations, the organization’s self-imposed data governance requirements, and copyrights or commercial interests. Additionally, the organization acts based on the results of this assessment, if deemed necessary. Further, confirm that the assessment is performed regularly (at least annually).
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate completeness of the organization’s assessment to evaluate its compliance with constraints on the data used for AI efforts (i.e., data used for training, validating, tuning, and augmenting the prompts of AI systems via RAG), including those related to applicable laws, applicable contractual obligations, the organization’s self-imposed data governance requirements, and copyrights or commercial interests. Reviews, tests, or audits are completed by the organization to measure the effectiveness of the implemented controls and to confirm that an assessment is performed regularly (at least annually).
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 19 Data Protection & Privacy
• Control category: 06 Compliance
• Control reference: 06.c – Protection of Organizational Records
  
  

Specific to which parts of the overall AI system? [?]

AI application layer:

• Prompt augmentations (e.g., via RAG) and associated data sources

AI platform layer:

• Model tuning and associated datasets
• AI datasets and data pipelines
  
  

Discussed in which authoritative AI security sources? [?]

• ISO/IEC 38507:2022- Governance implications of the use of artificial intelligence by organizations
  2022, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • 6. Policies to address the use of AI > 6.4. Governance of data use
    • 6. Policies to address the use of AI > 6.6. Compliance > 6.6.1. Compliance obligations
    • 6. Policies to address the use of AI > 6.6. Compliance > 6.6.2. Compliance management
      
      

• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #CHECKCOMPLIANCE
      
      

• LLM AI Cybersecurity & Governance Checklist
  Feb. 2024, © The OWASP Foundation
  • Where:
    • 3. Checklist > 3.7. Legal > Bullet #6
    • 3. Checklist > 3.7. Legal > Bullet #10
      
      

• Generative AI framework for HM Government
  2023, Central Digital and Data Office, UK Government
  • Where:
    • Using generative AI safely and responsibly > Data protection and privacy > Lawfulness and purpose limitation > Practical recommendations > Bullet 3
      
      

Discussed in which commercial AI security sources? [?]

• Databricks AI Security Framework
  Sept. 2024, © Databricks
  • Where:
    • DASF 12: Delete records from datasets and retrain models to forget data subjects
    • DASF 29: Build MLOps workflows to track models and trace data sources and lineage to retrain models with the updated dataset by following legal constraints
    • DASF 27: Pretrain a large language model (LLM) to only use the data that is allowed with LLMs for inference
      
      

Control functions against which AI security threats? [?]

• Control function: Decision support
  • Denial of AI service
  • Prompt injection
  • Evasion
  • Model inversion
  • Model extraction and theft
  • Data poisoning
  • Model poisoning
  • Compromised 3rd-party training datasets
  • Compromised 3rd-party models or code
  • Confabulation
  • Excessive agency
  • Sensitive information disclosed in output

Additional information

• Q: When will this requirement included in an assessment? [?]
  • This requirement will always be added to HITRUST assessments which include the
    Security for AI systems regulatory factor.
  • However, this requirement only applies to machine learning-based AI model types (generative, predictive).
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • No (dual responsibility). The AI application provider and its AI service providers (if used) are responsible for independently performing this requirement outside of the AI system’s technology stack.

HITRUST CSF requirement statement [?] (14.09fAISecSystem.1)

The organization performs an evaluation of the security posture of any external 
commercial providers of AI system components, including AI
(1) models; 
(2) datasets; 
(3) software packages (e.g., those for model creation, training, and/or deployment); 
(4) platforms and computing infrastructure; and 
(5) language model tools such as agents and plugins, as applicable. 
This evaluation is performed 
(6) during onboarding of the provider and 
(7) on a routine basis thereafter
in accordance with the organization’s supplier oversight processes.

Evaluative elements in this requirement statement [?]

1. The organization performs an evaluation of the security posture of any external 
commercial providers of AI models, if applicable.

2. The organization performs an evaluation of the security posture of any external 
commercial providers of AI datasets, if applicable.

3. The organization performs an evaluation of the security posture of any external 
commercial providers of AI software packages (e.g., those for model creation, training, 
and/or deployment), if applicable.

4. The organization performs an evaluation of the security posture of any external 
commercial providers of AI platforms and computing infrastructure, if applicable.

5. The organization performs an evaluation of the security posture of any external 
commercial providers of language model tools such as agents and plugins, if applicable.

6. This evaluation is performed during onboarding of the provider.

7. This evaluation is performed on a routine basis thereafter in accordance with the organization’s supplier oversight processes.

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample based test where possible for each evaluative element. Example test(s):
  • For example, review documentation associated with a sample of external commercial providers of AI system components to ensure the organization performed an evaluation of their security posture. Further, confirm that this evaluation is conducted during the provider’s onboarding and on a routine basis thereafter, in accordance with the organization’s supplier oversight processes.
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate if the organization performs an evaluation of the security posture of any external commercial providers of AI system components, including AI models, datasets, software packages (e.g., those for model creation, training, and/or deployment), platforms and computing infrastructure, and language model tools such as agents and plugins, as applicable. Reviews, tests, or audits are completed by the organization to measure the effectiveness of the implemented controls and to confirm that all external commercial providers of AI system components are evaluated.
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 14 Third-party Assurance
• Control category: 05.0 – Organization of Information Security
• Control reference: 09.f – Monitoring and Review of Third Party Services
  
  

Specific to which parts of the overall AI system? [?]

AI application layer:

• AI plugins and agents
• The AI application’s supporting IT infrastructure (Considered in the associated HITRUST e1, i1, or r2 assessment)

AI platform layer:

• The AI platform and associated APIs (Considered in the associated HITRUST e1, i1, or r2 assessment)
• The deployed AI model
• Model engineering environment and model pipeline
• AI datasets and data pipelines
• AI compute infrastructure (Considered in the associated HITRUST e1, i1, or r2 assessment)
  
  

Discussed in which authoritative AI security sources? [?]

• OWASP 2023 Top 10 for LLM Applications
  Oct. 2023, © The OWASP Foundation
  • Where:
    • LLM05: Supply chain vulnerabilities > Prevention and mitigation strategies > Bullet #1
    • LLM05: Supply chain vulnerabilities > Prevention and mitigation strategies > Bullet #10
      
      

• OWASP 2025 Top 10 for LLM Applications
  2025, © The OWASP Foundation
  • Where:
    • LLM03: Supply Chain > Prevention and Mitigation Strategies > Bullet #1
    • LLM04: Data and Model Poisoning > Prevention and Mitigation Strategies > Bullet #2
      
      

• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #SUPPLYCHAINMANAGE
      
      

• LLM AI Cybersecurity & Governance Checklist
  Feb. 2024, © The OWASP Foundation
  • Where:
    • 3. Checklist > 3.8. Regulatory > Bullet #5
    • 3. Checklist > 3.8. Regulatory > Bullet #7
    • 3. Checklist > 3.8. Regulatory > Bullet #8
    • 3. Checklist > 3.8. Regulatory > Bullet #9
    • 3. Checklist > 3.9. Using or implementing large language model solutions > Bullet #11
    • 3. Checklist > 3.9. Using or implementing large language model solutions > Bullet #12
      
      

• Guidelines for Secure AI System Development
  Nov. 2023, Cybersecurity & Infrastructure Security Agency (CISA)
  • Where:
    • 1. Secure design > Design your system for security as well as functionality and performance
    • 2. Secure development > Secure your supply chain
      
      

• Deploying AI Systems Securely: Best Practices for Deploying Secure and Resilient AI Systems
  Apr 2024, National Security Agency (NSA)
  • Where:
    • Continuously protect the AI system > Validate the AI system before and during use > Bullet 6
      
      

• Managing Artificial Intelligence-Specific Cybersecurity Risks in the Financial Services Sector
  March 2024, U.S. Department of the Treasury
  • Where:
    • 5. Best practices for managing AI-specific security risks > 5.5. Asking the right questions of vendors
      
      

Discussed in which commercial AI security sources? [?]

• The anecdotes AI GRC Toolkit
  2024, © Anecdotes A.I Ltd.
  • Where:
    • Control 3.3: Assessment
      
      

• Databricks AI Security Framework
  Sept. 2024, © Databricks
  • Where:
    • Control DASF 50: Platform compliance
      
      
• HiddenLayer’s 2024 AI Threat Landscape Report
  2024, © HiddenLayer
  • Where:
    • Part 4: Predictions and recommendations > 3. Data security and privacy > Bullet 2
      
      
• Snowflake AI Security Framework
  2024, © Snowflake Inc.
  • Where:
    • Model poisoning > Mitigations > Bullet 1
    • Self-hosted OSS LLMs Security > Mitigations > Supply chain security
      
      

Control functions against which AI security threats? [?]

• Control function: Variance reduction
  • Denial of AI service
  • Prompt injection
  • Evasion
  • Model inversion
  • Model extraction and theft
  • Data poisoning
  • Model poisoning
  • Compromised 3rd-party training datasets
  • Compromised 3rd-party models or code
  • Sensitive information disclosed in output

Additional information

• Q: When will this requirement included in an assessment? [?]
  • This requirement will always be added to HITRUST assessments which include the
    Security for AI systems regulatory factor.
  • No other assessment tailoring factors affect this requirement.
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • No (dual responsibility). The AI application provider and its AI service providers are responsible for independently performing this requirement outside of the AI system’s technology stack.

HITRUST CSF requirement statement [?] (14.05iAISecOrganizational.1)

For externally sourced AI models deployed by the organization in production 
applications, the organization 
(1) reviews the model card prior to deployment.

Evaluative elements in this requirement statement [?]

1. For externally sourced AI models deployed by the organization in production 
applications, the organization reviews the model card prior to deployment.

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample based test where possible for each evaluative element. Example test(s):
  • For example, review the externally sourced AI models deployed in production applications and confirm the organization reviews the model card prior to deployment.
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate percentage of the organization’s externally sourced AI models deployed in production applications are reviewed. Reviews, tests, or audits are completed by the organization to measure the effectiveness of the implemented controls and to confirm that all model cards are reviewed prior to deployment.
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 14 Third-party Assurance
• Control category: 05.0 – Organization of Information Security
• Control reference: 05.i – Identification of Risks Related to External Parties
  
  

Specific to which parts of the overall AI system? [?]

AI platform layer:

• The deployed AI model
  
  

Discussed in which authoritative AI security sources? [?]

• OWASP 2023 Top 10 for LLM Applications
  Oct. 2023, © The OWASP Foundation
  • Where:
    • LLM03: Training Data Poisoning > Prevention and mitigation strategies > Bullet #1
      
      

• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #SUPPLYCHAINMANAGE
      
      

• LLM AI Cybersecurity & Governance Checklist
  Feb. 2024, © The OWASP Foundation
  • Where:
    • 3. Checklist > 3.11. Model cards and risk cards > Bullet #1
    • 3. Checklist > 3.11. Model cards and risk cards > Bullet #2
      
      

• Guidelines for Secure AI System Development
  Nov. 2023, Cybersecurity & Infrastructure Security Agency (CISA)
  • Where:
    • 2. Secure development > Document your data, models and prompts
      
      

• Generative AI framework for HM Government
  2023, Central Digital and Data Office, UK Government
  • Where:
    • Using generative AI safely and responsibly > Ethics > Transparency and explainability > Practical recommendations > Bullet #4
      
      

Control functions against which AI security threats? [?]

• Control function: Decision support
  • Evasion
  • Model inversion
  • Model extraction and theft
  • Compromised 3rd-party models or code
  • Confabulation
  • Excessive agency
  • Sensitive information disclosed in output

Additional information

• Q: When will this requirement included in an assessment? [?]
  • This requirement will always be added to HITRUST assessments which include the
    Security for AI systems regulatory factor.
  • No other assessment tailoring factors affect this requirement.
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • No. Implementing and/or configuring this requirement is the AI application provider’s sole responsibility.
    
    

• More information about model cards from:
  • Hugging Face
  • AWS SageMaker
  • SalesForce
  • Google
  • ServiceNow

HITRUST CSF requirement statement [?] (14.05kAISecOrganizational.1)

Agreements between the organization and external commercial providers of AI system 
components and services clearly communicate the organization’s AI security requirements, 
including agreements with providers of AI
(1) models,
(2) datasets, 
(3) software packages, 
(4) platforms and computing infrastructure, 
(5) language model tools such as agents and plugins, and 
(6) contracted AI system-related services (e.g., outsourced AI system development), as 
applicable.

Evaluative elements in this requirement statement [?]

1. Agreements between the organization and external commercial providers of AI models 
clearly communicate the organization’s AI security requirements, as applicable.

2. Agreements between the organization and external commercial providers of AI 
datasets clearly communicate the organization’s AI security requirements, as applicable.

3. Agreements between the organization and external commercial providers of AI 
software packages clearly communicate the organization’s AI security requirements, 
as applicable.

4. Agreements between the organization and external commercial providers of AI 
platforms and computing infrastructure clearly communicate the organization’s AI 
security requirements, as applicable.

5. Agreements between the organization and external commercial providers of AI models 
clearly communicate the organization’s AI security requirements, as applicable.

6. Agreements between the organization and external commercial providers of contracted 
AI system-related services (e.g., outsourced AI system development) clearly communicate 
the organization’s AI security requirements, as applicable.

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample based test where possible for each evaluative element. Example test(s):
  • For example, review a sample of agreements between the organization and external commercial providers of AI system components and services to evidence these documents clearly communicate the organization’s AI security requirements. Further, confirm that agreements are in place with all providers of AI models, datasets, software packages, platforms and computing infrastructure, language model tools such as agents and plugins, and contracted AI system-related services (e.g., outsourced AI system development), as applicable.
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate if agreements between the organization and external commercial providers of AI system components and services clearly communicate the organization’s AI security requirements. Reviews, tests, or audits are completed by the organization to measure the effectiveness of the implemented controls and to confirm that agreements are in place with all providers of AI models, datasets, software packages, platforms and computing infrastructure, language model tools such as agents and plugins, and contracted AI system-related services (e.g., outsourced AI system development), as applicable.
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 14 Third-party Assurance
• Control category: 05.0 – Organization of Information Security
• Control reference: 05.k – Addressing Security in Third Party Agreements
  
  

Specific to which parts of the overall AI system? [?]

AI application layer:

• AI plugins and agents
• The deployed AI application (Considered in the associated HITRUST e1, i1, or r2 assessment)
• The AI application’s supporting IT infrastructure (Considered in the associated HITRUST e1, i1, or r2 assessment)

AI platform layer:

• The AI platform and associated APIs (Considered in the associated HITRUST e1, i1, or r2 assessment)
• The deployed AI model
• Model engineering environment and model pipeline
• AI datasets and data pipelines
• AI compute infrastructure (Considered in the associated HITRUST e1, i1, or r2 assessment)
  
  

Discussed in which authoritative AI security sources? [?]

• ISO/IEC 38507:2022- Governance implications of the use of artificial intelligence by organizations
  2022, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • 6. Policies to address the use of AI > 6.7. Risk > 6.7.2. Risk management
      
      
• ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system
  2023, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • Annex A > A.10. Third-party and customer relationships > A.10.2. Allocating responsibilities
    • Annex A > A.10. Third-party and customer relationships > A.10.3. Suppliers
      
      
• LLM AI Cybersecurity & Governance Checklist
  Feb. 2024, © The OWASP Foundation
  • Where:
    • 3. Checklist > 3.7. Legal > Bullet #11
      
      

• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #SUPPLYCHAINMANAGE
      
      

• Guidelines for Secure AI System Development
  Nov. 2023, Cybersecurity & Infrastructure Security Agency (CISA)
  • Where:
    • 2. Secure development > Secure your supply chain
      
      

• Deploying AI Systems Securely: Best Practices for Deploying Secure and Resilient AI Systems
  Apr 2024, National Security Agency (NSA)
  • Where:
    • Secure the deployment environment > Manage deployment environment governance > Bullet 3
      
      

• Managing Artificial Intelligence-Specific Cybersecurity Risks in the Financial Services Sector
  March 2024, U.S. Department of the Treasury
  • Where:
    • 5. Best practices for managing AI-specific security risks > 5.9. Cybersecurity best practices to closely apply to AI systems
      
      

• Generative AI framework for HM Government
  2023, Central Digital and Data Office, UK Government
  • Where:
    • Building generative AI solutions > Buying generative AI > Specifying your requirements > Paragraph 1
    • Using generative AI safely and responsibly > Ethics > Accountability and responsibility > Practical recommendations > Bullet 3
      
      

Discussed in which commercial AI security sources? [?]

• The anecdotes AI GRC Toolkit
  2024, © Anecdotes A.I Ltd.
  • Where:
    • Control 3.2: Agreement
      
      

Control functions against which AI security threats? [?]

• Control function: Variance reduction
  • Denial of AI service
  • Prompt injection
  • Evasion
  • Model inversion
  • Model extraction and theft
  • Data poisoning
  • Model poisoning
  • Compromised 3rd-party training datasets
  • Compromised 3rd-party models or code
  • Confabulation
  • Excessive agency
  • Sensitive information disclosed in output

Additional information

• Q: When will this requirement included in an assessment? [?]
  • This requirement will always be added to HITRUST assessments which include the
    Security for AI systems regulatory factor.
  • No other assessment tailoring factors affect this requirement.
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • No (joint responsibility). The AI application provider and its AI service providers (if used) are responsible for jointly performing this requirement outside of the AI system’s technology stack (e.g., through a jointly executed agreement / contract).

HITRUST CSF requirement statement [?] (19.13jAISecOrganizational.1)

The organization reviews the data used to 
(1) train AI models,  
(2) fine-tune AI models, and
(3) enhance AI prompts via RAG
to identify any data fields or records that can be omitted or anonymized (to prevent them 
from potentially leaking) and takes action on findings.

Evaluative elements in this requirement statement [?]

1. The organization reviews the data used to train AI models to identify any data fields or records that can be removed or 
anonymized (to prevent them from potentially leaking) and takes action on findings.

2. The organization reviews the data used to fine-tune AI models to identify any data fields or records that can be removed or 
anonymized (to prevent them from potentially leaking) and takes action on findings.

3. The organization reviews the data used to enhance AI prompts via RAG to identify any data fields or records that can be 
removed or anonymized (to prevent them from potentially leaking) and takes action on findings.

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample based test where possible for each evaluative element. Example test(s):
  • For example, evaluate the AI model to ensure the organization reviews the data used to train AI models, fine-tune AI models, and enhance AI prompts via RAG to identify any data fields or records that can be omitted or anonymized (to prevent them from potentially leaking) and takes action on findings.
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate the percentage of the organization’s AI datasets which have undergone this review.
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 19 Data Protection & Privacy
• Control category: 13.0 – Privacy Practices
• Control reference: 13.j – Data Minimization
  
  

Specific to which parts of the overall AI system? [?]

AI application layer:

• Prompt enhancement via RAG, and associated RAG data sources

AI platform layer:

• Model tuning and associated datasets
• AI datasets and data pipelines
  
  

Discussed in which authoritative AI security sources? [?]

• ISO/IEC 23894:2023 Information technology — Artificial intelligence — Guidance on risk management
  2023, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • Annex A > A.9- Model Robustness
      
      

• OWASP 2023 Top 10 for LLM Applications
  Oct. 2023, © The OWASP Foundation
  • Where:
    • LLM06: Sensitive information disclosure > Prevention and mitigation strategies > Bullet #1
      
      

• OWASP 2025 Top 10 for LLM Applications
  2025, © The OWASP Foundation
  • Where:
    • LLM02: Sensitive Information Disclosure > Prevention and Mitigation Strategies > Sanitization > Bullet #1
      
      

• OWASP Machine Learning Security Top 10
  2023, © The OWASP Foundation
  • Where:
    • ML04:2023 Membership inference attack > How to prevent > Bullet #4
      
      

• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #DATAMINIMIZE
    • #OBFUSCATETRAININGDATA
      
      

• Generative AI framework for HM Government
  2023, Central Digital and Data Office, UK Government
  • Where: Using generative AI safely and responsibly > Data protection and privacy > Data minimization > Bullet 1
    
    

Discussed in which commercial AI security sources? [?]

• The anecdotes AI GRC Toolkit
  2024, © Anecdotes A.I Ltd.
  • Where:
    • Control 4.1: Data sanitization
      
      
• Databricks AI Security Framework
  Sept. 2024, © Databricks
  • Where:
    • Control DASF 58: Protect data with filters and masking
      
      
• Snowflake AI Security Framework
  2024, © Snowflake Inc.
  • Where:
    • Training data leakage > Mitigations > Data anonymization
    • Privacy > Mitigations > Data minimization
      
      

Control functions against which AI security threats? [?]

• Control function: Preventative
  • Model inversion
  • Sensitive information disclosed in output

Additional information

• Q: When will this requirement included in an assessment? [?]
  • This requirement is included when confidential and/or sensitive data was used for model training, model tuning, and/or prompt enhancement via RAG for the assessment’s in-scope AI system.
  • However, this is requirement is not included when the in-scope AI system leverages a rule-based AI model only.
  • The Security for AI systems regulatory factor must also be present in the assessment.
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • Yes, fully. This requirement may be the sole responsibility of the AI platform provider and/or model creator. Or, depending on the AI system’s architecture, only evaluative elements that are the sole responsibility of the AI platform provider and/or model creator apply.

HITRUST CSF requirement statement [?] (07.10mAISecOrganizational.3)

The
(1) precision, and 
(2) specificity
of AI application outputs are reduced to limit an adversary's ability to extract information 
from the model and/or optimize potential attacks (e.g., omit or round indication of precision 
of confidence in the output so it cannot be used for optimization, limit specificity of 
output class ontology).

Evaluative elements in this requirement statement [?]

1. The precision of AI system outputs is reduced (e.g., round indication 
of confidence in the output so it cannot be used for optimization) to limit an 
adversary's ability to extract information from the model and/or optimize 
potential attacks.

2. The specificity of AI system outputs is reduced (e.g., limit specificity of 
output class ontology) to limit an adversary's ability to extract information 
from the model and/or optimize potential attacks.

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample based test where possible for each evaluative element. Example test(s):
  • For example, review the AI model to ensure the precision and specificity of AI application outputs are reduced to limit an adversary’s ability to extract information from the model and/or optimize potential attacks.
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate if AI application outputs are reduced to limit an adversary’s ability to extract information from the model and/or optimize potential attacks.
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 07 Vulnerability Management
• Control category: 10.0 – Information Systems Acquisition, Development, and Maintenance
• Control reference: 10.m – Control of Technical Vulnerabilities

Specific to which parts of the overall AI system? [?]

• AI application layer:
  • Application AI safety and security systems
    
    

Discussed in which authoritative AI security sources? [?]

• ISO/IEC 23894:2023 Information technology — Artificial intelligence — Guidance on risk management
  2023, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • Annex A > A.9- Model Robustness
      
      

• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #OBSCURECONFIDENCE
      
      

• MITRE ATLAS
  2024, © The MITRE Corporation
  • Where:
    • AML.M0002
      
      

• Guidelines for Secure AI System Development
  Nov. 2023, Cybersecurity & Infrastructure Security Agency (CISA)
  • Where:
    • 1. Secure design > Design your system for security as well as functionality and performance
      
      

• Securing Machine Learning Algorithms
  2021, © European Union Agency for Cybersecurity (ENISA)
  • Where:
    • 4.1- Security Controls > Specific ML > Reduce the information given by the model
      
      

Control functions against which AI security threats? [?]

• Control function: Resistive
  • Evasion
  • Model extraction and theft
  • Model inversion

Additional information

• Q: When will this requirement included in an assessment? [?]
  • This requirement is included when confidential and/or sensitive data was used for model training, model tuning, and/or prompt enhancement via RAG for the assessment’s in-scope AI systems.
  • This requirement is also included when the assessment’s in-scope AI system(s) leverage models with technical architectures that are confidential to the organization.
  • The Security for AI systems regulatory factor must also be present in the assessment.
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • No. Implementing and/or configuring this requirement is the AI application provider’s sole responsibility.

HITRUST CSF requirement statement [?] (17.03bAISecOrganizational.3)

The organization evaluates the need to take additional measures against AI training data (e.g., 
adversarial training, using randomized smoothing techniques) to specifically ensure that the 
machine learning-based AI models it produces are more resistant to evasion and poisoning 
attacks. This evaluation is 
(1) documented, 
(2) performed regularly (at least semiannually) thereafter, and 
(3) revisited when security incidents related to the AI system occur. 
Additional measures deemed necessary as a result of this evaluation are 
(4) implemented by the organization. 

Evaluative elements in this requirement statement [?]

1. The organization documents an evaluation of the need to take additional measures against AI training 
data (e.g., adversarial training, using randomized smoothing techniques) to specifically ensure that the 
machine learning-based AI models it produces are more resistant to evasion and poisoning attacks. 

2. This evaluation is performed regularly (at least semiannually).

3. This evaluation is revisited when security incidents related to the AI system occur.

4. Additional measures deemed necessary as a result of this evaluation are implemented by the organization. 

Illustrative procedures for use during assessments [?]

• Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
  
  
• Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
  
  
• Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample based test where possible for each evaluative element. Example test(s):
  • For example, inspect the documentation produced as a result of the evaluation described in this requirement and confirm that any measures deemed necessary as a result of the evaluation have been implemented. Further, evidence that the evaluation was revisited at the frequency described in the requirement.
    
    
• Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
  • For example, measures indicate the percentage of the AI models produced by the organization subject to this evaluation of total.
    
    
• Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
  
  
  

Placement of this requirement in the HITRUST CSF [?]

• Assessment domain: 17 Risk Management
• Control category: 03.0 – Risk Management
• Control reference: 03.b – Performing Risk Assessments
  
  

Specific to which parts of the overall AI system? [?]

• AI platform layer:
  • AI datasets and data pipelines
    
    

Discussed in which authoritative AI security sources? [?]

• ISO/IEC 23894:2023 Information technology — Artificial intelligence — Guidance on risk management
  2023, © International Standards Organization (ISO)/International Electrotechnical Commission (IEC)
  • Where:
    • Part 6. Risk management process > 6.4 Risk assessment > 6.4.2 Risk identification > 6.4.2.5 Identification of controls
    • Part 6. Risk management process > 6.4 Risk assessment > 6.4.2 Risk identification > 6.5.2 Selection of risk treatment options
    • Annex A > A.9- Model Robustness
      
      

• OWASP 2025 Top 10 for LLM Applications
  2025, © The OWASP Foundation
  • Where:
    • LLM02: Sensitive Information Disclosure > Prevention and Mitigation Strategies > Federated Learning and Privacy Techniques > Bullet #2
    • LLM10: Unbounded consumption > Prevention and Mitigation Strategies > Bullet #11
      
      

• OWASP Machine Learning Security Top 10
  2023, © The OWASP Foundation
  • Where:
    • ML01:2023 Input manipulation attack > How to prevent > Bullet #1
    • ML01:2023 Input manipulation attack > How to prevent > Bullet #2
    • ML04:2023 Membership inference attack > How to prevent > Bullet #1
    • ML04:2023 Membership inference attack > How to prevent > Bullet #2
    • ML10:2023 Model Poisoning > How to prevent > Bullet #2
      
      

• OWASP AI Exchange
  2024, © The OWASP Foundation
  • Where:
    • #TRAINDATADISTORTION
    • #TRAINADVERSARIAL
    • #EVASIONROBUSTMODEL
      
      

• MITRE ATLAS
  2024, © The MITRE Corporation
  • Where:
    • AML.M0002
    • AML.M0003
      
      

• NIST AI 100-2 E2023: Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations
  Jan. 2024, National Institute of Standards and Technology (NIST)
  • Where:
    • 2. Predictive AI taxonomy > 2.2. Evasion attacks and mitigations > 2.2.4. Mitigations
    • 2. Predictive AI taxonomy > 2.3. Poisoning attacks and mitigations > 2.3.1. Availability poisoning
      
      

• Guidelines for Secure AI System Development
  Nov. 2023, Cybersecurity & Infrastructure Security Agency (CISA)
  • Where:
    • 3. Secure deployment > Protect your model continuously
      
      

• Securing Machine Learning Algorithms
  2021, © European Union Agency for Cybersecurity (ENISA)
  • Where:
    • 4.1- Security Controls > Specific ML > Apply modifications on inputs
    • 4.1- Security Controls > Specific ML > Add some adversarial examples to the training dataset
      
      

Discussed in which commercial AI security sources? [?]

• Snowflake AI Security Framework
  2024, © Snowflake Inc.
  • Where:
    • Lack of explainability / transparency > Mitigations > Adversarial training
    • Prompt injection > Mitigations > Adversarial training
    • Indirect prompt injection > Mitigations > Bullet 2
    • Adversarial samples > Mitigations > Robust model training
    • Sponge samples > Mitigations > Adversarial training
    • Fuzzing > Mitigations > Adversarial training
    • Model poisoning > Mitigations > Bullet 4
    • Training data poisoning > Mitigations > Robust model training
      
      

Control functions against which AI security threats? [?]

• Control function: Resistive, Preventative
  • Evasion
  • Data Poisoning
  • Model inversion

Additional information

• Q: When will this requirement included in an assessment? [?]
  • The Security for AI systems regulatory factor must also be present in the assessment.
  • However, this is only included when non-generative machine learning models are in-scope, as these are the only types of models this requirement applies to.
    
    

• Q: Will this requirement be externally inheritable? [?] [?]
  • Yes, fully. This requirement may be the sole responsibility of the AI model creator. Or, depending on the AI system’s architecture, only evaluative elements that are the sole responsibility of the AI model creator apply.