What Actually Happens in a Penetration Test?

A penetration test is a planned, authorised attack with rules, a stop button and a report at the end. This guide walks through each stage, from scoping and the authorisation letter to the debrief and retest, and gives you a preparation checklist.

What is a penetration test, in one paragraph?

A penetration test is security testing in which a tester mimics real-world attacks to find ways around the security of an application, system or network. That is close to the definition in NIST Special Publication 800-115, one of the recognised references for this work. The difference from an automated scan is that a tester tries to prove a weakness can be used, and looks for combinations of small issues that add up to a serious one. If you’re weighing the two, our guide to vulnerability scans versus penetration tests compares them side by side.

Which methodologies do testers follow?

You don’t need to know these in detail, but it’s reasonable to ask a tester which one they follow. Three are widely referenced:

• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (published September 2008). It describes four phases: planning, discovery, attack and reporting, with reporting running alongside the other three. NIST presents this as one example of how a test can be divided, not the only acceptable one.
• The Penetration Testing Execution Standard (PTES), which has seven sections: pre-engagement interactions, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation and reporting.
• The OWASP Web Security Testing Guide (WSTG) for websites and web applications. Version 4.2 is the current stable release, with version 5.0 in development.

The stages below follow the shape all three share.

Stage 1: Scoping and rules of engagement

Scoping decides what gets tested and what "success" means. A good scoping conversation covers:

• Targets. Exact IP addresses, domain names, application URLs, Wi-Fi networks or cloud tenants. "Our network" isn’t a scope.
• Type of test. External, internal, web application, cloud or Microsoft 365, wireless, social engineering, or a mix. (The types are explained further down.)
• Starting point and knowledge. Does the tester start with nothing (black box), with some information or test accounts (grey box), or with full documentation (white box)? Grey box is common because it spends the time on testing rather than guessing.
• Exclusions. Systems that must not be touched, such as a fragile production database or a system owned by someone else.
• Out-of-bounds techniques. Denial-of-service testing, for example, is usually excluded.
• Testing windows and any change freezes.
• Contacts. A named person on your side, a backup, and a way to reach them during testing.

The result is a written rules of engagement document (NIST calls it the ROE, or assessment plan). In NIST’s words, in the planning phase "rules are identified, management approval is finalized and documented, and testing goals are set". No testing happens until it’s signed.

Stage 2: Authorisation and legal points

This is general information, not legal advice.

Part 10.7 of the Commonwealth Criminal Code Act 1995 sets out computer offences, including unauthorised access to and modification of restricted data, and the states have their own laws. A penetration test is legal because the owner of the systems has authorised it. So the authorisation needs to come from someone who actually has the authority.

Three situations catch people out:

• Hosted and cloud systems. You may own the data but not the platform. Cloud providers publish their own rules. Microsoft’s cloud penetration testing rules of engagement, for example, require testing to stay within your own tenant or assets and prohibit denial-of-service testing.
• Systems run by a supplier. If your IT provider, website host or software vendor runs the system, they usually need to agree too, and some contracts require notice.
• Social engineering. Tests that involve phoning or emailing staff should be approved by someone senior, with HR aware, and handled so that no individual is singled out in the report.

Check: the signed authorisation names the targets, the dates, the person authorising and their role, and every third party whose systems are in scope has agreed in writing.

Stage 3: Reconnaissance and discovery

The tester maps what’s there. For an external test, that means finding the internet-facing systems tied to your organisation, the services running on them and their versions. For an internal test, it means mapping hosts, services, shares and directory information from the agreed starting point.

NIST describes this as the first half of the discovery phase. The second half is vulnerability analysis: comparing what was found against known vulnerabilities and looking for misconfigurations. Testers use scanners here, but treat their output as leads to verify, not findings.

A common early discovery is something nobody had on their list: an old test server, a forgotten remote access portal, a printer’s admin page exposed to the internet.

Stage 4: Exploitation within scope

This is the part that separates a penetration test from a scan. In NIST’s words, "While vulnerability scanners check only for the possible existence of a vulnerability, the attack phase of a penetration test exploits the vulnerability to confirm its existence."

Exploitation here means proving a weakness is real and showing its impact, within the rules. Typical examples:

• Signing in with a default or reused password on an exposed service.
• Using an access-control flaw in a web portal to view another customer’s record.
• Moving from one compromised laptop to a file server because of a shared local admin password.
• Chaining two medium-rated issues into one critical path.

NIST notes that testing often loops back to discovery: each foothold reveals new systems to examine.

Stage 5: Post-exploitation, and where it stops

Once a tester has access, the question becomes "how far could an attacker get from here, and what could they reach?" PTES calls this post-exploitation. It might include escalating privileges, reaching sensitive data or showing a path to domain administrator.

Limits matter most at this stage, and a careful tester will agree them in advance:

• Prove access, don’t take data. Evidence is usually a screenshot, a file listing or a harmless marker file, not a copy of your customer database.
• No destructive actions. No deleting, encrypting or changing business data.
• Clean up. Test accounts, tools and marker files are removed at the end, and the report lists anything that couldn’t be.
• Stop and call. If the tester finds evidence that a real attacker has been there before them, they stop and escalate to your contact.

Safety controls that should be in every test

NIST is candid that systems "may be damaged or otherwise rendered inoperable" during testing and that experienced testers reduce this risk but can’t eliminate it. These controls keep it small:

• Agreed testing windows, with sensitive systems tested when an outage would hurt least.
• Exclusions for fragile or third-party systems.
• An emergency contact on both sides and an agreed way to pause testing.
• Critical findings reported to your contact as soon as they’re confirmed, rather than held for the final report.
• Recent, tested backups of in-scope systems before testing starts.
• Gentle settings on older equipment, and no denial-of-service testing unless specifically agreed.

Stage 6: The report

The report is what you’re paying for, so know what a useful one looks like. It should have two audiences.

For leadership: an executive summary. A page or two in plain English: what was tested, the overall result, the few issues that matter most and what they could lead to in business terms.

For your IT team or provider: the technical findings. Each finding should include:

• A clear title and description.
• A risk rating. Many testers use the Common Vulnerability Scoring System (CVSS) from FIRST, now at version 4.0, whose qualitative scale is None (0.0), Low (0.1 to 3.9), Medium (4.0 to 6.9), High (7.0 to 8.9) and Critical (9.0 to 10.0). Others use a likelihood-and-impact matrix. Either way, the rating should reflect your environment, not just a generic score.
• Evidence: screenshots, requests and responses, or command output that lets your team reproduce it.
• Affected systems listed precisely.
• Remediation advice that is specific ("disable legacy authentication for these accounts") rather than generic ("follow best practice").

It should also record the scope, the dates, the method used and anything that couldn’t be tested, so the report means the same thing to an auditor or insurer in a year’s time.

Stage 7: Debrief and retest

The debrief is a walkthrough of the findings with your team. Use it to ask which fixes are quick, which need planning, and whether any findings are linked so one change closes several.

A retest checks that fixes worked. The tester repeats the specific steps for each finding and updates the report to show what’s closed. It’s worth taking up for anything rated High or Critical, and for findings you’ll need to show as closed to a customer, insurer or auditor.

What types of penetration test are there?

If you’re unsure where to start, ASD’s Annual Cyber Threat Report 2025-26 is a useful guide to how attackers actually got in. Mapping incidents to MITRE ATT&CK techniques, ASD saw phishing in 39% of them, and it remained the most observed initial access technique. Valid accounts (signing in with real credentials) appeared in 15% and exploiting public-facing applications in 13%. That points most organisations towards an external test, a Microsoft 365 review and an internal test that assumes a phished laptop. Our summary of the report has the rest of the figures.

For a closer look at the first two, see internal versus external penetration testing.

How should you prepare? A checklist

Work through this before the test starts. Each line has a Check: you can tick.

1. Pick the question you want answered. "Could someone on the internet get to our client files?" is better than "test everything". Check: the scope document states the goal in one sentence.
2. List the targets exactly. Check: every IP address, domain and URL in scope is written down and confirmed as yours.
3. Get the right authorisations. Check: signed authorisation from your organisation, plus written agreement from any hosting, cloud or IT provider whose systems are involved.
4. Name a contact and a backup. Check: both know the testing dates and how to pause testing.
5. Tell the people who need to know, and decide who doesn’t. Your IT provider and security monitoring team may need notice so alerts aren’t treated as a real attack, unless detection is part of what you’re testing. Check: the decision is written down.
6. Confirm backups. Check: a recent restore test has worked for each in-scope system.
7. Prepare access. Test accounts at the right permission level, VPN access or a network port for an internal test. Check: the accounts work before day one.
8. Flag fragile or critical systems. Check: they’re either excluded or have agreed test windows.
9. Plan for the fixes. Book time with whoever will fix the findings. Check: each High and Critical finding has a named owner and a target date as soon as the report arrives.

Key takeaways

• A penetration test moves through scoping, authorisation, discovery, exploitation within limits, reporting, debrief and retest.
• Recognised references include NIST SP 800-115, PTES and the OWASP Web Security Testing Guide. Ask which one your tester follows.
• Written authorisation from someone entitled to give it, including any cloud or hosting provider, is what makes testing lawful.
• Safety controls (windows, exclusions, contacts, backups, immediate reporting of critical issues) should be agreed before testing starts.
• A useful report has a plain executive summary and findings with a risk rating, evidence and a specific fix.
• Your preparation decides how much value you get, so use the checklist above.

Sources

• NIST, SP 800-115: Technical Guide to Information Security Testing and Assessment (September 2008), section 5.2 Penetration Testing
• The Penetration Testing Execution Standard, high-level organisation of the standard (a documentation mirror; the official home is pentest-standard.org)
• OWASP, Web Security Testing Guide
• FIRST, CVSS v4.0 Specification Document, Table 22: Qualitative severity rating scale
• Federal Register of Legislation, Criminal Code Act 1995, Part 10.7 Computer offences
• Microsoft Security Response Center, Microsoft Cloud Penetration Testing Rules of Engagement
• ASD’s ACSC, Annual Cyber Threat Report 2025-26, Figure 8: top 10 MITRE ATT&CK techniques