What Kind of Penetration Testing Actually Reduces Ransomware Risk?

Nearly every organization agrees ransomware is a serious threat, but far fewer are confident they could survive an attack intact. Part of what makes it hard to plan for is that ransomware is not really a single attack. It is the last step in a chain that started somewhere else, usually days or weeks earlier, with an exposed service, a stolen password, or someone who clicked a convincing link.

Penetration testing is one of the few exercises that tells you whether that chain is present before someone else discovers it. But not every test answers the same question, and one that is scoped carelessly can leave you more confident than you should be. At Compass, we believe three main types of assessments can build your confidence in ransomware resilience: external penetration testing, internal penetration testing, and social engineering. This article covers the goals of each type of test, why scoping matters more than most people expect, and what to ask for when you plan an assessment.

How Ransomware Attacks Usually Start

Before deciding what to test, it helps to be specific about how these attacks begin. The patterns are remarkably consistent:

• An internet-facing system with a known vulnerability, misconfiguration, or software that is no longer supported.

• Remote access exposed to the internet without multifactor authentication.

• Valid credentials obtained through phishing, password reuse, or bought from someone who specializes in selling access.

• A vendor or service provider with network access into your environment.

Every one of these scenarios is testable. Ransomware is rarely the result of something nobody could have anticipated. More often it is the result of a gap that was present for a while and that nobody went looking for.

External Penetration Testing

An external penetration test looks at your environment the way an attacker on the internet would, generally with no credentials and no (or limited) inside knowledge. The scope covers web applications, VPN gateways, remote desktop services, mail servers, firewalls, cloud-hosted services, file transfer appliances, and anything else that answers a request from outside your network.

This is the test that maps most directly to how ransomware gets in. An attacker scanning the internet does not care about your industry or whether you passed an audit last year. They care whether something is reachable and whether it is vulnerable. A few things that turn up regularly:

• Systems that were spun up for a project, forgotten, and never patched again.

• Admin panels and management interfaces that were never meant to be publicly reachable.

• Software running old versions with exploit code freely available online, often for vulnerabilities disclosed months earlier.

A vulnerability scan will flag some of this. The difference with a penetration test is that a person tries to chain the findings together and show you where they lead, exploiting rather than just identifying. Knowing a service is out of date is useful. Knowing that a tester used it to land on a server holding domain credentials is what gets remediation funded.

Why Scoping Matters More Than Almost Anything Else

This is the part that quietly determines whether the whole engagement was worth paying for. A penetration test only covers what is in scope. If a host, IP range, or application is not on the target list, it does not get tested, and whatever might be wrong with it does not get found. The report will still come back looking reasonable. It just will not say anything about the part of your environment that ends up mattering the most.

These gaps open in ordinary ways rather than negligent ones. The asset inventory is a year old. A recently acquired business unit was going to be handled as its own project. A cloud subscription belongs to a development team that was not on the scoping call. Each of those is defensible on its own, and each one leaves something untested.

Questions Worth Asking Before Testing Begins

• Does our asset inventory reflect what is running right now, including cloud, remote sites, and anything a team stood up without telling IT?

• Have we accounted for every external IP range and domain we own, including ones we inherited through an acquisition?

• What are we excluding, and could we explain why an attacker would also ignore it?

• Are we testing production, or a lower environment that does not really look like production?

• If something is excluded for operational reasons, how are we validating its security some other way?

A good testing partner will push back when a scope looks thin and help you reconcile your inventory first. Leaving an asset out is sometimes the right operational call. It should just be a decision you made on purpose, with a plan attached, rather than an accident of paperwork.

Internal “Assumed Compromise” Testing

Hardening the perimeter lowers the odds of an intrusion. It does not eliminate them. So, the second question worth answering is, “What happens if someone gets in anyway?” and that is what an assumed compromise test is for.

The tester starts from inside, usually with access a normal employee would have, or as an unauthenticated device sitting on an internal network. From there they do what a ransomware operator would do: look around, collect credentials, escalate privileges, move between systems, and work out where the backups and the sensitive data live.

The findings from this kind of test are often the most useful in the whole program, because they explain the difference between a contained incident and a company-wide outage, the latter of which might be caused by:

• A flat network where nothing stops movement from a user workstation to a critical server.

• Service accounts with far more privilege than they need, or domain administrator credentials caught on ordinary laptops.

• Local administrator passwords reused across enough systems to make lateral movement trivial.

• Backup infrastructure being reachable and modifiable with the same credentials as production.

• Endpoint tooling not alerting on common attacker behavior, or producing alerts that nobody is triaging.

Scoping applies here just as much. If the internal test covers a single subnet or leaves out the domain controllers and the backup servers, it cannot answer the question you care about: whether someone who lands on a laptop in a branch office can reach the systems that keep the business running.

Phishing Tests, Because You Cannot Skip the People

Testing networks and leaving out your workforce is an incomplete exercise. Phishing remains one of the most dependable ways attackers get the credentials or the code execution they need, and it goes around the perimeter entirely. If an employee types a valid password into a convincing login page, nothing must be exploited at all; at that point, someone simply gave the attacker an “in.”

A phishing assessment sends controlled, realistic phishing emails to your people and measures what happens. The useful output is not the click rate on its own:

• How many people reported the message, and how long it took to reach the security team.

• How many recipients clicked, and how many went further and submitted credentials.

• Whether multifactor authentication stopped an attacker from using the credentials that were captured.

• Whether your email security controls or detection tooling noticed the campaign at all.

• Which teams, roles, or locations would benefit most from targeted follow-up training.

The reporting number is the one worth watching. An organization where a few people click but someone reports the message within minutes is in better shape than one where nobody clicks and nobody says anything. Reporting is what gives your team the chance to step in before encryption starts, and it is a behavior you can measurably improve, which is why these tests work better paired with awareness training than as an annual checkbox.

How the Three Fit Together

Each test answers a different question. External testing asks whether someone can get in. Internal assumed compromise testing asks how far they get once they do. Phishing tests ask whether your people will hand over the keys. Ransomware resilience depends on all three, and a program built around only one of them leaves an entire category of risk unmeasured. Cadence matters too, since deployments, cloud migrations, and acquisitions can each introduce something that did not exist in the last test.

What to Expect After the Test

A useful report should make the next step easier by grouping findings into rough tiers: quick fixes, items that need budget or a vendor to resolve, and items that require a longer-term architectural change like network segmentation. Anything that enables lateral movement belongs near the top regardless of tier, since that is what turns one compromised machine into an enterprise problem.

Timelines vary widely. A misconfiguration can be closed the same week. Segmentation work or a privileged access overhaul can take months. An honest report will be clear about which category each finding falls into rather than presenting everything as equally urgent. Retesting once the significant items are closed is worth budgeting for, since it is the only way to confirm the fix worked.

Red Flags to Watch For

• A provider who accepts your scope without asking anything about your asset inventory.

• A report that is mostly automated scanner output behind a cover page.

• Findings listed with no sense of which ones matter or what they lead to.

• An unwillingness to explain how a finding was reached or to walk your team through remediation.

• A fixed price and timeline quoted before anyone has looked at your environment.

Getting Started

If you have not tested recently, or ever, start with the inventory rather than the test. Pull together your external IP ranges and domains, a current network diagram even if it is rough, a list of internet-facing applications, and a note on which third parties have access into your environment. Having that ready before the first scoping call will make the test more accurate and the cost and timeline more realistic.

Ransomware defense is not a product you buy. It is the ongoing practice of finding your weak points before someone else does. Penetration testing, scoped honestly and repeated across your perimeter, your internal network, and your people, is the most direct way to find out where you stand.

Compass helps organizations build penetration testing programs that reflect how attackers really operate, from external and internal network penetration testing to phishing assessments and security awareness training. We work with clients to scope engagements accurately, prioritize findings by risk and effort rather than handing over a raw list, and turn results into a remediation plan that fits the resources they have. Reach out to us to talk through your environment and where testing would give you the most value.