The Vilkas Wire
Stop Buying Clean Reports: How to Prepare for a Pentest That Matters
Oct 14, 2025 · By Ben Rollin
How to Get the Most Out of Your Next Penetration Test
Most companies know they need a penetration test. Far fewer know how to do one right. The result is predictable: a tidy, checkbox report that makes executives feel reassured and leaves the real problems untouched. A year later the same issues bite someone, and everyone wonders how it happened.
The truth is, a pentest done to be easy will fail you when it matters. A pentest done with intention will show you where real risk lives, how your defenses respond, and what to fix first. If you want peace of mind, not a clean PDF, read on.
What a pentest is actually for
A penetration test is not a magic pill. It is a controlled simulation that shows how an attacker could compromise your environment and how your controls detect and respond. That means the test should validate both the gaps and the detection controls.
If your leadership thinks a pentest equals compliance, you will be disappointed. Compliance is a baseline. Real security is about risk reduction. If your goal is only compliance or a nice looking “no critical findings” stamp, you will likely sleep poorly anyway.
The scoping call is where value is won or lost
This is the single most important meeting you will have in the lifecycle of a pentest. Treat it like a board level conversation. Bring data, not just IPs.
What to have ready before the call:
- A clear list of environments. External, internal, cloud, mobile, wireless, APIs, OT or ICS, and any acquired domains or business units.
- An inventory of critical apps and data stores with business owners assigned.
- A list of security controls and monitoring tools in place. If you are running EDR, SIEM, WAF, or SSO, say so and indicate who handles alerts.
- Operational constraints and maintenance windows. If you cannot test during business hours, say so.
- The people who will coordinate during the test. That includes a technical lead and an executive sponsor.
- What success looks like. Is it detection testing, proof of concept exploits, or a full compromise exercise? Be explicit.
Important scoping questions to ask the tester:
- Do you include authenticated testing for web apps and APIs?
- If we give the tester a low privileged AD account, will you use it to test lateral movement and escalation if unauthenticated methods fail?
- How will you handle noisy exploitation attempts against production systems? Will you pause, notify us, or continue to see detection outcomes?
- What reporting format do you deliver and what is included in a remediation roadmap?
- Do you include retesting after remediation? How is that priced? Ideally this is included.
- How will remote internal testing be performed? From a physical appliance or VM? Over VPN? The most ideal scenario (which Vilkas typically does) is a secure physical device or VM within the client environment to be able to test as many scenarios as possible and not limit the attack surface.
- If remote internal testing is chosen, ask how their infrastructure is secured and your data is protected.
Red flags during scoping:
- The tester resists discussion of authenticated testing for key applications or Active Directory or both.
- The tester refuses to simulate common scenarios you asked about, like vishing or developer account compromise.
- The proposal hides hourly estimates or scopes the effort so small you cannot realistically exercise your assets.
If the tester balks at realistic scenarios, they may not have the depth you need.
Examples of smart scopes that actually help
Here are real, pragmatic scopes that produce useful findings.
External wide scope
Everything public facing is in scope. IP blocks, web applications, mail infrastructure, remote access, phishing and vishing. This mirrors what an external attacker sees and removes the artificial safety net of a tiny IP list.
External targeted plus authenticated If your external footprint is small but you have a web application used by customers and staff, include authenticated testing. Attackers do not care if your IP list is short. They will try the web app, the API, and any forgotten endpoints, especially if any web apps allow self-registration.
Internal AD focused If Active Directory is in scope, plan for a layered approach. Start with unauthenticated discovery and exploitation. If a foothold cannot be obtained, the pentester should use low privileged credentials next. Test the realistic compromise scenarios that match your business. What happens if a developer account is compromised? What if help desk credentials are phished? What access can be achieved using an account provided to a consultant for short term guest access? What if an acquired domain is trusted via an AD trust? If the pentester does not propose those types of scenarios, push back.
Operational Technology (OT) or Industrial Control Systems (ICS) adjacency If you have OT or a segmented sensitive environment, include tests from the corporate network and from the network segments established for maintenance or tester access. Test one way trust boundaries and any cross domain trust configurations. Unless the testing firm is very experienced in testing ICS environments, they should stop at validating the boundary as full ICS tests take a specific skill set.
Rant. Because this matters.
I am going to be blunt here because I see it every week. Prospects tell us their MSP handles everything. That same MSP deployed the tech, configured the services, and now signs off that everything is secure. You would not let your carpenter inspect their own work after a remodel. So do not let the vendor who builds your security check their own work and give you a clean bill of health.
We talk to organizations that skimp on scope to save a few thousand dollars and then ask us why we found a path to domain compromise. The scope they bought was designed to return a clean report. It was not designed to find the stuff that matters.
If you want security, you have to treat a pentest like an investment, not a commodity. Some companies spend big money on lunches and trinkets, and put pennies against the thing that will ruin them. You get what you pay for.
Now some reality. Yes, there are glorified scanners that take a Nessus export, run a few scripts, and call it a day. Those testers exist. They give the good ones a bad name. But great pentesters have usually spent a decade learning their craft. They understand Windows, Linux, databases, networking, AD, web application logic, default credentials, obscure appliances and more, and how to chain small weaknesses into a complete compromise. They write playbooks, keep copious notes, and can adapt when an environment throws them something new.
Do your homework. Vet testers on their experience. Look at their conference talks, their training material, the tools they publish, and references from your peers. A high quality tester is an investment that often pays for itself the first time they find a path your systems did not alert on. Don't be afraid to test them on their knowledge or bring a more technical team member into the discovery call to help vet their knowledge and skillset.
Why scenarios beat checklists
Attackers only need one path. Defenders need to close many. If you test in a single narrow way you will end up with a false sense of security.
Wargame scenarios during scoping:
- The sales engineer whose laptop is used for external demos is compromised at a coffee shop. What happens next?
- A customer support rep is phished and loses credentials. Can the attacker reach internal help desk tools or deeper into the network?
- An acquired company is connected via a trust. How easy is it for a domain user in the acquired domain to gain access to the main corporate domain?
- A forgotten admin panel is still accessible on a subdomain. Can that be leveraged for internal access?
- A simulated supply chain compromise relevant to the business.
If your pentest only touches one or two basic vectors, you are paying for theatre, not certainty.
Preparing operationally before a test
Do these things to get the most value from the exercise.
Communicate Tell your SOC leader and key business stakeholders. Let them know to expect activity, but not the exact timeline if you want realistic detection performance. On-call SOC staff should not be made aware of the test to keep monitoring and detections as realistic as possible.
Backups and snapshots Ensure critical systems are backed up and backups tested. A pentester should not cause issues with production, but accidents happen. Be prepared.
Logging and monitoring Confirm logs are flowing and retention is sufficient. If an exploit depends on log data that is not being collected, you will miss important insights.
Authority and escalation Give the tester a path to escalate if they find something critical during working hours. Decide how the tester will notify you if they find a live compromise that threatens operations. Ask the tester their procedure if a high-risk issue is found during external testing. Ideally they will pause testing, notify, and provide a written vulnerability notification. Certain issues like unauthenticated remote code execution ending in internal network access should be fixed as soon as possible.
Define remediation expectations Agree if the engagement includes a remediation retest (it should), and what the timeline looks like. Ideally remediated issues are provided to the pentester and batches and post-remediation testing is completed within 90 days of the end of testing. Fixes without verification are guesses.
During the test: how to work with your pentester
Stay involved. The best outcomes happen when defenders and testers collaborate.
- Keep the technical contact reachable. The pentester may come up with a scenario they need to receive a go-ahead to perform.
- Encourage the pentester to explain their steps if something causes unexpected outages. Transparency matters.
- Use the test as a SOC exercise. If your monitoring catches the simulated attack, celebrate that. Then ask how to make detection better.
If your tester refuses to show you how they got in or to help your team understand detection gaps, that is a signal.
After the test: reports are not the finish line
A PDF with findings is the raw material. The finished product is an action plan that your leadership can understand and your engineers can implement.
A strong final deliverable includes:
- Executive summary that explains business impact in plain language.
- Detailed technical findings with reproducible proof of concept steps.
- A pragmatic remediation roadmap split into short, medium, and long term.
- Detection analysis showing what alerts fired and where improvements are needed.
- An option for a retest or targeted verification.
Your goal is not to collect a backlog of tickets. Your goal is to reduce the probability and impact of a breach.
Value adds you should ask for
When you pick a tester, negotiate these extras when possible:
- A detection maturity review that shows what your alerts missed and why.
- A remediation retest included in the fixed cost for high risk findings.
- Short workshops with your SOC or engineering teams to explain findings and fixes.
- A prioritized roadmap that maps to business units and compliance needs.
- Optional social engineering tests such as phishing or vishing with consent and careful planning.
These add real operational value beyond the vulnerability list.
How to pick a good pentesting partner
Look for evidence of skill and thoughtfulness.
What to check:
- Case studies or talks that show real world experience.
- Public content they have produced: blog posts, tools, or conference slides. That shows depth and breadth of knowledge and experience.
- References from organizations with similar environments.
- Certifications matter in context. Practical experience matters more than a stack of credentials. A pentester may have every technical certification under the sun but not have the mindset or creativity to perform an in-depth, manual first, assessment.
- Will they work with you to scope realistic scenarios and help your team improve? Or do they hand you a spreadsheet and tell you to figure it out.
- Will they explain their testing methodology in-depth?
- Do they have a sample report? This will give you insight into the depth and breadth of testing and the quality of deliverable you should expect from testing. Any qualified pentester should be proud to provide this.
Interview them. Ask them to walk you through a past engagement similar to yours. Ask how they handled production constraints. If they sound defensive about realistic testing, keep looking.
Final thoughts
You will likely not be able to test every possible path. But you can test the most likely ones. You can test the ones that matter to your business. And you can make sure testing is about improving security, not producing a nice cover letter.
If you are buying a pentest, buy one that will actually help you sleep at night. Define a scope that mirrors your business reality. Let your pentester drive thoughtful scenarios. Vet your provider with curiosity, not price alone. And do not let the vendor who built your security be the same one who signs it off without outside validation.
A great pentest is an investment that will repay itself when it prevents a breach. It will also teach your team how to detect and respond. It should be a collaborative exercise so use it to gain as much confidence in the hard work your teams have been putting in over the months between tests. If you treat it like a cost center and try to minimize exposure at all costs, you will probably find yourself writing another check after the breach.
Quick scoping checklist for your next meeting
- Inventory the systems and mark crown jewels.
- Decide which environments to test: external, internal, cloud, wireless, APIs, OT.
- Identify realistic attacker scenarios based on user roles and third party access.
- Choose remote internal access method: full-tunnel VPN, shipped device, or hosted VM.
- Confirm logging, backups, and a technical point of contact.
- Ask for detection validation and remediation retest options.
- Vet the tester for practical experience, public content, and references.
Have a question about this article or a security challenge of your own?
Vilkas Cybersecurity helps organizations uncover and fix real-world exposures, not just theoretical ones. Fill out the form and we'll get back to you shortly.