A penetration test is a structured, authorised attempt to identify and exploit vulnerabilities in a system, application, or network. Unlike vulnerability scanning, which flags potential issues automatically, a penetration test involves a skilled tester actively working to find, validate, and demonstrate the impact of security weaknesses.

This article walks through the process from start to finish: what happens before, during, and after a penetration test.

Pre-engagement: Scoping and planning

Every penetration test begins with a scoping conversation. This is where the client and the testing team align on what will be tested, how, and under what constraints.

Defining the scope

The scope specifies exactly what is included in the test and what is excluded. This might be:

  • A single web application.
  • A set of external IP addresses or domains.
  • The internal corporate network.
  • A mobile application (iOS, Android, or both).
  • An API or set of microservices.
  • A combination of the above.

Clear scoping prevents misunderstandings. If a client wants their web application tested but the API it connects to is hosted by a third party, the third-party API is typically out of scope unless the third party has also given consent.

Testing approach

The approach defines how much information the tester is given before the test begins:

Black box. The tester receives minimal information — perhaps just a URL or IP address. They approach the target as an external attacker would, with no insider knowledge. This tests what an outsider can discover and exploit.

Grey box. The tester is given some information, such as valid user credentials, API documentation, or network diagrams. This simulates an attacker who has gained some level of access or an insider with limited privileges. Grey box testing is often the most efficient approach because it allows the tester to spend time on deep testing rather than basic enumeration.

White box. The tester is given full access to source code, architecture documentation, and administrative credentials. This allows the most thorough testing because the tester can identify vulnerabilities that would be invisible from the outside. White box testing is common for applications in development or those undergoing a security review before release.

Rules of engagement

The rules of engagement define operational constraints: testing hours, whether denial-of-service testing is permitted, how to handle the discovery of sensitive data, who to contact in an emergency, and how to communicate findings during the test (particularly critical vulnerabilities).

The testing methodology

Professional penetration testing follows a structured methodology. While testers adapt their approach based on what they find, the general flow is consistent.

Reconnaissance

The tester gathers information about the target: domain records, IP ranges, technology fingerprints, publicly exposed services, and any information discoverable through OSINT. For web applications, this includes mapping the application’s structure, identifying input points, and understanding the technology stack.

Enumeration

Building on reconnaissance, the tester actively probes the target to identify services, versions, configurations, user accounts, and potential entry points. For a web application, this means crawling the site, identifying all endpoints, and mapping parameters and functionality. For a network, this means scanning for open ports, identifying services, and determining operating system and software versions.

Vulnerability identification

The tester identifies potential vulnerabilities through a combination of automated scanning and manual analysis. Automated tools flag known issues and common misconfigurations. Manual analysis identifies logic flaws, chained vulnerabilities, and context-dependent issues that tools miss.

Exploitation

This is where penetration testing diverges from vulnerability scanning. The tester attempts to exploit identified vulnerabilities to demonstrate real-world impact. For a web application, this might mean extracting data from a database through SQL injection, accessing another user’s account through broken access control, or executing code on the server through a file upload vulnerability.

Exploitation is always conducted carefully and within the agreed rules of engagement. The goal is to demonstrate impact, not to cause damage.

Post-exploitation

If exploitation is successful, the tester explores what further access is possible. Can they escalate privileges? Can they move laterally to other systems? Can they access sensitive data? Post-exploitation demonstrates the real-world consequences of a vulnerability — the difference between “this system has a flaw” and “this flaw gives an attacker access to your entire customer database.”

What testers look for

The specific vulnerabilities depend on the target, but common categories include:

For web applications:

  • Injection flaws (SQL injection, command injection, template injection).
  • Broken access control (accessing resources or functions without proper authorisation).
  • Authentication weaknesses (weak password policies, session management flaws, MFA bypass).
  • Server-side request forgery (SSRF).
  • Cross-site scripting (XSS).
  • Insecure direct object references.
  • Business logic flaws (anything the application should not allow but does).
  • Misconfigurations (verbose error messages, default credentials, exposed admin panels).

For networks:

  • Unpatched services with known vulnerabilities.
  • Weak or default credentials.
  • Misconfigured services (open relays, anonymous FTP, exposed management interfaces).
  • Weak encryption or plaintext protocols.
  • Active Directory misconfigurations (excessive privileges, weak password policies, Kerberos vulnerabilities).
  • Network segmentation failures.

For mobile applications:

  • Insecure data storage on the device.
  • Weak transport layer security.
  • Authentication and session management flaws.
  • Reverse engineering and tampering vulnerabilities.

The report

The report is the primary deliverable. A well-structured penetration test report includes:

Executive summary. A non-technical overview for senior stakeholders: what was tested, the overall risk posture, the most significant findings, and high-level recommendations. Typically one to two pages.

Technical findings. Each vulnerability is documented individually with:

  • A clear description of the issue.
  • The affected system, URL, or component.
  • Steps to reproduce the vulnerability.
  • Evidence (screenshots, request/response data, proof of exploitation).
  • A risk rating, typically using CVSS (Common Vulnerability Scoring System) or a similar framework.
  • Specific, actionable remediation guidance.

Methodology. A description of the approach, tools, and techniques used. This provides context for the findings and allows the client to understand the coverage of the test.

Appendices. Supporting data such as full scan results, detailed technical evidence, and tool output.

After the test

The report is the starting point for remediation, not the end of the process.

Debrief. The testing team walks the client’s technical team through the findings, answers questions, and provides additional context where needed.

Remediation. The client addresses the identified vulnerabilities, prioritised by risk rating. The testing team may provide advisory support during this phase.

Retest. Once remediation is complete, a retest confirms that the fixes are effective. This is typically focused on the specific vulnerabilities identified in the original test rather than a full repeat engagement.

Integration. The findings should feed into the organisation’s broader security programme: informing the software development lifecycle, updating security policies, and contributing to risk registers.

When to commission a penetration test

Penetration tests are typically conducted:

  • Annually as part of a regular security programme.
  • After significant changes to applications, infrastructure, or architecture.
  • Before launch of a new application or system.
  • For compliance with frameworks such as PCI-DSS, ISO 27001, or Cyber Essentials.
  • As part of supplier assurance, when a client or partner requires evidence of security testing.

Regular testing ensures that new vulnerabilities are identified as the environment evolves and that remediation from previous tests has been effective.