What to Expect During Your First Penetration Test

Most organizations that reach out to MainNerve about a penetration test have been thinking about it for a while. Sometimes months. They know they need one because an insurance carrier asked for it, a client required it, or they’ve been reading about breaches in their industry and decided it’s time to find out where they stand.

But something keeps stalling the decision. And when we ask what that is, the answer is almost always some version of the same thing: they’re not sure what the process looks like. Will it disrupt operations? Will employees know it’s happening? Will it take down systems? How much of their time will it require?

The answer to most of those questions is much less than you’re probably imagining. A penetration test is a structured, professional engagement with a defined scope, a clear timeline, and very specific boundaries. For most small and mid-sized businesses, it requires minimal involvement from your team during the testing window itself, and the work that does fall on your side is straightforward and front-loaded into the scoping process.

Here’s what happens, from the first conversation through the final report.

Step One: The Scoping Conversation

Before any testing happens, we have a conversation about your environment. This is where we figure out what the test should cover. This includes which systems are in scope, what’s off-limits, what you’re most concerned about, and whether specific compliance requirements shape what the test needs to include.

This conversation is more important than most first-time buyers realize. Scope determines the cost, the timeline, and the usefulness of the results. A well-scoped test tells you something meaningful about your actual risk exposure. A poorly scoped test produces findings that are hard to act on.

What you’ll need to bring to this conversation isn’t complicated. For an external test, you need to know what IP addresses or domains you want tested. Essentially, what’s internet-facing and under your control. For an internal test, you need a general sense of how many internal devices are in scope and how your network is structured. If you don’t know these things precisely, that’s fine; we can help you work through it. What matters is that both sides understand what the test is supposed to cover before the engagement begins.

We’ll also ask about your budget during this conversation, because the reason isn’t to charge you the maximum you can spend. It’s to figure out the best test we can design within what you have available. If your budget and your environment don’t line up perfectly, there are usually ways to structure the engagement, like sampling specific device types, prioritizing the highest-risk systems, or phasing the work across multiple engagements, that deliver real value without blowing past what you can afford.

Once scope is agreed on, you’ll sign a master service agreement and a proposal.

Step Two: The Kickoff

Before testing begins, there’s typically a brief kickoff call or communication to confirm the testing window, verify contact information, and ensure your IT team knows what’s happening. That last piece is more important than it sounds.

Your IT staff, or whoever monitors your network, needs to know a test is scheduled. If they see unusual traffic patterns or login attempts during the testing window and don’t know a test is underway, there’s a real chance they’ll treat it as an active incident and begin incident response procedures. That creates unnecessary chaos and may end the test prematurely. Letting the right people know is a five-minute task that prevents a much larger headache.

You don’t need to brief your entire staff. The people who need to know are whoever would respond to unusual network activity, such as your IT person, your managed service provider, or anyone monitoring security alerts. The rest of your organization can go about their day without any awareness that a test is happening.

Not sure where to start with scoping? That’s what the first conversation is for. MainNerve will walk you through it at no charge. Reach out, and we’ll take it from there.

Step Three: The Testing Window

This is the part that most people worry about, and where reality tends to be much calmer than anticipation.

During the testing window, our testers are actively working against the in-scope systems. For an external test, which runs entirely from outside your network, you’ll need to confirm that the IPs and domains we’re testing are correct and allow-list us (blog about allow-listing), unless you specifically need to test how well your firewall blocks us. For an internal test, we typically need access to your internal network, which usually means remote access credentials or a physical connection point, depending on the engagement type.

What your team experiences during the testing window depends on the type of test and how your systems are configured. For most small and mid-sized business environments, day-to-day operations continue without noticeable disruption. We’re trying to find vulnerabilities in them, but we attempt to keep the risk of taking your systems down to a minimum. In most engagements, employees go about their normal work without realizing that anything unusual is happening.

That said, we recommend testing during business hours for internal engagements. Your network behaves differently when people are using it; certain attack techniques require active network traffic to test accurately, and if something unexpected does happen during the test, you want your team available to address it, not discover it the following morning. After-hours testing feels safer but often yields less accurate results and removes the safety net of having people present.

The testing window typically runs from a day or two to a few weeks, depending on scope. During that time, we’re the ones doing the work. Your team’s involvement is minimal, mostly being available if we need to confirm something or flag an unexpected issue.

 What We’re Doing During the Test

Understanding what testers are doing during the window helps demystify the process considerably.

The testing process starts with reconnaissance, which involves gathering information about your environment that’s publicly available or discoverable from an attacker’s perspective. For an external test, this includes what domains and IP addresses are associated with your organization, what services are running on those systems, and what information is visible from outside your network. An internal test includes mapping the internal network, identifying devices and services, and understanding how systems relate to each other.

From there, testers identify potential vulnerabilities, like misconfigurations, outdated software, weak authentication, overly permissive access controls, and other conditions that an attacker could exploit. This is where automated tools play a supporting role, but the work that matters is manual. Automated tools find what they’re programmed to look for. Human testers ask what a real attacker would do with what they’ve found, and then they try it.

The exploitation phase is where a penetration test becomes something meaningfully different from a vulnerability scan. Rather than simply identifying that a vulnerability exists, testers attempt to exploit it to demonstrate how it can be leveraged to gain unauthorized access, escalate privileges, move laterally through the network, or access sensitive data. This is the evidence that makes findings credible and actionable rather than theoretical.

After exploitation, testers document what they found, how they found it, and what they were able to do with it. The cleanup phase follows, which includes removing any tools or artifacts placed on systems during the test and restoring configurations to their pre-test state.

Step Four: The Report

The report is where the test becomes useful to your organization, and it’s worth understanding what a good report contains versus what a mediocre one looks like.

A useful penetration test report has two distinct parts. The first part, the executive summary, is written for non-technical stakeholders, such as business owners, leadership, board members, or whoever needs to understand the overall risk picture without wading through technical details. It covers what was tested, the most significant findings, and the high-level business risk those findings represent. If you need to share the results with a cyber insurance carrier, a client, or your leadership team, this is the section that communicates what they need to know.

The second part, the technical findings section, is written for the people who are going to fix things, like your IT staff, your managed service provider, or whoever handles remediation. Each finding includes a description of the vulnerability, the evidence that it was exploited or could be exploited, the severity rating, and specific remediation guidance. The goal is for whoever reads a finding to know exactly what it is, why it matters, and what to do about it, without needing to call us to interpret the report.

At MainNerve, severity ratings reflect three factors that we can verify during the test: how exposed the vulnerable condition is to an attacker, how difficult it is to exploit, and the technical consequences if exploitation succeeds. The practical implication is that our severity ratings are based on what we observed, not on assumptions about your organization’s detection capabilities or internal risk tolerance that we couldn’t reliably know.

Want to see what a MainNerve report looks like before you commit? We’re happy to walk you through a sample. Get in touch, and we’ll set that up.

Step Five: What Happens After the Report

Receiving the report is not the end of the engagement, or it shouldn’t be. The findings in a penetration test report are only useful if someone acts on them, and the organizations that get the most value out of testing are the ones that treat the report as a starting point rather than a deliverable to file away.

The first thing to do with a new report is prioritize. Not every finding carries equal weight, and trying to fix everything simultaneously is rarely practical. High and critical findings, particularly those involving external exposure or direct paths to sensitive data, typically warrant immediate attention. Medium findings are addressed in the near term. Low and informational findings get scheduled into normal IT work cycles.

If a finding is unclear, ask. A good testing firm will explain their findings in plain language and help you understand what remediation looks like in your specific environment. At MainNerve, that post-report conversation is part of the engagement, not an additional service you have to pay for separately.

Many organizations also ask about retesting after remediation is complete. Retesting verifies that the fixes your team implemented closed the vulnerabilities identified by the test, rather than addressing symptoms without resolving the underlying condition. For compliance purposes, documented retesting is often required. For peace of mind, it answers the question that naturally follows remediation: did we actually fix it?

The Questions We Get Asked Most Before a First Test

Will the test take my systems down?

Almost never, and not intentionally. We scope engagements specifically to avoid that outcome, and our testers work carefully around systems that carry elevated disruption risk. In more than two decades of testing, production outages during engagements are rare, and when they do occur, they’re typically brief and quickly resolved.

Do I need to tell my employees?

You need to tell the right people, the ones who monitor your network or would respond to unusual activity. Your broader staff doesn’t need to know and in most cases shouldn’t, because the test is more realistic when it happens under normal operating conditions.

What if we fail?

There’s no such thing as failing a penetration test. The test finds what it finds. Organizations with strong security postures get reports with fewer and lower-severity findings. Organizations with gaps get reports that tell them where those gaps are, which is exactly the information they need. Finding vulnerabilities is the purpose of the test, not a judgment on the organization.

How long until we get the report?

That varies by scope and firm. At MainNerve, we work to deliver reports promptly after the testing window closes. We’ll give you a specific timeline during scoping so you know what to expect and can plan around it, especially if you have a compliance deadline or an insurance renewal that the report needs to feed into.

Do we need to do anything to prepare?

Knowing your IP addresses for an external test and having a point of contact available during the testing window covers most of it. For an internal test, we’ll work through any additional access requirements during the kick-off call. The prep work is lighter than most first-time buyers expect.

The Simplest Way to Think About It

A penetration test is a professional service with a defined beginning, middle, and end. It doesn’t require your team to be on high alert, doesn’t disrupt your operations in any meaningful way, and produces a report that tells you something true and actionable about the security of your environment. The anxiety that builds up around it in the months before scheduling it is almost always larger than the experience itself.

If you’ve been putting off a first penetration test because the process felt unclear, we hope this makes it clearer. And if you have questions we haven’t answered here, a conversation costs nothing. MainNerve has been walking organizations through their first penetration tests for over 20 years. We’re glad to walk you through yours. Set up your free consultation today.