Annual Independent Penetration Testing

Penetration testing is conducted annually by an independent firm with expertise in both traditional application security and AI-specific threats. The scope must cover all attack surfaces identified in the threat model : internet-facing APIs, operator interfaces, administrative endpoints, inter-service communication, and model serving infrastructure.

For AI systems, the penetration test scope extends beyond traditional targets. Model API endpoints are tested for model extraction through repeated querying and information leakage through output analysis. Data pipeline endpoints are tested for data injection or poisoning through input manipulation. The human oversight interface is tested for privilege escalation, session hijacking, or interface manipulation that could cause operators to approve harmful outputs.

AI-specific penetration testing requires specialist expertise. Traditional penetration testing firms may not have ML security experience. Firms with documented AI security capabilities are engaged by the AI Governance Lead for the AI-specific components. The engagement brief references the threat model and the OWASP Top 10 for LLM Applications, specifying which threats the test should exercise. Testing frequency is annual at minimum and additionally after every substantial modification.

Key outputs

• Annual penetration test by an independent firm
• Scope covering traditional and AI-specific attack surfaces
• Engagement brief referencing the threat model and OWASP LLM Top 10
• Module 9 AISDP evidence

Penetration Test Reporting & Remediation SLAs

The penetration testing firm provides a structured report mapping each finding to a severity rating (CVSS score), the affected AISDP module, and a recommended remediation. The report format should enable direct traceability between the finding, the threat model entry it exercises, and the AISDP module it affects.

Critical findings have a remediation SLA of 30 days; high-severity findings have a remediation SLA of 90 days. The Technical SME verifies remediation through re-testing, confirming that the vulnerability is no longer exploitable. Findings that cannot be remediated within the SLA are escalated to the AI Governance Lead and recorded in the risk register with a documented justification, compensating controls, and a revised remediation timeline.

For AI-specific findings, remediation may require model retraining, architecture changes, or updates to the human oversight interface. These remediation paths are typically longer than patching a software vulnerability, and the SLA should account for the validation gate cycle that any model or architecture change must pass before deployment. The penetration test report and all remediation records are retained as Module 9 evidence.

Key outputs

• Structured penetration test report with CVSS scoring per finding
• Remediation SLAs (critical: 30 days; high: 90 days)
• Re-testing verification of remediation
• Module 9 AISDP evidence