What to Do After a Penetration Test

After a penetration test, do four things in order: read the summary with whoever runs your IT, work the fix list from the top down, have the fixes retested, and file the attestation letter where your insurer or clients can see it. Do those four and the test has done its job. Skip them and you’ve bought an expensive document. This guide is for the business owner or manager holding a fresh report and wondering what happens next, and it covers the order of operations, who does what, and the paperwork that turns a finished test into something you can show people.

Read the summary first, together

Start with the executive summary, not page one. A good report is written in layers: a summary in plain English for you, and technical detail with evidence for your IT team. Read your layer, then sit down with whoever runs your IT, in-house or your MSP, and walk through the findings together. Most testers will do a review call, and it’s worth taking; a finding explained out loud, with the chance to ask “so what could someone actually do with this,” sticks better than a PDF.

If the report doesn’t have a readable summary, or the findings arrive as a few hundred pages of raw scanner output, that’s a problem with the report, not with you. Our guide to what a penetration test report should look like shows what you should have received.

One small housekeeping item while you’re at it: if any test accounts or temporary access were created for the engagement, confirm they’ve been removed. A good tester cleans up after themselves, and it takes one question to verify.

Fix in the report’s order, not the scanner’s

A well-built report ranks findings by what an attacker could actually do with them, and that order is the one to work. It’s often different from the order a severity score would give you. A “medium” finding that chains with another “medium” to reach your finances can matter more than a scary-labeled item on a system that touches nothing. The report should have done this triage for you; trust it over the raw labels.

Resist two temptations. First, don’t cherry-pick the easy items to make the list shrink fast. Progress on paper isn’t the same as the door being closed. Second, don’t panic over the count. Every environment produces findings, and most of them are the same boring items with well-understood fixes. Ten findings with three that matter is a normal, healthy result.

Give every finding an owner and a date

A fix list without names and dates is a wish list, so turn the report into a short plan: each finding gets a person responsible and a target date. Your IT team or MSP almost always does the actual fixing, and that division of labor is healthy. We test, they fix, we verify. Everyone stays honest, nobody grades their own work.

For pacing, a reasonable default: critical items in days, high-priority items in weeks, the rest within the quarter. If the report groups fixes sensibly, some items collapse together; enforcing multi-factor authentication, for instance, often closes several findings at once. The prioritization logic in the CIS Controls is a useful sanity check here: basic hygiene first, exotic hardening later. And if the test was driven by an insurance renewal or a client contract, put that date on the wall and work backward from it, leaving room for the retest.

Get the retest

This is the step most businesses skip, and it’s the one that turns “we found problems” into “we fixed them, and someone independent verified it.” A retest re-checks the specific findings you remediated and confirms they’re actually closed, because fixes fail quietly more often than people expect: the patch that didn’t take, the setting reverted by a later change, the second server nobody remembered.

With us the retest is included in every tier, not sold back as a second engagement, and the updated results give you the sentence that matters: tested, fixed, retested, dated. That’s the sentence insurers and clients want, and standard testing methodology treats verification as part of the engagement, not an extra; NIST SP 800-115 folds it into the process for exactly this reason. If you’re comparing vendors, whether the retest costs extra is one of the five questions worth asking before you sign.

Put the paperwork to work

The test produced two kinds of paper, and they have different jobs.

The full report stays home. It’s a map of your weak points, with evidence. Your IT team works from it and it lives somewhere access-controlled. Don’t email it to third parties, even friendly ones.

The summary or attestation letter travels. This is the shareable piece: what was tested, when, by whom, and where things stand after remediation. It answers your cyber insurance questionnaire, satisfies the client security review, and goes in the compliance file. If insurance was the trigger, our cyber insurance readiness page walks through how the attestation maps to what carriers ask.

Send the retested version, not the day-one version. “We were tested and fixed what mattered” is a much better letter than “we were tested.”

Book the next one before you forget

A penetration test is a snapshot, and it ages in two ways: your environment changes, and the world keeps finding new flaws in software you already run. The standard rhythm is a test every twelve months, or after a significant change like a new office, a cloud migration, or a network rebuild. The easiest time to schedule the next one is now, while it’s on your mind and the renewal date is known. Twelve months out, put it on the calendar; the pricing won’t surprise you next year either.

Frequently asked questions

How long do we have to fix penetration test findings?

There’s no universal deadline, but a reasonable rhythm is days for the critical items, weeks for the high-priority ones, and a quarter for the rest. If the test was for cyber insurance or a client, their renewal or contract date is your real deadline, so work backward from it and leave room for the retest.

Is the retest included or does it cost extra?

With us it’s included in every tier. Elsewhere it varies, and it’s worth asking before you sign, because a test without a retest leaves you unable to prove the problems were actually fixed. The retest re-checks the specific findings you remediated and updates the record to show they’re closed.

Who should see the penetration test report?

The full report stays with you and whoever fixes the findings, because it’s effectively a map of your weak points. Insurers, clients, and auditors get the executive summary or an attestation letter instead. Those are written to be shared and say what was tested and where things stand, without handing anyone a road map.

Does the company that ran the test also fix the findings?

Usually your own IT team or MSP does the fixing, and that’s healthy: the tester stays independent, so the retest is a genuine check rather than someone grading their own work. What you should expect from the tester is a clear enough fix list that your IT can act on it without translation, plus answers when questions come up.