Every penetration test starts from a position, and the position decides what the test can tell you. Put the tester on the internet with nothing but your company name, and you learn what a stranger can do to you. Put the pentester inside your office network with an ordinary staff account, and you learn what happens after the stranger gets in, or after someone - an insider threat decides to act. The question is simple: where does the attacker stand when the clock starts?
The attacker positions, in plain terms
An external test simulates an attacker on the public internet with no access and no inside knowledge. They start where a criminal group would start: your domain names, your public IP ranges, whatever a search engine and a port scanner can surface. Everything they reach, they reach the hard way, from outside your perimeter.
An internal pentest assumes the perimeter has already failed. The tester begins with a foothold inside your network: a laptop on your office LAN, or a standard user account. That foothold stands in for the staff member whose credentials were phished, the vendor whose remote access was not restricted, the employee who is not loyal, etc. this is an assumed-breach position. It accepts that one compromised account or device can put an attacker inside your internal network perimeter.
What an external pentest finds
The external tester's first job is discovery: mapping everything your organization exposes to the internet, including the things nobody remembers was being exposed, then they attack it. In practice the findings cluster around a few surfaces:
- Exposed services: remote desktop, databases, admin panels, and file shares that should not be open to the internet.
- Web applications: your customer portal, your careers page, the forgotten subdomain vulnerable to takeovers. Authentication flaws, injection, and access-control gaps live here.
- Mail and identity: the login pages for email and single sign-on, tested for password spraying, weak lockout policies, and missing multi-factor authentication enforcement.
- VPN and remote access.
- Cloud: storage buckets, exposed APIs, and management consoles that sit outside your traditional network but inside your attack surface.
A good external test tells you, with proof, which of these an attacker can actually break. our comparison of vulnerability assessment versus penetration testing covers that distinction in full.
What an internal pentest finds
The internal pentest asks a colder question: once someone is in, how far can they go, and how fast can they move? The tester does what a real intruder does after a breach. They listen to the network, hunt for credentials in shares and scripts, move laterally from the first machine to a second and then a tenth, and escalate privileges wherever a mis-configuration allows it.
The findings are different from the types found on an external test. Flat networks where a receptionist's PC can reach the database servers directly, service accounts with heightened domain privileges and passwords set years ago. Legacy protocols still handing out password hashes to anyone on the network.
Post-exploitation is where the impact becomes concrete. With domain control demonstrated, the report can say plainly: from one laptop, an attacker accesses the finance share, backups, and the payment application, in that order, in this many days.
Why the internal picture shocks boards more
Internal findings feel personal, because the starting assumption is a regular user account. When the report shows one ordinary account could quietly reach the core of the business, directors stop thinking about firewalls and start thinking about people they greet in the corridor.
Nigerian boards have a recent, expensive reason to take that seriously. The FCMB case, where an insider-enabled scheme moved ₦677 million out of the bank without breaching the perimeter at all, is exactly the scenario an internal test rehearses. We examined that incident in our breakdown of the FCMB heist. The controls that failed there were internal ones, and no external test would have found them.
How to choose and sequence
If this is your first serious pentest, start with external coverage. The internet-facing surface is being probed tonight whether you test it or not, and external findings are usually cheaper to fix: close a port, patch a portal, enforce multi-factor authentication on the VPN. An external test also forces the asset discovery work that makes every later engagement better scoped.
Some organizations do not get to choose. Banks and other institutions under the CBN risk-based cybersecurity framework are expected to test in a way that reflects their actual threat picture, and that picture includes insiders. NGX rules require Trading Licence Holders operating online trading portals to complete VAPT twice a year. And any organization that has already had an incident should assume the next attacker gets in too, which makes the internal posture question the urgent one.
Scoping either test well
Whichever position you choose to go for, the scoping conversation decides most of the value. For an external pentest, insist that discovery is in scope so the engagement can find forgotten assets beyond the list you already know about. For an internal test, agree the starting foothold precisely (which segment, what level of account) and agree what "stop" means before anyone touches production data.
Also you would like to ask how the work maps to a published method. Our testing methodology aligns with PTES, OWASP, and NIST SP 800-115, and our senior penetration testers verify every finding manually with proof of concepts, in either position. The overview of our penetration testing services explains how the engagement types differ in practice. And when the report arrives, read it critically: the red flags that expose a padded report apply to internal and external work alike.
