Pentest Preparation Guide and Scoping Questionnaire: Scope, Credentials, RFP, and Attestation Workflow

Q1: What Is Penetration Testing Scope (And Why a Restricted Scope Is Worse Than No Test)?

Penetration testing scope is the upfront agreement defining the boundaries, targets, and exclusions of a test. It specifies which assets (URLs, IP ranges, cloud accounts, user roles) are tested, how (black, grey, or white-box), when, and what is delivered, plus the systems explicitly out of scope. A narrow scope lets you pass every time, yet the network can still fail the first hour it faces a real attacker.

The scope is the test, before any testing starts

I have watched teams treat scope as paperwork. It is the most important decision you make all engagement.

Scope answers a simple question: what are we allowed to attack, and what is off-limits? Get it right, and the report reflects your real risk. Get it wrong, and you buy a clean PDF that means nothing.

Here is the part that keeps me up. You can get a network certified, get an Authority to Operate, and your pentest will say you are secure. Then it dies the first hour it opens for business, because the test was scoped to be lame.

Scope is not the same as a vulnerability scan

People confuse the two constantly. A vulnerability scan pattern-matches software versions against a database and flags known issues. It is automated, fast, and shallow.

A penetration test defines a scope, then has a human exploit what is actually reachable inside it. The scope is the difference between a printout and a proven attack path.

This matters for compliance now. Auditors increasingly reject scan-only output as a substitute for a real test. Under PCI DSS Requirement 11.4, you need a documented methodology covering the full environment, rather than a scanner report. NIST SP 800-115 frames testing as a four-phase process, Planning, Discovery, Attack, and Reporting, where planning is where scope lives.

Open the front door, the side doors, and the back door

The honest version of scoping is uncomfortable. If you limit what you are willing to call a threat, you will pass every time. That is the trap.

If you want to be intellectually honest, you open the front door, the side doors, and the back door. You accept that you probably did a rough job placing some defenses, and you let the tester prove it. Credible providers such as UnderDefense validate every finding through a senior tester rather than shipping a raw scanner dump, so what reaches your report is real and reachable.

A restricted scope feels safer. It is more dangerous than no test at all, because it hands you confidence you did not earn. A clear pentest report template helps you see whether the scope behind it was honest.

Q2: Why Is a Pentest a Final Exam for Your Security Program Rather Than a Vulnerability Hunt?

A penetration test is the final exam for your security program. It validates whether your existing controls work and where the gaps sit, viewed from a real attacker’s perspective. Its purpose is to confirm control effectiveness, so if testers spend their hours documenting SSL issues you should have caught yourself, you are paying expert rates for low-hanging fruit instead of nation-state-grade attack-path analysis.

The unpopular truth about what a pentest is for

I will say the thing the category avoids. A pentest is not designed to find vulnerabilities. That is not the goal.

The goal is to view your stack from a threat actor’s perspective. When we spend all our time cataloging SSL weaknesses, that is time stolen from looking at your environment the way a serious adversary would. The standard read gets this backwards.

Think of it as the final exam. The exam validates that your existing controls work the way you think they do, and it finds the gaps where they quietly do not.

If you have not studied, you are not ready for the exam

Here is the consequence. If you have not done your own scanning, your own patching, and basic vulnerability management first, you are not studying for the test.

You are paying a senior tester to find the obvious stuff your own tooling should have caught. That is expensive, and it wastes the one thing you are really buying, which is human judgment on real attack paths. OWASP and the Penetration Testing Execution Standard both treat pre-engagement preparation as phase one for exactly this reason.

I might be slightly hard on this, but I have earned the opinion. A team that skips the prep gets a report full of findings they could have fixed for free. Continuous attack surface management closes many of those gaps before the testers ever arrive.

Do the cheap homework first

The fix is not complicated, and it respects your budget. Run the scanning yourself before the engagement.

Burp Suite costs around 350 dollars and does an excellent job at vulnerability scanning with very little expertise required. Run it, patch what it surfaces, then bring the testers in for the deep work. From what surfaces when you actually run engagements, the teams that prep this way get findings about business logic and privilege chains, the things that matter, instead of a list of mediums they already knew about.

Q3: How Do You Scope a Penetration Test? A Step-by-Step Method

To scope a penetration test: (1) list every distinct target, including web apps, APIs, mobile, cloud accounts, and network ranges; (2) prioritize by sensitivity and exposure; (3) choose a test type (black, grey, or white-box); (4) define authenticated user roles; (5) list explicit exclusions; (6) set rules of engagement and windows; (7) finalize the document. Specificity decides everything: “app.example.com in production with three authenticated roles” beats “our web app.”

Vague scope is where engagements go to die

The single biggest cause of a disappointing test is a scope written in generalities. “Test our web app” is not a scope. It is an invitation to confusion.

A tester reading that does not know your subdomains, your API endpoints, or which user roles exist. The fix is precision. Name the target as “app.example.com in production, with anonymous, standard user, and admin roles.” Now the tester knows exactly what to attack.

The seven steps to scope a test

Work through these in order. Each one removes a dispute you would otherwise have mid-engagement.

1. List every distinct target. Web apps, APIs, mobile builds, cloud accounts, and IP ranges, named individually.
2. Prioritize by risk. Rank assets by data sensitivity and internet exposure, then test the crown jewels first.
3. Choose a test type. Black-box (no access), grey-box (some credentials), or white-box (full access and code).
4. Define authenticated roles. Specify each user role and its permissions so the tester covers privilege escalation.
5. List explicit exclusions. Name anything off-limits, such as a fragile legacy host or a third-party system.
6. Set rules of engagement. Agree testing windows, blackout periods, and named contacts.
7. Finalize the document. Write it down and have both sides sign it.

Make the scope doc do double duty

Map your scope document to a named methodology, and it stops being a one-off form. NIST SP 800-115’s four phases give you a structure auditors recognize. The Penetration Testing Execution Standard calls scoping the pre-engagement phase, so your questionnaire becomes audit evidence.

A hybrid approach, where automated tools map the surface during recon while senior testers validate what is reachable, keeps scope wide enough for coverage and deep enough for the auditor. That is how UnderDefense runs its web app penetration testing engagements, which is what lets a defined two-to-three-week turnaround hold without thinning the human judgment. If you are weighing perimeters, our guide to internal vs external pentest scoping helps you decide where to point the test first.

Q4: What Goes Into a Scope of Work and Rules of Engagement?

A penetration testing scope of work answers five questions: what is tested, how (test type and methodology), when (windows and blackout periods), how risk is controlled, and what is delivered. The rules of engagement add the safety contract: testing windows, stop conditions, escalation paths, and named emergency contacts. Together they protect both sides from missed assets, production outages, and disputes over what testing actually meant.

The five pillars of a scope of work

A good scope of work (SoW) reads like a clear answer to five questions. Cover all five, and there is no room for surprise.

Pillar	What it covers	Example
What	The exact assets in scope	app.example.com, the REST API, two cloud accounts
How	Test type and methodology	Grey-box web app test mapped to OWASP WSTG
When	Windows and blackout periods	Weeknights, 8 PM to 2 AM, no testing on release day
Risk control	How damage is prevented	Staging only, daily check-ins, named stop contact
Deliverables	What you receive	Technical report, exec summary, retest, attestation

One pillar has a hard rule attached. For web application testing, a non-production staging environment is an absolute full stop. We will not test in production. The last time a team pushed us to, the result was catastrophic, so make sure you have a staging environment we can access.

Rules of engagement are the safety contract

The rules of engagement (RoE) sit on top of the scope and keep the test from breaking your business. They define the testing windows, the stop conditions, the escalation path, and the named people we call at 2 AM if something goes wrong.

They also list explicit exclusions. Common ones include denial-of-service attacks, social engineering of named executives, and extracting real production data. Write these down. An exclusion you assumed but never documented is an argument waiting to happen. When social engineering does belong in scope, our social engineering testing findings show why teams keep it on the list.

Read your findings against your own policy

Here is a small move that surfaces big problems. When we find an eight-character lowercase password during a test, the first question is, what is your password policy?

If your policy says twelve characters with complexity, and we cracked an eight-character one, you do not have a policy problem. You have an implementation problem, where the rule exists on paper but not in the system. The scope and RoE are what let us catch that gap cleanly, which is the kind of validated finding UnderDefense puts in front of your engineers instead of raw noise. Teams under audit pressure pair this work with compliance services so the proof maps straight to the framework, and a virtual CISO can own the policy fixes the test exposes.

Q5: What’s the Pre-Test Checklist for Credentials, Access, and Tier-Zero Audits?

Before a pentest starts, prepare a non-production staging environment, test accounts for each user role, allowlisting for tester IPs, named contacts, and a credential-handover plan shared out-of-band. Then do the homework: manually audit Active Directory for Tier-Zero misconfigurations (domain admins, enterprise admins, anything with “admin” in the name) and look for low-privilege users carrying elevated rights. This preparation turns the engagement into a real exam.

The week I lost to a locked-down environment

Let me tell you about a test that still stings. My job was to pentest all the systems and networks for a large government health agency.

We had two weeks for the engagement. We spent the first seven days just finding the environment, because they would not open it up and let us test. That left three days to do the actual work.

Seven days burned on access negotiation is seven days of senior testing you paid for and never received. Preparation is not paperwork. It is the difference between a deep test and a rushed one.

The pre-test access checklist

Prepare these before the kickoff call, rather than during it. Each item removes a delay that eats your testing window.

• Staging environment. A non-production copy the testers can attack freely.
• Test accounts. One per user role, anonymous through admin, with credentials ready.
• Allowlisting. Add tester IPs to your firewall and WAF so they are not blocked on day one.
• Named contacts. Who answers the phone if something breaks at 2 AM.
• Credential handover. Share passwords out-of-band, over Slack or Teams, never in the open ticket.

This kind of access discipline is exactly what separates a thorough penetration testing engagement from a rushed one, and it mirrors the prep we expect before web app penetration testing begins.

“Scoping and detailed remediation reporting were clean and very comprehensive.”
CTO, IT Services UnderDefense Gartner Verified Review

Do your Tier-Zero homework first

Here is the Monday-morning task that pays off most. Audit your Active Directory permissions and hunt for Tier-Zero misconfigurations.

Tier Zero means your crown-jewel identities: domain admins, enterprise admins, anything with “admin” in the name. Look hard for low-privilege users who somehow carry elevated rights. That gap is the exact path a real attacker walks to take over your domain.

Knowing your identity posture before the test means the testers spend their hours proving real attack paths instead of mapping your org chart. UnderDefense delivers and stores the report on the UnderDefense Agentic AI SOC platform, or a password-protected archive with the password shared out-of-band, so the document mapping your weaknesses stays protected. Ongoing visibility into those same identities is where MDR service coverage takes over after the test ends.

“Under Defense security experts took the time to explain every discovered vulnerability as well as corresponding remediation steps.”
CTO, Software Development UnderDefense Gartner Verified Review

Q6: What Penetration Testing Requirements Do PCI DSS, SOC 2, and HIPAA Impose?

PCI DSS Requirement 11.4 mandates a documented methodology covering the full cardholder data environment and its perimeter, annual internal and external tests plus testing after significant change, remediation and re-testing of all exploitable findings, and segmentation validation at least annually, and every six months for service providers. PCI v4.0 brings APIs explicitly into scope. SOC 2 and HIPAA add their own evidence and attestation expectations.

PCI DSS 11.4, in plain language

Most pentests in the mid-market start because a framework demands one. PCI DSS is the most specific, so start there.

Requirement 11.4 has teeth. It wants a documented methodology, annual internal and external tests, testing after any significant change, and re-testing of every exploitable finding you fix. PCI v4.0 also pulls your APIs explicitly into scope and closes the old “we accepted that risk” loophole.

One detail trips people up. Segmentation validation, proving your cardholder zone is truly isolated, runs at least annually. For service providers, it runs every six months. Mapping these obligations early is where compliance services save teams the most rework.

What each framework actually accepts

The frameworks differ in what evidence satisfies an auditor. Here is the short version.

Framework	Core requirement	Cadence	What the auditor accepts
PCI DSS 11.4	Pentest of full CDE plus perimeter, with retest	Annual, plus after major change	Documented methodology, exploited findings, retest proof
SOC 2	Pentest as evidence of control effectiveness	Typically annual	Report tied to your control set, remediation tracking
HIPAA	Risk-based technical evaluation of ePHI systems	Periodic, risk-driven	Evidence the assessment covered systems holding health data

The thread connecting all three is the same. A vulnerability scan printout no longer clears the requirement that triggered your spend. Teams in regulated EU sectors face an added layer through DORA penetration testing obligations.

Scope the test to the trigger, not to a generic checklist

Here is my honest read. Too many teams buy a generic “pentest” and then discover it did not satisfy the framework that started the conversation.

Scope to the trigger. If PCI sent you here, the cardholder data environment and its segmentation are the priority. UnderDefense scopes engagements for the 100 to 5,000-employee FinTech, HealthTech, or SaaS company facing its first or next audit, so the deliverables aim squarely at clearing the compliance trigger. For regulated healthcare data, our MDR for Healthcare coverage documents the same controls year-round. The report becomes evidence your auditor accepts, rather than a document they question.

Q7: How Do You Write a Penetration Testing RFP That Attracts the Right Vendor?

A strong penetration testing RFP defines objectives, in-scope assets and explicit exclusions, required methodology (OWASP, NIST, PTES), compliance drivers, deliverables and mandatory retest terms, vendor qualifications, and a transparent scoring rubric. Buying on certifications alone misleads: a wall of OSCP badges or “top 1% on TryHackMe” shows someone can find bugs while saying little about operating inside a business. Look for battle scars, incident-response heritage, and community contribution.

What belongs in the RFP

A request for proposal (RFP) is your filter. A clear one attracts serious vendors and scares off the rest.

Include these sections, and you give every bidder the same picture:

• Objectives and compliance driver. Why you are testing, and which framework demands it.
• In-scope assets and exclusions. The same precision from your scope of work.
• Required methodology. Name OWASP WSTG, NIST SP 800-115, or PTES so coverage is comparable.
• Deliverables and retest terms. Report format, executive summary, and a mandatory retest.
• Vendor qualifications. Team experience, references, and sample (redacted) reports.

A solid pentest report template gives bidders a clear target for the deliverable, and comparing the field against the best pentest companies sharpens your shortlist.

Certifications tell you less than you think

Here is where I push back on common buying advice. I have seen a thousand people describe themselves as top 1% on TryHackMe.

That tells you they can find bugs. It says little about whether they understand operating as a security practitioner inside a real business. Certifications and leaderboard ranks are a floor, rather than the signal.

Think of it like a baseball bat. You could hand the bat to Babe Ruth, or you could hand it to me. The tool is the same, so the result depends entirely on who is holding it. Look for battle scars, real incident response heritage, and people who contribute to the community.

“We chose them among 5 other vendors. They understood our needs and gave us a detailed pen test report. Their team was quick and professional.”
Manager of IT Services UnderDefense Gartner Verified Review

A scoring rubric that keeps you honest

Score every bidder on the same axes, weighted to what matters for your trigger.

Criterion	Weight	What good looks like
Methodology fit	25%	Named standard, exploitation not just scanning
Tester experience	25%	IR background, redacted sample reports, references
Deliverables and retest	20%	Clear report, exec summary, retest included
Timeline fit	15%	Clears your audit deadline
Price for value	15%	Sized to your company, no hidden retest fees

UnderDefense’s testing grows out of real incident-response work, so testers who have cleaned up live breaches know which findings attackers actually use. That experience is why the report prioritizes what a company like yours would genuinely face.

“UD was a great partner in our penetration testing needs and contracted with great experience and new techniques for us. It was highly technical, very documented and high value.”
VP Security Services UnderDefense Gartner Verified Review

Q8: Automated, Consultant-Led, Hybrid, or PTaaS, Which Pentest Model Fits the Mid-Market?

Four models compete: automated scanning is cheap and fast while auditors increasingly reject scan-only output; consultant-led is deepest while priced and paced for enterprises; PTaaS suits always-shipping enterprises while overshooting a finite audit deadline; and hybrid sends scanners across the surface during recon while senior testers handle all exploitation and validation. For a 100 to 5,000-employee company with a deadline, a finite budget, and a small team, hybrid fits the problem: wide enough, deep enough, fast enough.

The four models, side by side

Each model is good at something real. The question is whether that strength matches your size, deadline, and budget.

Model	Real strength	Breaks for mid-market when	Audit acceptance
Hybrid (UnderDefense)	Senior validation on every finding, scanner-fast recon, 2 to 2.5-week turnaround, 5K to 30K dollar band, free retest	Rarely, for this buyer	High, validated and documented
Automated scanning	Cheap, sweeps wide surface in hours	You need exploited, validated findings	Often rejected as scan-only
Consultant-led	Deepest manual coverage on bespoke targets	Enterprise pricing, open-ended timelines	High, but slow and costly
PTaaS / continuous	Year-round cadence for always-shipping teams	You have a finite, deadline-bound trigger	High, but oversized for the need

Scanners are useful, and I rely on them. But automation alone misses the business-logic flaws and privilege chains that real attackers use. In our own internal testing, humans who manually attacked layered protections bypassed every one of them. The automation is not there yet for the deep work.

Why “good enough” automation still worries me

There is a math problem with leaning on automation for decisions. Getting it right 99% of the time still stinks.

That means one in a hundred actions is wrong. Think about how many actions run on your behalf during a test. One in a hundred is a bad miss when it is the finding that mattered.

This is why a human validates every finding before it reaches your report. We do not do PTaaS, and that is deliberate. The mid-market buyer with an audit in six weeks needs a defined engagement that clears the trigger, then a result they can hand to the people who demanded it. The same human-plus-automation balance shapes how our UnderDefense Agentic AI SOC platform supports analysts rather than replacing them.

What I would choose with a deadline and a lean team

If you have a hard date, a finite budget, and a small team, hybrid is the fit. You get scanner breadth on recon and senior judgment on exploitation, delivered in weeks. For teams weighing where to point that budget, our cybersecurity budget 2026 guide helps frame the trade-offs.

“Highly qualified pentesters will perform a pentest with exceptional quality within the agreed terms. Experience, qualification, speed and fast feedback during the pentest and after.”
Director, IT Security and Risk Management UnderDefense Gartner Verified Review

“They offered multiple alternative solutions that suited our budget. They maintained excellent communication throughout the testing phase.”
Denis Volokh, CTO, Noviscient Pte Ltd UnderDefense Clutch Verified Review

Q9: What Happens After the Test, Remediation, Retest, and the Attestation Workflow?

After a pentest, the real work begins: testers walk your engineers through each exploit path and the fix, you remediate, and the testers re-test the fixed issues to confirm the repair held. The final deliverable is a signed letter of attestation describing scope, results, and security standing, which is the proof your auditor or enterprise customer demanded. Remember the blind spots too, such as an outsourced WordPress site whose plugins you cannot patch yourself.

The report is the start, not the finish

A lot of buyers think the report is the deliverable. The report is the map. The work is fixing what it shows.

A good test ends with a walkthrough where the testers sit with your engineers and explain each exploit path step by step. Your team fixes the issues. Then the testers re-test the fixed items to confirm the repair actually held, which closes the loop PCI DSS 11.4 expects.

That verification loop matters because a fix that looks done in the ticket is not always done in the system. We fold the retest into the original price for exactly this reason, so the budget you approved covers proof that the holes are closed. This is also where a thorough penetration testing engagement earns its keep over a one-off scan.

“Scoping and detailed remediation reporting were clean and very comprehensive. The team gave us a clear path to fix each finding.”
CTO, IT Services UnderDefense Gartner Verified Review

The attestation letter is what your auditor reads

Here is the document that actually clears the trigger. The letter of attestation is a signed summary describing the scope, the results, and your security standing after remediation.

Your auditor reads it. Your enterprise customer’s security team reads it. Most executives skim the detailed technical report for a few seconds, so the attestation letter is what travels up to the board and out to the people who demanded the test. Pairing that letter with ongoing compliance services keeps the evidence current between tests.

UnderDefense walks your engineers through each exploit path, includes the retest, and issues a signed attestation letter you can hand straight to the auditor or customer who started the conversation. That is the proof that survives contact with a skeptical reviewer.

“They understood our needs and gave us a detailed pen test report. Their team was quick and professional throughout.”
Manager of IT Services UnderDefense Gartner Verified Review

Mind the assets you do not control

One blind spot catches teams every time. Picture a law firm that outsources its website to an agency.

It is a WordPress site, and maybe some of its plugins are vulnerable. The firm cannot patch it themselves. So the real task becomes knowing who to contact and how to get that third party to fix the issue before the window closes. Firms in this exact position often lean on dedicated coverage for insurance and law firms to manage those outside dependencies.

Map those outsourced assets during scoping, and name the contact who owns each one. When the test surfaces a vulnerable plugin you do not control, you already know whose phone to pick up. A finding without an owner is a finding that never gets fixed. Continuous attack surface management keeps those forgotten assets on your radar between engagements.

I am still chewing on one question for the next year of this work. As agentic AI starts handling more of the routine testing, the human judgment in that engineer walkthrough and that signed letter becomes the part that matters most, and our UnderDefense Agentic AI SOC platform is built around keeping that judgment in the loop. If you want a report your auditor or customer will actually accept, that conversation is where I would start, so talk to our team when you are ready.