A plain-English scoping guide for security-conscious – but not necessarily security-savvy – organizations
SOC 2 Type II
1.1 Why Pen-Testing Matters for SOC 2
While the AICPA’s Trust Services Criteria (TSC) do not explicitly say “run a penetration test,” they do require you to demonstrate that technical controls prevent, detect, and react to attacks over the entire audit period (usually 12 months). Pen-tests are the most direct evidence for:
- CC4.1 / CC4.2 – Monitoring and evaluating system changes
- CC7.1 – Identifying and managing vulnerabilities
Bottom line: A pen-test isn’t mandatory by name, but auditors (and your clients!) nearly always expect one as proof that the security, availability, and confidentiality controls you claim are actually effective
1.2 Scoping Your “System”
Everything that supports the service you provide to customers (production cloud accounts, CI/CD pipelines, admin consoles, support VPNs, third-party managed services, etc.) is in scope until it’s segmented or contractually carved-out.
1.3 Typical SOC 2 Set-ups & What to Test
| Scenario | In-Scope for the Pen-Test | Notes |
|---|---|---|
| SaaS platform in AWS/Azure/GCP | • Public endpoints (external) • Optional: VPC/VNet hosting the app (internal) • Optional: IAM roles, container registry, serverless functions | Primarily focuses on your front-end and back-end web applications, including REST and GraphQL APIs and endpoints. |
| Hybrid cloud + on-prem HQ | • Data-center VLANs that replicate or back-up prod data • SSO/IdP, jump-boxes, bastion hosts | Segmentation test proves corp LAN can’t pivot into prod. |
| Third-party integrations (e.g., payment, CRM) | • API gateways, webhooks, outbound service accounts | If an exploit here compromises customer data, it’s in scope. |
1.4 Pen-Test Types to Expect
| Test | Depth | Typical Approach |
|---|---|---|
| Web / API app test | Grey-box (credentials) or black-box (no-credentials) | Required by most auditors and commonly requested by your customers |
| Infrastructure: Internal lateral-movement | Black/grey-box | Focus on privilege escalation & data exposure. |
| Infrastructure: Segmentation validation | Grey-box | Firewall/WAF reviews, trace-route, ACL tests. |
| External attack surface | Black-box | It can be configured to run continuously but is required at least annually to validate perimeter controls in accordance with CC7. |
1.5 Frequency & Independence
Perform at least annually and after significant changes; keep evidence covering the entire Type II period. Testers must be outside the day-to-day ops team (auditors will ask)
ISO 27001 (2022 Revision)
2.1 Why Pen-Testing Matters for ISO 27001
Pen-testing is a recognised control under Annex A 8.8 (Technical Vulnerability Management) and 8.29 (Security Testing in Development & Acceptance). It’s one of the easiest ways to show your risk treatment plan is working.
2.2 Map Your ISMS Boundary
List every asset that stores, processes, or transmits information covered by the Statement of Applicability (SoA) – including SaaS tools where you are data controller. Anything outside that boundary must be justified as “not significant.”
2.3 Test Types
| Control Goal | Suggested Test | Depth |
|---|---|---|
| 8.8 – Technical vulnerabilities | External + internal network & app tests | Grey-box |
| 8.29 – Secure dev & acceptance | Dynamic app test in staging + Code Scanners | Grey-box + code scanners (SAST, SCA, etc) |
| 5.17 – Information security in supplier relationships | Limited pen-test of vendor-hosted portals or strong segmentation evidence | Often contractual |
HIPAA (US Health-Care Entities)
3.1 Why Pen-Testing Matters for HIPAA
The Security Rule (45 CFR §§164.306 & 308) demands a risk analysis and “ongoing technical evaluation.” OCR’s latest NIST SP 800-66 Rev 2 maps that to vulnerability scanning and penetration testing.
A January 2025 Notice of Proposed Rulemaking (NPRM) goes further – requiring:
- Pen-testing at least once every 12 months
- Network segmentation tests
- Semi-annual vulnerability scans
3.2 Find Your ePHI Flows
Draw a simple data-flow map: EHR, patient portal, billing, backups, vendors. Any system that touches or can reach electronic protected health information (ePHI) is in scope.
3.3 Typical Health-Tech Set-ups & Scope
| Scenario | In-Scope for Pen-Test | Notes |
|---|---|---|
| SaaS patient portal | • Web app/API (external) • App servers & DB (internal) • Cloud storage buckets | Verify encryption-at-rest controls & MFA. |
| On-prem EHR plus remote clinics | • Hospital LANs, clinic VPNs • HL7 interfaces, SFTP feeds • Wireless in clinical areas | Wireless & segmentation tests are hot-button OCR issues. |
| Outsourced billing vendor | • VPN tunnel endpoints • User-provisioning portal | Your BAA should grant testing rights or provide evidence. |
3.4 Recommended Test Types
| Test | Why | Depth |
|---|---|---|
| External network/app | Validate perimeter & portal auth | Black (no-credentials) / Grey-box (with credentials) |
| Internal network | Show lateral-movement resistance | Grey-box (credentials, diagrams, etc) |
| Segmentation | NPRM mandates proof ePHI is isolated | Grey-box (credentials, diagrams, etc) |
| Social engineering / phishing | Maps to 164.308(a)(5) Workforce Security | Optional but persuasive |
3.5 Frequency & Evidence
Until the NPRM is final, annual pen-tests are considered industry best practice; keep detailed reports plus remediation evidence for six years (same retention period as other Security Rule docs).
Common Deliverables Across All Frameworks
- Executive Summary – risk-ranked, non-technical.
- Detailed Findings – with CVSS/CWE, and remediation.
- Segmentation / Scope-Validation Letter (if you’re excluding parts of the network).
- Retest Report – evidence critical issues are closed.
- Formal Attestation Letter – language mapped to the relevant standard/audit.
Pen-tests are a snapshot in time, but when aligned with SOC 2, ISO 27001, or HIPAA requirements they also become powerful audit artifacts that prove your security program is more than paperwork.
