Internal vs External Penetration Testing: A UK Business Guide to Which Type You Actually Need in 2026

The difference between internal and external penetration testing is not a matter of where the tester sits. It is a difference in the question being asked. An external test asks whether someone on the internet, with no access at all, can get in. An internal test asks what happens once they have — how far an attacker can move from a single compromised laptop, phished account or malicious insider, and how much of the business they can reach before anyone notices. Most UK businesses buy the first, assume it answers the second, and are surprised by the incident that proves otherwise.

This guide is about choosing deliberately. It explains what each type of test actually simulates and which threat scenarios each can and cannot answer, why the boundary between them has blurred as businesses moved to Microsoft 365, cloud platforms and remote working, how scope and access differ in practice, what each typically costs, and a framework for deciding which your organisation needs — based on how attacks against businesses like yours actually unfold rather than on which test is cheaper or quicker to book. The engagement process itself is covered in our guide to what happens during a penetration test, and the wider landscape in our complete guide to penetration testing.

What each test actually simulates

The clearest way to understand the two types is to describe the attacker each one imitates.

External testing: the outsider with nothing

An external test starts from the public internet with no credentials and no foothold, and examines everything your organisation exposes to it: internet-facing IP addresses, firewalls and edge devices, remote access gateways and VPNs, mail systems, public web services, and increasingly the internet-facing parts of cloud platforms and identity services. The question it answers is whether an opportunistic or targeted attacker can find a way in through what you have published to the world.

Internal testing: the attacker already inside

An internal test starts from a position inside your environment — a device connected to the office network, a standard user account, or a corporate laptop — and examines what an attacker who has obtained that position could achieve. It looks at how far they could move between systems, whether they could escalate from ordinary to administrative privileges, which sensitive data and systems would be reachable, and whether anything would detect them doing it. The question it answers is how bad a breach would be once the initial access has happened.

Why the second question matters more than it used to

Most incidents affecting UK businesses do not begin with a sophisticated attack on a firewall. They begin with something mundane — a phishing email, a stolen password, a compromised supplier connection, a malicious attachment — that gives an attacker an ordinary user’s access. From there, the damage depends almost entirely on what that access can reach, which is the question only internal testing answers. An organisation with a well-defended perimeter and a flat, over-permissioned internal network has protected the route attackers use least and left open the one they rely on most.

Security practitioners often describe this as an assumed-breach mindset: rather than asking only whether someone can get in, accept that eventually someone will, and test what happens next. It is a useful framing for decision-makers because it shifts the conversation from whether the business is secure to how contained an inevitable incident would be.

Penetration testing scope in UK businesses — the numbers

The figures below reflect what we see across UK organisations of 20 to 400 staff commissioning penetration testing, typically for a client contract, an insurance requirement or a first security review.

The first and second figures together are the core argument of this guide. Two-thirds of organisations have only ever tested the perimeter, and in three internal tests out of four, a tester starting from an ordinary user account reaches full administrative control. Those organisations have measured the route attackers use less often and never measured the one that determines how bad an incident becomes.

The third figure is worth sitting with. Less than a working day from an ordinary account to the keys to everything is typical, not exceptional. It reflects accumulated weaknesses that are individually modest — an old service account with a weak password, credentials stored where a user can read them, administrative rights granted too broadly, systems trusting each other more than they need to — and that chain together quickly in the hands of someone looking for them.

The fourth figure is the one most organisations find uncomfortable. In fewer than a quarter of internal tests did anyone notice the tester’s activity. That means most organisations would not detect an attacker doing the same thing, which turns a contained incident into a prolonged one. Internal testing measures detection as a side effect, and that is frequently the most valuable finding of the whole engagement.

Where serious findings actually come from

The chart below shows the share of combined internal and external engagements in which each category of high or critical finding appeared, labelled by the type of test that found it. It is not a ranking of importance; it shows what each type tends to surface.

The pattern is consistent. External tests find fewer serious issues on average, and those they find tend to be discrete and fixable — patch this device, close that interface, enforce strong authentication on remote access. Internal tests find more, and the issues compound: excessive privilege plus exposed credentials plus a flat network is not three findings but one path from a single phished user to every server in the business.

This is not an argument that external testing is unimportant. An exploitable internet-facing device is exactly the kind of weakness opportunistic attackers scan for constantly, and finding it before they do is valuable. It is an argument that a clean external report says very little about internal resilience, and organisations reading one as a general clean bill of health are misreading what was tested.

The privilege and credential rows at the top connect directly to identity design. A great deal of internal compromise runs through accounts with more rights than they need, and the remedies — separate admin accounts, just-in-time elevation, removing standing privilege — are covered in our guide to Azure identity and access management.

What each test type costs and answers

The table below sets out the common test types with indicative UK costs for 2026, excluding VAT, and the question each one answers. Costs vary with estate size, accreditation requirements and whether retesting is included; detailed pricing sits in our guide to penetration testing cost in the UK.

The third row is the one many organisations have not encountered, and for cloud-first businesses it is often the most representative test available. Rather than plugging a device into an office network that few staff use any more, the tester is given a standard corporate laptop and user account and works out what an attacker with that starting point could reach — across the device, the identity platform, cloud services and anything still on-premises. It mirrors how most real incidents start in 2026.

The final row is usually better value than buying the two separately, and not only on price. A combined engagement lets the tester connect an external finding to an internal path — for example, a weakness in remote access that leads to a foothold, from which internal weaknesses lead to administrator — which is the end-to-end story a board actually needs to understand.

Note also the cost relationship. Internal testing typically costs somewhat more than external, because there is more to examine and the work is more involved. That price difference is frequently the reason organisations choose external only, and it is a poor reason given what each tends to find.

External against internal testing

The comparison below highlights internal testing. The qualification is important: this is not a recommendation to stop external testing, which remains valuable and is frequently required by clients and insurers. The highlight marks the test most UK SMEs are missing, given that two-thirds have only ever been tested externally and that most incidents progress internally after a mundane initial access.

The last row is the one worth showing to whoever approves the budget. A clean external result means attackers did not find a way through the perimeter during the test window. A clean internal result means that even if they did, they would struggle to turn it into a business-ending incident. The second is the more useful assurance for most organisations, and it is the one fewer have.

The detection row is often underappreciated. An internal test generates exactly the kind of activity an intruder would — reconnaissance, credential use, movement between systems — and whether your monitoring raises an alert is a direct measure of whether you would catch a real one. Agree with the tester in advance how that will be reported, because a test your monitoring did not notice is one of the most informative results you can get.

Scope gaps each test leaves

The grid below groups what each test type typically does not cover, and what neither covers on its own. Badges reflect how often the gap leaves a meaningful risk untested in UK SMEs.

The third card is the one that matters most for cloud-first organisations. A traditional internal infrastructure test focuses on the office network and servers; a traditional external test focuses on internet-facing IP addresses. Neither, on its own terms, examines whether your Microsoft 365 tenant is configured so that a compromised account cannot forward all mail externally, grant itself access to every mailbox, or register a malicious application. For a business whose servers have moved to the cloud, that tenant is where most of the value and much of the risk now sits, and it needs to be explicitly in scope.

Custom web applications are the other common blind spot. An infrastructure test, internal or external, will note that a web server exists and check its configuration; it will not test the application’s own logic — whether one customer can see another’s data, whether access controls can be bypassed. If you run a client portal or any custom application handling sensitive data, it needs its own application test.

Why the perimeter has moved

The internal and external distinction was designed for organisations whose systems lived in an office behind a firewall. That description fits fewer UK businesses every year, and the change affects what each test should cover.

Identity is the new perimeter

When email, files, collaboration and line-of-business applications live in Microsoft 365 and other cloud services, the thing standing between an attacker and your data is not a firewall but a sign-in. A stolen password and a relayed MFA prompt give access from anywhere. That means the internet-facing surface now includes your identity platform, and an external test that examines only IP addresses and edge devices is looking at a shrinking share of the real exposure.

The office network matters less, the device matters more

For organisations where most staff work remotely, the office network may carry little of importance. The equivalent of being inside is now being signed in on a corporate laptop with a user’s identity. A test that plugs a device into an office switch may examine an environment few attacks would ever touch, while missing what a compromised laptop at home could reach through cloud services and remote access.

What this means for scoping

Modern scoping blends the two. The external portion should include identity-facing services alongside traditional infrastructure. The internal portion should start from a realistic foothold — often a corporate device and standard account rather than a network port — and follow the paths an attacker would take into cloud and on-premises systems alike. And the Microsoft 365 or cloud tenant configuration should be in scope explicitly, because it sits across both.

For organisations that still run substantial on-premises infrastructure — manufacturing sites, offices with local servers, hybrid estates — traditional internal network testing remains highly relevant. The point is not that it is obsolete but that it should be chosen because your estate looks like that, not because it is the default product on a price list.

Planning a testing programme across a year

The sequence below is a practical first-year programme for a UK organisation of 50 to 300 staff with a mix of cloud and on-premises systems. It is ordered so that each test informs the next rather than repeating the same scope annually.

The remediation step in months three and four is where the value of internal testing is realised or lost. Internal findings arrive as attack paths: a series of weaknesses that together lead from an ordinary account to full control. Fixing them one by one in order of individual severity can leave the path intact. Identifying the links that, if removed, break the most paths — usually privilege and credential issues — delivers far more risk reduction for the same effort.

The final step reflects a common mistake: commissioning the same external test every year because that is what the contract requires, while the estate and threats change around it. Frequency and triggers are covered in more depth in our guide to how often to commission penetration testing.

Benchmarks — testing practice against what we find

The figures below show how often each practice is in place across UK organisations of 20 to 400 staff that have commissioned at least one penetration test.

Ninety-four per cent against thirty-two per cent is the gap this guide is about. Almost every organisation that tests has tested its perimeter; fewer than a third have ever tested what an attacker could do from inside. The third row is closely related: with so much business data now in Microsoft 365 and cloud platforms, a scope that omits the tenant omits a large share of what an internal attacker would actually go after.

The scope-from-risk figure at twenty-one per cent explains the pattern. Most organisations scope their testing to whatever a client contract or insurance proposal asks for, and those requirements most often specify external testing. The result is that scope follows paperwork rather than threat, and the internal blast radius goes unmeasured.

The number that shows what most businesses have not tested

If one figure captures the gap in UK penetration testing, it is the proportion of organisations whose only testing has been of their perimeter.

Sixty-eight per cent external-only means two-thirds of organisations that believe they have been penetration tested have measured one question — can an outsider get in — and never measured the one that determines how damaging an incident would be. Given that three internal tests in four reach administrator from an ordinary account, most of those organisations would probably be surprised by the result.

The figure is not a criticism of the organisations concerned. External testing is what most client contracts and insurance questionnaires ask for, it is cheaper, and it produces a tidier report. The difficulty is that a tidy external report is easily read as general assurance, and it is not. It is assurance about the front door.

Moving the figure does not require abandoning external testing. It requires adding an internal or assumed-breach component, ideally in the same engagement so that findings connect, and including the cloud tenant in scope. For many organisations the additional cost is a few thousand pounds, set against the question of whether a single phished account would become a contained problem or a business-wide one.

Deciding which test you actually need

The framework below works through the questions that determine scope. It is deliberately driven by your estate and risk rather than by the test that is easiest to buy.

Where does your valuable data live?

If most of it is in Microsoft 365 and cloud services, the identity platform and tenant configuration must be in scope, and the internal component should start from a corporate device and account rather than an office network port. If substantial systems remain on-premises, traditional internal network testing is directly relevant. Most organisations are somewhere in between and need both elements.

How would your worst incidents begin?

If the incidents you most fear begin with someone breaking through an internet-facing system, external testing addresses them directly. If they begin with a phished user, a compromised laptop or a supplier connection — as most do — internal or assumed-breach testing is what tells you how bad they would be.

What do clients, insurers and frameworks require?

Treat these as a floor rather than a scope. If a contract specifies an external test, do one; if your risk profile also calls for internal testing, add it. Building scope only from requirements is how organisations end up with a decade of external reports and no idea of their internal resilience. Requirements and insurance interplay is covered in our guide to Cyber Essentials and insurance.

Would you detect an intruder?

If nobody can say with confidence, internal testing will answer it as a side effect. That answer is often worth as much as the vulnerability findings, because detection determines whether an incident is contained in hours or discovered in weeks.

Do you run custom applications?

If you operate a client portal, booking system or any custom application handling sensitive data, it needs its own application test regardless of what infrastructure testing you choose.

What has changed since the last test?

Migrations, acquisitions, new remote access arrangements and significant application releases all change the attack surface. Testing triggered by change is more useful than testing on an anniversary.

For most UK SMEs with a mix of cloud and on-premises systems, working through these questions arrives at the same answer: a combined engagement covering external infrastructure and identity-facing services, an assumed-breach internal component from a corporate device, the cloud tenant explicitly in scope, and a separate application test where one is warranted. The choice of accreditation level is a separate question, covered in our guide to CREST against standard penetration testing.

The 12-point scoping checklist

Items one to four establish what needs testing. Items five to nine shape the engagement. Items ten to twelve make the results useful.

1. List the incidents that would most damage the business, and how each would begin. This decides whether the priority is the perimeter, the internal blast radius, the cloud tenant or an application.
2. Build an accurate asset list. Internet-facing addresses and domains, cloud tenants, applications, remote access routes and on-premises systems.
3. Identify where your valuable data lives. Cloud-first estates need tenant and identity scope; on-premises estates need internal network scope; most need both.
4. Treat contract and insurance requirements as a floor. Meet them, then add what your risk profile requires.
5. Include external infrastructure and identity-facing services. The perimeter now includes sign-in, not only IP addresses.
6. Include an internal or assumed-breach component. Starting from a realistic foothold — often a corporate laptop and standard account.
7. Put the Microsoft 365 or cloud tenant explicitly in scope. Neither traditional test covers its configuration on its own terms.
8. Commission separate testing for custom applications. Infrastructure tests do not examine application logic.
9. Agree how detection will be reported. Whether your monitoring noticed the tester is one of the most valuable results available.
10. Prioritise remediation by attack path. Break the chains from user to administrator rather than fixing findings in isolation.
11. Commission a verification retest. To confirm attack paths no longer work and to produce evidence clients and insurers value.
12. Re-plan scope from findings and change. Not a repeat of last year’s scope, and triggered by material change as well as the calendar.

Testing scope readiness — where most UK organisations sit

Combining the assessment areas gives an indication of how well an organisation’s penetration testing reflects its actual risk. The gauge reflects a first review of a UK organisation that tests annually to meet a contract requirement.

A score in the mid-thirties reflects an organisation that tests diligently and tests the wrong thing for its risk. Perimeter coverage scores well. Internal and cloud coverage score poorly. Detection measurement scores close to zero because external tests rarely generate activity that monitoring would need to catch. And remediation by attack path scores low because external findings rarely form paths in the first place.

The useful feature of this benchmark is that improving it rarely requires spending much more. The same annual budget, redirected from a standalone external test to a combined engagement with an assumed-breach component and the tenant in scope, typically moves the score substantially. The added cost is usually modest compared with the gap in assurance it closes.

Preparing for each type of test

The two test types need different preparation, and organisations that prepare for an internal test as though it were external routinely lose the first day of the engagement to provisioning and access problems.

Preparing for an external test

The core input is an accurate list of what you expose: the public IP ranges you own or lease, the domains and subdomains in use, remote access endpoints, mail services and any public applications. Incomplete lists are common, because services accumulate — a forgotten subdomain pointing at an old marketing site, a remote access gateway from a previous supplier, a test environment left reachable. Ask the tester whether discovery of unlisted assets is in scope, because finding what you did not know you exposed is often the most useful part of an external engagement.

Authorisation needs care where systems are hosted by others. Cloud platforms publish rules for customer-initiated testing of their own resources, and services run by third parties — a hosted website, a managed firewall, a SaaS platform — may need the provider’s agreement. Establish this during scoping rather than discovering mid-test that part of the scope cannot lawfully be touched.

Preparing for an internal or assumed-breach test

The starting position must be provisioned in advance. For an assumed-breach test, that means a corporate laptop built to your standard image and a standard user account with the access a typical member of staff would have — not an administrator, and not a special account with unusual permissions that would distort the result. For a network-based internal test, it means arranging a device on the network or a VPN connection, with the network team aware of it.

Three further items prevent the commonest problems. Identify fragile or business-critical systems so the tester can treat them carefully, because some older systems respond badly to entirely ordinary activity. Confirm backups are current and restorable before testing begins, as a precaution rather than an expectation of harm. And brief your monitoring provider appropriately on scope and starting position, with an agreed way to confirm that suspicious activity is the authorised test.

Decide what the tester may do with what they find

Internal tests frequently uncover credentials, sensitive files and access the tester was not given directly. Agree in the rules of engagement whether found credentials may be used to continue the test — they should be, if the aim is to simulate a real attacker, though with care around production impact — and how any sensitive data encountered will be handled and destroyed. An internal test that stops the moment the tester finds a password is not measuring what an attacker would do next.

Across both types, name an escalation contact who is genuinely reachable throughout the testing window and agree how critical findings will be reported immediately rather than waiting for the final report. The wider engagement mechanics, including rules of engagement and the legal basis for authorisation, are covered in our guide to what happens during a penetration test.

Reading internal and external reports differently

The two types of test produce reports that look similar and should be read differently. Treating them the same way is one of the commonest reasons internal findings fail to get fixed.

External reports are lists

An external report usually consists of discrete findings, each with a severity, evidence and a remedy: this device is unpatched, that interface is exposed, remote access accepts weak authentication. They are relatively independent of each other, so working through them in order of severity is reasonable, and most can be assigned to whoever owns the relevant system and closed individually.

Internal reports are stories

A good internal report describes attack paths: the sequence of steps by which the tester moved from the starting position to their objective. Each step may be modest on its own — a medium-severity misconfiguration, an account with slightly too many rights — and the significance lies in the chain. Reading such a report as a list of individual findings, and fixing the highest-rated first, can leave the path entirely intact if the critical link happened to be rated medium.

The useful way to read an internal report is to ask, for each path, which single change would break it, and which changes would break several paths at once. Those are frequently identity and privilege changes — removing standing administrative rights, eliminating exposed credentials, separating admin accounts — and they often deliver more risk reduction than closing a long tail of individually higher-rated issues.

Presenting each to a board

External findings translate naturally into a list of fixes with owners and dates. Internal findings are better presented as the story of what an attacker could do: starting as one member of staff who clicked a link, within a few hours they could read every mailbox, encrypt the file servers and delete the backups, and nobody noticed. That narrative is uncomfortable and it is exactly what a board needs to understand to prioritise remediation, because it connects technical weaknesses to the business outcomes directors are accountable for.

Ask your testing provider, at scoping, whether internal reports will include attack path narratives and an assessment of which remediations break the most paths. A provider that delivers only a severity-sorted list of findings for an internal test is giving you the raw material and leaving the most valuable analysis to you.

Common scoping mistakes

The errors below recur across UK organisations commissioning penetration testing. Most come from scoping to a requirement or a price rather than to a threat.

• Assuming one test covers everything. An external test answers whether outsiders can get in. It says nothing about how far an attacker could go once inside, which is where most incidents become serious.
• Choosing external only because it is cheaper. The price difference is usually modest compared with the gap in assurance, given that most internal tests reach administrator from an ordinary account.
• Scoping to the contract rather than the risk. Client and insurer requirements are a floor. Building scope only from them leaves the internal blast radius untested indefinitely.
• Reading a clean external report as general assurance. It is assurance about the perimeter during the test window, not about internal resilience or detection.
• Leaving the cloud tenant out of scope. For cloud-first organisations, the Microsoft 365 or cloud configuration is where much of the data and risk now sits, and neither traditional test covers it on its own terms.
• Testing an office network nobody uses. Where staff work remotely, an assumed-breach test from a corporate laptop is more representative than plugging into an office switch.
• Ignoring the detection result. Whether monitoring noticed the tester is one of the most valuable findings. Agree in advance how it will be reported, and act on it.
• Fixing internal findings in isolation. Internal reports describe chains. Fix the links that break the most paths, not simply the highest-rated items.
• Assuming infrastructure tests cover applications. Custom portals and applications need their own testing; infrastructure tests do not examine application logic.
• Repeating last year’s scope. The estate and threats change. Re-plan from what was found and what has changed.

What this looks like in practice

A UK accountancy practice with 90 staff commissioned an external penetration test every year to satisfy a requirement from a large corporate client. For three consecutive years the report came back with a handful of medium findings — an outdated TLS configuration, a certificate nearing expiry, an information disclosure on a web server — all fixed promptly. The partners regarded security as in good shape.

The practice ran Microsoft 365, kept client files on an on-premises file server and in SharePoint, and had most staff working at least partly from home. When its cyber insurer added questions about internal security controls at renewal, the practice’s IT provider suggested adding an assumed-breach component to that year’s test, starting from a standard corporate laptop and an ordinary staff account.

The tester reached Global Administrator in the Microsoft 365 tenant and domain administrator on-premises in under five hours. The path involved no single critical flaw. A script on a shared drive, readable by all staff, contained credentials for a service account. That service account had been granted broad rights years earlier to make a backup product work. From there, the tester could reach the server running directory synchronisation and, through it, administrative control of both environments. Along the way, they had read access to every client folder in the practice. None of the activity triggered an alert.

The external portion of the same engagement found the same small set of medium issues as in previous years. Taken alone, it would have produced another clean report.

Remediation focused on breaking the path rather than working through findings by severity. The script and its credentials were removed and the service account’s password rotated; the account was replaced with a narrowly scoped identity limited to what the backup product actually needed. Standing administrative rights were removed from everyday accounts and moved to separate admin accounts with just-in-time elevation. Client folder permissions were restricted to the teams working on each client. Alerting was added for use of privileged accounts and for access to the directory synchronisation server. A retest six weeks later confirmed the path no longer worked.

Three years of clean reports and we genuinely believed we were well protected. The internal test took one morning to show that any member of staff who clicked the wrong link could have handed someone every client file we hold. The external results were exactly what they had always been — the problem was that we had only ever been asking the outside question.

Two points generalise. The first is that the external test was never wrong; it accurately reported a well-defended perimeter. The organisation had simply mistaken the answer to one question for the answer to another. The second is the path itself: no individual finding was critical, and a severity-sorted remediation would likely have fixed other items first. Breaking the chain at the exposed credentials and the over-privileged service account closed the route entirely.

At a glance — internal against external penetration testing

How Cloudswitched approaches penetration test scoping

Cloudswitched delivers penetration testing for UK organisations, and scoping starts from how your worst incidents would begin rather than from a standard product. In practice that usually means combining external infrastructure and identity-facing services with an assumed-breach internal component from a realistic foothold, putting the Microsoft 365 or cloud tenant explicitly in scope, testing custom applications separately where they warrant it, reporting whether your monitoring detected the activity, and presenting internal findings as attack paths with the remediations that break the most of them identified. Where a contract only requires an external test, we will meet the requirement and tell you plainly what it does and does not answer.

Frequently Asked Questions

What is the difference between internal and external penetration testing?

External testing simulates an attacker on the internet with no access, examining what your organisation exposes — internet-facing systems, edge devices, remote access, mail and public services — to see whether anyone can get in. Internal testing simulates an attacker who already has a foothold, such as a phished user account, a compromised laptop or a malicious insider, and examines how far they could move, whether they could escalate to administrative control, what data they could reach, and whether anyone would notice. One measures the front door; the other measures how contained an incident would be once someone is through it.

Do I need both internal and external testing?

Most UK organisations with a mix of cloud and on-premises systems benefit from both, ideally in a single combined engagement so that findings connect into end-to-end attack paths. External testing addresses opportunistic scanning and targeted break-in attempts and is frequently required by clients and insurers. Internal testing addresses what happens after the mundane initial access that starts most real incidents. If budget allows only one in a given year and your perimeter has been tested recently, internal or assumed-breach testing is usually the larger gap.

Which is more important, internal or external testing?

For most UK SMEs, internal testing answers the more important question, because most incidents begin with ordinary access — a phishing email, a stolen password, a compromised supplier connection — rather than a break-in through the perimeter, and become serious through what that access can reach. In our experience about three internal tests in four reach full administrative control from a standard user account. External testing remains valuable and is often contractually required; the point is that it does not answer the internal question.

What is an assumed-breach penetration test?

An internal test that starts from the position a real attacker most often obtains first: a standard corporate device and an ordinary user account. The tester works out what an attacker with that starting point could reach across the device, the identity platform, cloud services and any on-premises systems. For cloud-first organisations where most staff work remotely, it is usually more representative than plugging a device into an office network, because it mirrors how incidents actually begin in 2026.

How much does internal penetration testing cost compared with external?

Indicatively in the UK for 2026, excluding VAT: external infrastructure testing around £2,000 to £4,500, internal infrastructure £3,000 to £6,500, an assumed-breach engagement from a corporate device £3,500 to £7,500, and a combined external and internal engagement £4,500 to £10,000. Internal testing costs more because there is more to examine. A combined engagement is often better value than buying both separately and lets the tester connect external findings to internal paths.

Does an external penetration test cover Microsoft 365?

Not fully on its own terms. A traditional external test examines internet-facing infrastructure and may touch identity-facing services, but it does not review how your Microsoft 365 tenant is configured — whether a compromised account could forward mail externally, grant itself wider access or register malicious applications. Nor does a traditional internal network test. For cloud-first organisations, the tenant configuration should be explicitly in scope, either as part of an assumed-breach engagement or as a dedicated cloud configuration review.

What is lateral movement and why does it matter?

Lateral movement is an attacker moving from the system they first compromised to other systems within the same environment, typically using credentials, trust relationships and permissions they find along the way. It matters because it is how a single compromised laptop becomes access to file servers, finance systems and administrative control. Internal testing measures how easily that movement is possible; external testing does not examine it at all. Segmentation, least privilege and removing exposed credentials are the usual remedies.

Will an internal test disrupt our business?

Reputable testing is designed to avoid disruption, and the rules of engagement agreed before testing set out what is permitted, what is excluded and how to halt immediately if needed. Internal testing is more likely than external to interact with systems staff use, so fragile or business-critical systems should be identified at scoping so the tester can handle them carefully. Restrictions that protect production are sensible; restrictions that make it impossible for the test to succeed produce a misleadingly reassuring report.

Should our monitoring provider know an internal test is happening?

Brief them on scope and the tester’s starting position, and agree with one named contact how authorised activity will be confirmed, but consider not revealing exact timing. Whether your monitoring detects the tester is one of the most valuable outcomes of an internal test, and that is only measured if the response is genuine. In most internal tests we see, the activity goes unnoticed, which is itself a finding worth acting on.

How should we prioritise internal test findings?

By attack path rather than individual severity. Internal reports describe chains of weaknesses leading from a starting position to an objective, and each link may be modest on its own. Ask, for each path, which single change would break it, and which changes break several at once — usually privilege and credential issues such as standing admin rights, exposed passwords and over-permissioned service accounts. Fixing those often delivers more risk reduction than working down a list of higher-rated but isolated findings. Then commission a retest to confirm the paths no longer work.

Our client only requires an external test. Is that enough?

It satisfies the requirement, and it answers one question. Client and insurer requirements are best treated as a floor rather than a scope. Meeting them with an external test while also commissioning internal or assumed-breach testing based on your own risk profile is the usual approach. Scoping only to the paperwork is how organisations accumulate years of clean external reports without ever measuring how damaging an incident would be.

How often should internal and external testing be done?

Annual testing is common and frequently a contractual floor, but material change is a better trigger than the calendar: a migration to cloud, an acquisition, new remote access arrangements, or significant application releases. Internal testing does not necessarily need to be as frequent as external if the internal estate is stable and earlier findings have been remediated and retested, but it should be repeated after significant changes to identity, privilege or network design. Scope each year from what the previous tests found rather than repeating the same scope by default.

Related reading

More guidance on securing and governing UK business IT:

• Azure identity and access management: securing admin access
• Cyber Essentials and insurance: how certification affects premiums
• Microsoft 365 email archiving and eDiscovery
• VoIP security: preventing toll fraud and call interception
• Backup vendor lock-in: choosing a provider you can leave