# External vs internal penetration testing: which one to buy

Source: https://penetrationtestservices.com/guides/external-vs-internal-penetration-testing/
Publisher: Excession Labs (penetrationtestservices.com)
Last updated: 2026-11-09

External vs internal penetration testing for a SaaS app and API: what each covers, how the terms map to cloud, which to buy first, and a scoping checklist.

> **Short answer:** An external penetration test attacks what anyone on the internet can reach, with no credentials. An internal test starts from inside: a network foothold or a signed-in account. For a cloud-hosted web app and API, external means the public app, API and login. Internal means each signed-in role and tenant. Most SaaS teams buy external first, then an authenticated test.

External penetration testing means testing your systems the way an anonymous person on the internet would. Internal penetration testing means testing from a position of access: a foothold inside a network, or a signed-in account. The terms come from network testing. For a web app, API or SaaS product they need translating, and that translation decides what you buy.

## External vs internal penetration testing in one table

The two differ in starting point, targets and the question each one answers.

| | External | Internal |
|---|---|---|
| Starting point | The internet, no credentials | A foothold: network access or a signed-in account |
| Typical targets | Public hosts, login pages, public API routes, DNS, exposed services | Authenticated app areas, admin paths, internal APIs, other tenants' data |
| Question | What can a stranger reach or break? | What can a user, a stolen account or a compromised machine reach? |
| Web and SaaS reading | The public app, API and sign-up and login flows | Each role and tenant, tested with accounts you provide |
| Network reading | Firewalls, VPNs, exposed ports | Servers, file shares, directory services behind the perimeter |

PCI DSS v4.0 requirement 11.4.1 says the pentest methodology defines both internal testing (from inside the network) and external testing (from outside), per the PCI Security Standards Council summary of changes (checked 9 November 2026).

## What does an external penetration test cover?

An external test finds what an unauthenticated attacker can reach and abuse. The tester maps the public attack surface first, then probes it.

For a web application and API, that work includes:

- Public hosts and subdomains, including forgotten ones.
- Login, sign-up, password reset and invitation flows, which any visitor can call.
- Public API routes and what they return without a token.
- Transport and header settings, error messages and exposed files.
- Exposed services and admin consoles on the internet.

Authorization flaws behind the login are out of reach for a pure external test, because the tester cannot sign in. That is the main limit. A broken object-level authorization flaw, where user A reads user B's record, needs an account to find. See [IDOR testing](/guides/idor-testing/).

## What does an internal penetration test cover?

An internal test starts from access and asks how far that access goes. In a classic network test the start is a connected machine. In a web app test the start is an account.

For a SaaS app, the internal side covers:

- Each user role, from viewer to owner, and what each can do beyond its rights.
- Cross-tenant access: can tenant A read or change tenant B's data?
- Admin and support paths that a normal user should not reach.
- Internal APIs and service calls the browser app depends on.
- Session handling, token scope and what a stolen token allows.

Our [multi-tenant isolation guide](/guides/multi-tenant-isolation-testing/) shows how the two-account method works. Tenant-isolation proof needs at least two accounts in two tenants.

## How do the terms apply to a SaaS app and API?

A cloud-hosted SaaS product has no office-style internal network for the tester to plug into. The inside is the set of trust levels in your application.

Use this mapping when you write the scope:

| Network term | SaaS and API reading |
|---|---|
| External test | Anonymous black-box test of public app, API and login |
| Internal test | Authenticated test with accounts for each role and tenant |
| Assumed breach | Test that starts from a named account, token or leaked key |
| Internal network | Your cloud account, private network and CI/CD, only if you scope them |

An assumed-breach test starts with a stated foothold and measures how far it goes. In SaaS the foothold is often a normal customer account, because anyone can sign up for one.

Excession Labs tests web applications, APIs and multi-tenant SaaS platforms. A classic internal network or directory-service test is not on that list. If you need one, ask a provider that lists network testing.

## Which one first, and when do you need both?

For most SaaS teams the order is external first, then authenticated. The external pass is quick to scope and shows what is exposed to everyone. The authenticated pass then goes where the real data lives.

Buy both in one engagement when:

- A customer or auditor asks for internal and external testing. PCI DSS 11.4 does for the cardholder data environment.
- Your product is multi-tenant, so cross-tenant access is the main risk.
- You release often and the public surface changes with each release.

Buy only authenticated testing when the app has no meaningful public surface beyond login. The grey-box method in [black box, grey box and white box testing](/guides/black-box-grey-box-white-box-testing/) fits that case, since it gives the tester accounts and docs. The broader menu is in [types of penetration testing](/guides/types-of-penetration-testing/).

## Scoping checklist for each type

The NCSC says scoping should bring together the risk owners, technical staff who know the system and a representative of the test team. It also says to agree the technical boundaries, the type of test and the time and effort (checked 9 November 2026). Use these lists as the input.

External scope:

- [ ] Domains and subdomains in scope, and any out of scope
- [ ] Public IP ranges or cloud load balancers
- [ ] API base URLs and public route list
- [ ] Hosting and cloud provider testing policies checked
- [ ] WAF and rate limit decision: allowlist the tester or not
- [ ] Test windows, time zone and an escalation contact

Internal scope:

- [ ] Accounts for each role, in at least two tenants
- [ ] MFA path for test accounts
- [ ] Test data marked as test data
- [ ] OpenAPI file, GraphQL schema or Postman collection
- [ ] Admin and support paths named, in or out
- [ ] Limits for emails, uploads, password guessing and paid APIs

Write the rules down in the [rules of engagement](/guides/penetration-testing-rules-of-engagement/), and finish the [preparation checklist](/guides/how-to-prepare-for-a-penetration-test/) before the start date.

## What should the report show for each?

The report should say which starting point each finding used. A reader needs to know if a flaw needs no login or needs a customer account.

Ask for these items:

1. The scope as tested, including what was left out.
2. For each finding: the starting position (anonymous, role X, tenant Y), the evidence and the fix.
3. Controls that held, so you know what was tested and did not fail.
4. Limits and open questions, such as areas the tester could not reach.

Our reports state evidence labels and a "Controls that held" section. See [how to read a penetration testing report](/guides/how-to-read-a-penetration-testing-report/).

## Common mistakes

Scope that is too narrow is the most frequent mistake. A list that names only the marketing site leaves the app and API untested. List every host the product uses.

Two other mistakes cost time. Teams buy an external test and read it as proof that logged-in data is safe, which it does not show. Teams also skip the retest, so fixes go unchecked. Ask for a retest of fixed findings when you scope the work; see [after the pentest](/guides/after-the-pentest-remediation-and-retest/).

## Questions

### Do I need both an external and an internal pentest?

Often yes, over time. External shows what an anonymous visitor can reach. Internal shows what a signed-in user, a stolen account or a compromised network position can reach. PCI DSS 11.4 asks for both internal and external testing for the cardholder data environment.

### Does a cloud-hosted SaaS app have an internal network?

Your app may have no office-style network to test. It still has internal trust levels: signed-in roles, tenants, admin paths and service-to-service calls. Test those as the internal side. Your cloud account and any private network are separate scope items.

### Can an external test use test accounts?

No. By the usual definition an external test starts without credentials. Once you give accounts, the test is authenticated, which is the internal side for a web app. Many scopes combine both.

### Is an assumed-breach test the same as an internal test?

It is one form of it. The tester starts with a stated foothold, such as a normal user account or a laptop on the network, and tries to go further. The scope names the starting point.

## Sources

- [PCI DSS v3.2.1 to v4.0 Summary of Changes (requirement 11.4.1: internal and external testing)](https://listings.pcisecuritystandards.org/documents/PCI-DSS-v3-2-1-to-v4-0-Summary-of-Changes-r1.pdf)
- [NIST SP 800-115: Technical Guide to Information Security Testing and Assessment](https://csrc.nist.gov/pubs/sp/800/115/final)
- [NCSC: Penetration testing (scoping guidance)](https://www.ncsc.gov.uk/guidance/penetration-testing)
- [OWASP Web Security Testing Guide](https://wstg.owasp.org/)