How Long Does a Penetration Test Take?

How long does a penetration test take? For one clearly scoped engagement, plan on three to six weeks of calendar time and roughly three to ten days of hands on testing. Those are two different numbers, and the gap between them is where MSPs lose client goodwill. MSP Pentesting runs these channel-only under your brand, so when a client asks for a date you're quoting a schedule you can actually hold.

Here's what nobody says on the sales call. The testing window is the shortest stage of the whole thing.

Everything around it is paperwork, access and writing.

The short answer, by engagement type

These are the ranges we scope against. They're testing days, not calendar days, and they assume the target list is settled before anyone starts.

If somebody quotes you two days for a full internal test on a 400 seat environment, they're selling you a scan with a cover page. That isn't the same product.

Calendar time and testing time aren't the same number

Clients hear "five days" and write it on a calendar as a week. Then they're annoyed when the report lands three weeks later. That's an expectation problem, and it's yours to manage because you're the one holding the relationship.

Break the calendar into five stages and it stops being mysterious.

Scoping. Two business days if the client answers fast. Two weeks if they have to go ask a hosting provider how many IPs they actually own. This stage is almost entirely dependent on the client, and it's the one MSPs underestimate hardest.

Authorization and scheduling. Contracts, the NDA, the signed rules of engagement, and finding a window that doesn't collide with month end close. Figure a week.

Testing. The days in the table above. This is the only part where anyone's actively attacking anything.

Reporting and QA. Five to seven business days after the last testing day. A second tester reviews findings, checks reproduction steps, and confirms severities before the document goes out. Skipping that is how you end up defending a false positive in front of your client's board.

Retest. Whenever the client finishes remediating. Could be next week. Could be next quarter.

Scope is the variable, effort is not

Every conversation about penetration testing scope eventually turns into a conversation about counting. Count the wrong things and the estimate is wrong before anyone opens a terminal.

Here's what we count, and what we ignore.

• Live services, not IP ranges. A /24 with six responding hosts is a small external test. A /28 running twelve distinct web applications is not.
• Distinct application roles. An app with an admin, a manager and a read only user is three times the authorization testing of a single role app.
• Forests and domains. Two domains with a trust between them is not one internal test. It's closer to one and a half.
• Physical sites. Anything requiring a shipped device or an on site day adds a week of logistics before testing starts.
• API endpoints. Documented endpoints get tested. Undocumented ones get discovered, which costs more.

What we don't count: total employee headcount, total storage, or the number of servers that are powered off. Those show up in a lot of scoping questionnaires and they don't predict effort.

One more thing that changes the number. Whether the client wants the tester to stop at proof of access or continue into post exploitation. Proving you can authenticate as a domain user is one afternoon. Proving you can pivot from that account to a domain controller, then to the finance file share, is several days and a much more useful report. Decide which one you're buying before you compare two quotes, because the cheaper one is usually the shorter one.

Rules of engagement take longer than you think

The penetration testing rules of engagement document is where a two week project quietly becomes a five week project. It defines the testing window, the escalation contacts, what's explicitly out of scope, whether denial of service techniques are permitted, and what happens if the tester gets domain admin at 2am on a Saturday.

None of that is controversial. All of it needs a signature.

The delay usually isn't legal review. It's that the person who can authorize testing against a system isn't the person you've been emailing. Cloud hosted apps often need the platform provider's rules acknowledged. Third party SaaS in scope means somebody has to get written permission from a vendor who has no reason to hurry.

Start the rules of engagement in parallel with scoping, not after it. You'll save a week almost every time.

Gray box shortens the clock

Black box testing sounds thorough and mostly just burns days. The tester spends the first two days doing reconnaissance the client could have handed over in an email, and you pay for it.

Gray box penetration testing gives the tester partial knowledge up front: a network diagram, a standard user account, application documentation, maybe a list of known third party integrations. The tester still has to find and prove the attack path. They just don't have to spend a third of the engagement rediscovering things the client already knows.

For most MSP client work, gray box is the right default. It buys more findings per day.

White box, with source code and architecture docs, goes further still and suits applications more than networks. Black box earns its place when the question is specifically "what can an outsider learn about us," which is a narrower question than most clients think they're asking.

What actually causes overruns

We've watched the same four things blow schedules, over and over.

Credentials that don't work on day one. The test accounts got created but never logged into, so they're stuck at a forced password change screen, and conditional access blocks the tester's IP anyway. Test the test accounts before the window opens.

Scope that grows mid engagement. The client remembers a second web app on Wednesday. That's a change order, not a favor, and pretending otherwise trains them to do it again.

Nobody available to answer questions. If the tester finds something that might be a live production issue, they need a human within the hour. Not a ticket queue.

Remediation that stalls. The retest can't happen until the fixes ship. If your client's dev team has a six week release cadence, the letter of attestation isn't coming next month no matter who you hire.

What MSPs ask when a client wants a date

How long does a penetration test take from first call to final report?

Four to six weeks is a realistic promise for a normally scoped engagement with a responsive client. Three weeks is achievable when scope is already documented, the rules of engagement are signed, and access is confirmed before the window opens. Anything faster usually means something got skipped.

Can it be rushed for an audit deadline?

Sometimes. Testing days can be compressed by running two testers in parallel on separable scopes. Report QA can't be compressed much without losing the second pair of eyes. If your client needs a letter of attestation by a hard date, work backward from it and start scoping six weeks out.

Does the report arrive the day testing ends?

No, and be suspicious of anyone who says it does. Findings need reproduction steps verified, severities peer reviewed and evidence attached. Five to seven business days is normal. A same day report is an automated tool export.

How long does the retest take?

Usually one to three days, covering only the findings the client says they've fixed. It's not a second full test. If the client remediated by rebuilding half the environment, that's a new engagement.

Can two testers cut the time in half?

Not in half, but it helps when the scope splits cleanly. Two testers on one external range mostly get in each other's way. Two testers where one takes the web application and the other takes the network is genuine parallelism. Ask how the work divides before you assume more people means fewer days.

How often should a client repeat it?

Annually is the common cadence, plus after any significant change to the environment. PCI DSS v4.0.1 requires penetration testing at least once every 12 months and after significant infrastructure or application changes. Other frameworks are less explicit, but auditors have converged on the same rhythm.

Set the date, then work backward

The honest answer to how long a penetration test takes is that testing is days and delivery is weeks. Your client only experiences the weeks.

So sell the calendar, not the testing window. Tell them four to six weeks, explain the five stages, and get the scoping questionnaire back before you promise anything. You'll be right most of the time and early some of the time, which is a much better position than the reverse.

If you want the scoping questions in a format a client can actually answer, our white-labeled pentesting program includes them, and you can see what the deliverable looks like in the pentest report template before you sell one. When the scope is settled, get a pentest quote and we'll put a real date on it.