APP-005 Penetration Testing
Description
Penetration testing of production systems and applications is conducted at a defined frequency (at minimum annually) and after significant architectural changes. Testing is performed by parties independent of the team responsible for the system under test. Findings are documented, risk-rated, and remediated according to a defined schedule. Retesting confirms remediation.
Rationale
Automated scanning finds known vulnerability patterns but misses logic flaws, chained vulnerabilities, and novel attack paths. Independent penetration testing provides adversarial validation that automated tools cannot replicate.
Framework Mappings (2)
| TVM-07 | Penetration Testing | full |
| CA-8 | Penetration Testing | full |
Evidence (2)
Penetration test report from the most recent annual engagement, conducted by an independent third party, with findings, risk ratings, and remediation status.
Example: Penetration test report (PDF) from a named third-party security firm, covering production systems and applications, dated within the last 12 months. Report must include: scope statement, methodology, finding list with severity ratings, and a remediation status column.
Test: Request the most recent penetration test report. Verify: (1) the report is dated within the last 12 months, or within 30 days of a significant architectural change if that occurred sooner, (2) the testing firm is independent of the development team, (3) the scope covers production-facing systems and applications, (4) all critical and high findings are either remediated (confirmed by retest) or have a documented risk acceptance signed by an authorised individual, (5) a retest report exists for any originally critical/high findings.
Remediation tracking records showing that penetration test findings were triaged, assigned, and resolved within the defined SLA.
Example: Jira or equivalent issue tracker export showing all findings from the most recent pen test as individual tickets, each with severity, assignee, target remediation date, and current status (open/in-progress/closed). Closed tickets must include a resolution note.
Test: Cross-reference the pen test finding list against the issue tracker. Verify: (1) every finding from the report has a corresponding ticket, (2) critical findings were resolved within the policy-defined SLA (typically 30 days), high within 60–90 days, (3) any open findings beyond their SLA have a documented risk acceptance or extension approval, (4) retest evidence exists for all remediated critical/high findings.
Questions (2)
Is penetration testing of production systems and applications conducted at least annually by a party independent of the team responsible for the system?
Testing must be performed by a party independent of the development team — either an external firm or a distinct internal red team. Self-assessed or developer-led testing does not satisfy this control.
How are penetration test findings managed after testing is complete?
Every finding must have a corresponding ticket. Critical findings should be remediated and retested within 30 days. Untracked or unconfirmed remediation significantly weakens the value of the pen test.