What Happens During a Penetration Test and How to Read the Report

Most business owners agree to a penetration test without a clear picture of what they just bought. You sign the proposal, a date goes on the calendar, and a few weeks later a document lands in your inbox with a color coded severity chart and forty pages of technical detail. If nobody on your staff works in IT, that document can sit unread for months. We have seen it happen at companies in McKinney and Plano that did everything right up to the point of actually using what they paid for.

That is an expensive place to end up, so this post walks through the whole thing in plain English. What a penetration test really is, what happens during each stage, what the report is trying to tell you, and how to decide what to fix first when the list is longer than your budget. No technical background required. By the end you should be able to sit in a debrief call, ask useful questions, and walk out with a plan instead of a PDF.

What a Penetration Test Actually Is

A penetration test, usually shortened to pen test, is a hired expert trying to break into your systems on purpose, with your written permission, so that gaps get found before a real attacker finds them. That is the entire idea. Someone with the same skills as a criminal attacker spends a defined number of days attempting to get into your network, your applications, or your accounts, and then writes down exactly how far they got and how they did it.

The important word is trying. A pen test is not a scan. A vulnerability scan is automated software that checks your systems against a list of known problems and prints what it finds. It is fast, cheap, and useful, and it is not the same thing. A scan tells you a door is unlocked. A pen test tells you that the unlocked door leads to a hallway, that the hallway reaches the accounting server, and that the accounting server had a password saved in a text file. We wrote a full comparison in our guide on vulnerability scanning versus penetration testing if you want the longer version, but the short answer is that you want both, and they answer different questions.

The business reason this matters is chaining. Individually, most findings look minor. An out of date piece of software here, a weak password policy there, a file share that was opened for a project in 2023 and never closed. A scanner reports those three things as three separate medium risk items. A human tester connects them into a path that ends with your entire customer database. Your insurance carrier, your largest client, and any regulator who ever asks will care about the path, not the individual items.

The Weeks Before Anyone Touches Your Network

The first stage is scoping, and it happens before any testing starts. Scoping is the conversation where you and the testing firm decide what is in bounds, what is out of bounds, and what success looks like. It is the single most important part of the engagement, and it is also the part most likely to be rushed.

Scope means naming the things being tested. Your external network, meaning everything of yours that faces the public internet. Your internal network, meaning what an attacker could reach after getting a foothold inside. A specific web application. A mobile app. Your cloud tenant. Your people, through social engineering. Each one is a different test with different pricing and different findings, and a proposal that says only network penetration testing without saying which network is not specific enough to sign.

You also agree on the rules. Whether testers may attempt denial of service, meaning deliberately knocking something offline, which most businesses exclude. Whether testing happens during business hours or overnight. Who at your company knows the test is happening, because if your whole team knows, you are testing your systems but not your detection. Whether the testers start with credentials, meaning a normal employee login, or start from zero knowledge the way an outsider would.

That last decision changes the results more than anything else. Starting with a standard employee account is not cheating. It simulates the far more common real world scenario, which is an attacker who already phished one set of credentials and now wants to know how much damage that one account allows. If you have ever wondered what your exposure looks like after a single employee falls for a fake login page, that is the test to ask for. Our post on what to do in the first 24 hours after an attack covers the other side of that same scenario.

Finally, you sign an authorization letter. This is the document that makes the activity legal. Keep a copy.

What Testers Do During the Test Window

The active testing window for a small or midsize business is usually one to two weeks. Here is what fills those days.

The first phase is reconnaissance, which is information gathering without touching anything aggressively. Testers map what you have exposed to the internet, find employee names and email formats from public sources, look for credentials from your company already circulating in breach data, and identify the software versions you are running. If your team's email addresses and a batch of old passwords are already for sale, an attacker starts the game several moves ahead. This is exactly the exposure that ongoing dark web monitoring is meant to catch between tests.

The second phase is scanning and enumeration, where testers systematically identify live systems, open services, and likely weaknesses. This is the part that overlaps with automated tooling, and it is where a good platform earns its keep. Our own CyberSphere platform handles continuous vulnerability management so that the human testing time gets spent on judgment rather than on rediscovering the same expired certificate every quarter.

The third phase is exploitation, which is the actual attempt to get in. This is where a tester takes a theoretical weakness and proves it is real. Proof matters enormously to you as a buyer. Anyone can hand you a list of theoretical risks. A useful report says here is the screenshot of your payroll folder, taken at 2:14 on Tuesday, reached from an account with no special privileges.

The fourth phase is post exploitation, meaning what happens after the first success. Can the tester move from the machine they landed on to other machines, a step called lateral movement. Can they escalate from a normal user to an administrator. Can they reach the data that would actually hurt you if it left the building. Can they establish a foothold that survives a reboot. This phase is the one that translates most directly into business risk, because it is the difference between one compromised laptop and a company wide shutdown.

Throughout all of it, the testers are also, whether you asked for it or not, testing whether anyone notices. If your monitoring is only staffed Monday through Friday during office hours, a test that runs on a Saturday evening produces a quiet result that should worry you. That gap is why we pair testing with a genuinely staffed 24/7 managed SOC, meaning a security operations center with real analysts watching your environment around the clock rather than an alert queue that gets reviewed the next business morning.

The Report Is the Product

You are not really buying the testing. You are buying the report. The testing is how the report gets written, and a report you cannot act on is a receipt for nothing.

A well built report has three layers, and they are written for three different readers. The executive summary is for you and your board. It should be readable in five minutes, contain no unexplained jargon, and answer one question, which is whether the business is in acceptable shape or not, and why. If your executive summary is a wall of tool output, that is a warning sign about the whole engagement.

The findings section is the detailed body. Each finding should state what was found, where, how severe it is, how the tester proved it, and what to do about it. Specific remediation guidance matters here. Update to a supported version is not guidance. Upgrade the firewall at the McKinney office to firmware version such and such, which closes this specific issue, is guidance your IT provider can act on without a follow up call.

The methodology and evidence section is what you hand to an auditor, an insurance underwriter, or a client doing vendor due diligence on you. It is the proof that a real test happened on real systems on real dates. Many businesses first buy a pen test precisely because a customer contract or an insurance renewal demanded one. If that is your situation, our overview of what cyber insurance companies require from North Texas businesses explains how the evidence gets used, and our compliance services page covers the frameworks that ask for testing by name.

Ask for a draft report and a live debrief. The debrief call is where you get to ask what does this actually mean for us, and a good testing firm expects that question rather than resenting it.

How to Read a Finding Without an IT Background

Every finding carries a severity rating, usually critical, high, medium, low, and informational. Those ratings are useful but they are generic. They describe how dangerous the issue is in the abstract, not how dangerous it is to your specific company. Translating from one to the other is your job as the business owner, and it is not as hard as it sounds.

For each high or critical finding, ask three questions. First, what would an attacker be able to reach if they used this, and would that thing shut down operations or expose customer records. Second, how hard is this to exploit, meaning does it require deep skill and physical access, or is there public tooling that automates it. Third, would we know if someone used it, meaning does anything in our environment produce an alert.

Those three answers reorder the list quickly. A critical rated issue on a test server with no real data and heavy monitoring may genuinely wait. A medium rated issue on the file server that holds every client contract, exploitable with published tooling, that nobody would notice, is the thing to fix on Monday morning. Severity is a starting point for the conversation, not the end of it.

Be equally careful with the informational findings, which people skip because they look harmless. Informational items are often the small pieces that a tester chained together to reach something serious. If the report describes an attack path, trace it, and note every step in that path regardless of its individual rating.

What to Fix First When You Cannot Fix Everything

Almost no company remediates every finding. That is normal and it is fine, provided the decisions are deliberate and written down.

Sort the work into three buckets. The first bucket is anything that gives an outsider a direct path to sensitive data or to stopping operations. Fix those immediately, and many of them are configuration changes rather than purchases, which means they cost time rather than money. The second bucket is anything that meaningfully shortens an attacker's path even if it is not the whole path, which includes password policy, administrative account hygiene, network segmentation, and closing the file shares nobody uses. The third bucket is everything else, which gets scheduled into normal maintenance.

Then handle what you are not fixing. For each accepted risk, write down what it is, why you are accepting it, what compensating control reduces it in the meantime, and when you will revisit. That document is genuinely valuable. It demonstrates to an insurer, an auditor, or a client that your unresolved items are decisions rather than oversights, and it prevents the same finding from surprising you next year.

Along the way, notice which findings keep pointing at the same weakness. If several items trace back to email, your gap is email security rather than five unrelated problems. If several trace back to recovery capability, the honest answer is tested backups rather than another tool. If your current IT provider is handling uptime but nobody owns security outcomes, that is a structural gap that a co-managed arrangement is designed to fill.

Why One Test a Year Is Not a Security Program

A penetration test is a photograph, not a video. It describes your environment on the days it ran. Then you onboard a new application, a vendor gets access, someone opens a port for a project, and the photograph goes out of date.

Two habits fix this. The first is retesting. After you remediate, have the tester verify the fixes actually worked, because a meaningful share of remediation does not fully close the issue on the first attempt. Many firms include one retest window in the original engagement, so ask before you sign rather than after. The second habit is continuous coverage between tests, meaning ongoing vulnerability management and monitoring that catches the drift a yearly test would miss entirely. That is the pairing we recommend for most clients across Collin County and the wider DFW area, and it is why our testing work and our monitoring work are built to feed each other.

Cadence depends on your situation. Annually is the common baseline. Move to twice a year or more if you handle regulated data, ship software changes frequently, went through a merger, or had an incident. Test again after any significant infrastructure change, because the change is exactly the thing the last test did not see. If cost is the constraint, our breakdown of what penetration testing costs in 2026 shows where the money actually goes and how scope drives price.

Getting the Most Out of Your Next Test

Three things separate businesses that get value from a pen test from businesses that get a PDF.

They scope for the question they actually have. Not test our security, but rather show us what one phished employee account leads to, or show us whether our customer portal can be reached without logging in. A specific question produces a specific answer you can act on.

They put a name on every finding. An owner and a due date, tracked wherever the business already tracks work. Findings without owners do not get fixed, in companies of every size.

They treat the debrief as the beginning rather than the end. That call should produce a remediation plan and a retest date before it ends.

We do this work for businesses across McKinney, Allen, Plano, Frisco, and the rest of North Texas, and the pattern is consistent. The companies that improve year over year are not the ones with the biggest budgets. They are the ones who read the report, argued about the priorities, and fixed things in a deliberate order.

If you are considering your first penetration test, or you have a report sitting in a folder that nobody has translated into a plan, we are glad to walk through it with you. Start with our free security assessment to get a baseline, browse more owner focused guides on our blog, or reach us directly through our contact page or by phone at 512-518-4408. A short conversation is usually enough to tell you whether a test is the right next step or whether something more basic should come first.