What is Penetration Testing — and What it Is Not
Penetration testing is the authorised, controlled simulation of a cyberattack against your organisation's systems, networks, or applications. A qualified tester — operating under a formal scope and rules of engagement — attempts to exploit vulnerabilities the same way a real adversary would: chaining weaknesses, escalating privileges, and moving laterally through your environment. The objective is not simply to find vulnerabilities but to demonstrate the real-world impact of those vulnerabilities when exploited by a motivated attacker.
This distinction matters because penetration testing is frequently conflated with vulnerability scanning — and the two are fundamentally different activities. A vulnerability scanner is an automated tool that compares your systems against a database of known signatures and misconfigurations. It produces a list of potential issues ranked by generic severity scores. It does not attempt to exploit anything, it cannot chain multiple low-severity findings into a critical attack path, and it has no understanding of your business logic. A vulnerability scan is a useful hygiene activity, but it is not a penetration test.
Key distinction:A vulnerability scan tells you what might be wrong. A penetration test tells you what an attacker can actually do with what is wrong — and proves it with evidence. Regulators and auditors understand this difference, and so should your procurement team.
An increasing number of regulatory frameworks and industry standards now mandate penetration testing — not vulnerability scanning — as a compliance requirement. PCI DSS Requirement 11.4 requires an annual penetration test conducted by a qualified internal resource or qualified external third party. The SWIFT Customer Security Programme (CSP) Objective 3 mandates regular security testing of the SWIFT-connected infrastructure. The Monetary Authority of Singapore (MAS) Technology Risk Management (TRM) Guidelines require regulated financial institutions to conduct penetration testing at least annually and after significant changes. Bank Negara Malaysia's Risk Management in Technology (BNM RMiT) framework similarly requires periodic penetration testing of critical systems. ISO 27001 control A.8.8 addresses technical vulnerability management and expects organisations to assess vulnerabilities through structured testing.
Beyond regulatory mandates, cyber insurance underwriters are increasingly requiring evidence of annual penetration testing as a condition of coverage. Insurers want to see that your organisation proactively tests its defences, and a vulnerability scan report will not satisfy this requirement. If your renewal questionnaire asks whether you conduct penetration testing, submitting a scanner output could jeopardise your claim in the event of a breach.
For organisations operating in regulated industries or handling sensitive data, penetration testing is no longer optional — it is a baseline expectation. The question is not whether to test, but how to scope, commission, and act on the results effectively. That is what this guide covers. For more information about our penetration testing engagements, visit our penetration testing service page. If your organisation also processes card data, our PCI DSS compliance service addresses the Requirement 11.4 penetration testing mandate directly.
Types of Penetration Testing
Not all penetration tests are the same. The type of test you commission depends on what you are trying to protect, what regulatory requirements apply, and where your greatest exposure lies. There are six primary types of penetration test, each with a different scope, methodology, and duration. Understanding these distinctions ensures you commission the right engagement and avoid paying for testing that does not address your actual risk.
1. External Network Penetration Test
An external network penetration test targets your internet-facing infrastructure — public IP addresses, firewalls, VPN gateways, mail servers, DNS servers, and any other services exposed to the internet. The tester operates from outside your network with no prior access, simulating an attacker who has discovered your organisation online. This is the most commonly requested test type and typically runs for five to ten days depending on the number of live hosts and services in scope.
2. Internal Network Penetration Test
An internal network penetration test simulates an attacker who has already gained access to your corporate network — either through a compromised employee device, a rogue insider, or a successful phishing attack. The tester is given a network connection (physical or VPN) and attempts to escalate privileges, move laterally across network segments, and access sensitive systems or data. Internal tests frequently reveal more critical findings than external tests because internal networks often have weaker segmentation and rely on perimeter defences. Duration is typically five to ten days.
3. Web Application Penetration Test
A web application penetration test focuses on a specific web application — its authentication mechanisms, session management, input validation, access controls, business logic, and API endpoints. Testing follows the OWASP Testing Guide methodology and covers the OWASP Top 10 categories as a minimum. This test type is essential for any organisation with customer-facing web applications, payment portals, or API-driven services. Duration is typically five to ten days per application, depending on complexity and the number of user roles.
4. Mobile Application Security Testing
Mobile application testing covers both the client-side application (iOS or Android) and its interaction with backend APIs. Testers examine local data storage, certificate pinning, binary protections, inter-process communication, and the security of API calls made by the app. Each platform (iOS and Android) is tested separately because the attack surfaces differ. Duration is typically five to seven days per platform.
5. Cloud Security Review
A cloud security review assesses the configuration and security posture of your cloud infrastructure — AWS, Azure, or GCP. This includes identity and access management policies, storage bucket permissions, network security groups, logging and monitoring configuration, and encryption settings. This is a configuration-focused assessment rather than an exploit-driven penetration test, but it is critical for organisations running production workloads in the cloud. Duration is typically three to five days.
6. Red Team Exercise
A red team exercise is the most comprehensive form of security testing. It simulates a realistic, multi-vector attack campaign against your organisation — combining network exploitation, social engineering, physical security testing, and application attacks over an extended period. The objective is to test your organisation's detection and response capabilities, not just its technical defences. Red team exercises typically run for four to eight weeks and are most appropriate for mature organisations that have already addressed basic penetration testing findings.
| Test Type | What It Covers | When to Commission | Typical Duration | Who Needs It |
|---|---|---|---|---|
| External Network | Internet-facing IPs, firewalls, VPNs, DNS | Annually or after infrastructure changes | 5–10 days | All organisations |
| Internal Network | LAN, AD, segmentation, lateral movement | Annually or after network redesign | 5–10 days | All organisations with internal networks |
| Web Application | Auth, sessions, input validation, APIs | Annually or before major release | 5–10 days/app | Orgs with customer-facing web apps |
| Mobile Application | Client-side app + backend API security | Before launch and annually | 5–7 days/platform | Orgs with iOS/Android apps |
| Cloud Security | IAM, storage, network, logging config | Annually or after cloud migration | 3–5 days | Orgs running cloud workloads |
| Red Team | Multi-vector attack simulation | After baseline pen tests are clean | 4–8 weeks | Mature security organisations |
Most organisations should commission an external network, internal network, and web application penetration test annually as a baseline. Additional test types should be added based on your technology stack, regulatory requirements, and threat landscape. If you are unsure which combination is appropriate, a scoping call with a CREST-accredited organisation will help you determine the right engagement.
CREST vs Non-CREST — Why It Matters
CREST (the Council of Registered Ethical Security Testers) is an international non-profit organisation that accredits companies providing penetration testing and cyber security services. Unlike individual certifications such as OSCP or CEH, CREST accreditation is granted at the organisation level. This means CREST evaluates the company's methodology, quality assurance processes, staff qualifications, professional indemnity insurance, data handling procedures, and adherence to a strict code of conduct — not just whether one person on the team holds a certificate.
Organisation-level accreditation matters because it ensures consistency across every engagement the company delivers. When you engage a CREST-accredited organisation, you know that the testing methodology has been independently validated, that the company carries appropriate insurance to cover the engagement, that staff have passed CREST examinations, and that there is a formal complaints and dispute resolution process. Individual certifications, while valuable for the practitioner, do not provide any of these organisational guarantees.
Organisation-level vs individual certification:CREST accredits the company, not just the tester. This means methodology, insurance, QA, and code of conduct are all independently validated. An individual OSCP or CEH holder working independently does not carry these organisational assurances — there is no external oversight of their methodology, no professional indemnity insurance requirement, and no formal quality control process.
Why does this matter practically? Several regulatory frameworks and industry standards either require or strongly recommend CREST-accredited penetration testing. PCI DSS Requirement 11.4 mandates that penetration testing be performed by a qualified internal resource or qualified external third party — and PCI assessors (QSAs) typically interpret "qualified external third party" as a CREST-accredited organisation or equivalent. The MAS Technology Risk Management Guidelines reference the use of accredited security testing firms. BNM RMiT similarly expects financial institutions to engage qualified external parties for penetration testing. Enterprise procurement teams in banking, insurance, and telecommunications increasingly require CREST accreditation as a prerequisite for vendor selection.
The practical risk of using a non-CREST provider is that your penetration test report may not be accepted. If you are undergoing a PCI DSS assessment, your QSA may reject a non-CREST report and require you to commission a new test — doubling your cost and delaying your certification timeline. If you are responding to a regulator or an enterprise client's security questionnaire, a report from a non-accredited firm carries less weight and may prompt additional questions or requirements.
You can verify whether a penetration testing firm holds CREST accreditation by searching the CREST member directory at crest-approved.org. EIC holds CREST organisation accreditation for penetration testing, and every engagement we deliver follows CREST methodology with full professional indemnity coverage.
Before you engage: Ask your penetration testing provider for their CREST accreditation certificate and verify it at crest-approved.org. If they cannot provide it, consider whether their report will satisfy your compliance and procurement requirements.
To learn more about what CREST accreditation involves, read our blog post on CREST accreditation. You can also learn about why organisations choose EIC for their penetration testing requirements.
Methodology — OWASP, PTES, and CREST Standards
A penetration test is only as reliable as the methodology behind it. Without a structured framework, testing becomes ad hoc — dependent on the individual tester's habits and preferences rather than a reproducible, auditable process. Three methodologies dominate professional penetration testing: the OWASP Testing Guide, the Penetration Testing Execution Standard (PTES), and CREST's own standards. Each serves a different purpose, and most serious engagements draw from more than one.
OWASP Testing Guide v4.2
The OWASP Testing Guide is the gold standard for web application penetration testing. Version 4.2 defines 91 specific test cases organised into 12 categories: Information Gathering, Configuration and Deployment Management, Identity Management, Authentication, Authorisation, Session Management, Input Validation, Error Handling, Cryptography, Business Logic, Client-Side Testing, and API Testing. Each test case includes a description, objectives, how to test, and remediation guidance.
The strength of OWASP is its specificity. When a penetration tester follows OWASP, every test case is documented, reproducible, and can be mapped to findings. This means your report is not a subjective opinion — it is the output of a structured process that another qualified tester could replicate. For web application testing, OWASP is the baseline that every CREST-accredited organisation follows.
Penetration Testing Execution Standard (PTES)
PTES provides a seven-phase framework applicable to all types of penetration testing — not just web applications. The seven phases are: Pre-engagement Interactions, Intelligence Gathering, Threat Modelling, Vulnerability Analysis, Exploitation, Post-Exploitation, and Reporting. Each phase has detailed technical guidelines covering what activities should be performed and what outputs should be produced.
PTES is particularly valuable for network penetration tests and red team exercises where the engagement involves multiple attack vectors and requires a structured approach to scoping, reconnaissance, and post-exploitation activities. The pre-engagement interactions phase is especially useful for defining rules of engagement, emergency contact procedures, and scope boundaries before testing begins.
CREST Standards
CREST maintains its own testing standards that build upon OWASP and PTES with additional quality assurance and reporting requirements. CREST standards are the most rigorous of the three and are mandatory for certain regulatory testing schemes — including CBEST (the Bank of England's threat-intelligence-led penetration testing framework) and TIBER-EU (the European Central Bank's equivalent framework for euro-area financial institutions).
CREST standards require that all testing activities are logged, that findings are validated and false positives are eliminated before reporting, that reports follow a consistent structure, and that the testing organisation maintains quality assurance processes to review reports before they are delivered to clients.
Why methodology consistency matters: When you use the same structured methodology year after year, you can compare results across annual assessments. A decline in Critical findings from 8 to 2 over three years is meaningful. Without consistent methodology, year-over-year comparison is unreliable.
EIC's approach combines all three frameworks depending on the engagement type. Web application tests follow OWASP. Network and infrastructure tests follow PTES. All engagements are delivered under CREST standards for quality assurance, reporting, and professional conduct. This layered approach ensures that every test is structured, reproducible, and defensible. Learn more about our methodology on our penetration testing service page.
What to Expect — Scoping, Testing, and Reporting
A penetration testing engagement follows three distinct phases. Understanding what happens in each phase helps you prepare internally, allocate the right resources, and set expectations with your leadership team. Organisations that understand the process get better results because they provide the right information during scoping, avoid disruptions during testing, and act on findings more effectively.
Phase 1: Scoping (1–2 weeks)
Scoping is the most important phase of any penetration testing engagement. Poor scoping leads to incomplete testing, unexpected costs, and findings that miss your actual risk. During scoping, you and your testing provider agree on the target systems (IP addresses, URLs, applications, cloud accounts), the types of test to be performed, the testing window (dates, hours, and any blackout periods), the rules of engagement (what is in scope, what is explicitly out of scope, what activities require prior approval), and emergency contact procedures in case the testing causes an unexpected service disruption.
A well-defined scope document should be signed by both parties before any testing begins. It protects your organisation by ensuring testers do not access systems outside the agreed boundary, and it protects the testing provider by clearly documenting what was authorised. Scoping typically takes one to two weeks, including internal approvals and the back-and-forth between your team and the testing provider.
Phase 2: Testing (5–15 days)
The testing phase is where the actual penetration test takes place. Testing duration depends on the scope — a single web application might take five days, while a combined external, internal, and web application engagement could run for fifteen days. During this phase, testers work through the agreed methodology, document all findings with evidence (screenshots, request/response logs, proof-of-concept exploits), and escalate any critical findings immediately rather than waiting for the final report.
Testing is conducted under one of three knowledge profiles. Black box testing provides the tester with no prior knowledge of the target — this is the most realistic simulation of an external attacker but may miss issues that require authenticated access. Grey box testing provides the tester with partial knowledge — typically user credentials, network diagrams, or API documentation — and is the most common approach for enterprise engagements because it balances realism with thoroughness. White box testing provides the tester with full knowledge including source code, architecture diagrams, and administrator credentials — this is the most thorough approach but the least realistic in terms of simulating an actual attack.
EIC recommends grey box testing for most engagements. It provides sufficient context for the tester to identify business logic flaws and privilege escalation paths while still requiring the tester to discover and exploit vulnerabilities through skill rather than simply reviewing source code.
Phase 3: Reporting (3–5 days)
The report is the deliverable your organisation uses to remediate findings, satisfy regulators, and demonstrate due diligence. A professional penetration test report contains two sections: an executive summary written for non-technical stakeholders (CISO, board members, auditors) that summarises the overall risk posture, key findings, and strategic recommendations; and a technical findings section written for your remediation team that provides the detail needed to fix each issue.
Each technical finding includes a title, severity rating using the Common Vulnerability Scoring System (CVSS), a description of the vulnerability, evidence demonstrating exploitation (screenshots, HTTP request/response pairs, proof-of-concept code), an assessment of business risk, specific remediation steps, and references to relevant standards or advisories. This structure ensures that your remediation team knows exactly what to fix, how to prioritise it, and how to verify the fix.
EIC includes one retest of all Critical and High severity findings as standard with every penetration testing engagement. After your team has remediated the critical issues, we retest them and issue a supplementary report confirming whether each finding has been successfully resolved. This retest report serves as evidence of remediation for auditors, regulators, and cyber insurers.
How to Use Pen Test Results Effectively
A penetration test report is an action plan, not a checkbox. The value of a penetration test is not in the report itself — it is in what your organisation does with the findings. Too many organisations file the report, confirm that "a pen test was done," and move on without addressing the vulnerabilities that were identified. This approach defeats the purpose of testing and leaves your organisation exposed to the exact risks the test was designed to reveal.
Effective remediation starts with triage. Not all findings require the same urgency, and your remediation team needs clear timelines aligned to severity. The following remediation windows are industry-standard and align with expectations from PCI DSS, SWIFT CSP, and most regulatory frameworks:
| Severity | Remediation Window | Examples |
|---|---|---|
| Critical | 15 days | Remote code execution, SQL injection with admin access, authentication bypass |
| High | 30 days | Privilege escalation, XSS with session hijack, insecure direct object reference |
| Medium | 90 days | Missing security headers, weak TLS configuration, verbose error messages |
| Low | Next maintenance cycle | Information disclosure, cookie without Secure flag, minor misconfigurations |
Every finding in the report needs a named owner and a target remediation date. Without ownership, findings remain open indefinitely. The security team should not be the default owner of every finding — infrastructure findings belong to the infrastructure team, application findings belong to the development team, and configuration findings belong to the operations team. The security team's role is to track progress, escalate delays, and coordinate the retest.
Evidence of remediation is not optional for regulated organisations. PCI DSS requires that penetration test findings are remediated and retested. SWIFT CSP expects organisations to demonstrate that identified vulnerabilities have been addressed. Cyber insurance renewals increasingly ask for evidence that prior-year findings have been resolved. The retest report — issued after your team has fixed the Critical and High findings — serves as this evidence. EIC produces a formal retest evidence report documenting the status of each finding: remediated, partially remediated, or not remediated.
Year-over-year improvement: The most meaningful metric from annual penetration testing is the trend in Critical and High findings over time. If your organisation had 12 Critical findings in year one, 5 in year two, and 2 in year three, that demonstrates measurable improvement in your security posture — and it is exactly the kind of evidence that boards, regulators, and insurers want to see.
AI-Driven VAPT — How EIC's Approach Differs
Traditional vulnerability assessment and penetration testing (VAPT) engagements begin with a manual scoping and reconnaissance phase that typically takes two to four weeks. During this phase, the testing team manually identifies the organisation's external attack surface — discovering domains, subdomains, IP addresses, cloud infrastructure, open ports, technology stacks, and expired or misconfigured certificates. This reconnaissance work is essential because you cannot test what you have not found, but it is time-consuming, labour-intensive, and often incomplete because it depends on the tester's individual thoroughness and the time allocated to the task.
EIC's approach addresses this limitation with CardIntel, our AI-powered attack surface discovery platform. CardIntel automates the reconnaissance phase and generates a comprehensive attack surface map within 48 hours — identifying all externally visible domains, subdomains, IP addresses, cloud infrastructure components, open ports, technology stacks, SSL/TLS certificates, and their configurations. This is not a simple DNS lookup or port scan. CardIntel uses machine learning to correlate data across multiple sources, identify shadow IT assets that your team may not know exist, and map relationships between infrastructure components.
How It Changes the Engagement Timeline
Week 1: CardIntel generates the attack surface map. The testing team reviews the output, confirms scope with the client, and identifies priority targets based on exposure and risk. This replaces what traditionally takes two to three weeks of manual reconnaissance.
Week 2 onward: Manual penetration testing begins with full visibility of the attack surface from day one. Testers are not spending their first few days discovering what exists — they already know, and they can focus their time and expertise on the testing activities that require human judgment: exploiting business logic flaws, testing authentication workflows, chaining vulnerabilities, and assessing the real-world impact of findings.
The result is a 30 to 40 percent reduction in overall engagement timeline, higher coverage (because CardIntel identifies assets that manual reconnaissance often misses), lower cost (because fewer tester-days are spent on reconnaissance), and a documented asset inventory that your organisation can use for ongoing security monitoring between annual tests.
What CardIntel Does Not Replace
CardIntel accelerates and improves the reconnaissance phase, but it does not replace skilled manual testing. Penetration testing requires human expertise for activities that AI cannot perform: understanding business logic and testing whether it can be abused, assessing complex authentication and authorisation workflows, evaluating whether chained vulnerabilities create a viable attack path, and applying social engineering techniques in red team scenarios. The value of CardIntel is that it frees your testing team to spend more time on these high-value activities instead of spending days on manual reconnaissance.
The combination:CardIntel AI-powered reconnaissance plus CREST-accredited manual penetration testing equals faster scoping, broader coverage, and deeper testing. It is not a replacement for human expertise — it is a force multiplier that makes every engagement more thorough and more efficient.
To learn more about CardIntel and how it integrates with our penetration testing engagements, visit our CardIntel technology page or explore our penetration testing service.
Free Guide · 3,000+ Words
Continue Reading: Penetration Testing Complete Guide
Enter your work email for instant access — including the full guide and PDF download.
- ✓CREST vs non-CREST — why it matters
- ✓OWASP, PTES methodology deep-dive
- ✓Report format & how to use findings
- ✓AI-driven VAPT approach explained