AI Control Library / CF-08: Testing & Robustness
Designation: Supplemental | Control types represented: Operational and Technical
Control requirement
Respond to credible AI threats through documented triage, investigation, containment and recovery actions linked to affected systems and authority. Verify that response capability works across model, data, application and tool boundaries.
Why this matters
A threat alert has little value if responders cannot identify the service or interrupt the harmful path. Response needs concrete authority and evidence while distinguishing suspected activity from confirmed impact.
How the control types work together
Operational controls define scope, authority and the actions required when conditions are not met. Technical controls produce evidence or enforce the relevant boundaries. Both must apply to the same deployment and operating conditions.
When it applies
AI security threats from monitoring, tests, advisories, user reports and supplier notifications.
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 security response owner coordinates system, data and platform owners with appropriate business authority.
Implementation guidance
- Define triggers, severity, contacts and immediate containment options for relevant AI threat scenarios.
- Collect protected context and assess scope, affected permissions, data and actual actions without overclaiming what the evidence proves.
- Contain through approved controls, addressing delegated work and supplier dependencies while preserving necessary evidence.
- Verify trusted restoration and lessons, updating detections, tests and procedures after the event.
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 |
|---|---|
| Exercise a credible AI threat | The responsible team receives evidence and can apply the defined containment. |
| Include delegated or queued activity | Response addresses continuing work beyond the visible interface. |
| Review restoration | Required trust and operating conditions are verified before normal use. |
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
- AI threat response playbooks
- Triage and scope records
- Containment exercises
- Restoration and improvement evidence
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
Activate incident response for ongoing material exposure. Use alternate containment if the primary path fails and keep affected functions restricted until recovery is authorized.
Example in practice
Hypothetical example: A retrieved document triggers suspicious tool activity. Response blocks the affected tool identity and investigates actual requests rather than assuming that every instruction in the document was successfully executed.
Related controls
- CF09-005: AI Security Monitoring & Alerting
- CF07-006: AI System Kill Switch & Emergency Stop
- CF10-003: AI Incident Response Plans
Framework mappings
- CSA AICM
- NIST AI RMF (MANAGE 4.1, 4.3)
- MITRE ATLAS
- OWASP LLM Top 10
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