Internal vs external penetration testing

External testing starts from outside your network, so its first phase is about what an attacker on the public internet can already see. NIST SP 800-115 describes it as reconnaissance of public sources such as registration records and DNS data, followed by network discovery and scanning to enumerate external hosts and the services listening on them. Only after that inventory does the tester attempt to validate exposed weaknesses, such as a vulnerable remote access service or a misconfigured web application. Because this work depends on what is publicly reachable, the buyer's first deliverable is an accurate external inventory of IP ranges, domains and hosts that the tester is authorized to touch.

The PCI SSC guidance adds a practical condition that affects the result. External tests should run from a location without port or service restrictions imposed by the internet provider, so that filtering at the provider does not hide services the test is meant to find. Before the engagement, confirm with your provider and your own perimeter team whether any upstream filtering, DDoS protection or web application firewall will sit in the path, and decide whether the test should cover the perimeter as attackers see it or the origin systems behind it. Record that decision in the scope, because it determines whether a clean result means the services are closed or simply blocked for this one source.

The buyer must supply the written scope list, the IP ranges and domain names in scope, and the rules of engagement modeled on the template in Appendix B of NIST SP 800-115. The rules should name permitted techniques, testing windows, stop conditions, a contact for escalation and how third-party hosting providers and cloud platforms will be handled, since some providers require their own notice before testing. Ask the testing firm to list which inventory sources it used and to confirm that out-of-scope addresses will not be probed, and keep that list with the signed scope so auditors can trace every finding to an authorized target.

External testing needs no credentials, because the tester starts from the public internet and works only from the scope the buyer publishes or approves. Before work begins, the buyer should confirm the exact list of public IP addresses, domains and listening services in scope, and whether any third-party hosted assets (such as SaaS tenants or cloud load balancers) are included or must be excluded. NIST SP 800-115 describes external work as beginning with reconnaissance of public registration data and DNS, then discovery and scanning of exposed hosts, so the scope document should name what the tester may touch and what it must leave alone.

Internal testing depends far more on access decisions. NIST SP 800-115 notes that internal testers are often given network access as general users, then attempt privilege escalation, so the buyer must decide which account or machine the tester starts from. CIS Safeguard 18.5 notes that internal tests may be clear box, where testers receive architecture and configuration detail, or opaque box, where they start with little knowledge. Ask the provider which model they propose, how test accounts will be provisioned and disabled, and whether those accounts will be subject to the same logging and multi-factor controls as ordinary staff accounts.

NIST SP 800-115 Appendix B provides a rules of engagement template, and it is the right place to record access, timing and contacts in one signed document. Use it to name the source network segments, the test-machine location, the escalation contacts who can stop testing, the testing windows, and the emergency procedure if a service degrades. The buyer should also confirm network placement and test-machine location with the provider: a tester on a neutral internet connection outside corporate access controls will see a different perimeter than one connected from inside, and PCI SSC guidance addresses this distinction directly, so the results will only be comparable if the placement is written down.

Organizations combine techniques to reach an in-depth assessment at an acceptable level of risk, and NIST SP 800-115 describes exactly this approach. For internal versus external work, the practical question is sequencing. Run external testing first, as the guide recommends, so that the testers who later work from the inside do not start with knowledge an outside attacker would not have. Then pair the viewpoints with a cadence: NIST SP 800-115 suggests regularly scheduled network and vulnerability scanning interspersed with periodic penetration testing. Scans catch drift between tests, while the penetration test validates whether exposed weaknesses can actually be chained into access. Ask your provider to show how each engagement's findings feed the next scan schedule, and confirm who owns that handoff in your organization.

Retesting is where many programs lose value. A finding closed in a ticket is not closed until a tester has checked the fix from the same viewpoint that found it, and an external fix should be verified from outside as well as inside. Agree the retest window and whether retests are included in the original scope before work starts, since many quotes treat them as separate work. Also ask whether validated fixes are reflected in your detection rules. CIS Controls Safeguard 18.4 asks for security measures to be validated after each test so that detections cover the techniques the testers used, which means the retest should confirm that monitoring still fires, not only that the vulnerable component was patched.

Two adjacent topics affect how you combine viewpoints, and each deserves its own review. Segmentation testing checks whether networks out of scope can reach the cardholder data environment, which is a narrower question than a full internal test, and PCI DSS requirement 11.4.5 and 11.4.6 set frequencies you should confirm against your own assessor's expectations. Red teaming goes further than either viewpoint by emulating an adversary's objectives and testing detection and response. Most organizations build the internal and external layers first. Treat red teaming as a later decision, and confirm with your provider whether an internal test's findings are a sound starting point for it.