A penetration test runs in five stages: scoping, where you agree what is tested and why; written authorisation and rules of engagement; the testing itself; a report and debrief; and a retest once fixes are in. Your team has a part to play at every stage, and the work before and after testing matters as much as the testing.
The NCSC describes a typical engagement as following the same pattern: “initial engagement, scoping, testing, reporting and follow up” (NCSC, retrieved 27 October 2026). This article walks through what happens at each stage, what you need to provide and what you should get back, so nothing comes as a surprise.
Executive Summary & Key Takeaways
- Scoping sets the boundaries, the type of test and the effort. Most later problems trace back to it.
- Written authorisation is not a formality. Accessing a computer without authorisation is an offence under the Computer Misuse Act 1990.
- Good testers raise critical findings straight away rather than saving them for the report.
- The report should give you evidence, a risk rating and a fix for every finding, but decisions on what to fix and when are yours.
- A retest closes the loop and produces the evidence auditors and customers usually ask for.
The stages at a glance
| model | What happens | What you provide | What you get |
|---|---|---|---|
| Scoping | Agree targets, test type, goals and constraints | Asset list, context, reason for the test | Scope document and quote |
| Authorisation | Sign off rules of engagement | Signatory, contacts, test accounts | Signed authorisation and plan |
| Testing | Discovery, exploitation, analysis | A contact on call during testing | Immediate alerts for critical issues |
| Reporting | Write-up and debrief | Attendance from technical and business owners | Report with prioritised findings |
| Retest | Check fixes for the findings | Confirmation that fixes are in | Updated report showing what is closed |
Stage 1: scoping
Scoping decides what will be tested, how, and why. The NCSC recommends involving all relevant risk owners, technical staff who know the target systems, and a representative of the testing team (NCSC, retrieved 27 October 2026). Risk owners explain what worries them, technical staff set out the boundaries of the estate, and the testers propose the testing that will answer the question.
The output should be a document stating the technical boundaries, the types of test, the effort in days, any scenarios to test, what the testers need from you, any compliance requirements and any reporting requirements. If you have a recent vulnerability scan, share it: the NCSC suggests this lets the test give an opinion on how accurate and complete your own vulnerability assessment is.
Scoping is also where cost is set. For how each scoping decision affects the price, see what affects the cost of a penetration test.
Stage 2: authorisation and rules of engagement
Penetration testing involves deliberately trying to get into your systems, so permission has to be explicit. Under section 1 of the Computer Misuse Act 1990, a person commits an offence if they cause a computer to perform a function intending to secure access to a program or data, knowing that access is unauthorised (legislation.gov.uk, retrieved 27 October 2026). Written authorisation from someone entitled to give it protects both you and the testers.
The rules of engagement turn the scope into operating instructions. They typically cover:
- the exact targets in scope and anything explicitly excluded
- testing dates and windows, including any out-of-hours work
- the addresses the testers will test from, so your team can recognise the traffic
- emergency contacts on both sides and how to stop testing quickly
- which techniques need extra approval, such as anything that could affect availability
- how test data, credentials and evidence will be handled and deleted
If your systems are hosted by a third party, check their rules too. Cloud providers publish their own testing policies. AWS, for example, allows testing of listed services without prior approval but prohibits denial of service testing and requires a request for some simulated events (AWS, retrieved 27 October 2026). Systems run by suppliers or managed providers may also need their consent.
Stage 3: testing
This is the part most people picture. NIST’s technical guide to security testing describes penetration testing in four phases: planning, discovery, attack and reporting (NIST SP 800-115, retrieved 27 October 2026). During discovery, testers gather information and identify potential weaknesses. During attack, they try to exploit them. Where an exploit gives them more access, they go back to discovery from that new position. That loop is what separates a penetration test from a scan: testers look for how weaknesses combine and how far an attacker could get.
Testers usually work to a recognised methodology. For web applications, the OWASP Web Security Testing Guide is widely used. Its latest stable release is version 4.2, with version 5.0 in development (OWASP, retrieved 27 October 2026).
Three things to expect while testing is under way:
- A contact on call. The NCSC recommends a technical point of contact is available at short notice throughout, so testers can raise critical issues and resolve anything blocking them (NCSC, retrieved 27 October 2026).
- Critical findings raised immediately. If testers find something serious, you should hear about it the same day, not in the final report.
- Possible scope questions. If testers find out-of-scope systems that affect the security of in-scope ones, the NCSC notes they may suggest changing the scope, which can affect time and cost, or record it as a limitation. The decision is the risk owner’s.
NIST also notes that reporting runs alongside testing: logs are kept and periodic updates are given during discovery and attack, not just at the end (NIST SP 800-115, retrieved 27 October 2026).
Stage 4: reporting and debrief
The NCSC says a test report should include the security issues found, the testers’ assessment of the risk each one poses, a way of resolving each issue, an opinion on the accuracy of your own vulnerability assessment and advice on improving it (NCSC, retrieved 27 October 2026).
Each finding should carry a severity rating. Many testers use the Common Vulnerability Scoring System, now at version 4.0 (FIRST, retrieved 27 October 2026). Reports produced under the NCSC’s CHECK scheme must state risk as High, Medium, Low or Informational, with CVSS allowed in addition but not instead.
A good report works for two audiences. The executive summary tells leadership how exposed you are and what needs attention first. The technical findings give engineers enough evidence to reproduce and fix each issue. A debrief meeting lets both groups ask questions.
Stage 5: remediation and retest
The report hands responsibility back to you. The NCSC is clear that “risk assessment and decisions on the application of fixes are your responsibility”, because the testers may not know the full business impact of each issue (NCSC, retrieved 27 October 2026). It also points out that the suggested fix is not always the only option. Removing unused software or adding monitoring may be a better answer than a patch.
Pay particular attention to anything the test found that your own processes missed. Those findings show where your routine vulnerability management needs to improve.
Once fixes are in, the testers retest the affected findings and update the report. Some standards require this: PCI DSS v4.0.1 requirement 11.4.4 says penetration testing is repeated to verify corrections (PCI SSC, retrieved 27 October 2026).
Common mistakes
- Leaving the people who own the risk out of scoping, so the test answers a technical question nobody in the business asked.
- Starting without signed authorisation from someone who actually has the authority, including for systems hosted by third parties.
- Not telling the operations team or managed provider, unless you are deliberately testing detection, which then needs its own plan.
- Having no one available during testing, so critical findings wait and blocked tests waste days.
- Filing the report without a remediation plan, then arriving at next year’s test with the same findings.
Frequently asked questions
How long does a penetration test take?
The testing time is agreed at scoping, in tester days, and depends on the number and complexity of targets. Allow time either side for scoping, authorisation, reporting and the retest. Regulator-led schemes are much longer: the Bank of England’s CBEST guide puts the average assessment at around 9 to 12 months (Bank of England, retrieved 27 October 2026).
Should we tell our IT team or managed provider that testing is happening?
Usually, yes. They need to recognise the activity and know who to call. The exception is a test that deliberately measures detection and response, where only a small group knows. That needs to be designed into the scope and rules of engagement from the start.
Can we share the report with customers or auditors?
Usually, but full technical reports contain detail you may not want to circulate. Many organisations share the executive summary or a redacted version alongside the retest results. Agree the format you need at scoping so the report is written with that audience in mind.
What happens to our data after the test?
That should be set out in the rules of engagement. NIST’s guide treats data collection, storage, transmission and destruction as distinct parts of any assessment (NIST SP 800-115, retrieved 27 October 2026). Ask how long evidence is kept, where and how it is deleted.
Getting started
If you know what you want tested and why, the rest of the process follows from a good scoping conversation. Our penetration testing service covers every stage, from scoping to retest. If you are still deciding on a test type or a provider, see which type of penetration test do we need and how to choose a penetration testing company.
When you are ready, talk to our team.
Jared Henderson
Writing about cyber security and technology at Falx.
