What to Expect from a Penetration Test: A Complete Guide
Buying your first penetration test is harder than it should be. Vendors throw acronyms at you, sales decks blur together, and the word “pentest” gets used for everything from a one-hour Nessus scan to a four-week red team engagement. If you’re a CISO, a head of security, or a compliance lead who’s been asked to “get a pentest done” before your next audit, you need a clearer picture of what you’re actually buying.
This guide walks through what a real pentest looks like, how to scope it, what the deliverables should contain, and the mistakes we see first-time buyers make. ZynoSec runs these engagements every week for Indian mid-market and BFSI clients, so the advice here is pulled from real engagements, not theory.
Pentest vs. vulnerability scan vs. audit
A vulnerability scan is automated. A tool like Nessus, Qualys, or OpenVAS crawls your assets, matches versions against a CVE database, and spits out a list. It’s fast, cheap, and shallow. It will tell you that a server is running an outdated OpenSSL; it won’t tell you whether that actually lets someone in.
A penetration test is a human sitting in front of your application, network, or Active Directory for days or weeks, trying to compromise it the way a real attacker would. The tester chains together misconfigurations, weak logic, and exposed services until they reach a meaningful goal — domain admin, access to customer PII, or the ability to move money.
A security audit is something else entirely. Audits check whether your controls exist and are documented (ISO 27001, SOC 2, PCI-DSS). They rarely test whether the controls actually work. A clean audit with no pentest is a false sense of safety.
You want all three. But don’t let a vendor sell you a scan and call it a pentest.
The main types of pentest
Scope is the first real conversation you’ll have with a vendor. The answer depends on what you’re protecting.
Web application pentest. Covers OWASP Top 10 classes plus business-logic flaws specific to your app — broken access control, IDOR, SSRF, injection, auth bypass, and the weird stuff scanners miss. Test from an unauthenticated, low-privilege, and admin role. Tools like Burp Suite and Caido do the heavy lifting; the tester supplies the brain.
API pentest. Similar to web but focused on the REST/GraphQL surface — broken object-level authorisation (BOLA), mass assignment, rate-limiting, JWT handling, and excessive data exposure. If your frontend is a thin wrapper around APIs, this is where most real bugs live.
External network pentest. Everything internet-facing — VPN concentrators, mail servers, web apps, forgotten dev subdomains. Starts with nmap and subdomain discovery, then exploitation of exposed services. Often the smallest effort but the most public-facing risk.
Internal network pentest. Simulates a compromised laptop on your corporate LAN. The tester tries to escalate from a regular user to domain admin using tools like Responder, CrackMapExec (now netexec), BloodHound, Impacket, and Certipy. Almost every internal pentest ends with domain admin — the question is how fast.
Active Directory pentest. A specialised internal pentest focused on Kerberoasting, ADCS abuse, DACL misconfigurations, and tier-0 compromise. Critical if you’re a bank, insurer, or any org with more than a few hundred employees.
Red team. Goal-oriented, stealthy, adversary-simulation. The red team doesn’t try to find every bug — they try to reach one specific objective (read CEO’s email, pivot into SWIFT, exfiltrate design data) without your SOC catching them. Scope is objectives, not IPs.
Mobile pentest. Android and iOS binaries, API backends, local storage, runtime manipulation with Frida or Objection, and certificate pinning bypass. Essential if you’re a fintech or have a public-facing consumer app.
Typical timelines
Timelines are the most lied-about part of pentest sales. Here’s a rough honest version, assuming a competent vendor and reasonable scope.
Engagement type Field work Reporting Total
------------------------ ------------- ------------ -----------
Web app (small) 3-5 days 2 days ~1 week
Web app (complex SaaS) 10-15 days 3-5 days 3 weeks
API (20-30 endpoints) 5-7 days 2-3 days ~2 weeks
External network (/24) 2-3 days 1-2 days ~1 week
Internal + AD 7-10 days 3-4 days 2-3 weeks
Red team (4-week op) 15-20 days 5 days 4-5 weeks
Mobile (iOS + Android) 8-10 days 3 days 2 weeks
If a vendor offers you a full web app pentest in two days for a flat fee, they’re selling you a scan with a Burp crawl on top.
What you need to prepare
Half the time wasted in pentests happens because the client didn’t prep. Get these ready before kick-off.
- Scope document. URLs, IP ranges, API base paths, mobile package names. Explicitly list what’s out of scope (production database host, third-party SaaS you don’t control).
- Test credentials. Two accounts per role minimum — you want the tester to find horizontal privilege escalation, and that needs two users at the same level. Provide admin, regular user, and any unusual role (auditor, read-only, vendor).
- NDA and MSA signed. Don’t start scoping specifics over unencrypted email before paperwork is done.
- Single point of contact. One person on your side who can answer questions within hours, not days. Pentests stall fast when the tester hits a weird auth flow and can’t get clarification.
- Whitelisting. If you have a WAF like Cloudflare or Akamai, the tester’s source IPs need to be whitelisted. Otherwise you’re paying them to test your WAF, not your application.
- Blue team heads-up. Let your SOC know (unless it’s a red team, where you explicitly don’t). Otherwise you’ll spend day two on a conference call about “the attack in progress”.
- Staging or prod decision. Staging gives you freedom to let the tester be aggressive. Prod gives you real findings. Most engagements run on staging with a final sanity check against prod.
What a good report contains
The report is the deliverable. If it’s thin, the engagement was thin. A solid report has:
- Executive summary. One page, written for your CEO. Risk in business terms, not CVSS scores.
- Methodology. What the testers did, what was in and out of scope, what they couldn’t test and why.
- Findings. Each finding with severity (CVSS 3.1), affected asset, reproduction steps, proof-of-concept screenshots or requests, impact description, and remediation. “Reproduction steps” means a dev can reproduce it cold from the report — if they can’t, the finding is half-written.
- Retest summary. After you fix, a retest section confirming which issues are closed.
- Attestation letter. The short auditor-friendly version you can hand to clients and regulators.
Ask for a sample report before you sign. Any serious vendor will share a redacted one. If they refuse, walk away.
How to evaluate vendors
Certifications matter, but only the hands-on ones. OSCP, OSEP, OSCE3, CRTP, and CRTO prove the tester actually breaks things. CEH and similar theory-heavy certs tell you the person passed a multiple-choice exam. Ask to see the CVs of the testers who will actually do your work — not the sales engineer’s CV, not the founder’s.
Ask these questions:
- Who, by name, will perform the test? Can I see their credentials?
- Is every finding manually validated, or do scanner outputs end up in my report?
- What’s your retest policy? Is it included for 30, 60, or 90 days?
- Can you show me a redacted sample report from a similar engagement?
- What do you do when you find a critical during testing — stop and notify, or keep going silently?
A vendor that hesitates on any of those is not ready for your business.
Common first-time-buyer mistakes
We see the same mistakes repeatedly. Scoping too narrowly so the tester can’t chain bugs — for example, testing the API but not the frontend that calls it. Providing one test account instead of two. Running the pentest the week before an audit deadline, with no time to actually fix what gets found. Treating the report as a compliance artefact instead of a remediation plan. And the biggest one: not budgeting for a retest, so the fixes you push out in a hurry never get verified.
A pentest is a snapshot. The value comes from what you do with it in the weeks after. Pick a vendor who’ll be around for that part, too.