Penetration testing is a core requirement under Essential Cybersecurity Controls (ECC – 2 : 2024) Control 2-11-1, and auditors expect both clearly documented test requirements and verifiable evidence that tests were planned, executed, and remediated in line with your Compliance Framework; this post explains how to structure those documents, what artifacts to collect, and how a small business can implement a practical, audit-ready process.
Why this control matters and the risks of non-compliance
Control 2-11-1 exists because simulated adversary testing demonstrates whether controls, detection, and response processes work under realistic conditions; failing to document and evidence penetration testing leads to audit findings, potential fines, missed vulnerabilities, data breaches, business disruption, loss of customer trust, and prolonged remediation cycles. Auditors look for traceability: requirement → execution → evidence → remediation → verification; any gap increases your compliance risk and operational exposure.
Practical implementation steps within the Compliance Framework
Implement this control by embedding penetration testing into your Compliance Framework lifecycle: (1) Define scope and objectives in a Test Plan (assets, IP ranges, apps, API endpoints, cloud services). (2) Create Rules of Engagement (RoE) and a signed Statement of Work (SoW) that includes test windows, allowed testing methods (e.g., credentialed vs. non-credentialed), escalation contacts, and rollback/abort procedures. (3) Select an internal team or independent third-party with documented qualifications. (4) Execute the test, collect artifacts, and raise findings into your Vulnerability Management workflow. (5) Track remediation SLAs and require retest verification. Frequency: at least annually, after significant changes (deployments, architecture, mergers), and more frequently (quarterly) for high-risk assets.
Control 2-11-1 checklist (what to document)
Use the following checklist to prepare documentation for auditors: 1) Approved Test Plan with objectives and asset inventory; 2) Signed RoE and SoW; 3) Tester qualifications (CVs, certifications such as OSCP, CISSP, CREST); 4) Schedule and test windows; 5) Scope exclusions and rationale; 6) Allowed tools and exploit policy; 7) Evidence collection and retention policy; 8) Communication and emergency contact list; 9) Pre- and post-test backups and rollback plan; 10) Test execution logs and raw artifacts; 11) Formal test report (exec summary + technical appendix); 12) Vulnerability ticket IDs with remediation owner and SLA; 13) Retest evidence and closure confirmation; 14) Approvals from Risk/Compliance and IT owners; 15) Chain-of-custody notes if sensitive evidence is handled externally.
Evidence to collect — technical details auditors want to see
Collect both high-level and technical artifacts: signed Test Plan/RoE (PDF), final Penetration Test Report (PDF), raw scan outputs (e.g., nmap.xml, nessus.csv), web proxy logs (Burp project files), exploit proofs (screenshots, shell sessions), packet captures (.pcap), authenticated test logs, and SIEM correlation showing generated alerts. Include commands and timestamps for reproducibility (example: nmap -sV -p1-65535 --open -oX nmap_example.xml example.com), and provide SHA256 hashes for archived evidence files. Store evidence with access controls (encrypted S3 with KMS or a GRC platform), log who accessed items, and retain per your Compliance Framework retention policy (commonly 1–3 years). Maintain a simple naming convention: penetration-ecc2-11-1_
Small-business scenario: practical example
Imagine a small e-commerce business hosted on AWS with a customer-facing web app, API gateway, RDS database, and S3 for images. For Control 2-11-1: create a Test Plan listing the app URL, API endpoints, associated IP ranges, and IAM roles. Use credentialed testing against a staging mirror and targeted production tests only for non-destructive cases. Contract a reputable third-party for the external network and web app test; require RoE and tester insurance. During testing collect Burp project data, web logs (ALB/CloudFront), CloudTrail records for API calls, and a host of vulnerability-scan exports. After delivery, create tickets in the existing ticketing system (e.g., Jira) with remediation owners and SLAs: Critical = 7 days, High = 30 days, Medium = 90 days; schedule retest within 30 days of fixes for Critical/High vulnerabilities. Document all of this in your Compliance Framework's GRC module and attach reports to the related control evidence folder.
Compliance tips and best practices
Best practices include using independent 3rd-party testers for objectivity, rotating testing vendors to avoid blind spots, always including authenticated (credentialed) testing for business-critical apps, and defining clear remediation SLAs with owners. Automate evidence ingestion into your GRC system where possible (scan result parsers, ticket links, signed PDFs), enforce encryption and least-privilege access to artifacts, and log all access for audit trails. Ensure your retention and destruction policies match regulatory requirements and your Compliance Framework. Finally, maintain a retest policy (mandatory retest for Critical/High within 30 days) and require the tester to provide reproducible steps for each finding to reduce remediation time.
In summary, meeting ECC – 2 : 2024 Control 2-11-1 requires clear scoping, signed rules of engagement, detailed evidence collection (both reports and raw artifacts), tracked remediation with retest verification, and secure evidence management; following the checklist and practical steps above will make audits smoother, reduce risk, and improve your organization's security posture.
