Essential Cybersecurity Controls (ECC – 2 : 2024) Control 2-11-2 requires organizations to perform penetration testing and maintain documentation demonstrating that tests were planned, executed, and remediated in a controlled and auditable manner; this post gives Compliance Framework–specific, practical steps, real-world examples for small businesses, and the documentation items you must produce to demonstrate compliance.
Interpretation of ECC 2-11-2 within the Compliance Framework
Under the Compliance Framework, Control 2-11-2 is typically interpreted as requiring: (a) a repeatable process for penetration tests or equivalent assessments, (b) documented scope and authorization, (c) evidence of technical findings and proof-of-concept where appropriate, (d) remediation actions tied to findings, and (e) retention of test artifacts for audit. For small businesses this means you must show auditors a clear trail from planning to fix verification — not just a vulnerability scanner output.
Planning: scope, rules of engagement, and risk controls
Define scope and get written authorization
You must begin with an asset inventory and a scoped test plan. List IP ranges, hostnames, web apps (with URLs and environments: prod/QA), cloud accounts (AWS/GCP/Azure), and in-scope APIs. Create a Rules of Engagement (RoE) document specifying test windows, allowed test techniques (e.g., non-destructive exploitation only), escalation contacts, and rollback procedures. For Compliance Framework alignment, include an approval block signed by the CTO or Compliance Officer and a legal sign-off if customer data could be touched.
Execution: technical approach and tooling
Use credentialed and non-credentialed testing where appropriate
Adopt an established methodology (e.g., OWASP for web apps, PTES/OSSTMM for networks) and perform layered testing: external perimeter (non-credentialed), internal network (credentialed where allowed), web application dynamic testing, and limited exploitation for proof-of-concept. Practical technical steps: run a discovery phase with nmap (e.g., nmap -sS -Pn -p- -T4 --open -oA discovery
Documentation: what to capture and how to present it
Produce a structured report with executive and technical sections
Your final deliverable should include: an executive summary (risk posture and remediation priorities), scope & RoE, methodology & tools list (versions and configurations), a finding-by-finding technical appendix (title, affected asset, CVSS score or risk rating, CWE reference, PoC evidence such as screenshots or log extracts, commands run, timestamps), remediation recommendations, and retest/verification results. For each finding include a remediation ticket reference (change control ID), target SLA for fixes (e.g., critical within 7 days), and the person/role assigned. Store raw artifacts—pcap files, scanner exports (Nessus .nessus), Burp project files, and signed RoE—in encrypted storage and log access to those artifacts to preserve chain-of-custody for Compliance Framework audits.
Remediation, retest, and evidence retention
After testing, require development or ops to create documented remediation tickets and link them to the specific finding in your pen-test report. Perform a targeted retest (credentialed where relevant) to verify fixes and include the retest evidence in the updated report. Compliance Framework best practice is annual penetration testing, and mandatory retesting after major changes (e.g., new public web app or cloud migration). Retain the final report and supporting artifacts for the period required by the Framework or your regulator — a practical recommendation for small businesses is a minimum of 3 years — and ensure reports are encrypted at rest and access-controlled.
Small-business scenario and cost-efficient approaches
Example: a 30-person e-commerce retailer hosting a web app on AWS with a small internal network. Practical plan: inventory public IPs and the web app, run an initial authenticated vulnerability scan, hire an external tester for a focused web-application penetration test (2–3 days) that includes proof-of-concept of critical findings, and require remediation tickets in the retailer's IT ticketing system (e.g., Jira) with retest within 14 days. Cost-saving options: perform monthly authenticated scanning in-house with Nessus Essentials or open-source tools, and use an annual third-party pen-test for compliance evidence. Alternatively, use a vetted bug-bounty program for web apps but ensure you still obtain a formal pen-test report covering network-level risks to meet ECC 2-11-2 expectations.
Risk of non-compliance and final compliance tips
Failing to conduct and document penetration tests as required by ECC 2-11-2 leaves exploitable vulnerabilities unaddressed, increases the chance of data breaches, regulatory penalties, and customer loss, and undermines your ability to demonstrate due diligence to auditors or insurers. Compliance tips: always get written authorization before testing, use test accounts or sanitized data to avoid PII exposure during PoC, map findings to business impact (CWE/CVSS + probable impact), track remediation using change-control IDs, redact sensitive customer data from reports, and maintain an audit trail showing who ran tests and when.
Summary: To meet Compliance Framework Control 2-11-2, implement a repeatable pen-testing lifecycle that includes scope and RoE approval, methodological testing with clear technical evidence, prioritized remediation with retest, and secure, auditable storage of artifacts; for small businesses, combine in-house scanning with an annual third-party test, document everything to an auditor-friendly standard, and treat test documentation as evidence of due diligence rather than just a security checkbox.
