Penetration Testing Defined in Plain Terms
A penetration test or pentest, is an authorised and controlled cyberattack on your own systems. A skilled tester takes the role of an attacker to find and safely exploit weaknesses in networks, applications and people, then reports exactly what was reachable and how to fix it before a real attacker finds the same gaps.
This is where a penetration test differs from a vulnerability scan. A scan is automated and produces a list of possible weaknesses. A pentest adds a human who confirms which of those weaknesses can actually be exploited, chains them together and shows the real business impact. The two are often bought together as vulnerability assessment and penetration testing, or VAPT.
The need is not abstract. In the EU, exploited vulnerabilities were behind 21.3 percent of intrusions that the EU Agency for Cybersecurity (ENISA) analysed between July 2024 and June 2025, its second most common way in after phishing. Attackers weaponise newly disclosed flaws within days. A penetration test finds the exposed, exploitable gaps on your side first.
How a Penetration Test Works
A good penetration test follows a repeatable method so the results are consistent and defensible. The US National Institute of Standards and Technology sets out the shape in its guide SP 800-115 which groups the work into planning, discovery, attack and reporting. In practice most engagements run through these stages:
- Scoping and rules of engagement: You agree what is in scope, what is off limits and how far the tester may go, in writing before anything starts.
- Reconnaissance and discovery: The tester maps your attack surface and gathers information the way an attacker would.
- Vulnerability analysis: Findings are reviewed to work out which weaknesses are worth trying to exploit.
- Exploitation: The tester safely proves which weaknesses are real by using them to gain access, escalate privileges or reach sensitive data.
- Post-exploitation and reporting: The tester documents what was reachable, rates each finding by severity and sets out clear remediation steps.
- Remediation and retest: You fix the issues and the tester checks that the fixes hold.
The report is the deliverable that matters. It ranks each exploitable finding by severity shows the evidence and gives the steps to close it which is what turns a test into fewer real incidents.
Types of Penetration Testing
Penetration testing covers several distinct activities. Each type is scoped to a different attack surface so you test the part of your environment you most need assurance on.
- Network penetration testing: Tests your servers, firewalls and network devices. External network penetration testing targets internet-facing systems while internal testing looks at what an intruder could reach once inside.
- Web application penetration testing: Probes your websites, portals and APIs for flaws such as injection, broken authentication and access-control gaps.
- Wireless penetration testing: Checks Wi-Fi and other wireless networks for weak encryption and rogue access points.
- Cloud penetration testing: Looks for misconfigured storage, over-permissive roles and exposed services in environments such as AWS or Azure.
- Social engineering: Tests people and process with phishing and pretext calls to see whether staff can be tricked into granting access.
- Physical penetration testing: Attempts to reach servers, offices or devices in person, past locks, badges and reception.
- Mobile and API testing: Assesses mobile apps and the interfaces behind them which now carry much of the sensitive data.
Tests also differ by how much the tester is told at the start. In a black-box test the tester begins blind like an outside attacker. In a grey-box test they get limited information such as a standard user login. In a white-box test they get full detail including source code and architecture.
More knowledge means faster and deeper coverage. Less knowledge gives a more realistic picture of what an outside attacker would find on their own.
Penetration Testing Methods and Standards
Professional testers work to published methodologies rather than improvising. Standards make a test repeatable, comparable and audit-friendly, and several are widely used.
- OSSTMM: The Open Source Security Testing Methodology Manual, maintained by the non-profit ISECOM, is a peer-reviewed method for measuring operational security across five channels, from data networks to human and physical security.
- OWASP Web Security Testing Guide: The Open Worldwide Application Security Project publishes the WSTG, the reference method for web application testing, organised into twelve categories. Its companion OWASP Top 10 ranks the most critical web risks.
- NIST SP 800-115: The US technical guide that frames testing as planning, discovery, attack and reporting, widely used as a baseline in regulated environments.
- PTES: The Penetration Testing Execution Standard, which describes an engagement in seven phases from pre-engagement to reporting.
Two related terms come up often. Red teaming is a broader and stealthier exercise that tests detection and response against a realistic attacker over weeks rather than a scoped snapshot of one system. Purple teaming runs the attackers and your defenders together so lessons land at once.
For large financial firms in the EU, DORA turns this into a legal duty called threat-led penetration testing built on the European Central Bank’s TIBER-EU framework.
Real-World Cases
The clearest argument for testing is what happens without it. Each case here turned on a weakness a test would very likely have surfaced first.
Equifax and the Unpatched Struts Flaw
In 2017 the credit agency Equifax exposed the personal data of roughly 147 million people. The way in was a known flaw in Apache Struts, a web framework component. Apache had released a patch on 7 March 2017 and US authorities alerted affected firms the next day.
Equifax’s own scan failed to find the vulnerable, internet-facing system so it stayed unpatched. Attackers reached it and moved through the network from mid-May until the activity was spotted in late July. The breach was disclosed to the public on 7 September 2017.
A thorough external test of internet-facing systems is built to catch exactly what an automated scan misses. Finding and confirming that one exposed component would have closed the door.
Capital One and a Cloud Misconfiguration
In 2019 Capital One lost data on around 106 million people across the US and Canada. A former cloud engineer exploited a misconfigured web application firewall using a server-side request forgery attack.
That single request tricked the firewall into fetching temporary cloud credentials from an internal metadata service. Those credentials unlocked storage holding customer records including roughly 140,000 US social security numbers. A US regulator later fined the bank 80 million dollars.
Server-side request forgery is a standard check in web application penetration testing. A test aimed at the firewall and its access to cloud metadata would have exposed the flaw before an outsider did.
Colonial Pipeline and a Forgotten VPN Account
In May 2021 a ransomware crew shut down Colonial Pipeline which carries close to half of the fuel used on the US East Coast. The pipeline was down for about five days and set off panic buying across several states.
Investigators traced the entry to a single leaked password for an old VPN account that was still enabled and had no multi-factor authentication. Colonial paid about 4.4 million dollars in ransom though US authorities later clawed back most of the bitcoin.
No exotic exploit was involved. An external test of remote access would have flagged the dormant account and the missing second factor, the sort of basic gap these engagements are built to find.
Penetration Testing and Compliance
Testing is increasingly not optional. Several regimes that apply in Sweden and the EU expect organisations to test their defences and prove the results.
NIS2 and Cybersäkerhetslagen: Sweden’s NIS2 law, Cybersäkerhetslagen (SFS 2025:1506), came into force on 15 January 2026. The NIS2 Directive’s Article 21 requires risk-management measures that include testing and vulnerability handling and its Article 20 makes the management body personally accountable. Cybersäkerhetslagen transposes both into Swedish law.
Since 1 July 2026 the national single point of contact and incident-reporting body has been the National
Cyber Security Centre (NCSC) at Försvarets radioanstalt (FRA) which took these functions over from
MCF (formerly MSB). Supervision itself is handled by sector-specific authorities such as
Finansinspektionen and PTS.
DORA: The EU’s Digital Operational Resilience Act has applied to financial entities since 17 January 2025. Under Articles 26 and 27, the significant firms identified by regulators must run threat-led penetration testing at least every three years. See our DORA guide for who is in scope.
GDPR: Article 32 of the GDPR requires a process for regularly testing, assessing and evaluating the effectiveness of security measures. Penetration testing is the accepted way to evidence that duty for systems that process personal data. In Sweden the data protection authority is IMY.
ISO 27001 and PCI DSS: ISO 27001, the information security management standard, expects organisations to manage technical vulnerabilities and test that controls work. PCI DSS which governs card data is more prescriptive still and requires internal and external penetration tests at least every twelve months and after any significant change.
Meeting these duties is not about a single report. It is about testing on a sensible cycle, fixing what is found and being able to show the evidence which is what a managed penetration testing service is built to deliver.
How to Choose a Penetration Testing Provider
Not all tests are equal. The difference between a report that lowers your risk and one that gathers dust is in how the work is scoped and who does it.
- Qualified and independent testers: The people testing should be skilled and organisationally separate from the team that built the systems.
- A clear methodology: Ask which standard the test follows such as OSSTMM or the OWASP guide, and how coverage is recorded.
- Scope that matches your risk: The test should target your most valuable systems and data, agreed before work starts.
- Safe execution: Rules of engagement, safeguards and an agreed way to pause protect production.
- Reporting you can act on: Findings ranked by severity with evidence and plain remediation steps plus a summary a board can read.
- A retest included: The provider should confirm that your fixes actually closed the gaps.
One caveat matters. A penetration test is a point-in-time snapshot rather than a guarantee that you are secure tomorrow. New systems and newly disclosed flaws appear constantly so testing works best alongside continuous vulnerability scanning and monitoring, not instead of them.
How to Get Started with Penetration Testing
You do not need a mature security programme to begin. A focused first test on your most exposed systems is more useful than waiting for the perfect moment.
- Identify what matters most. List the systems and data that would hurt the business if breached and start there.
- Set the scope and rules in writing. Agree what will be tested, what is off limits and how findings are handled.
- Choose the right type. Match the test to the risk, whether that is network, web application or cloud.
- Fix the cadence to reality. Test at least once a year and again after any major change to systems, applications or infrastructure.
- Plan for remediation. Book time to fix findings and require a retest to confirm they are closed.
- Layer in continuous checks. Pair periodic tests with ongoing vulnerability scanning so new gaps are caught between engagements.
Handled this way, penetration testing becomes a steady supply of the specific fixes that keep attackers out rather than a yearly compliance chore.
