Table of Contents
What Is Penetration Testing?
Penetration testing, commonly called a pen test or ethical hacking, is the practice of hiring certified security professionals to simulate a real-world cyberattack against your systems, applications, or infrastructure, with the explicit goal of finding exploitable vulnerabilities before a real attacker does. Unlike automated scanning tools, penetration testers apply human judgment, chain together multiple weaknesses, and demonstrate the actual business impact of a successful breach. The output is not just a list of vulnerabilities, it is evidence of what an attacker could have done with them.
Penetration Test vs. Vulnerability Scan: The Critical Difference
One of the most persistent misconceptions in enterprise security is that a vulnerability scan and a penetration test are the same exercise at different price points. They are not. They answer fundamentally different questions.
| Dimension | Vulnerability Scan | Penetration Test |
|---|---|---|
| Method | Automated tool-based enumeration | Manual exploitation by human testers |
| Output | List of known CVEs and misconfigurations | Demonstrated attack paths with proof-of-concept |
| Depth | Surface-level detection | Full exploitation including privilege escalation |
| Chaining | Identifies individual weaknesses | Chains multiple weaknesses into realistic attack scenarios |
| Business context | None – severity is CVSS score | Explicit — impact is mapped to business risk |
| False positives | High – tool reports unconfirmed findings | Low — tester confirms exploitability before reporting |
| Regulatory value | Limited – most frameworks require more | Accepted for ISO 27001, PCI-DSS, DORA TLPT, NIS2 |
| Typical duration | Hours | Days to weeks depending on scope |
| Cost | Low ($500-$5,000) | Significant ($10,000-$100,000+) |
| When to use | Continuous hygiene, weekly or monthly | Annual assurance, pre-audit, post-change |
A vulnerability scan tells you what might be broken. A penetration test tells you what can be broken, by whom, and with what consequences. For organizations facing regulatory scrutiny or managing significant digital assets, only the latter provides the evidence quality that auditors, insurers, and boards require.
What Makes a Penetration Test “Outcome-Driven”?
Most penetration testing engagements are scoped by asset type: “test the web application,” “test the external perimeter,” “test the internal network.” This approach produces technically accurate findings, but it often fails to answer the question that actually matters to the business: Can an attacker reach our crown jewels, and what would happen if they did?
Outcome-driven penetration testing begins from the opposite direction. Instead of defining scope by asset type, it defines scope by risk objective:
- What is the most damaging outcome we need to prevent? (Customer data exfiltration, ransomware deployment, financial transaction manipulation, operational system disruption.)
- What regulatory control must we validate? (ISO 27001 Annex A.8.8 technical vulnerability management, PCI-DSS Requirement 11.4, DORA TLPT Article 26, NIS2 Article 21 security measures.)
- What specific attack vector represents our highest unvalidated risk? (Phishing to ransomware, third-party access to core systems, cloud misconfiguration to data exposure.)
Only after those outcomes are defined does scope get set. This means the test simulates the scenarios that would actually matter – not the scenarios that happen to fall inside a convenient network segment. The report that follows maps every finding to a specific business impact and a specific remediation priority, so the organization can act on it without needing a security expert to translate it.
This is IPV Security’s proprietary positioning on penetration testing: every engagement is scoped around business risk and regulatory requirements, not around the convenience of the asset inventory.
The 5 Phases of a Professional Penetration Test
A structured penetration testing engagement – whether conducted against an external perimeter, an internal network, a web application, or a cloud environment – follows five defined phases. Understanding these phases is essential for evaluating whether a proposed engagement will deliver genuine assurance.
Phase 1 – Scoping and Rules of Engagement
Before any technical work begins, the engagement parameters are defined in writing: target systems, permitted techniques, excluded systems (production environments with zero tolerance for disruption), timing windows, emergency escalation contacts, and the legal authorization that protects both parties. This is not administrative overhead, it is the foundation that separates ethical hacking from criminal activity. A penetration testing firm that skips this phase is a liability, not an asset.
The outcome-driven scoping conversation happens here: the client defines the attack scenarios that represent real business risk, and the testing team designs the engagement to test exactly those scenarios.
Phase 2 – Reconnaissance
Passive and active reconnaissance maps the target’s external footprint – domains, IP ranges, exposed services, technology stack, employee directories, credential leaks in public data sources, and any information that a real attacker would gather before launching an attack. Passive reconnaissance uses only open-source intelligence (OSINT) and generates no traffic against target systems. Active reconnaissance – port scanning, service fingerprinting, web crawling – is conducted within the agreed scope and timing windows.
This phase frequently surfaces unexpected exposure: forgotten subdomains, legacy services left internet-facing, credentials found in public code repositories, or organizational information that enables highly targeted phishing scenarios.
Phase 3 – Exploitation
This is the phase that distinguishes penetration testing from all other security assurance activities. Using the vulnerabilities and attack vectors identified in reconnaissance, the testing team attempts to exploit weaknesses and gain unauthorized access, exactly as a real attacker would. This includes:
- Exploiting software vulnerabilities (unpatched CVEs, logic flaws, injection vulnerabilities)
- Bypassing authentication controls
- Exploiting misconfigured cloud resources or network services
- Conducting phishing simulations (where authorized)
- Attempting credential stuffing or password spraying
Critically, the tester documents every step – the exact technique used, the payload deployed, the response received – so that findings are fully reproducible and can be validated during remediation.
Phase 4 – Post-Exploitation
Once initial access is achieved, the test does not stop. Real attackers do not stop at the front door. Post-exploitation maps what an attacker can do with the access they have achieved: lateral movement to other systems, privilege escalation to administrative or domain-level control, data identification and exfiltration simulation, persistence mechanisms, and pivoting to otherwise-isolated environments.
This is where the outcome-driven approach pays its most significant dividend. By defining the crown jewel assets upfront, the testing team can demonstrate whether a realistic attacker could reach customer payment data, production source code, executive communications, or operational control systems and what the path looked like. That demonstration is what makes the board take the findings seriously.
Phase 5 – Reporting
A penetration test report is only as valuable as the decisions it enables. A high-quality pen test report contains four elements:
- Executive summary – a non-technical narrative of what was achieved, what it means for the business, and what the organization must prioritize
- Detailed technical findings – each vulnerability fully documented with steps to reproduce, evidence, affected assets, and CVSS severity
- Business impact mapping – every finding translated into business risk language, not just technical severity
- Remediation roadmap – prioritized, specific, and actionable recommendations, not generic best-practice statements
Types of Penetration Tests: Choosing the Right Scope
Not all penetration tests test the same things. The appropriate scope depends on the organization’s primary risk exposure, regulatory requirements, and the maturity of its existing security program.
- External network penetration test – targets internet-facing infrastructure: perimeter firewalls, VPN gateways, web servers, email infrastructure, and any externally accessible services. This is typically the starting point for organizations that have not previously commissioned professional penetration testing.
- Internal network penetration test – simulates a breach from inside the network perimeter, representing the scenario of a compromised workstation, a rogue insider, or an attacker who has successfully phished their way through the perimeter. This test exposes lateral movement paths, Active Directory vulnerabilities, and the absence of internal network segmentation.
- Web application penetration test – focuses on a specific web application or API, testing for the OWASP Top 10 and application-specific logic flaws. Essential for any organization running customer-facing applications or APIs that handle sensitive data.
- Cloud security assessment – evaluates the security configuration of cloud infrastructure (AWS, Azure, GCP), including IAM permissions, storage access controls, network security groups, logging coverage, and data protection configurations.
- Social engineering / phishing simulation – tests the human element by simulating phishing emails, vishing calls, or physical intrusion attempts. Particularly valuable before security awareness training programs, as it establishes a measurable baseline.
- DORA Threat-Led Penetration Testing (TLPT) – a specialized, intelligence-led red team exercise mandated by the Digital Operational Resilience Act for significant financial entities. TLPT follows the TIBER-EU framework and tests the full attack lifecycle against real, intelligence-sourced threat scenarios.
Regulatory Requirements That Mandate Penetration Testing
Penetration testing is no longer a discretionary security best practice for most regulated organizations – it is an explicit regulatory requirement. Understanding which frameworks apply to your organization determines both the scope and the minimum frequency of testing.
- ISO 27001:2022 Annex A.8.8 – requires that organizations assess technical vulnerabilities and take appropriate measures. While the standard does not prescribe penetration testing by name, Annex A.8.8 is widely interpreted by auditors to require it for medium and large organizations.
- PCI-DSS v4.0 Requirement 11.4 – mandates external and internal penetration testing at least annually and after any significant infrastructure change. Scope must cover the cardholder data environment and all system components. Testers must be qualified and independent.
- DORA Article 26 – Threat-Led Penetration Testing (TLPT) – applies to significant financial entities under the Digital Operational Resilience Act (effective January 17, 2025). TLPT is an advanced red team exercise based on real threat intelligence, conducted at minimum every three years, by certified testers against production systems including people, processes, and technology.
- NIS2 Article 21 – requires operators of essential and important entities to implement “appropriate and proportionate technical and operational measures” including security testing. Regulators in multiple EU member states have issued guidance explicitly listing penetration testing as a required measure.
- SOC 2 (Trust Services Criteria) – while SOC 2 does not mandate penetration testing, auditors routinely evaluate the existence and results of penetration tests as evidence for the availability, security, and confidentiality trust service criteria.
The average cost of a data breach reached $4.45 million in 2023 (IBM Cost of a Data Breach Report) a figure that dwarfs the cost of any professional penetration test. For organizations subject to regulatory enforcement, the penalty exposure compounds that risk further: NIS2 fines reach €10 million or 2% of global turnover, and DORA violations carry significant supervisory penalties for financial entities.
What Certifications Should Your Pen Tester Hold?
The quality of a penetration test is only as high as the capability of the tester conducting it. These are the certifications that provide meaningful assurance of technical competence:
- OSCP (Offensive Security Certified Professional) – the industry’s most respected hands-on penetration testing certification. Requires a 24-hour practical exam in which candidates must compromise a set of target machines using only manual techniques. No multiple-choice exam; pass or fail is determined by demonstrated exploitation.
- CREST – the UK-based accreditation body that certifies both individual testers and testing organizations. CREST-certified organizations meet defined standards for methodology, quality assurance, and professional conduct. Required for TIBER-EU/TLPT engagements.
- CEH (Certified Ethical Hacker) – a vendor-neutral certification covering the concepts and tools of ethical hacking. Widely recognized but less technically demanding than OSCP; useful as a screening credential rather than a standalone assurance.
- GPEN / GWAPT (GIAC Penetration Tester / Web Application Penetration Tester) – GIAC certifications with strong technical rigor, valued particularly for network and web application testing respectively.
When evaluating a penetration testing provider, ask specifically which certifications the testers assigned to your engagement hold – not the credentials of the firm’s most senior staff member.
What a Good Penetration Test Report Must Include
The deliverable that matters most is the final report – and the quality of that report is what separates a useful engagement from an expensive document that sits in a drawer.
A professional penetration test report must include:
- Scope confirmation – a precise record of what was tested, what was excluded, and what the testing period was
- Methodology statement – the frameworks and approaches used (PTES, OWASP, OSSTMM, custom)
- Executive summary – written for a non-technical audience; describes what happened, what it means, and what to do
- Risk-rated findings – each finding rated by exploitability, impact, and business risk (not just CVSS score)
- Evidence and proof-of-concept – screenshots, logs, and reproduction steps for each finding
- Remediation guidance – specific, actionable, and prioritized, not generic “patch your software” statements
- Retest commitment – confirmation that the provider will retest critical findings after remediation to verify they are closed
Reports that deliver only a CVSS-sorted list of vulnerabilities without business context, without attack path documentation, and without actionable remediation guidance are not fit for board presentation, regulatory submission, or meaningful security improvement.
How IPV Security Approaches Penetration Testing
IPV Security’s penetration testing practice is built on a foundational principle: a test that does not produce a decision is a test that should not have been conducted. Every engagement begins with an outcome-driven scoping conversation that identifies the business risks and regulatory requirements the test must address and ends with a report that maps every finding directly to those objectives.
Our testers hold OSCP and CREST certifications and operate within a methodology aligned to PTES (Penetration Testing Execution Standard) and the OWASP Testing Guide. For DORA-regulated financial entities, IPV Security conducts TIBER-EU compatible threat-led penetration tests using current threat intelligence relevant to the Israeli and EU financial sector.
Penetration testing at IPV Security does not exist as a standalone transaction. Within the vCISO program, pen test results feed directly into the CISOteria Cyber OS™ platform – updating the risk posture dashboard, refreshing remediation priorities, and generating the audit-ready evidence that regulators and insurers require. For standalone engagements, the same reporting quality applies: the client receives a report that can be presented to the board, submitted to a regulator, and used to drive a prioritized remediation program without needing additional translation.
Explore IPV Security’s Penetration Testing service →
|Learn about the full vCISO program →
Read the Compliance Guide: ISO 27001, NIS2, DORA →
About the Author
Ido Ganor is the Founder and CEO of IPV Security, an Israeli enterprise cybersecurity advisory firm serving mid-market companies across Israel and the EU. He brings 21+ years of enterprise CISO experience across regulated industries including financial services, critical infrastructure, and technology. He is the creator of the CISOteria Cyber OS™ platform and the architect of IPV Security’s 4-Pillar Operating Model for managed security leadership.
Related Articles
- What Is a vCISO Program? Complete Guide 2026 →
- Compliance Guide: ISO 27001, NIS2, DORA, and GDPR Explained →
- The 18-Domain Cyber Risk Assessment →
Ready to test your security posture? IPV Security conducts outcome-driven penetration tests that produce decisions, not just reports – scoped to your specific business risks and regulatory requirements, delivered by OSCP and CREST certified testers.
Frequently Asked Questions
What is the difference between a penetration test and a red team exercise?
A penetration test has a defined scope, a fixed timeframe, and the goal of finding as many exploitable vulnerabilities as possible within that scope. A red team exercise is longer, broader, and objective-based: the red team’s goal is to reach a specific target (exfiltrate a specific dataset, deploy ransomware on a production server) using any available means – technical, social, or physical. Red team exercises better simulate what a sophisticated, persistent attacker actually does. Penetration tests are appropriate for most organizations on an annual cycle; red team exercises are reserved for organizations with a mature security program that needs adversarial validation.
How long does a penetration test take?
Scope determines duration. A focused external network penetration test against a defined IP range might take three to five days of active testing plus two to three days of reporting. A comprehensive web application test against a complex application can take two to three weeks. An internal network penetration test for a mid-market enterprise typically runs one to two weeks. DORA TLPT exercises are longer-form engagements running several months, including the threat intelligence preparation phase. Any provider quoting a one-day penetration test for a meaningful scope should be questioned carefully.
How often should we conduct penetration tests?
At minimum, annually – and after any significant change to the environment (major infrastructure migration, new application deployment, cloud adoption, acquisition). PCI-DSS mandates annual testing explicitly. For organizations under NIS2 or DORA, regulatory guidance in most member states assumes at least annual testing. For organizations managing significant cyber risk – financial services, critical infrastructure, healthcare – semi-annual testing of external perimeters combined with annual internal testing is a more appropriate cadence.
Can penetration testing disrupt our production systems?
A professionally conducted penetration test includes explicit discussion of risk tolerance during scoping. Testers define which techniques and payloads will and will not be used against production systems. Modern penetration testing methodology deliberately avoids denial-of-service conditions and data destruction. The exception is DORA TLPT, which is specifically conducted against production systems under a controlled framework – but even then, disruption avoidance is a core requirement. Organizations that have never had a penetration test should begin with an external test, which carries the lowest disruption risk.
What should we do with the penetration test report after we receive it?
A penetration test report is a remediation roadmap, not a compliance certificate. The first step is triage: identify which critical and high findings require immediate action and assign clear ownership. Within 30 days, critical vulnerabilities should be remediated and retested. Within 90 days, high and medium findings should have documented remediation plans. The report itself should be presented to the board (via the executive summary), shared with the organization’s insurers if cyber insurance is in place, and retained as audit evidence. The cycle should then be scheduled: remediation, retest, and the next full assessment.
Does IPV Security offer retesting after findings are remediated?
Yes, IPV Security includes a structured retest of all critical and high findings as part of every penetration testing engagement. This is not a separate billable exercise; it is a commitment to outcome delivery. A finding that has been reported but not verified as closed is not a closed finding and an organization that submits an unverified report to a regulator or insurer is taking a significant risk. The retest produces a formal closure confirmation that can be appended to the original report for audit and regulatory purposes.