What is a penetration test and when do you need one?

What a penetration test actually is

A penetration test — or pentest — is a controlled, authorised attack on your systems, carried out by a human. The goal isn't to tick off a list of known vulnerabilities, but to investigate whether an attacker can actually get in and, if so, how far they get inside your environment before anyone notices.

The official definition uses terms like "authorised simulation of an attack" and "verification of technical security measures." In practice it comes down to one thing: an experienced specialist using the same tools and thinking patterns as an attacker — but with a signed agreement that this was authorised.

A pentest is explicitly not an automated scan. The difference is fundamental and is often misunderstood by both buyers and suppliers.

Pentest, scan, audit — what's what?

There are three related services that are regularly confused. The difference is more than semantic: it directly determines what you get and what you do not get.

A good security strategy uses all three instruments — but for different purposes, at different times. Anyone who hires a scanner and thinks that's a pentest is buying the wrong product.

What a pentest is not

Let's clear the air on a few common misconceptions:

• A pentest is not an audit. An auditor checks whether you comply on paper with a standard (NEN 7510, ISO 27001, BIO). A pentester validates whether those measures technically work in practice. Both are necessary. They are not substitutes for each other.
• A pentest is not a permanent monitoring product. It's a snapshot. A week later a new developer could introduce a vulnerability that wasn't present during the test. Periodic repetition is therefore the norm.
• A pentest is not a substitute for secure development. It's a final check. If you skip the basics (input validation, authorisation, secret management) and think "the pentester will find it," you'll ultimately pay far more than necessary.
• A pentest is not a DDoS test. Availability tests are a separate discipline, and are never performed without explicit permission, if only because a failed test could take down your production environment.

When you need a pentest

There are four situations where a penetration test is the right answer. If one or more apply, waiting is generally not an option.

1. You need to demonstrably comply with a standard or regulation

NIS2, NEN 7510, ISO 27001, SOC 2, GDPR, BIO — almost every modern compliance requirement expects periodic verification of technical security measures. A pentest is the standard evidence for this. No pentest? Then you need to explain in another way how you fulfil that verification requirement.

2. You're going live with a new application

Before production release of a new web application, API or customer portal, a pentest is the last filter. Not because developers are incompetent, but because an external view of the application systematically sees different things than the person who built it. Half a day of exploitation can save a week of repair after a production incident.

3. You have an important audit moment

A client is about to do a vendor risk assessment. An insurer requests evidence. An investor is starting due diligence. In all these cases, a recent pentest report is the strongest documentation instrument you can provide. Waiting until it's requested means delay and deal risk.

4. You or a supplier have been breached

An incident at your organisation or at a closely linked supplier changes the risk evaluation. A targeted pentest directly after recovery shows that the lessons learned have been technically implemented — not just on paper.

What you get from a pentest

A serious pentest delivers four things you can't get from a scan:

1. A list of genuinely exploitable vulnerabilities, prioritised by impact and exploitability. Not a list of "potential issues" with CVSS scores without context.
2. Reproduction steps per finding. A developer can follow every finding themselves, replicate it and patch it.
3. An executive summary with which you can account to the board, client or regulator for where you stand — in plain language, without jargon.
4. A retest after remediation (included as standard at Resync), to demonstrably record that findings have actually been resolved.

What you do not get is a 200-page report full of scanner output. A good pentest report is typically 30–60 pages, half technical depth and half management-readable.

How much does a pentest cost?

That depends on scope. A small SaaS application with ~5 endpoints and simple authorisation usually costs less than a municipal portal with multiple roles, back-office and external integrations. That's why Resync works with fixed price based on scope — you know the exact price before the test. No surprises, no hourly billing.

You'll usually get an initial indication within one business day after a short intake call. No commitment. More detail on the pricing model and scope categories on the penetration testing page.

How often should I test?

The practical guideline: annually for stable applications, per release for rapidly changing applications, and always after a significant architecture change. For compliance-driven environments (NEN 7510, ISO 27001, SOC 2), annually is typically the minimum. For fast-developing SaaS products, a combination of an annual deep pentest plus continuous automated scanning is often effective.

Conclusion

A penetration test is not a luxury, not a formality. It's the only mechanism that demonstrably shows whether your security works in practice. A scanner makes statements based on patterns. An audit makes statements based on documentation. A pentest makes statements based on what an attacker can actually do in your environment.

Not sure whether a pentest is right for your situation? A free intake conversation gives clarity within 30 minutes — no obligations, no sales pitch. That's exactly what a first contact is for.