How to Prepare for a Penetration Test

Preparing for a penetration test takes about an hour of real work: agree on the scope in writing, name a point of contact, confirm your backups are current, and then run your network exactly the way you normally do. That’s the whole job. If you’ve been putting off a test because it sounds like a project, this guide should be a relief. It’s written for the business owner or office manager coordinating a test, not the IT person executing one, and it covers what actually needs doing, what the tester needs from you, and the one thing you should deliberately not do.

The whole checklist

Here’s everything, up front:

Agree on scope, timing, and authorization, in writing.
Name a point of contact and an emergency contact.
Tell the few people who need to know.
Confirm your backups are current.
Loop in third parties where required, like a hosting provider.
Change nothing else. Run the business as usual.

Everything below is the detail behind those six lines.

Get the scope and authorization in writing

Before any testing starts, two documents matter. The scope says what’s being tested: your internet-facing systems, your internal network, a web application, your people, or some combination. The authorization says you approve the testing, when it happens, and under what rules. Together they’re often called the rules of engagement, and no professional will start without them. This is the industry standard, not caution on our part; NIST’s testing guide, SP 800-115, builds the whole process on a planning phase for exactly this reason.

This paperwork protects you as much as the tester. It’s the difference between authorized testing and someone poking at your network with no agreement about what happens if something breaks. If a vendor is casual about it, that tells you something; it’s one of the checks in our guide to choosing a penetration testing company.

One common wrinkle: if some of your systems live with a third party, a hosting provider or a cloud platform, their terms may require notice before testing. That’s a scoping-call question, and sorting it takes minutes when it’s handled up front.

Pick the window and name your people

Testing gets scheduled, not sprung on you. Most businesses pick an ordinary work period, because the point is to see the environment as it really runs; a quiet week works fine too if that lowers the stress. What matters more is people:

A point of contact. One person who can answer questions during the engagement, usually whoever runs your IT, in-house or at your MSP.
An emergency contact. Someone reachable by phone if the tester finds something that can’t wait for the report. You’ll probably never get that call, but the number needs to exist before testing starts, not during.

On telling your staff: tell the people who need to know and skip a company-wide announcement. If phishing is part of the scope, keep the circle genuinely small. A team that’s been warned to expect a suspicious email will pass the test and tell you nothing.

Check your backups

Have current, working backups before testing starts. Not because we expect to break anything, careful manual testing is quiet by design, but because this is exactly the kind of activity a professional plans around. It’s the same reason you wear a seatbelt on an uneventful drive. And frankly, if checking reveals that your backups aren’t current or haven’t been test-restored in a year, the penetration test has already found something, free of charge.

Don’t clean up for us

This is the counterintuitive one. Some businesses treat a penetration test like a house showing: patch everything the weekend before, disable the old accounts, tighten the firewall, then present the polished version. We understand the instinct, and it’s the one piece of preparation that works against you.

The test is for you. You’re paying to learn where a business that runs like yours, on an ordinary Tuesday, is exposed. If you stage the environment, you get a report about a network you don’t actually operate, and the real one goes back to normal the week after. So: if you already know about a problem, by all means fix it now, that’s just progress. But don’t go hunting for things to hide. There’s no grade, and nobody is judging your IT team. The most common findings are the same boring items in nearly every small business we see, and finding them is the entire point.

What we need from you, by test type

The honest answer for most engagements is: almost nothing.

External testing: essentially nothing beyond the signed scope. We test from the internet, the way an outsider would.
Internal testing: a way in, usually a small device we ship that plugs into your network, or a remote connection your IT sets up. Ten minutes of someone’s time.
Web application testing: test accounts, typically two per role, so we can check whether one user can reach another’s data.
Wireless assessment: someone to expect us, since checking your Wi-Fi means being physically near the building.

What happens once testing starts

Mostly, nothing you’ll notice. Testing runs during the agreed window, your contact might field a question or two, and anything urgent triggers a call rather than a surprise in the report. A typical small-business engagement runs one to two weeks from scoping to report; the full schedule is in how long a penetration test takes. Then comes the part that matters: a plain-English, prioritized report, and the work described in what to do after a penetration test.

Frequently asked questions

Will a penetration test take down my network?

It’s very unlikely. Careful manual testing is deliberately quiet, and anything with a real chance of disruption gets discussed and scheduled with you before it happens. That’s also why you name an emergency contact and keep backups current: not because trouble is expected, but because professionals plan for it anyway.

Should I tell my staff about the penetration test?

Tell the people who need to know: whoever runs your IT, and anyone who would panic at unusual activity. If phishing is in scope, keep the circle as small as you can, because a warned team tells you nothing about how the training is working. The point is a fair read, not a trap.

Should I fix known issues before the test?

If you already know about a problem, fix it now rather than waiting for us to confirm it. But don’t go hunting for things to patch just to look better on the report. The test is for you, and the most useful result describes the environment you actually run on an ordinary Tuesday.

What happens if you find something serious during the test?

You hear about it right away, directly, not three weeks later in the report. Critical findings get a phone call, a plain explanation of what we found and what it means, and enough detail for your IT to act immediately. Everything else lands in the prioritized report.

Preparing for a penetration test, the short version

Scope and authorization in writing, a contact and an emergency number, current backups, third parties notified where needed, and then business as usual. That’s how to prepare for a penetration test, and none of it should take more than an hour. The scoping conversation handles most of it for you, and it’s also where the fixed quote comes from; our pricing page shows the starting points. Tell us a little about your business and what’s prompting the test, and we’ll take it from there. Request a quote.