Annual Penetration Testing

Why it matters

An annual external pentest by independent testers identifies vulnerabilities and misconfigurations that internal teams may miss or rationalize away, reducing the risk of exploitation by actual attackers before detection systems catch them. Without this systematic external perspective, organizations accumulate exploitable weaknesses in production applications and infrastructure that violate CC7's requirement to identify and remediate security gaps through detective controls.

Evidence to collect

• Signed statement of work or contract with third-party pentest firm naming scope (production infrastructure, web apps, APIs, network perimeter), testing methodology (black-box or grey-box), and engagement dates within the past 12 months
• Pentest final report with executive summary, detailed findings ranked by severity (critical/high/medium/low), proof-of-concept evidence, and remediation recommendations
• Issue tracking evidence (Jira, GitHub, spreadsheet, etc.) showing critical and high findings from the pentest report linked to closure tickets with remediation dates and verification notes
• Evidence of remediation verification—either retesting results from the pentest firm, or security team validation (screenshots, log excerpts, configuration reviews) confirming fixes before the next audit cycle

Testing procedure

Request the signed pentest engagement agreement and obtain the final report dated within the previous 12 months; verify scope explicitly covers production applications, APIs, and network perimeter at your primary data centers or cloud regions. Cross-reference all critical and high findings in the report against your issue tracking system to confirm they were assigned, remediated, and closed before the current audit period. For a sample of 3–5 remediated findings, request evidence of remediation (patched versions, configuration changes, or retesting confirmation) and verify closure dates fall before your next planned pentest or audit cutoff.

Common gotchas