External vs Internal Penetration Testing

Perimeter testing and insider threat simulation are not interchangeable: they start from different places, answer different risk questions, and produce different findings, so they should be scoped as distinct pieces of work.

External testing is testing the locks on your front door; internal testing is assuming someone already has a key and testing what rooms they can access.

The practical split is the attack surface each test is allowed to touch. External testing examines the internet-facing attack surface: public IPs, domains, remote access, mail gateways, and applications that strangers can reach. Internal testing examines the internal attack surface after a trusted foothold exists: identity, shares, admin tools, segmentation, and data stores that only become visible once someone is already on the inside.

Insider threat simulation is a specific form of internal testing that uses realistic insider personas rather than a generic user on the LAN as the start point. Those personas typically cover malicious insiders, negligent insiders, unwitting insiders, and compromised accounts, so the test measures what those people or stolen identities can actually do.

Insider risk is the potential for harm created by access, privilege, or process gaps. An insider threat is that potential turning into harmful activity, credible intent, or attacker use of an insider’s account. Internal testing is how you measure both.

Privilege escalation and lateral movement can appear in both engagements, but they are not the same job. In perimeter testing they matter only if the tester first gains a foothold from outside. In insider threat simulation they are the core of the work, because the tester already holds an agreed key.

Both approaches belong in a wider network penetration testing services programme. One checks whether outsiders can get in. The other checks what happens after someone is already in.

External vs Internal Penetration Testing: The Definitive Difference

The comparison separates two jobs. Perimeter testing answers whether they can get in. Insider threat simulation answers what they can do once they are in.

Threat modelling should decide the scope of each job before anyone scans or logs in. If the question is internet intrusion, do not buy an insider persona. If the question is stolen or misused credentials, do not expect a perimeter scan to answer it.

Which Test Do You Need? External, Internal, or Both

You need external testing when internet-facing systems are the unknown, internal testing when insider or compromised-account impact is the unknown, and both when you must evidence perimeter strength and post-compromise control.

Trusting your staff does not remove the need for internal testing, because a trusted employee’s credentials can be stolen and used by an external attacker.

The claim that the organisation has nothing to hide misses that point: internal testing is not an accusation against employees. It is a check on what a valid account, including a stolen one, can reach.

Neither test is more actionable in the abstract. External findings are usually specific vulnerabilities you can patch or shut. Internal findings are usually access paths and detection gaps that need identity, process, and monitoring changes.

Choose the test that matches the decision you need to make, not the report format you find more familiar.

Sequencing External and Internal Tests

External testing should run first if you have never tested the perimeter, because it establishes the baseline before you spend effort on insider scenarios.

Internal testing then shows what remains possible after perimeter controls are in place, including what an insider or stolen account could still do despite those controls.

Run external testing more frequently, typically quarterly or twice a year, because internet-facing change is constant.

Run internal testing less frequently, typically annually or after significant changes such as identity redesign, mergers, major cloud moves, or privilege model changes.

After a major infrastructure change, run both rather than assuming last year’s perimeter result still describes the inside, or that last year’s insider result still describes the new boundary.

If you have never tested externally, start there. An insider simulation on an untested perimeter can create false comfort about rooms inside a house whose front door has never been checked.

Do not wait for a perfect internal programme before commissioning a first perimeter test, and do not treat a clean external report as proof that leaver, contractor, or stolen-account risk is under control.

Know the Limitations: What Each Test Won't Tell You

External testing cannot reveal insider risk, and internal testing cannot validate whether the perimeter can be breached from outside. The two tests are complementary because each covers what the other misses.

Neither engagement finds everything, and both are point-in-time snapshots of the scope you authorised, not a guarantee against later change or unknown exploits.

What External Testing Will Not Tell You

External penetration testing will not tell you what a person with valid internal access can do after login. It is a perimeter exercise, not an insider-access exercise.

A clean external result can still hide excessive privilege, weak segmentation, and silent exfiltration paths that only appear after a trusted foothold.

• It will not simulate insider threat scenarios or leaver behaviour.
• It will not show what a compromised account can access or exfiltrate.
• It will not prove whether detection controls catch insider activity.
• It will not map internal lateral movement paths that only appear after a trusted foothold.
• It cannot predict zero-day exploits that are unknown at the time of the test.
• It will not tell you whether the SOC notices a staff-like user copying data from inside the identity plane.

What Internal Testing Will Not Tell You

Internal penetration testing will not tell you whether an outsider can break in, because it starts with access already granted. That is a design choice, not a full attack-chain substitute.

It also does not replace personality screening or HR judgement: the useful evidence is observable access, movement, and data handling, not whether someone looks like a risk.

• It will not prove whether the perimeter can be breached from the internet.
• It will not inventory internet-facing vulnerabilities as its primary output.
• It will not test initial access vectors such as exposed services or unauthenticated remote entry.
• It assumes valid credentials, so it does not answer how the attacker got the key.
• It will not, by itself, prove that physical entry, supply-chain access, or out-of-scope third parties are blocked.

Treat a clean external test as evidence about the boundary, not about staff, contractors, or stolen accounts. Treat a clean internal test as evidence about post-access control, not about whether strangers can get in.

If you need both answers, you need both tests, or you will be filling one gap with confidence that belongs to the other.

What Drives the Cost and Effort of Each Testing Type

Cost and effort for external and internal penetration testing are driven by different variables: attack surface size and testing depth for perimeter tests, and persona count, duration, and detection complexity for insider threat simulation. Neither type is universally cheaper. The expensive version is the one whose scope, access model, and reporting depth expand without a tight brief.

Budget against the variables you can control. Shrink noisy attack-surface lists, agree persona count before kick-off, and decide whether the test must include detection validation, social engineering, or only technical exploitation.

Adding more IPs, more personas, live SOC observation, or a fuller narrative report all increase effort. Leaving those choices vague does the same thing, because the provider has to discover the real scope during the engagement.

External testing typically consumes less calendar time from HR, legal, and operations. Internal testing consumes more of that time because testers are operating as if they were staff, and the organisation must authorise that behaviour in writing.

Duration follows the same split: a tightly scoped perimeter test is bounded by the public attack surface, while an insider simulation is bounded by how many personas you want observed and how long you need the SOC to have a fair chance of noticing them.

How External and Internal Testing Methodologies Differ

External testing starts outside the network with little or no trusted access, while internal testing starts inside with issued credentials and persona-based simulation. The techniques overlap in places, but the rules of engagement, knowledge level, and success criteria are not the same.

Recognised methods such as PTES, OWASP testing guidance, and NIST SP 800-115 can shape either engagement. They do not make the two tests the same piece of work.

Knowledge level is the first methodology fork.

• Black-box testing gives testers little or no internal information, which is common for a realistic external attacker.
• White-box testing gives substantial internal information, which is common when you want an insider simulation to use a known role quickly.
• Gray-box testing sits between those poles: enough context to avoid wasted time, not so much that the test stops resembling a real path.

External Testing Methodology

External testing uses a black-box or gray-box approach and begins on the public side of firewalls, VPNs, mail gateways, and internet-facing applications. Testers discover the attack surface, scan for weaknesses, attempt exploitation, and, where agreed, include social engineering. Success is proving or failing to prove a path in from outside, not proving what a helpdesk account can later reach.

• Lock scope: IPs, domains, applications, exclusions, and testing windows.
• Reconnaissance and enumeration of internet-facing services.
• Vulnerability analysis and controlled exploitation of in-scope weaknesses.
• Optional social engineering if it is explicitly in scope.
• Evidence capture, impact rating, and perimeter-focused reporting.

Internal Testing Methodology

Internal testing uses a white-box or gray-box approach, issues valid credentials, and starts from inside the network. The tester is not trying to pick the front-door lock. The tester is using an agreed key and seeing which rooms, files, and admin functions that key unlocks.

Testers typically need issued accounts, a sanctioned path onto the network such as VPN or a jump host, and an out-of-band channel to the named owner so a real incident can be separated from the test.

• Agree legal authority, personas, data-handling limits, and emergency stop procedures.
• Issue credentials that match the chosen insider types.
• Attempt access to sensitive systems, data stores, and privileged functions.
• Attempt lateral movement and privilege escalation within the agreed boundary.
• Observe whether detection and response controls notice the activity.
• Document access paths, missed alerts, and control or process failures.

Authorisation is not paperwork for its own sake. Written authority tells testers what they may touch, tells the SOC what activity is expected, and gives legal and HR a record that the behaviour was requested.

Slow, low-noise execution is often more useful than a noisy burst of activity, because a real insider or a careful attacker using stolen credentials may try to blend in. A short mapping pass can still be useful to chart obvious access, but detection quality is judged more fairly when the tester is not advertising every step.

Rules of engagement must set boundaries for both test types: in-scope assets, forbidden techniques, testing hours, data handling, and who can halt the work. Scope creep is the usual failure mode, especially when a tester finds an interesting path that was never authorised.

If a perimeter tester reaches an internal host, or an insider persona reaches an out-of-scope HR system, the next step should be a documented scope decision, not silent expansion. Internal testing often needs HR and legal sign-off because it can imitate staff behaviour, touch personal or HR data, and create monitoring or employment-law questions that a purely external scan does not.

Do not treat those four types as a glossary only. Each one changes the test: a leaver scenario emphasises exfiltration, while a compromised privileged account emphasises movement, escalation, and whether anyone notices.

A negligent-user scenario often exposes over-permissioned shares and weak DLP. An unwitting-insider scenario exposes process gaps, because the harm starts with someone being talked into doing a helpful action.

What Internal Testing Reveals About Your Detection Stack

Internal testing reveals whether SIEM, DLP, UEBA, IAM, and EDR controls actually generate usable alerts when insider-like activity occurs. Vulnerability lists are only part of the value. The other part is proof that security spend detects and supports a response.

External testing can show whether edge prevention failed. It is a weak way to prove that internal monitoring works against an already-authenticated user.

A useful report states which tools failed to alert, which alerts fired but were not actioned, and where SOC process fell short of the documented playbook. That is a different outcome from an external test, which is mainly trying to prove a breach path from outside.

The finding may be a missing log source, a rule that never fired, an alert that drowned in noise, or a well-tuned alert that nobody owned.

• SIEM: whether relevant logs are collected, correlated, and turned into timely alerts rather than unused noise.
• DLP: whether sensitive data leaving by email, cloud sync, USB, or staging shares is blocked or at least recorded.
• UEBA: whether unusual access volume, odd hours, or abnormal peer behaviour is treated as a signal.
• IAM: whether least privilege, joiner-mover-leaver controls, and privileged access actually constrain the persona.
• EDR: whether endpoint telemetry catches credential use, discovery, collection, or staging on the device.

SIEM is not UTM. SIEM aggregates and correlates logs across many systems so analysts can investigate. UTM is a perimeter or gateway appliance that combines firewall, intrusion prevention, and related edge controls.

Internal testing is one of the few practical ways to check the SIEM side of that stack against insider behaviour, because a UTM at the edge may never see an already-authenticated user moving data inside.

Internal testing is also a poor substitute for judging people. Personality, private stress, or a single late night in the office is not a reliable early indicator on its own, and it is not what this test is for. The test looks for control evidence: could this persona reach the data, did any tool notice, and did the SOC treat that notice as an incident?

Immediate detection is a positive finding, not a failed test. It means the control worked. The engagement can then switch persona, reduce noisiness, or continue under the agreed rules to see what still succeeds after the first alert.

The report should credit the detection, time-to-alert, and quality of SOC response, then still record any path that remained open after that first catch. If the SOC detects the tester in minutes and then closes the ticket without containment, that response gap belongs in the report as clearly as a missing patch would in an external test.

Compliance Considerations: Which Tests Satisfy Which Frameworks

Compliance programmes more often treat external penetration testing as the visible minimum, while internal testing supplies extra assurance about insider access, data exposure, and detection.

No test type is a legal shortcut by itself. Evidence quality depends on scope, independence, and whether findings are actually fixed. A report that never leads to treatment is weak evidence under any of the frameworks below.

UK businesses, including London-based organisations selling to regulated or public-sector buyers, should not assume one annual external test closes every framework. Cyber Essentials is not a full penetration test.

GDPR does not name a single mandated pentest format, but it does expect appropriate technical and organisational measures for personal data, which is why insider-access testing can support a defensible control story.

ISO 27001 expects risk-based testing and treatment, not a branded product name.

PCI DSS is the case where both external and internal network testing are part of the control set rather than one being optional garnish.

Build the budget case in two layers: the test that satisfies the written minimum, and the internal simulation that shows whether stolen or misused credentials can still reach regulated data.

If a customer, board, or auditor only asked for a pentest, clarify which question they need answered before you commission the cheaper-looking option and discover it did not cover insider access or, equally, did not cover the perimeter.

What You'll Get From Each Test: Reports and Findings

External test reports concentrate on specific exploitable vulnerabilities, while internal test reports concentrate on access paths, control failures, detection gaps, and data-exposure scenarios.

One output is usually a request to fix a named weakness. The other is usually a statement that an insider with these credentials can reach this data, and these controls did not stop it. That difference in finding type is why the two reports should not be scored as if they were the same deliverable.

Internal findings often cannot be closed with a patch window alone. If a leaver can still sync a file share, or a helpdesk account can reach finance data, the fix may be joiner-mover-leaver process, privilege redesign, DLP policy, or alert handling.

Treat those as first-class results, not as soft commentary around CVE lists. Where a primary control cannot be changed immediately, the report should still distinguish a genuine compensating control from an untested assumption.

What to Do With Your Results

• Prioritise remediation by exploitability and business impact for external findings, and by data exposure plus detection failure for internal findings.
• Fix critical items before re-testing.
• Use the report to harden controls, not only to clear individual tickets.
• Re-testing is how you confirm the path is closed.
• A status of patched or policy updated is not the same as proving the next persona or the next external scan fails.

Do not wait until the debrief to decide who owns patches, identity changes, and SOC tuning. If nobody owns process findings, internal testing becomes a story about risk rather than a reduction in risk. The same is true of external testing if internet-facing owners are unclear: the CVSS list will age while the exposed service remains in production.

How to Prepare for Testing: A Readiness Checklist

You prepare for external or internal penetration testing by locking scope, documents, authority, communications, and a remediation path before testers start. Weak preparation creates delays, noisy alerts, and findings nobody can action.

External tests usually need a clean internet-facing inventory. Internal tests usually need that plus personas, credentials, and people who can approve staff-like activity.

• Asset inventory: systems, IPs, domains, applications, and identities in scope, plus explicit exclusions.
• Network documentation: architecture diagrams, trust boundaries, access control lists, and firewall rules that testers are allowed to know.
• Rules of engagement: boundaries, testing windows, allowed techniques, data-handling limits, and emergency stop procedures.
• Stakeholder sign-off: security approval for both test types; legal and HR approval for internal and insider-persona work.
• Communication plan: named contacts, SOC coordination, how testers identify themselves if challenged, and how triggered alerts will be handled.
• Remediation process: triage rules, fix owners, evidence needed for closure, and whether re-testing is in the same engagement.
• Tester access path: for internal work, issued credentials, a sanctioned network entry point, and an out-of-band contact who can halt the test.

Start with a short scope document rather than a vague request to test the network. For a first internal simulation, a small pilot persona is safer than an unbounded tour of every business unit.

Confirm that production-impacting techniques are either forbidden or confined to agreed low-traffic windows. Plan how real incidents will be distinguished from test activity before the first probe, especially if the SOC is expected to stay live and attentive.

Do not treat either test as a one-off event. The checklist is also how you keep the next cycle cheaper and cleaner: updated inventories, known owners, and a remediation path that already exists. If those pieces are missing, the first finding will be operational unreadiness rather than a useful security result.

How to Choose a Penetration Testing Provider

Choose a penetration testing provider by checking relevant certifications, sample reporting, methodology control, and experience with your industry and stack, not by price alone.

UK buyers should verify CREST, CHECK, and Tiger Scheme credentials against the actual work being bought, because public-sector CHECK assurance is a different gate from commercial CREST-style delivery.

• Ask for redacted sample reports and judge whether findings are evidenced, ranked, and actionable.
• Ask for specific experience with your industry, identity model, and technology stack.
• Ask how rules of engagement, scope changes, and out-of-scope discoveries are handled.
• Verify certifications: CREST, CHECK, and Tiger Scheme for UK providers, matched to commercial versus public-sector or CNI needs.
• For internal tests, ask how detection testing is run, what happens on early detection, and how SOC coordination is planned.
• Request references from similar organisations and check that the named work resembles your scope.
• Ask which method they map the work to, such as PTES or NIST-style process, and how that changes between perimeter testing and insider threat simulation.

Avoid three common mistakes:

• selecting on price before reading a sample report
• skipping industry or technology fit
• accepting certification claims without checking which scheme applies to your sector

A provider that cannot explain the difference between perimeter testing and insider threat simulation will struggle to scope either one cleanly.

Ask them to describe a leaver scenario and a compromised privileged-account scenario in plain language. If those two stories sound identical, the internal test is unlikely to be designed as a testing variable rather than a generic LAN scan.

Frequently Asked Questions