Penetration Testing Reference Guide

10 Things Your Testing VendorWishes You Knew

Ten candid things we wish more clients knew before, during, and after a penetration test.

Penetration tester field notes showing objectives, scope, budget, constraints, attack paths, testing activity, and useful findings.

One Thing First

Your Tester Is on Your Side.

A penetration test is adversarial by design, but the relationship between you and your tester should not be. You know your environment, business, constraints, and concerns. Your tester brings an attacker's perspective and experience identifying where meaningful weaknesses tend to hide.

Neither side needs to do the other's job. Better information simply lets both sides make better decisions about where finite testing time should be spent.

You do not get bonus points for defeating your penetration tester. You are both on the same team.

Tell Us What You're Actually Trying to Learn.

“We need an external and internal penetration test.” Okay. But why?

What worries you? What prompted the assessment? What question do you hope you can answer when it is finished? A customer requirement, ransomware concern, product launch, acquisition, previous incident, tenant-isolation concern, or annual testing requirement can all lead to different priorities.

Those are not administrative details. They help determine where testing time should go. An asset count tells us how large something is. Your objective tells us what matters.

Bring the problem. You do not need to know exactly what kind of penetration test you need before talking to a provider. Helping translate business concerns and technical environments into an appropriate testing scope is part of the job.

Time Is Your Tester's Enemy. It Isn't Your Attacker's.

Your attacker does not have a testing window. Your penetration tester does.

An attacker can spend weeks researching an organization, wait for an opportunity, return later, change tactics, and keep trying. A penetration tester might have five days.

That does not mean reconnaissance should be skipped or that a tester should magically begin with privileged access. Discovery may be exactly what you want evaluated. It means every decision about what the tester must discover, what information is withheld, how much is placed in scope, and what access is provided consumes part of a finite resource.

Make those tradeoffs deliberately. If you want to know whether an attacker could discover a system, let the tester discover it. If you already know where it is and want to understand whether it can be compromised, spending hours rediscovering it may not be the best use of the time you bought.

Your Budget Isn't a Target. It's a Constraint We Can Design Around.

We understand why organizations hesitate to disclose a budget. If you tell a vendor you have $20,000 available, it is reasonable to wonder whether a $20,000 proposal will magically appear.

But penetration testing scope can often be adjusted significantly. If you have $5,000 available, that does not automatically mean meaningful testing is impossible. It may mean prioritizing the most important application, attack surface, role, tenant boundary, or testing activity instead of spreading limited time too thinly.

If more resources are available, additional depth or coverage may meaningfully improve the assessment. That does not mean inventing work simply to consume the budget.

Your budget isn't a target for us to hit. It's a constraint we can design around.

More Scope Does Not Automatically Mean a Better Test.

“Everything” is a scope. It is not always a good one.

Twenty applications tested in five days may look like more coverage on a proposal, but it does not create more hours in the week. Manual investigation, authorization testing, business-logic testing, exploitation, attack chaining, and evidence collection all take time.

Sometimes broad coverage really is the objective. Other times, testing fewer systems deeply provides substantially more useful information than touching everything superficially. The right balance depends on what you are trying to learn.

Scope and testing time have to make sense together. If you are still separating hands-on testing from automated coverage, our Penetration Test vs. Vulnerability Scan guide explains the difference.

“Black Box” Doesn't Automatically Mean More Realistic.

“We want a black-box test. We don't want to give you anything.”

We hear this a lot, and the logic makes sense: a real attacker would not receive architecture diagrams, test accounts, or a list of known issues.

A real attacker also is not billing you for a five-day engagement.

Black-box testing, where little or no information is provided initially, is useful when discovery itself is part of the question. Gray-box testing provides selected information or access so more time can be spent evaluating particular attack paths. White-box testing provides substantial information to maximize coverage or depth. None is inherently better. They answer different questions.

The same principle applies to known vulnerabilities and previous assessment information. If rediscovery is not something you are intentionally evaluating, making the tester find something you already know may simply consume time that could have been spent finding something you do not.

You do not get bonus points for making your tester rediscover something you already know.

Tell Us About the Weird Stuff. Seriously.

Legacy systems. Fragile applications. Strange authentication flows. Undocumented dependencies. Unusual integrations. Third-party services. The server nobody wants to reboot because nobody is completely sure it will come back.

We want to know.

Knowing that something is unusual or fragile does not automatically mean it cannot be tested. It lets the tester understand the environment, adjust techniques where appropriate, coordinate higher-risk activity, and avoid learning about an operational constraint the hard way.

Third-party boundaries belong in this conversation too. Hosting providers, Software as a Service (SaaS) platforms, managed infrastructure, and shared services may affect authorization and what can safely be tested. Sorting that out before testing starts is much easier than discovering it halfway through the engagement.

Weird is useful information. Surprising the penetration tester with your architecture usually is not nearly as useful as it sounds.

“It's Out of Scope” Doesn't Mean It Doesn't Matter.

If something is out of scope, we do not test it. Period.

But we may ask why.

There are plenty of legitimate reasons to exclude a system. It may belong to a third party, present an unacceptable operational risk, be covered by another assessment, be scheduled for replacement, or simply fall outside the available time and budget.

We once encountered an internal assessment where nearly the entire environment was in scope except for the domain controllers. We respected the boundary, as any tester should. But the exclusion itself deserved a conversation. Domain controllers are often central to the attack paths an internal penetration test is intended to evaluate.

Was the requirement “do not disrupt the domain controllers,” or was it “do not evaluate whether an attacker could compromise the domain controllers”? Those are very different requirements.

An attacker does not stop because an asset was not included in your statement of work. Your tester does.

“Don't disrupt it” and “don't test it” are not the same thing. Every important scope exclusion should have a reason, and you should understand what security question you are choosing not to answer.

Not Every Penetration Test Needs to Happen After Hours.

We understand the instinct. You are hiring someone to attack your systems, so doing it while employees and customers are using them can sound unnecessarily risky.

But normal penetration-testing activity should not inherently be disruptive. In many cases, testing during normal business hours means client contacts, system owners, and the tester are available at the same time if a question or unexpected condition comes up. Some application behavior, integrations, and business processes may also be easier to evaluate while the environment is operating normally.

Specific higher-risk activities may absolutely deserve a maintenance window or explicit coordination. That is different from forcing an entire assessment into nights and weekends because all penetration testing is assumed to be dangerous.

Schedule risky activities around the environment. Don't schedule the entire penetration test around the assumption that all testing is risky.

We Know When You're Doing It for the Checkbox. That's Okay.

Customer requirement? Annual requirement? Cyber insurance? Procurement checkbox?

That's fine. Really.

The value of a penetration test is not reduced because someone required you to have one. The missed opportunity is spending the money solely to obtain a report proving that testing occurred.

If you have to do the assessment anyway, tell the tester what requirement you need to satisfy. Then tell them what you would actually like to learn while they are there. A required external penetration test can still prioritize the systems or scenarios that matter most to your organization.

The value of a penetration test isn't reduced because someone required you to have one. It gets reduced when satisfying the requirement becomes the only objective.

It's Okay If Your Environment Is a Mess.

People apologize to their penetration testers more often than you might expect.

Old systems. Flat networks. Shared passwords. Excessive privileges. Legacy applications. Missing documentation. Security debt inherited from people who left years ago. You do not need to make the environment presentable for us first.

We are not there to grade your IT department. We are there to help you understand risk.

You may already know that fifty things in your environment are not ideal. One of the useful outcomes of a penetration test is learning which of those things actually create meaningful attack paths, what impact can be demonstrated, and what deserves attention first.

If everything were perfect, you probably wouldn't need us.

Bring What You Know

We'll Work Through the Rest.

You do not need to arrive with a perfectly defined scope, a spotless environment, or all the answers. Tell your testing provider what concerns you, what you are working with, what constraints exist, what you can spend, and what you hope to learn.

A good penetration testing provider should help you work through the rest.

Scoping a Security Assessment Start a Conversation

Our scoping resources include an online scoping process as well as downloadable questionnaires for organizations that prefer to gather the information internally first.

Contact Us