AI Control Library / CF-08: Testing & Robustness
Designation: Supplemental | Control types represented: Operational
Control requirement
Establish AI application security policy covering design, development, acquisition, deployment and operation, with clear requirements, ownership and verification for both conventional and AI-specific security boundaries.
Why this matters
An AI application combines models with code, data and permissions. Policy must connect those responsibilities instead of assuming a model safety feature secures the whole service.
How the control types work together
Operational controls establish the assigned responsibilities, review processes and response decisions described here. Their effectiveness depends on performing the work and using evidence to guide action, rather than approving a document alone.
When it applies
AI applications and integrations, including internally developed systems, vendor features and agent workflows.
Define the assessed boundary, dependencies and evidence limitations. Tailor depth and review frequency to potential impact, and document why a particular safeguard or exclusion is appropriate to the actual deployment.
Ownership
The application security owner maintains policy with AI, engineering and operations leaders.
Implementation guidance
- Define scope and risk-based requirements for identities, data, tools, interfaces, dependencies and administrative paths.
- Assign design review, testing, remediation, release and operational duties, including shared supplier responsibilities.
- Integrate requirements into acquisition and delivery gates with controlled exceptions.
- Review policy using actual findings and incidents, updating related baselines, training and evidence expectations.
How to verify it
Use representative records and authorized controlled tests. Identify the relevant version, operating conditions and expected result before testing, and retain enough evidence to support the conclusion.
| Test | Expected result |
|---|---|
| Trace an application release | Security requirements and accountable reviews shaped the decision. |
| Inspect an AI-specific integration | Its data and action boundaries receive explicit coverage. |
| Review a policy exception | Owner, duration and compensating conditions are recorded. |
Record a finding when required results cannot be demonstrated or practice differs materially from the approved conditions. Missing evidence limits the conclusion; it should not be treated as a successful test.
Evidence to retain
- Approved application security policy
- Responsibility and lifecycle gates
- Release and exception records
- Review and improvement decisions
Protect evidence according to its sensitivity, access needs and retention rules. Avoid unnecessary copies of personal information, secrets or confidential material, while preserving the records needed for authorized review.
If the control fails
Escalate unowned security requirements or unsupported release to the security and business owners. Restrict affected functionality until required controls or an authorized alternative operate.
Example in practice
Hypothetical example: A chatbot project protects the model endpoint but has no owner for exports. The policy assigns application-level data access and output-handling requirements before release.
Related controls
- CF08-S02: AI Application Security Baseline Requirements
- CF08-S04: AI Secure Development Lifecycle
- CF08-007: AI Application Security Testing
Framework mappings
- CSA AICM (AIS-01)
- NIST AI RMF (MEASURE 1.1)
- ISO 42001 (Cl. 8.2)
Review and maintenance
Review at the interval approved by the control owner and after relevant changes, incidents or failed assessments. Update affected procedures and configuration, address evidence gaps and verify corrective action before closing findings.
Version 1.0