Malicious Actor or Rogue Employee: What an Internal Network Pentest Actually Simulates

Most security conversations start with the same question: can someone get in? 

That's the wrong question to build a security program around. The better one, and the one an internal network pentest is built to answer, is: assume they already did. Now what?

An internal network pentest starts with the assumption that an attacker or insider already has a foothold inside your network, then spends the engagement figuring out how far that foothold goes.

That's different from what most companies think they're paying for. An external penetration test asks what's exposed to the internet, which doors and windows someone outside can actually reach. An internal network pentest skips past that layer entirely and starts from wherever a phished credential, a misconfigured service, or a first-day account has already landed someone inside.

Two Ways Someone Ends Up Inside Your Network

Scenario 1: The External Attacker Who Already Got In

A phishing email got clicked, a credential leaked somewhere it shouldn't have, a service got misconfigured and exposed. However it happened, the attacker now has a foothold inside your network. The starting point for this test isn't the front door. It's the compromised laptop or the exposed service, already inside.

Strong perimeter defenses don't tell you what an attacker can reach once they've crossed them. Firewalls and endpoint protection are built to stop the initial compromise. They say very little about what happens after one succeeds.

Scenario 2: The Insider or Contractor Who Already Has Access

Assume no breach at all. Instead, start with a rogue employee, a compromised contractor account, an offshore developer, or a vendor with legitimate credentials and some level of internal access. The test explores what that access could become if it were pushed or combined with other weaknesses in the environment.

This scenario matters more as a SaaS company grows because fast-growing teams grant internal access to more employees, contractors, offshore developers, and third-party vendors, usually faster than anyone goes back to check what that access actually allows. Insider risk is about access sprawl that nobody has stress-tested.

This is exactly where PCI DSS environments raise the stakes. If your cardholder data environment relies on network segmentation to stay separate from the rest of your infrastructure, the objective isn't just to confirm that segmentation controls exist. It's to determine whether someone who gains access to one part of the environment, through either scenario above, can reach systems or components that should be isolated from it.

PCI DSS v4.0.1 addresses this directly. Requirement 11.4.2 covers internal penetration testing generally, while Requirement 11.4.5 requires organizations that rely on segmentation to reduce PCI scope to test that segmentation specifically, at least once every 12 months. Service providers face a higher bar under Requirement 11.4.6, which calls for that segmentation testing every six months. An internal network pentest is where that segmentation actually gets tested, not just documented. This PCI DSS penetration testing guide covers what a Qualified Security Assessor (QSA) expects to see in more detail.

We're In. Now We Do the Worst We Can.

Once a tester has that starting position, the job is to pressure-test that access and see what it actually unlocks.

The process looks like: 

1. Enumerate what's reachable from the starting position
2. Look for weaknesses
3. Escalate privileges where possible
4. Move laterally across systems
5. Chain individual vulnerabilities together
6. See what sensitive or business-critical systems eventually come into reach.

What surprises most leadership teams is that the most consequential outcome in a real engagement rarely comes from a single severe vulnerability. It usually comes from two or three individually unremarkable weaknesses that become serious once they're connected. A misconfigured permission on its own might not be worth a second look. Combined with a service account that has more reach than it should, it can become a path to something much bigger.

Five Signs Your Internal Trust Boundaries Have Changed

Internal network pentesting isn't something every startup needs on day one. It becomes relevant at a specific moment, and it's not about company size. It's about whether the trust boundaries inside your company have changed since you last thought about them.

Each of the five triggers below is the same event in a different form: something has changed who or what your internal network now has to trust, and nobody has tested whether that trust is safe to extend.

Enterprise customers bring new trust requirements. The first major enterprise deal usually brings a security review that goes beyond "do you have a pentest report?" Enterprise buyers are effectively asking whether they can trust your internal environment with their data. Knak, a Series A SaaS company that sells to enterprise customers including Google, Meta, and Uber, ran into exactly this: their enterprise customers required rigorous security testing before moving forward.

Contractors and vendors introduce new identities. The team granting internal access is no longer just full-time employees. Every additional identity with internal access is another starting point that Scenario 2 needs to account for.

SOC 2 puts your access controls under scrutiny. Auditors are now asking pointed questions tied to specific control areas, including those associated with CC6.1 and CC6.3. Internal access control claims need to hold up under evidence-based review at this point. To be precise about what pentesting does and doesn't do here: an internal network pentest provides supporting evidence for those conversations. It does not, by itself, satisfy CC6.1, CC6.3, or any SOC 2 requirement, and it shouldn't be sold or read as doing so.

M&A means inheriting someone else's trust relationships. A potential acquirer's or investor's technical diligence team is now assessing what they'd inherit, including every internal trust relationship ever set up and never revisited. A recent, credible internal pentest report gives the company a documented answer to a question diligence is likely to raise anyway.

Your network architecture has materially changed. A cloud migration, a move toward Kubernetes, new VPCs or subnets, a new VPN or bastion setup, or an acquisition that folded another company's network into yours all redraw the map your last assessment was based on. None of these changes are inherently risky, but each one resets the trust boundaries, usually without anyone deciding that on purpose.

What an Internal Network Pentest Actually Looks Like

Scoping and structure follow directly from the two scenarios above, tested against an environment that reflects how your network actually runs today.

Scope starts with a full, precise list of the IP addresses or ranges involved, since scope defines what gets tested and, just as importantly, what doesn't. Alongside that, you need access instructions, typically a VPN or bastion-host configuration. For larger or more complex environments, you don't have to type that list line by line: Software Secured onboarding checklist supports a file upload for target lists once they exceed 20 IP addresses, which most clients use since typical environments have several hundred to several thousand internal IPs.

For the testing environment itself: network and infrastructure pentests are always conducted against production. Application and software pentests generally use a staging environment instead, and that's not an inconsistency; it's a difference in risk profile. Network-only testing carries a lower risk of outages or data loss than application testing, where data and availability can genuinely be affected by the testing itself.

Testing production isn't done casually. Standard practice is to back up the environment before testing starts and take regular backups throughout, so business continuity is protected if anything unexpected happens during the engagement. Our research on production testing tradeoffs covers this in more depth, and it's worth a look before assuming production testing is riskier than it actually is.

What Happens When We Find Something

The output of an internal network pentest is a structured, actionable report built for security, engineering, and business stakeholders, including auditors and customers where appropriate.

The report opens with a calibrated scoring overview before getting into individual vulnerabilities, each broken out with severity (scored for both impact and risk), business impact, remediation guidance, and proof of concept, delivered through the Software Secured Portal about two business days after testing ends. A lighter executive summary is also available for anyone who needs the substance without the full technical detail, with access to each controlled separately, so you decide who on your team, or outside it, sees what.

Vulnerabilities come with remediation timelines by severity: critical within 5 business days, high within 30, medium within 90, low within 180, with informational items flagged as best practices rather than deadlined fixes. Once something's remediated, retesting confirms the fix holds and gives you evidence for an auditor or customer, typically within two weeks of a request, with the number of rounds depending on your service package.

What If You Want to Know Whether Your Team Would Catch Us?

Once a company knows what internal access can be turned into, the next honest question is: would your people and controls actually detect and stop that activity in real time?

Internal network pentesting answers what an attacker or insider could do from inside. Red teaming answers whether your team would actually catch them doing it. It’s also a way for leadership to think about security spend as a sequence of specific questions being answered over time, rather than a single one-time purchase.

FAQ

How much does an internal network pentest cost, or what factors affect scoping and pricing?

Cost depends primarily on the size and complexity of the in-scope environment: the number of IP addresses and subnets, the mix of asset types, and how much segmentation exists to test. Software Secured pricing starts at $7,700 USD.

How long does an internal network pentest take from kickoff to report?

Two milestones anchor the timeline. Tests are typically scheduled 1 to 2 weeks after the Statement of Work signature, giving your team time to prepare the environment and access. Once active testing wraps up, the report is delivered about two business days later. Internal Network tests can take as little as 4 testing days or more than 13, depending on the network's complexity and size.