External or internal pentest: which one first?

TL;DR

• An external pentest shows what an attacker sees from the internet: websites, VPN, mail, exposed services and the hosts everyone forgot about.
• An internal pentest starts from a first foothold, such as a stolen password or an infected laptop, and measures how far someone gets in Active Directory or Entra ID.
• Start external if you do not know what you expose. Start internal if you assume someone will get in anyway.
• Auditors and insurers often ask for both. A retest is always included, and testing on demand is possible through RedSOC.

Almost every first conversation about a penetration test reaches the same question within ten minutes. External or internal, and which one first? The honest answer is that it depends on what you already know about your own environment, and most teams know less than they think. So here is a short decision guide. If you would rather not choose once a year but test whenever something changes, RedSOC offers pentesting on demand. First, what the two tests actually look at.

What an external pentest sees

An external pentest takes the position of someone on the internet with no account and no inside knowledge. The scope is whatever answers from the outside: your websites and web applications, the VPN gateway, mail servers, remote access portals, APIs, cloud services you put online and the hosts nobody remembers.

That last group is where the surprises live. A test server from a project that ended two years ago. A staging copy of the webshop with a default password. An old portal that still answers because nobody dared to switch it off. The tester maps all of that, then tries to get in: outdated software, weak or reused passwords, misconfigurations, admin panels left open.

The result is a list of ways in, ranked by how easily someone could use them. For a lot of organisations it is the first time anyone has looked at the company the way an outsider does. Our network pentest page describes the scope in more detail, and our post on what a pentest is covers the basics.

What an internal pentest does after a first foothold

An internal pentest starts where the external one stops. We assume someone is already in. That is simply how most incidents begin: a phishing click, a password stolen by an infostealer on a private laptop, a contractor account that was never closed. We wrote about the infostealer route earlier, because it is the most ordinary way a "secure" network gets an uninvited guest.

So the tester gets what an attacker would have: a standard user account, a laptop on the office network or VPN access with low privileges. From there the question is simple. How far can this person get?

In practice that means Active Directory or Entra ID. Can a regular user read things they should not? Are there service accounts with weak passwords? Is there a path from a helpdesk account to domain admin? Can a compromised laptop reach the backup server, the file shares, the finance system? An internal test often ends further than the client expected. A network that grew over fifteen years is full of shortcuts, and the tester only needs one.

An internal test says nothing about your perimeter. It says everything about what one bad click costs you.

A short decision guide

Start external if any of this applies. You have never had a pentest. You are not sure what is reachable from the internet. You recently moved things to the cloud, merged with another company or changed IT partner. A customer or auditor asked for proof that your public systems were tested.

Start internal if this sounds more like you. You already had an external test and fixed what it found. You assume someone will get in eventually, through phishing or a stolen password, and you want to know what happens next. Your worry is ransomware rather than a defaced website. Your Active Directory is old and nobody fully knows what lives in it.

If you have budget for one test and no idea where you stand, go external. It is the cheapest mistake to correct. If you had an external test in the past year, go internal. The attack that hurts rarely comes through the firewall. It comes through a mailbox.

If you run both, keep that order and leave a few weeks in between. What the external test finds often changes the starting point of the internal one.

Auditors and insurers often ask for both

Cyber insurers often ask for evidence of regular testing before they write or renew a policy, and the questionnaire rarely distinguishes between the two. Frameworks such as ISO 27001 and the NIS2 directive expect you to assess your technical measures and to show that you repeat it. They do not prescribe a test type. What an auditor wants to see is that you know your attack surface from the outside, and that you have measured what happens once that surface is breached. Our compliance pentest page explains how we scope a test when the driver is an audit rather than a recent scare. The pentest checklist helps you prepare the scoping conversation.

Retest always included

Whatever you choose first, a pentest without a retest is a report, not a result. Every Sectricity pentest includes a retest: once you have fixed the findings, we check whether the fix really closed the path and update the report. That is the document an auditor or insurer wants, because it shows the problem and the proof that it is gone. We explained earlier why we do not sell the retest separately.

For organisations that change often, a yearly external and internal test is not enough. A new web application or a new cloud tenant creates ground nobody has tested yet. RedSOC is our answer to that: pentesting on demand, when something changes, without a new procurement round every time. How it works is in our RedSOC post.

Frequently asked questions

What is the difference between an external and an internal pentest?

An external pentest tests what an attacker can reach from the internet without an account: websites, VPN, mail, exposed services. An internal pentest starts from a foothold inside the network, such as a user account or a laptop, and measures how far an attacker gets in Active Directory or Entra ID.

Which pentest should you do first?

Start external if you do not know what your organisation exposes to the internet or have never been tested. Start internal if you already had an external test, or if you assume an attacker will get in through phishing or stolen credentials anyway.

Does an internal pentest require someone on site?

Not necessarily. An internal test can run on site or remotely, for example through a VPN account with normal user rights. What fits depends on your environment and is agreed during scoping.

What does an internal pentest look at in Active Directory or Entra ID?

Paths from a normal user to administrator, weak or reused passwords on service accounts, excessive rights, legacy protocols, misconfigured trust relationships and what a compromised device can reach in the rest of the network.

Do auditors and insurers require both tests?

Often, yes. Cyber insurers and frameworks such as ISO 27001 and NIS2 expect regular testing of your technical measures, without prescribing one type. Having both an external and an internal test on file makes that conversation easier. See our compliance pentest.

Is a retest included?

Yes. Every Sectricity pentest includes a retest of the findings after you have fixed them, so your final report shows what was found and what has been closed.

Can you test on demand instead of once a year?

Yes. Through RedSOC we offer pentesting on demand: you test when something changes, such as a new application or a new cloud environment, instead of waiting for the yearly round.

Related services and resources

Our penetration testing services cover both the external and the internal side, with the network pentest as the usual starting point and a retest included in every engagement. If an audit or an insurer is the reason you are reading this, our compliance pentest is the better fit. For testing on demand there is RedSOC. Background reading: what a pentest is, our pentest checklist, why the retest is always included, how stolen credentials from infostealers become an internal foothold, and how RedSOC works.