Why Regular Penetration Testing Matters

Two extremes dominate the conversation around penetration testing. One holds that it is a waste of money because "they always find something anyway". The other holds that testing once a year is enough and the system is then secure. Both are wrong, and both stem from the same source: misunderstanding what a test is for.

Vulnerability scan or penetration test?

These two are frequently conflated, yet their outputs are fundamentally different.

The essential difference: a scanner gives you a list of what might be wrong. A penetration test shows you what is wrong, and what an attacker achieves with it.

An example from practice. A scanner separately rates three things as "medium": an outdated library, an over-permissive privilege, and default credentials on an internal service. None would justify urgent action. A tester chains all three together and obtains domain administrator privileges. The value of the chain far exceeds the sum of its parts, and only a human sees it.

Why once a year is not enough

The most common approach is an annual test, usually driven by a compliance requirement. That is better than nothing, but it has two problems.

The environment changes constantly. A typical organisation deploys or modifies dozens of systems a year. The results of a January test are largely obsolete by August.

The threat landscape changes too. An annual test does not measure how quickly you respond to a newly published, actively exploited vulnerability.

A workable rhythm looks more like this:

• Continuous vulnerability scanning, automated, across the full asset inventory.
• A full annual penetration test, from external and internal perspectives.
• Ad hoc testing after significant change: a new internet-facing service, a major architectural change, post-acquisition integration.
• A targeted test of the most critical business process once a year, potentially as a red team exercise.

What to test, and from which perspective

Scoping determines the value of the test. The typical perspectives:

External. What an attacker sees from the internet. This is the minimum: but on its own it can create false confidence, because most real incidents begin with phishing, which bypasses the perimeter entirely.

Internal. Starting from a compromised workstation or a guest network connection. For most organisations this is the most instructive: it is where you discover that the internal network is flat, passwords are reused, and nothing impedes lateral movement.

Web application. From authenticated and unauthenticated roles, including business logic flaws, which no scanner will find.

Social engineering. Phishing simulation, possibly physical intrusion. This measures the most common real-world attack vector.

OT/ICS. Industrial environments require a distinct approach, see below.

OT environments change the rules

On an industrial network, standard penetration testing methodology is dangerous. Aggressive port scanning can knock over a PLC; an exploitation attempt can halt production.

OT testing therefore typically:

• begins with passive discovery from traffic mirroring,
• performs active work in a lab or during planned downtime, ideally on identical spare hardware,
• focuses on segmentation verification: can you really not cross from IT into OT? Do the zone boundaries hold?
• often concludes with a theoretical attack chain rather than actual exploitation, where the risk of execution is unacceptable.

We covered this in more depth on our OT penetration testing page.

How to recognise a good report

The report is the only thing that remains after the test. Look for these:

Reproducible evidence. Step-by-step description, screenshots, requests and responses. If you cannot reproduce it yourself, you will not be able to verify the fix either.

Prioritisation by business impact, not CVSS. CVSS measures theoretical severity, not what it means in your environment. A "medium" flaw in your payment flow matters more than a "high" on an isolated test system.

Attack chains, not just isolated findings. As above: the value is in the chain.

Concrete remediation guidance. Not "strengthen access control", but which configuration to change and where.

An executive summary, in plain language, so decision-makers can act on it.

Included retesting. Without a verification round after remediation, you do not know whether the flaw is actually gone.

The compliance angle

Regular testing is not only good practice, it is expected in several frameworks. NIS2 measure area five (security in acquisition, development and maintenance) and area six (measuring the effectiveness of security measures) effectively require regular, documented testing. The ISO 27001 control on technical compliance review points the same way, and PCI DSS mandates it explicitly.

The order matters, though: do not test in order to have paper. Test in order to find out what works, the paper will follow as a by-product.

What to do after the report

The value of a test is realised in remediation. A workable process:

1. Triage, classify findings by business impact, assign owners.
2. Immediate action on critical items, with temporary compensating controls if necessary.
3. Scheduled remediation for the rest, with firm deadlines.
4. Root cause analysis, why did the flaw exist? If the same class of flaw appears in several places, you have a process problem, not a configuration problem.
5. Retest to verify the fixes.
6. Feedback into development and operations processes.

Step five is the one most often skipped, yet it is what separates an improving security programme from one that finds the same flaws year after year.

If testing is on your agenda, our penetration testing service starts with scope alignment and ends with a retest.