On this page
Only ever tested your perimeter? Run the free scan at scan.sumrite.com for the external view, then talk to us about the internal picture a scanner cannot reach.
“We get pentested every year” almost always means an external test. That is a good habit, but it answers only half the question. The other half, what happens after someone gets in, is where incidents actually turn into disasters, and it is the half most often left untested.
Two different attackers
| External penetration test | Internal penetration test | |
|---|---|---|
| Vantage point | The public internet | Inside the network, or an assumed-breach foothold |
| Attacker simulated | An outsider with no access | A malicious insider, or an outsider who already breached the perimeter |
| Typical scope | Websites, apps, APIs, VPNs, email, exposed infrastructure | Internal networks, Active Directory, file shares, databases, admin systems |
| Core question | Can someone get in from outside? | Once in, how far can they go? |
| Common findings | Exposed services, unpatched edge systems, weak authentication, web and API flaws | Over-privileged accounts, weak segmentation, privilege escalation, lateral movement to crown jewels |
What external testing covers
External testing maps and attacks everything you expose to the internet: web applications, APIs, remote access, mail, and any infrastructure with a public address. It is the first thing worth doing because it reflects the most constant threat, the automated and opportunistic attacker scanning the internet. A good external test goes well beyond a scan: it exploits what it finds, chains issues together, and tests the business logic of your applications. Our web application VAPT guide covers that application layer in depth.
The limitation of external testing is the assumption underneath it: that keeping attackers out is enough. It rarely is.
Why the perimeter is not the whole story
Attackers do not always break down the front door; often they are handed a key. Phishing captures a password. A reused credential appears in a breach dump. A contractor’s laptop is compromised. A supply-chain update carries malware. In every case, the attacker starts inside, and your external test said nothing about what happens next.
That “next” is the expensive part. Ransomware crews rarely exploit a clever external bug; they get an initial foothold, then move laterally, escalate privileges and reach the systems that let them encrypt or exfiltrate everything. Internal testing is how you find out whether that journey is a five-minute sprint or a hard climb.
Assumed breach is the realistic default
Modern internal tests usually start from “assume the attacker already has a foothold”, for example a standard employee device or a low-privilege account. It skips the argument about whether the perimeter can be breached (it can) and spends the time on the question that matters: how bad is it once they are in?
What internal testing reveals
From an inside starting point, a tester looks for the things that turn one compromised laptop into a company-wide incident:
- Flat networks with no segmentation between user devices and critical systems
- Over-privileged accounts and service accounts with far more access than they need
- Weak internal authentication and cached credentials ripe for harvesting
- Privilege escalation paths through misconfigured systems and Active Directory
- Sensitive data on open file shares and databases with weak access control
- Missing monitoring, so lateral movement would go unnoticed
These are exactly the weaknesses our article on the absence of RBAC describes, seen from the network rather than the application.
Where cloud fits
In cloud environments, “internal vs external” shifts from network location to identity. The external view is still your public endpoints, but the internal view becomes an assumed-breach test from a low-privilege account, a compromised workload or a leaked key, following identity and permission paths rather than network segments. The two-perspective principle holds; the mechanics change. Our guide to cloud penetration testing on AWS, Azure and GCP goes deeper.
Which should you do, and when
- Never tested? Start external. Close the most exposed, internet-reachable issues first.
- Add internal next. Once the perimeter is in reasonable shape, test the blast radius with an assumed-breach internal engagement.
- Let compliance steer the cadence. Many frameworks expect both over time; map the scope to what you must evidence.
- Re-run after change. A new office network, a cloud migration or a big release can reopen either side.
- Graduate to red teaming. When both are mature, a red team exercise tests detection and response across the whole path. See red team vs penetration testing.
How Summit helps
Summit runs both perspectives. Our network penetration testing covers external perimeter testing and internal, assumed-breach engagements, alongside web application and cloud testing for the systems that sit on each side. Every engagement is manual, evidence-led and retested. When you are ready to test detection as well as exposure, our red team operations tie it all together. Start with the free external check at scan.sumrite.com.
Cover both the outside and the inside
Tell us what you have tested so far. We will scope the external and internal testing that closes the gap. Get a quote or run the free scan first.
Related reading: Black-box, grey-box and white-box testing · Types of penetration testing · Red team vs penetration testing
Frequently asked questions
What is external penetration testing?
Testing from outside your network, against your internet-facing systems: websites, applications, APIs, VPNs, email and exposed infrastructure. It simulates an attacker on the internet with no prior access, and answers how well your perimeter holds up.
What is internal penetration testing?
Testing from inside your network, usually from an assumed-breach position such as a standard employee device or a foothold an attacker might gain. It simulates what someone could do once inside: move laterally, escalate privileges and reach sensitive systems and data.
Do I need both internal and external penetration testing?
Most organisations do. External testing alone assumes the perimeter never fails, which is unrealistic given phishing, stolen credentials and supply-chain compromise. Internal testing shows how far a breach would spread. Together they cover the full picture.
Which should I do first?
If you have never tested, start with external to close the most exposed, internet-reachable issues, then add internal to understand blast radius. Compliance or a recent incident may change the priority.
Does cloud change internal vs external?
Yes. In cloud environments the boundary is identity more than network location, so 'internal' often means an assumed-breach test from a low-privilege account or workload. The principle, test both the outside view and the post-foothold view, still holds.
How do I scope this?
Run Summit's free scan at scan.sumrite.com for your external exposure, then talk to us about the internal, assumed-breach testing a scanner cannot do.
