Penetration tests: what they are, when you need them and how they work

"We should get a penetration test done." A sentence almost every IT department hears today, from auditors, customers and regulators. Few people say when a test makes sense and what to expect from it. Here is a practical answer.

What a penetration test is (and is not)

A penetration test is a controlled, authorised attempt to break into a system using the same techniques an attacker would use. The goal is not just to find vulnerabilities but to show what can actually be done with them, how far an attacker gets and to which data.

Do not confuse it with a vulnerability scan. A scan is automated and lists potential weaknesses. A pentest verifies which of them are actually exploitable and thinks through how they chain together. A scan says "there is an unlocked window here"; a pentest says "through this window I got all the way to the customer database".

When it makes sense to order one

• Before releasing a new application or a major change into production.
• For regulatory compliance: NIS2, DORA and a number of standards expect testing; under DORA it is even mandatory and regular.
• At a customer's request in a tender or as part of due diligence.
• After an incident, to verify that the hole really is closed.
• Regularly: once a year and after major changes is a sensible minimum.

Types of tests by the amount of information

• Black box: the tester has no starting information and simulates an external attacker.
• Grey box: limited knowledge (for example an ordinary user account), a realistic "what can an employee or a compromised account do" scenario.
• White box: full access to source code and architecture, the deepest coverage.

Grey box most often makes the most sense; the balance between depth and realism tends to be the best.

How a test runs

1. Scope and rules. What is tested, when, and what is out of bounds. No test is done without written authorisation.
2. Information gathering and mapping of the attack surface.
3. Finding and verifying vulnerabilities, from automation to manual work.
4. Exploitation: controlled abuse to prove the real impact.
5. Report: findings ranked by risk, with evidence and concrete remediation steps.
6. Retest: verification that the fixes actually work.

How to recognise a good report

A bad report is a scanner export with a hundred "medium" findings. A good report prioritises by real risk, describes the attack path, gives understandable remediation advice and separates what is critical from the noise. The value lies in what you fix after the test, not in the length of the PDF.

What to do with the results next

A test is a snapshot in time. The real value comes when you feed the findings into a process: fix the critical items, secure the interfaces that were the entry point (web, API, login) and set up continuous protection so the same hole does not open again next time. Many perimeter findings, unprotected interfaces, missing rate limiting, vulnerable login, no protection against bots and volumetric attacks, can be covered systematically at the network level, not just with a patch in the application.

---

Want to discuss what is worth testing in your environment and how to secure the results at the perimeter right away? We will go through your case in a short consultation. Arrange a free pilot →

Integrity is a certified Cloudflare partner focused on the Czech and Slovak market.