Vulnerability Assessment or Penetration Test: Which Should Come First?

We've seen 200-page "penetration test reports" that were nothing but scanner exports: unvalidated, unprioritized, with no explanation of what matters to the business. The client paid for a pentest and got a poor vulnerability assessment. Before you hire anyone, understand that these two services answer different questions.

Two questions

A vulnerability assessment (VA) answers: what weaknesses do we have, and where? Scanners sweep every IP and system in scope for known vulnerabilities (CVEs), misconfigurations and outdated software, then a specialist validates the results to remove false positives.

A penetration test answers: how far could a capable attacker get? A tester attacks for real, with written authorization, chaining small weaknesses together (say a default camera password, plus a flat network, plus an over-privileged service account) to prove they can reach the data that matters.

Why VA should usually come first

If a VA finds critically vulnerable firewall firmware, RDP open to the internet and an NVR still on admin/12345, paying a pentester to find the same things is wasted money. They'll be in on day one, and you'll learn nothing a scanner couldn't have told you.

The order we recommend for most organizations:

1. External VA (every public IP) and internal VA.
2. Fix critical and high findings.
3. Rescan to confirm.
4. Make VA routine and track the trend.
5. Once the basics hold, commission a pentest. Now it will find what scanners can't: logic flaws in applications, misconfigured Active Directory permissions, and paths that chain several weaknesses together.

Types of pentest

• External: from the internet, targeting firewalls, VPN, websites, mail servers.
• Internal: assumes the attacker already has one machine on the network (an infected staff laptop, say). For ransomware risk, this is often the most revealing test.
• Web application / API: based on OWASP guidance; important for banks and businesses with customer-facing apps.
• Wireless: staff and guest Wi-Fi. Can a guest reach the internal network?
• Social engineering: phishing or physical entry.

Information given to testers: black-box (nothing), grey-box (a normal user account and partial diagrams), white-box (documentation and source code). On a limited budget, grey-box gives the best value, because testers don't spend paid days guessing what you could simply tell them.

Before testing starts

1. Written scope: IPs, domains, applications, and what must not be touched. In factories and mines, production control systems (PLC, SCADA) are usually excluded or tested passively only, because ordinary scanning can hang older equipment.
2. Authorization letter signed by someone with authority. If systems are hosted by a cloud or hosting provider, check their testing policy first.
3. Time windows and emergency contacts on both sides. If something goes down mid-test, who stops and who fixes it?
4. Backups of critical systems beforehand.
5. Confidentiality agreement, and how data the testers see or collect will be destroyed.

What to send a provider for a quote

A clear request gets you comparable quotes instead of three proposals that cannot be lined up. Include:

• The number of public IP addresses and domains, and who hosts each one
• Approximate counts of internal servers, PCs, network devices and cameras, by site
• The web applications and APIs in scope, with how many user roles each has
• Whether you want black-box, grey-box or white-box testing
• Systems that must not be touched, and the hours when testing is allowed
• Whether a retest after fixes should be included
• Who will receive the report, and in which language the summary should be

Providers who still ask nothing more after seeing this list are probably going to run a scanner and print the output.

A good report, and what to do with it

A good report has a two-page executive summary, evidence for every finding, business impact, a severity rating, and fix instructions detailed enough for your IT team to follow. If every finding just says "update to the latest version", you're looking at scanner output.

Set remediation targets and track them:

A CVSS score measures technical severity, not your risk. Put internet-facing systems and vulnerabilities known to be actively exploited (for example, those on the CISA KEV list) first, even if their score is lower than others. Then retest to confirm.

Triage example: five findings from a first scan

Here is how we would rank a typical mix from a first external and internal scan. The numbers are illustrative, not from a real client.

Notice that the highest CVSS score is not automatically first, and two of the top three have no CVSS score at all. Scanners report CVSS 3.1 and increasingly CVSS 4.0; FIRST's EPSS adds a probability that a flaw will be exploited soon. Use both alongside the CISA KEV list and your own knowledge of what is exposed.

Authenticated scans find much more

A scan without credentials sees only what a stranger on the network sees: open ports and banners. Give the scanner a read-only account on Windows and Linux hosts and it can list missing patches, weak local settings and outdated software properly. For internal VA, an authenticated scan is the normal choice. Create a dedicated account for it, limit where it can log in from, and disable it between scans.

Devices that get forgotten

Scans often cover servers and PCs only. The weaknesses we find most often are elsewhere: CCTV cameras and NVRs, printers, UPS and PDU network cards, fingerprint scanners, Wi-Fi controllers and switch admin pages. Many have never had a firmware update since installation day.

Choosing a provider

• Ask for a sample report with client details removed. It tells you more than any proposal.
• Ask about methodology: which standards (OWASP, PTES), and how much is manual work versus tooling.
• Ask who will actually do the testing, their qualifications, and their experience with environments like yours.
• Is a retest included in the price?
• Data handling: where findings and collected data are stored, and when they are deleted.

What changes in Lao conditions

• Confirm your public IPs with the ISP. Many offices are behind ISP-managed routers, sometimes with dynamic or shared addresses. Scanning an address that now belongs to someone else is not acceptable, so get the current list in writing.
• Hosted elsewhere. Websites and email often sit with a hosting company in Thailand, Singapore or further away. Their written permission is needed before anything is tested.
• Timing. Avoid month-end closing at banks and accounting teams, and production peaks at factories and mines. Internal scans can slow older switches and printers, so start them outside working hours.
• Language. The executive summary should be readable by management in Lao or Thai, while the technical detail can stay in English for the IT team.
• Staff turnover. Findings often stay open because the person who received the report has left. Assign each finding to a role, not a name, and keep the tracking sheet with IT management.

Send us your public IP list

The easiest starting point is an external VA. Send your public IP addresses and domains with a signed authorization, and we'll scan, validate the results by hand, and send back a fix-first list ranked by real risk rather than CVSS score alone.