The penetration testing checklist: scope, type, drivers, budget, timing and vendor
Getting a penetration test is not a one-click purchase, but it is not a months-long project either. It is a series of decisions you can make in an afternoon, provided you know which questions are on the table. This checklist walks through them in the right order: what you test, which type of test fits, why you are testing, how deep, what it may cost, when, what you arrange yourself and what to look for in a vendor.
If the concept is new to you, start with what a penetration test is. This page assumes you know what a pentest is and want to get one done without missing anything.
Two numbers to keep in mind. At traditional consultancies, four to eight weeks typically pass between the first email and the first testing day. At Budget Security, testing starts within 7 days of booking; a faster start is possible only subject to tester availability and an urgency surcharge, and we never guarantee it.
1. Start with scope: what are you testing?
Everything starts with scope. Not with price, not with the vendor, but with the question of which systems an attacker would go after and which of those you want examined in this test. A scope that is too broad spends testing days on parts that do not matter; a scope that is too narrow produces a report your auditor or customer will not accept.
List your assets. Web applications with a login, the APIs behind them, mobile apps in the stores, the outside of your network (everything with a public IP address), the internal network, your cloud environment. For each asset note the URL or IP range, who owns it, what data it holds and whether it is production or staging.
Choose what goes into this test. Start with whatever processes customer data or is reachable from the internet. A SaaS company usually starts with the web application and the API; a company with offices and its own servers with the external network; a company with an app in the stores with the mobile app plus the API that app talks to.
Production or staging. Testing production gives the truest picture, because staging is rarely identical. If you choose staging anyway, confirm that version, configuration and integrations match. Most of our customers choose production with an agreed testing window and separate test accounts.
Write down what is out of scope. Third-party systems, denial of service, social engineering unless agreed, and production data that must not be modified. What is not on the list does not get tested, so be precise here.
2. Which type of pentest do you need, and do you need more than one?
The type of test follows from the scope. Each asset has its own form of test, with its own methodology and its own number of tester-days.
| Asset | Type of pentest | Typical size |
|---|---|---|
| Web application with login and customer portal | Web application pentest, grey box | 2 to 5 tester-days |
| REST, GraphQL or SOAP API | API pentest, grey box with an OpenAPI spec | 1 to 3 tester-days |
| Public IP addresses, VPN, mail servers | External network pentest, black box | 1 to 3 tester-days |
| Office network, Active Directory, internal servers | Internal network pentest, performed remotely through a test device | 2 to 5 tester-days |
| iOS or Android app | Mobile app pentest, grey box | 2 to 4 tester-days |
| AWS, Azure or Google Cloud environment | Cloud pentest, arranged with your account manager | Custom |
Black, grey or white box. In a black box test the tester gets nothing up front; in a white box test everything, including source code. For most tests we recommend grey box: the tester receives test accounts and documentation, so the testing days go to the real work rather than to guessing login pages. It is also the closest match to what an attacker with a stolen account can do.
Do you need several tests? Often yes, but not necessarily at the same time. A web application and its API form one attack surface and are best tested in one engagement, by the same tester, so attack chains between the two become visible. The external network can go in the same engagement or a quarter later. An internal network test is a separate engagement with its own preparation. On the platform you add each asset separately and see the tester-days per asset; you decide what goes together and what follows later.
3. What is driving the test: internal or external?
Why you test determines how deep you test and what the report must look like. There are roughly two kinds of drivers, and most organizations have both.
Externally driven. An auditor asks for evidence for SOC 2, ISO 27001 or PCI DSS. A large customer demands a recent pentest report before signing. A law or regulator requires it: HIPAA's risk-analysis duty for healthcare data, PCI DSS requirement 11.4 for card data, NIS2 and DORA in the EU, FedRAMP or CMMC for federal work, state privacy laws that expect reasonable security. A buyer wants assurance in an acquisition. With this driver, what counts is that the report meets the recipient's requirements: an independent tester, a recognizable methodology, a clear scope, findings with severity and evidence, and a retest showing you followed up.
Internally driven. You want to know where your systems stand before someone else finds out. You are launching a new product, you have just finished a major rebuild, or you hold customer data whose exposure would hurt the business. Here depth is what counts: the tester needs the time to build attack chains and test business logic, not just tick off the known lists.
Why the distinction matters. Companies that are only externally driven sometimes choose the narrowest scope the auditor will accept. That is understandable but rarely smart: the same tester-days, with a slightly broader scope, produce a report that also covers the next customer questionnaire and the next audit. Companies that are only internally driven sometimes forget to have the report written so it also serves as evidence later. Decide up front who reads the report: developers, leadership, auditor, customer.
4. One pentest for several certifications and goals
A well-designed pentest serves several goals at once. The major frameworks rarely prescribe a specific form of test; they ask for evidence that your security controls work and that the evidence was not produced by the people who built the system. One report from an independent, certified tester satisfies that requirement for several frameworks.
What one test usually covers. SOC 2 (criteria on monitoring and vulnerability management), ISO 27001 (Annex A technical vulnerability management and security testing), HIPAA (the security rule's evaluation and risk-analysis requirements), customer security questionnaires and due diligence in an acquisition. One report on your web application, API and external network serves all of these readers.
Where extra requirements apply. PCI DSS requirement 11.4 asks for a test of the cardholder data environment and, where you rely on network segmentation, a segmentation test; that needs a specific scope. DORA sets requirements for tester qualifications and independence and adds the separate threat-led penetration test for larger financial firms. FedRAMP and CMMC follow NIST testing expectations with their own reporting formats. In those cases, tell the tester up front which framework the report is for, so scope and reporting are set up accordingly.
Compliance mapping. If you want the report to show per finding which standard or control it touches, that is available on request. By default you receive a report that auditors of the frameworks above recognize: scope, methodology, findings with severity, CVSS, impact, fix and evidence, plus an executive summary.
5. Threat level and depth: how many tester-days?
The depth of a pentest is expressed in tester-days. How many you need depends on the size of the asset and on your threat level: how attractive are you to an attacker, and how large is the damage if it goes wrong?
Questions that set the threat level. Do you process personal, financial or health data? Are your systems reachable from the internet? Do you host several customers on one platform (multi-tenant), so that an access-control flaw puts customer A inside customer B's data? Does money flow through your application? Are you a link in the supply chain of larger organizations? Every yes raises the stakes and justifies more tester-days on that asset.
What extra tester-days buy. The first day goes to mapping the attack surface and verifying what the tooling finds. Only after that comes the work scanners are blind to: authorization flaws between roles and tenants, business logic, attack chains that turn several small findings into an account takeover. An application with many roles and integrations needs those extra days; a simple brochure site does not.
How it works on the platform. A test runs 1 to 30 tester-days in half-day steps. The scoping engine sets the number based on the asset you add; for custom environments the account manager does. When booking you can adjust the number by two days up or down and see immediately what that does to the price.
6. Budget: what moves the tester-day count and the total
At Budget Security the total is a simple sum: the number of tester-days times the day rate of $985 per tester-day for US clients, €849 per tester-day in the EU, excluding tax, with no setup or project-management fee. The total goes up with more or larger assets (pages, endpoints, roles, IP addresses), with urgency on the earliest available start dates and with options such as a retest (1 tester-day), a report walkthrough or a separate attestation letter for your auditor; it goes down with grey box instead of black box, because the tester does not have to guess first. Budget your developers' fix time in the sprint after the test as well. Booking creates a quote, not a payment; you pay after the report has been delivered. How much a pentest costs in your situation shows in the calculator as soon as you enter your assets.
7. Timing: when should you schedule the pentest?
The right moment for a pentest depends on your development cycle and on your external deadlines. Four situations come up again and again.
Before a major launch or migration. A new product, a new customer portal, a move to another cloud environment. Test when the functionality is complete but there is still room in the schedule to fix findings: two to four weeks before go-live is realistic. A test on launch day produces findings you can no longer fix.
After major changes. A new authentication layer, a rebuilt API, an acquisition where systems are connected. Last year's pentest says nothing about code written since. Auditors expect a test after every significant change, not only annually; see how often to run a pentest for what each framework expects.
In rhythm with your sprints. If you develop in sprints and ship a lot of new code, a fixed cadence works better than one large test: for example an annual broad test plus a targeted test each quarter on what was added. Schedule the test at the end of a sprint, so the findings can be picked up in the next one.
Before an audit or a customer deadline. Work backwards from the date the report has to exist. Add up: the lead time to the start, the number of tester-days, 48 hours for the report, your team's fix time and 1 tester-day for the retest. With a consultancy on a six-week waiting list you quickly lose three months; with a start within 7 days the whole cycle fits in four to six weeks.
What to expect on lead time. At many providers, four to eight weeks pass between the request and the first testing day: proposal, scoping call, scheduling. At Budget Security you pick a start date within 7 days of booking; faster only subject to tester availability and an urgency surcharge, never guaranteed. Read what a fast pentest can realistically deliver before you plan on urgency.
8. What you arrange yourself: the preparation checklist
Without authorization a pentest is unauthorized access; with authorization it is a service. That is why preparation sits with you, not with the tester. Every item still open on the first testing day eats testing hours that should go to the test itself.
- Written authorization from the system owner. Only the owner can grant it. If a vendor hosts the application for you, that vendor has to agree.
- Hosting and SaaS terms. Cloud providers generally allow pentests on your own environment, but some services require advance notice or exclude certain forms of testing.
- Test accounts per role. At least two accounts per user role (admin, regular user, and where applicable a second organization or tenant), so the tester can check whether user A can see user B's data.
- Testing window and time zone. Within which hours may testing happen? Business hours have the advantage that your team is reachable.
- Two points of contact. A technical contact for questions and an escalation contact for critical findings, both with phone numbers.
- Exclusions. Third-party systems, functions that must not be touched, data that must not be modified, denial of service.
- Allowlisting the tester. Put the tester's IP addresses on your WAF allowlist, so the test examines your application and not your firewall.
- A heads-up to your own team or SOC. So nobody treats the test as an incident and the tester is not blocked halfway through.
- Documentation. An OpenAPI specification for APIs, a short description of roles and key functions, and for a mobile app the store links or a test build.
On the platform you record these agreements when adding an asset. The tester sees them before the test starts; credentials are stored encrypted.
9. What to look for in a penetration testing vendor
The market runs from one-person shops to global consultancies and from automated scans to hand work. The full comparison is in our guide on how to choose a penetration testing company; these are the points that make the difference.
- Certification of the testers themselves. Ask who performs the test and which hands-on certification that person holds. The OSCP is the most recognized practical certification for penetration testers; a certificate held by the company says nothing about the person at the keyboard.
- Independence. The tester must not be the same party that builds or manages your systems. Auditors check this.
- Manually verified findings. Ask whether every finding in the report has been confirmed by a human. A report full of unverified scanner output costs your developers days chasing nothing.
- A sample report up front. A vendor that cannot show an anonymized sample either has something to hide or nothing to show.
- Retest and follow-up. How is it shown that findings were fixed, and what does the retest involve? An auditor wants the file complete. Most standards name no specific accreditation scheme, so check what your auditor actually requires before making one a hard requirement.
Do it yourself or have it done?
What your own team can do. Run a vulnerability scanner, apply patches, harden configurations, create test accounts and describe the scope. That removes the known, automatically detectable problems, so the external tester spends the tester-days on what a scanner cannot see.
Why having it done is the norm. Independence: whoever builds the system knows the assumptions behind it and unconsciously tests around them. Skill: a pentest is hand work, chaining individual weaknesses into an attack path. Evidential value: a report from an external, certified tester is accepted by auditors and customers; an internal memo rarely is. SOC 2, ISO 27001, HIPAA, PCI DSS, NIS2 and DORA all expect the tester to be independent of whoever builds or manages the system.
When internal is enough. When you only want to know for yourself where your systems stand, with no auditor or customer asking for evidence; when it concerns an internal tool without customer data; or as preparation for an external test. In every other case you have the pentest done and use the internal work as preparation.
What happens next: the seven steps in brief
Once you have been through the checklist, the test itself follows a fixed pattern. This is what to expect and when.
| Step | What happens | Lead time |
|---|---|---|
| 1. Scope and goal | Assets, method and number of tester-days are fixed; on the platform the scoping engine does this instantly for a standard asset | Instant to a few days |
| 2. Authorization and ground rules | You supply authorization, test accounts, testing window, contacts and exclusions | Half a day to a few days, depending on your organization |
| 3. Mapping | The tester maps domains, technology, endpoints and roles; the only phase where tooling leads | First testing day |
| 4. Finding and verifying vulnerabilities | Manual testing of authorization, authentication, injection and business logic along the OWASP Top 10, API Top 10 or Mobile Top 10; every finding is confirmed | Most of the tester-days |
| 5. Exploitation and attack chains | Individual findings are chained into attack paths; access is proven without damage; critical findings are reported immediately | Within the tester-days |
| 6. Report | PDF per asset with executive summary, scope, methodology and per finding severity, CVSS, impact, fix, reproduction steps and evidence; all findings also in the portal with status, notes, Jira integration and a prompt for your AI coding tool | Within 48 hours after the test ends |
| 7. Fix and retest | Your team fixes in order of severity; the retest (1 tester-day, paid option) confirms the fixes and closes the file for your auditor or customer | Depends on your sprint planning |
A worked example: a 4-day test booked on Monday starts no later than the following Monday, finishes Thursday, and the report is in your portal within two days after that. A confirmed start date can be moved, but not for free, because the tester-days are reserved for you.
How to get a pentest done at Budget Security
The whole process runs through the platform, without a sales call; our guide on how to buy a penetration test compares this with the consultancy and marketplace routes. You can order a pentest any day of the week; this is what happens next:
- Register. Create an account at app.budgetsecurity.com with your business email. The account manager approves new accounts, usually within 24 hours on business days.
- Add assets. Enter your web application, API, network or mobile app, with the agreements from the preparation checklist.
- Scoping engine. The platform translates each asset into a number of tester-days and shows what that covers. Adjust the days and you see what changes.
- Pick a date. Choose a start date within 7 days of booking. Earlier is possible only when a tester is available, with an urgency fee.
- Book. Booking creates a quote, not a payment. You pay after the report has been delivered.
- Test and report. An OSCP-certified tester performs the test by hand. Within 48 hours after the test ends, the report is in your portal.
- Retest. Book the retest with the test or later, and close out the findings with evidence for your auditor or customer.
New customers find a demo project in the portal with sample findings and a full sample report, so you see up front what you get.
The checklist in one list
Go through these twelve points before you book. If you can answer all twelve, your pentest is scoped and booked in an afternoon.
- List of assets with URLs, IP ranges, store links and API specification, and per asset the owner and the data it holds.
- Which assets go into this test, and which follow later.
- Production or staging, and for staging the confirmation that it matches production.
- Type of test per asset and the method: black, grey or white box.
- The driver: which auditor, customer, law or internal question must the report answer?
- The frameworks the report has to serve (SOC 2, ISO 27001, HIPAA, PCI DSS, NIS2, DORA, FedRAMP, customer questionnaire) and whether compliance mapping is wanted.
- The threat level: personal data, money, multi-tenant, supply-chain position, and from that the number of tester-days.
- The budget: tester-days times $985 (US) or €849 (Eurozone) excluding tax, plus retest and options, plus your team's fix time.
- The timing: before launch, after major changes, in sprint rhythm or counted back from the audit date.
- The preparation: authorization, test accounts per role, testing window, contacts, exclusions, allowlisting, heads-up to your SOC.
- The vendor: tester certification, independence, manual verification, sample report, transparent price and lead time, retest.
- The readers of the report: developers, leadership, auditor, customer, and who gets access to the portal.
FAQ
Frequently asked questions about getting a penetration test
What do I need to get a penetration test?
How many tester-days does my pentest need?
Can one pentest cover SOC 2, ISO 27001 and HIPAA at the same time?
When is the best time for a penetration test?
Can a penetration test be run on production?
Can we run the penetration test ourselves?
Get your pentest done by OSCP-certified testers
Scope it yourself, pick a start date within 7 days and receive the report within 48 hours after the test ends. Pay after delivery.