# Third-Party Penetration Testing
Third-party penetration testing is the practice of engaging an external security firm to simulate adversary attacks against the organization's systems, applications, and infrastructure. The external firm (the pen test provider) operates independently from the organization's internal security team, providing an unbiased assessment of the organization's defenses from an attacker's perspective.
Third-party pen testing is distinct from internal security testing (red team exercises, vulnerability scanning, automated pen testing tools) in one critical way: the external team has no prior knowledge of the organization's defenses, no relationship with the internal team, and no incentive to produce favorable results. This independence is what makes third-party pen testing valuable as an assurance mechanism: it tests the organization's defenses as an actual attacker would encounter them, without the familiarity bias that internal testing inherently carries.
The pen testing article on CDA.Wiki covers the discipline of penetration testing (methodologies, types, tools, MITRE ATT&CK alignment). This article covers the operational practice of procuring, scoping, executing, and operationalizing third-party pen tests: how to buy one, how to scope it correctly, how to evaluate the results, and how to ensure the findings produce security improvement rather than a shelf-bound report.
Not all pen testing firms deliver equivalent value. The market ranges from automated vulnerability scan reports relabeled as "penetration tests" to sophisticated adversary emulation conducted by experienced operators. Selection criteria:
Methodology. The provider should follow a recognized methodology (PTES, OWASP Testing Guide, NIST SP 800-115, CREST) and describe their approach in sufficient detail during the proposal process. A provider that cannot articulate their methodology beyond "we use industry-standard tools" is likely running automated scans, not conducting penetration testing.
Team qualifications. The individuals conducting the test (not the sales team) should hold relevant certifications (OSCP, OSCE, GPEN, GXPN, CREST CRT/CCT) and have documented experience in the type of testing being procured. Request the resumes or qualification summaries of the assigned testers.
Reporting quality. Request a sample report (redacted). The report should include: executive summary (business-impact language, not just CVSS scores), detailed findings with reproduction steps (another tester should be able to reproduce every finding from the report), evidence (screenshots, command output, data samples), severity ratings with context (not just CVSS, but exploitability in the specific environment), and specific remediation recommendations.
Scope of services. Some providers offer retesting after remediation at no additional cost or reduced cost. Retesting validates that the findings were actually fixed. A provider that delivers a report and disappears provides assessment without assurance.
References. Request references from organizations similar in size and industry. A provider with extensive financial services experience may not have the cloud-native expertise needed for a SaaS company's environment. Domain expertise matters.
Insurance and liability. The provider should carry professional liability (E&O) insurance and cyber liability insurance. The engagement contract should include liability provisions for damage caused during testing (a pen tester who accidentally disrupts production systems should have insurance to cover the impact).
Scoping determines what is tested, how it is tested, and what constraints apply. Poor scoping produces useless results: too narrow and the test misses critical attack paths; too broad and the test is superficial across everything.
Test type selection:
External network pen test: testing the organization's internet-facing infrastructure from the outside. Identifies vulnerabilities in perimeter defenses, public-facing applications, and external services. This is the minimum pen test that every organization should conduct at least annually.
Internal network pen test: testing from inside the network (the tester is given a network connection on the internal network or VPN access). Simulates an attacker who has achieved initial access and is attempting lateral movement, privilege escalation, and data access. Internal tests frequently reveal that perimeter defenses are strong but internal controls are weak.
Web application pen test: focused testing of specific web applications for OWASP Top 10 vulnerabilities and application-specific logic flaws. More thorough than automated DAST scanning because the tester applies human judgment to identify business logic vulnerabilities that scanners miss.
Cloud pen test: testing cloud infrastructure configurations, IAM policies, and cloud-native services. Cloud pen testing requires familiarity with the specific provider's (AWS, Azure, GCP) architecture and common misconfigurations.
Social engineering assessment: phishing, vishing (voice phishing), and physical social engineering to test the human layer. Social engineering tests measure employee awareness and the effectiveness of security awareness training.
Red team engagement: a multi-vector assessment that simulates a realistic adversary operation: combining social engineering for initial access, technical exploitation for lateral movement, and objective-based testing (reach the crown jewels, exfiltrate specific data, compromise the domain). Red team engagements are the most comprehensive but also the most expensive and time-consuming.
Scope boundaries: Define what is in scope and what is out of scope. Production systems may be in scope for testing but with restrictions (no denial-of-service testing, no data destruction, no modification of production data). Certain systems may be excluded entirely (medical devices, ICS/SCADA, systems with known instability). Third-party systems (SaaS applications, cloud provider infrastructure) may require the provider's written authorization before testing.
Rules of engagement (ROE). Document the testing constraints: authorized testing hours, notification requirements (who is notified before testing begins), emergency contact procedures (if the tester causes an unintended disruption), data handling requirements (how the tester handles any sensitive data encountered during testing), and stop conditions (circumstances that require the tester to halt and notify the organization).
Testing window. Define the calendar period for testing. Business-hours testing captures the environment under normal operating conditions. After-hours testing captures the environment when monitoring may be reduced. Most external pen tests are conducted during a 1 to 3 week window. Red team engagements may extend to 4 to 8 weeks.
The pen test report is not the deliverable. Security improvement is the deliverable. The report is the input to an improvement process.
Finding triage. Review each finding and validate: is this a real finding (does it represent actual risk in the organization's context)? What is the business impact (not just the CVSS score, but the operational consequence if the finding is exploited)? What is the remediation effort (quick fix, moderate project, or significant infrastructure change)?
Remediation prioritization. Prioritize findings using the same risk-based approach as vulnerability management: critical and actively exploitable findings first, then high-severity findings with significant business impact, then medium findings during normal maintenance cycles. CDA's recommended remediation SLAs for pen test findings:
| Severity | Remediation SLA | |----------|---------------| | Critical | 14 days | | High | 30 days | | Medium | 60 days | | Low | 90 days or next maintenance cycle |
Remediation tracking. Each finding is assigned to a remediation owner with a defined deadline. Progress is tracked through the organization's issue tracking system (Jira, ServiceNow, Linear) alongside vulnerability management findings. Pen test findings that are not tracked are pen test findings that are not fixed.
Retesting. After remediation, the pen test provider (or internal team) retests the specific findings to verify they are resolved. A finding that was reported as "remediated" but still exploitable during retest is a remediation failure that needs investigation (was the fix implemented incorrectly? was it applied to some systems but not all? was a different vulnerability introduced by the fix?).
Trend analysis. Across multiple annual pen tests, track the trending: are the same finding categories recurring (suggesting systemic issues rather than individual vulnerabilities)? Is the total finding count decreasing (suggesting the security program is improving)? Are critical findings decreasing while informational findings increase (suggesting the maturity level is improving)? Trend analysis transforms individual pen tests from point-in-time assessments into a longitudinal measure of security program effectiveness.
Internal security teams have blind spots. They configured the systems. They wrote the detection rules. They defined the security policies. They have institutional knowledge that biases their testing toward known weaknesses and away from assumptions they have not questioned. An external pen tester arrives without this knowledge and tests the environment as an actual attacker would: probing every surface, testing every assumption, and following every attack path the defenders did not anticipate.
Third-party pen testing is required or recommended by every major compliance framework. PCI DSS Requirement 11.4 mandates annual external and internal penetration testing by a qualified resource. NIST CSF 2.0 includes penetration testing as a security assessment activity. ISO 27001 A.8.34 (Protection of Information Systems During Audit Testing) addresses security testing. SOC 2 examiners frequently expect pen testing evidence. CMMC includes penetration testing at Level 3. Cyber insurance underwriters commonly ask whether the organization conducts annual pen testing.
Vulnerability scanners identify known vulnerabilities. Architecture reviews identify design flaws. Compliance audits verify control documentation. Only penetration testing validates whether the combination of controls actually prevents an attacker from achieving their objective. A pen tester who chains a low-severity web application vulnerability with an internal misconfiguration and an over-privileged service account to reach the database demonstrates a real attack path that no individual assessment method would have identified.
Third-party pen testing sits in the VSD (Vulnerability and Surface Defense) domain of the Planetary Defense Model. VSD is the ocean layer: the attack surface that adversaries probe and breach. Pen testing is the controlled simulation that validates whether the VSD controls (and controls in adjacent domains) actually prevent an adversary from achieving their objective.
CDA's Continuous Surface Reduction (CSR) methodology uses pen test findings as empirical evidence of surface exposure. A pen test finding that demonstrates access from the internet to an internal database is CSR evidence that the surface reduction is incomplete. The finding drives specific remediation through VSD, SPH (segmentation), and IAT (access control) domain missions.
Two TOP missions connect directly to third-party pen testing:
CDA approaches third-party pen testing with one distinction: CDA does not sell pen testing as a standalone service. Pen testing produces findings. Findings require remediation. Remediation requires operational capability across multiple PDM domains. CDA provides the end-to-end cycle: scope the pen test (VSD-D01/D02), manage the engagement with the external provider, triage and prioritize findings, remediate through domain-specific missions (VSD, SPH, IAT, DPS), and verify through retesting. The pen test is an input to the operational cycle, not the output.
Word count: 1,969