What to Expect from a Penetration Test (And How to Prepare)

Who this is for

This is a buyer's guide. If you've never bought a penetration test before — or you've bought one and walked away wondering what you actually paid for — this is the article we wish every prospective client had read before their first call. It's vendor-neutral. We'll tell you what to expect, what's a red flag, and what questions actually separate a real pentest from a scanner-with-a-logo.

1. What a pentest actually is

A penetration test is a time-boxed, scoped attempt by a security professional to find and exploit vulnerabilities in a target system. The deliverable is a report describing what they found, how they found it, what an attacker could do with it, and how to fix it. The point is not to find every possible bug — that's impossible inside any reasonable budget. The point is to give you a credible answer to the question "if a competent attacker came after this, what would they get?"

It's worth being precise about what a pentest is not:

• It's not a vulnerability scan. A scan runs a tool against your target and produces a list of known issues. A pentest uses scans as one input, then a human investigates, chains issues together, and tries to actually break in
• It's not a security audit. An audit checks your environment against a control framework (SOC 2, ISO 27001, PCI). A pentest doesn't care about controls — it cares about whether the system can be broken
• It's not a red team. A red team is a goal-oriented exercise that emulates a specific adversary, often unscoped, often over weeks. A pentest is scoped and time-boxed
• It's not a guarantee. "Passed a pentest" doesn't mean "no vulnerabilities exist." It means "none were found inside the scope, in the time available, by these testers"

2. Why companies actually buy pentests

Most pentests are bought for one of four reasons. Knowing which one you're in helps you write the scope and read the report:

• Compliance: SOC 2, ISO 27001, PCI DSS, HIPAA, and most enterprise customer security questionnaires require an annual third-party pentest. The deliverable that matters is the attestation letter
• Customer ask: a prospect or existing customer demands evidence that your product is secure before they sign or renew. The deliverable that matters is a clean report you can share (or an executive summary you can share)
• Pre-launch validation: you're shipping a new product, a new feature, or a major architectural change, and you want a senior security professional to look at it before users do. The deliverable that matters is the actual finding list
• Genuine curiosity: the engineering or security team wants to know what's broken so they can fix it. The deliverable that matters is everything in the report, especially the parts marked low and medium

A surprising amount of pentest disappointment comes from buyers who said reason 4 to themselves but were really doing reason 1. If the goal is the attestation letter, optimize for that. If the goal is finding bugs, optimize differently.

3. Scope: the most important conversation

Scope is the line between "what's in the test" and "what's not." It's where most pentests succeed or fail before they even start. A good scoping conversation takes an hour at minimum, and it covers six things:

• Targets: which URLs, IP ranges, mobile apps, APIs, infrastructure, source repositories, and cloud accounts are in scope. Be specific. "Our production environment" is not a scope; a list of hostnames is
• Environment: production, staging, or a dedicated test environment. Each has tradeoffs. Production gives the most realistic results but the highest risk. A test environment is safer but can give false negatives if it doesn't mirror production
• Test type: black box (no information given), grey box (some information — credentials, architecture diagrams), or white box (full information including source code). White box gives the most coverage per dollar; black box gives the most realistic threat-actor simulation. Most quality tests are grey box
• Authenticated vs unauthenticated: if your application has user accounts, you almost certainly want authenticated testing across multiple roles. Unauthenticated-only testing skips most of the interesting attack surface
• Out of scope: systems the team is not allowed to touch. Common ones: third-party SaaS, anything that would affect customer data, anything that would trigger an incident response
• Constraints: testing windows, change-freeze periods, blackout dates, on-call contacts. Sort this out in writing before the test starts

4. The rules of engagement (RoE)

The rules of engagement document is the legal and operational contract between you and the tester. It's usually 3-6 pages and it should answer:

• What targets are authorized for testing, with explicit IP ranges, hostnames, or asset IDs
• What attack types are permitted and which are excluded (denial of service, social engineering, physical access)
• The testing window with start and end dates and times
• Source IP ranges the tester will be working from
• Emergency contact information on both sides
• Stop-test conditions: what causes the tester to stop and notify you immediately
• How findings will be communicated during the test (live for criticals, end-of-test for everything else)
• Data handling: what the tester is allowed to exfiltrate, what they have to delete, what they're not allowed to read at all

If a vendor offers to skip the RoE document, walk away. It exists to protect both of you, and a tester who doesn't insist on it is a tester who hasn't been burned yet.

5. How to prepare for the test

The week before the test starts is your highest-leverage week. A test against an unprepared target wastes the testers' time on findings you already knew about. Spend the week doing things that aren't testing:

• Patch the obvious: if you have an open backlog of critical vulnerabilities you already know about, fix them first. Otherwise the report will be 80% things you already knew
• Provision test accounts: one account per role the tester needs. Document credentials, MFA bypass procedures, password reset flows
• Whitelist tester IPs: in any WAF, IPS, or rate-limiter that would otherwise block traffic. The point of the test is to find application-layer issues, not to test your WAF
• Notify on-call: SREs and on-call engineers should know there's a test happening. Without this, you'll spend the test responding to false-alarm pages
• Inform any third parties: if you're hosted on AWS, Azure, or GCP, most don't require notification anymore but some specific services do. If you use a CDN or DDoS provider, definitely tell them
• Pre-stage documentation: architecture diagrams, API documentation, list of integrations, known limitations. Save the testers from spending day one on reconnaissance you could just hand over

6. What happens during the test

A typical test runs 1-3 weeks of active testing depending on scope, plus a week of reporting. You should expect:

• A kickoff call on day one to confirm scope, RoE, and access. This is your last chance to add or remove targets without changing the contract
• Daily or near-daily check-ins from the lead tester. Brief — what was tested yesterday, what's planned for today, any blockers
• Live escalation for criticals. If the tester finds something that puts you at immediate risk (full account takeover, data exfiltration path, RCE in production), they should call you the same day, not wait for the report
• A debrief call at the end of the active testing window, before the report is finalized. This is where ambiguities get resolved and severity ratings get sanity-checked
• The draft report for review, usually a week after testing ends. Read it carefully — this is when factual corrections happen
• The final report after your review comments are incorporated

7. How to read the report

A pentest report is a long document and most of it is for your auditor. The parts that matter for actually improving your security are smaller and worth reading carefully:

• The executive summary: one to two pages. This is what your CFO and your customers will read. It should describe the scope, the methodology, the headline findings, and the overall risk posture
• The findings: each finding should have a title, severity, affected component, reproduction steps, evidence (screenshots, requests, code snippets), business impact, and recommended remediation. If any of these are missing, the finding is half-baked
• The methodology: what was tested, how, with what tools, and from what perspective. This is the section that tells you whether the report is from a real test or a scanner export
• The "not tested" section: what was in scope but not tested, and why. Time, blockers, access issues. This is the honest tester's section and it should not be missing
• Appendices: tool output, raw scan results, full list of tested URLs. Useful as evidence, not usually as reading material

8. What to do with the findings

The most common mistake we see is fixing findings in the order they appear in the report. Don't. The order they appear is usually not the order of risk. Triage them yourself, in this order:

• Anything cross-tenant or cross-user. If a finding lets one customer reach another customer's data, that's the first fix regardless of severity rating
• Anything that gives an unauthenticated attacker access to authenticated functionality. Auth bypasses, broken access control on public endpoints, default credentials
• Anything that touches money, secrets, or production data. Privilege escalation paths to admin, secret exposure, ways to extract production data
• Everything else by severity. Critical, high, medium, low — in that order, with a documented SLA per severity

And then do the part most teams skip: book the retest. A pentest without a retest is half a pentest. The retest verifies that the fixes actually work, and it catches the cases where the fix introduced a new bug. A reputable firm includes the retest in the engagement; a less reputable one charges you again for it

9. How to spot a bad pentest vendor

The pentest market has both world-class operators and complete charlatans, and they all have similar-looking websites. Some of the patterns that should make you walk away:

• The proposal doesn't ask scoping questions. If the vendor sends you a fixed-price quote for "a pentest" without a 60-minute scoping call, the test is going to be cookie-cutter
• The price is dramatically lower than the alternatives. Pentesting is human labor. If one vendor is 30% cheaper than the others, they're either using less senior people or running a scanner and writing it up
• The team isn't named. You should know who is doing your test and what their certifications, experience, and previous public work look like. Anonymous testers are a red flag
• The sample report looks like a scanner export. Pages of raw tool output, no chained findings, no business context, no exploitation evidence. This is what an unmanned scan looks like
• The retest is expensive or excluded. A vendor confident in their findings includes one retest. A vendor charging extra for the retest is selling you finding volume, not finding quality
• The communication is async-only. Real tests need a kickoff call, daily check-ins, and a debrief. If the vendor will only communicate by email, they're not running the engagement seriously

10. Questions to ask any vendor before you sign

• Who specifically will be testing? What are their certifications and years of experience?
• How much of the testing is automated, and how much is manual?
• Can I see a sanitized sample report?
• How do you handle critical findings discovered during the test?
• Is a retest included in the engagement, and what does it cover?
• How do you scope and price a follow-up engagement?
• What happens if you don't find anything? What does the report look like in that case?
• How do you handle data found during testing — what gets exfiltrated, what gets deleted?
• Are you carrying professional liability insurance, and at what limit?
• What's your stance on responsible disclosure if you find a vulnerability in a third-party product we use?

The short version

A good pentest is a conversation, not a transaction. The vendor asks more questions than they answer in the first call. The scope is specific. The testers are named. The report has business context. The retest is included. The findings are ranked by risk, not by tool severity. And when you're done, you have a list of fixes you actually understand and can ship.