The Penetration Testing Process, Step by Step

Most penetration tests move through five stages: initial engagement, scoping, testing, reporting and follow-up. The UK National Cyber Security Centre (NCSC) describes the same sequence for a typical engagement. The stage that gets the attention is testing, but much of the value is decided before it starts, when scope, accounts and rules are agreed, and after it ends, when findings are fixed and checked.

Step 1: Initial engagement

The first conversation is about why you want a test, because the reason shapes everything after it. For a SaaS company the usual reasons are a customer security review, a major release, a new API, or wanting an independent check on how well your own controls hold up. If you're still deciding whether you need a test at all, start with what a penetration test is.

This is also when you find out whether the provider has the right skills. The NCSC advises flagging unusual systems during the bid so the provider knows what expertise to bring. For a typical web or API product, ask about their experience with your authentication method, with multi-tenant designs and with the frameworks you depend on. A tester who has seen fifty GraphQL APIs will find different things in yours than one who mostly tests internal networks.

Step 2: Scoping

Scoping turns "test our app" into a plan both sides agree on. A useful scope document states:

• the technical boundaries: domains, API base URLs, versions and environments;
• the kinds of testing expected and the user roles to test as;
• the time frame and effort, often given in tester-days;
• exclusions and special handling, such as out-of-hours windows or fragile systems;
• reporting requirements, for example whether you want CVSS scores.

Alongside the scope come the rules of engagement: written authorization, permitted techniques, rate limits, emergency contacts and the conditions under which testing stops. If your product depends on third-party services, check whether testing them needs that provider's permission; owning your app doesn't give you the right to authorize attacks on someone else's. Scoping a pentest covers each of these in more detail.

What your team prepares

Before the start date, create working test accounts for every role in scope, load realistic synthetic data and share your API documentation. For a multi-tenant product, set up at least two separate test organizations, otherwise nobody can check whether one tenant can reach another's records. Then log in with every account the day before. An authenticated test whose credentials don't work quietly becomes an unauthenticated one.

Step 3: Testing

Testing usually opens with mapping: finding endpoints, parameters, roles and workflows, and comparing them with what the documentation says exists. Testers then look for weaknesses and try to confirm, within the agreed rules, whether each one can actually be exploited.

Published frameworks give the work structure. NIST SP 800-115 provides guidance on planning and conducting technical security tests and analysing what they find. The OWASP Web Security Testing Guide organizes web testing into areas such as authentication, authorization, session management, input validation and business logic. Neither is a checklist every engagement must finish; they're references for deciding what coverage to plan.

Staying in contact during the test

Keep a technical contact reachable throughout. The NCSC recommends this so testers can report critical issues straight away and get unblocked quickly when, say, an IP allowlist stops them reaching the API. Testers should avoid causing undue impact, but nobody can promise a test will never trigger an unexpected reaction, which is exactly why the stop conditions agreed in scoping matter.

When scope changes mid-test

Testers sometimes find systems that weren't in scope but affect the ones that are, such as an old admin subdomain that shares the production database. You can either widen the scope, which changes time and cost, or record the exclusion as a limitation in the report. Either is a legitimate choice. What goes wrong is agreeing something on a call and having nobody remember it when the report arrives, so put the decision in writing.

Step 4: Reporting

A good report says what was tested and when, what was found, how serious each issue is in your context and how to fix it. The NCSC also recommends a debrief meeting where your engineers can ask the testers about specific findings, which often saves days of guessing at how to reproduce something. What's in a penetration test report breaks the document down section by section.

Step 5: Follow-up and retesting

This is the stage most often cut short. Your team assesses each finding, decides on a fix and then has the fix verified. The NCSC is clear that risk decisions remain your organization's responsibility, and that the fix a tester proposes isn't always the only option; removing an unused feature can be better than patching it. Prioritizing and fixing pentest findings walks through that loop.

Stage	Main output	Who owns it
Engagement	Agreed objectives	You and the provider
Scoping	Scope and rules of engagement	You (approval), provider (plan)
Testing	Evidence of weaknesses	Provider, with your contact on call
Reporting	Findings, risk ratings, fixes	Provider
Follow-up	Fixes and retest results	You, with provider verification

How penetration testing works collects the guides that go deeper into each stage.

Where automated testing fits the process

Automated web and API testing, such as pentest99.com's, covers part of what happens in the testing stage for in-scope apps and APIs: repeatable checks for detectable weaknesses. It doesn't carry out the investigative manual work, the scoping conversation or the judgement in a tester's report. The comparison of automated and manual pentesting helps decide which you need, and pentest99.com can confirm its current scope.

Process questions

How long does a penetration test take?

It depends on scope. Providers usually estimate effort in tester-days during scoping, and a single small web application needs far fewer days than several applications plus their infrastructure. Ask for the estimate, and the assumptions behind it, in writing.

Do we need to tell our hosting provider?

Check your hosting provider's published penetration testing policy and follow it. Policies differ between providers and between services, and some activities, such as load or denial-of-service testing, are commonly restricted.

Should testing happen in production or staging?

Either can work. Staging lowers operational risk but may differ from production in configuration and integrations; production testing needs agreed limits and safeguards. Record which you chose, and what that choice leaves untested, in the scope.

What happens if the tester finds something critical?

Agree in advance that critical issues are reported as soon as they're confirmed rather than held for the final report, and name the person who takes that call.

Sources: NCSC, "Penetration testing" guidance; NIST SP 800-115; OWASP Web Security Testing Guide. Sources checked: November 2026.