AI Control Library / CF-08: Testing & Robustness
Designation: Supplemental | Control types represented: Operational
Control requirement
Integrate AI application security into lifecycle activities from requirements and design through implementation, evaluation, release, operation and retirement. Require stage-appropriate evidence and accountable decisions.
Why this matters
Late testing cannot always correct architecture or data choices already embedded in the system. A secure lifecycle makes security a delivery responsibility rather than a final review obstacle.
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 software development and acquisition, including prompt, retrieval, model, tool and configuration changes.
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 delivery owner maintains the lifecycle with application security and AI risk specialists.
Implementation guidance
- Assign security requirements and threat analysis before data commitments and architecture decisions become difficult to change.
- Apply controlled implementation, code review, dependency management and protected development environments.
- Require relevant tests and release authorization for the actual candidate and deployment scope.
- Maintain operational feedback and retirement procedures, feeding vulnerabilities and incidents back into design and development.
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 a feature across stages | Security decisions precede the changes they govern. |
| Inspect a prompt or tool change | It follows the relevant lifecycle checks rather than bypassing them as non-code work. |
| Review a retired service | Access, tasks and sensitive artifacts are addressed. |
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
- Secure lifecycle and gate criteria
- Design and implementation reviews
- Testing and release records
- Operational feedback and retirement
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 bypassed security gates to delivery and release owners. Pause the affected progression and assess exposure already introduced.
Example in practice
Hypothetical example: A team treats tool permissions as versioned delivery artifacts. A new write-capable tool triggers threat review and authorization tests before it reaches production.
Related controls
- CF01-017: AI System Lifecycle Stage Controls
- CF08-S07: AI Application Source Code Management
- CF08-S05: AI Application Secure Deployment
Framework mappings
- CSA AICM (AIS-04)
- NIST AI RMF (MEASURE 2.5)
- 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