What Happens During a Penetration Test (Step‑by‑Step)
Many organisations approach their first penetration test with uncertainty. What does the tester actually do? Where does the testing happen? How do you avoid breaking things — or the law? A credible penetration test is neither guesswork nor chaos. It follows a defined methodology, begins with careful scoping and planning, and ends with a report that you can use to improve your security posture. This article demystifies the process and highlights what to expect at each stage.
Planning, scoping and authorisation
The first phase of a penetration test happens before any technical activity. NIST's guide to information security testing notes that the planning phase defines rules, obtains management approval and sets testing goals. The Penetration Testing Execution Standard (PTES) stresses that defining scope is essential; neglecting pre‑engagement activities leads to scope creep and even legal issues. A proper kick‑off meeting, as recommended by the U.S. General Services Administration (GSA), also reviews the rules of engagement (RoE), confirms system backups and disaster recovery plans, and ensures third‑party providers are notified.
During this stage you and your tester should agree on:
- In‑scope assets. Be specific about IP ranges, applications and environments. Vague phrases like "test the network" are not enough; instead, specify exact address ranges or domains.
- Test depth. Decide whether the assessment is black‑box (no prior knowledge), grey‑box (limited knowledge, perhaps a low‑privileged account) or white‑box (full access to code and architecture). Grey‑box is common because it balances realism with efficiency.
- Rules of engagement. Agree on testing windows, whether denial‑of‑service is allowed, social engineering boundaries, how to handle sensitive data and the escalation process if something goes wrong.
- Written authorisation. Under UK law, any unauthorised access is illegal, even if intended for testing. Ensure you sign a letter of authorisation ("permission to test") to comply with the Computer Misuse Act 1990 and have it available if external providers (like ISPs) need to see it.
Experienced testers will challenge unrealistic scopes or timelines. If someone offers to test a complex SaaS application in two days without detailed scoping, consider it a red flag.
Discovery and analysis
After planning, the tester begins the discovery phase. NIST describes discovery as the first part of penetration testing where actual testing begins. The objective is to build an accurate picture of the target environment and identify potential attack surfaces.
Discovery typically involves three complementary activities:
- Passive reconnaissance. Collect publicly available information without touching the target. This includes DNS and WHOIS records, certificate transparency logs, open‑source code repositories, breach data and search engine artefacts. The tester uses this information to map the organisation's external footprint.
- Active enumeration. Use tools to identify open ports and services, gather hostnames and IP addresses, enumerate shares and software versions, and discover API endpoints. NIST notes that techniques such as port and service identification, DNS interrogation and banner grabbing help identify potential targets during discovery.
- Vulnerability analysis. Combine scanner results with human expertise to prioritise weaknesses. Automated vulnerability scanners can match identified services to public vulnerability databases, but manual review is vital for identifying obscure or contextual vulnerabilities. At this stage, testers create hypotheses about potential attack paths rather than declaring findings.
The goal of discovery is not to produce a laundry list of CVEs, but to understand which attack vectors warrant further investigation. Modern environments are dynamic, so expect testers to find assets and services that were not in your asset inventory.
Exploitation, attack and validation
With a list of promising attack vectors, testers move into the attack or exploitation phase. In NIST's four‑stage methodology, this phase validates previously identified vulnerabilities by attempting to exploit them. The aim is not to cause outages but to confirm whether the weaknesses can be abused in practice and to what extent.
During exploitation testers will:
- Chain low‑severity issues into a high‑impact compromise. For example, combining an information disclosure with a weak password policy might lead to administrative access.
- Move laterally from an initial foothold towards systems of real value such as databases, source code repositories or domain controllers. NIST notes that successful exploits often provide additional access or information that leads to further testing.
- Demonstrate authorisation bypasses with concrete evidence — for instance, showing that a user in one tenant can read another tenant's data due to misconfigured access controls.
- Validate scanner results. Many vulnerabilities flagged by scanners turn out to be false positives in context. Exploitation confirms which findings are genuine and which are not.
Testers remain in contact with your security team during exploitation. If they uncover an issue that poses an immediate risk — such as evidence of a live compromise — they will pause and inform you straight away (often referred to as a "stop‑the‑test" finding). Otherwise, they proceed carefully to gather proof‑of‑concept evidence without causing harm.
Reporting and retesting
Once exploitation is complete, the tester produces a report. NIST stresses that the reporting phase documents the test's findings and allows the organisation to fix vulnerabilities and improve security. A high‑quality report serves multiple audiences: executives, security teams and developers. It should include:
- An executive summary that tells a clear story of what was tested, what was found and what it means in plain language.
- Prioritised findings with severity ratings based on context — not just CVSS base scores — and evidence of exploitation where applicable.
- Reproducible evidence for each issue (e.g., requests, screenshots, timestamps) so engineers can replicate and fix problems effectively.
- Actionable remediation guidance specific to your environment rather than generic advice.
- Root‑cause analysis pointing to systemic issues such as insecure configurations or development practices.
Professional testers also include retesting. After you have remediated the issues, the tester will verify that each fix actually works. Without this step, you have no assurance that the vulnerability is closed. A credible provider includes at least one round of retesting as part of the engagement.
Frequently asked questions
How long does a penetration test take?
Most engagements involve one to three weeks of active testing plus another one to two weeks for reporting and retesting. The duration depends on the scope, complexity and size of the environment.
Is penetration testing legal in the UK?
Yes — but only with written permission. The Computer Misuse Act 1990 prohibits unauthorised access, so a signed authorisation (and, where relevant, a rules‑of‑engagement document) is essential. Reputable providers will not start testing without it.
What qualifications should I look for?
For UK‑regulated work, look for companies accredited by CREST or NCSC CHECK. At the individual level, certifications like OSCP, OSWE or CRTO demonstrate hands‑on capability. However, experience and methodology matter more than badges.
Will the test break our systems?
Properly scoped tests minimise the risk of outages. Denial‑of‑service and other high‑risk activities are only conducted with explicit consent. The planning phase should include backups and disaster recovery preparation.