Kantyra
Kantyra
Alain Rees · 12-07-2026 · 12 min leestijd
A penetration test, usually called a pentest, is a controlled attack on your own systems to find vulnerabilities before a real attacker does. A one-off pentest produces a report, but only a structured approach delivers real value. This article explains why you test, how to set up a pentest policy and a pentest calendar, what belongs in a good pentest report and what you do with the findings afterwards.
In short
- A pentest simulates a real attack and shows which vulnerabilities are actually exploitable in your context.
- A pentest policy records what you test, how often, by whom and under which conditions.
- A pentest calendar plans the tests ahead and ties them to changes and new systems.
- A pentest report is only useful once you follow up on the findings, remediate them and have them retested.
- You make the whole demonstrable by managing the findings in a register that connects to your ISMS.
- The penetration testing process coincides with the four phases of the Kantyra model: detect, assess, resolve and demonstrate.
A pentest is an authorised, controlled attempt to break into your systems, carried out by an expert who thinks and acts like an attacker. The goal is not to cause damage, but to show where you are weak and what the consequences would be if someone exploited that weakness.
The distinction from a vulnerability scan matters. A scan is automated and finds known vulnerabilities, but says little about the real impact. A pentest goes further. A tester combines separate weaknesses into a genuine attack chain and shows how far someone can get. This way you know not only that a vulnerability exists, but also what an attacker could achieve with it in your environment.
Pentesting is sensible for several reasons, and sometimes even necessary.
The main reason is that you find vulnerabilities before attackers do. You gain insight into real, exploitable weaknesses instead of a theoretical list, and you can remediate them at a moment you choose yourself.
Then there is demonstrability. The ISO 27001 standard requires you to manage technical vulnerabilities and test your controls periodically, and a pentest is the common way to do that. The duty of care in the Cyber Security Act (Cbw) also requires appropriate measures, and you must be able to substantiate those measures. On top of that, customers and clients increasingly ask for a recent test report before they do business with you.
Finally, a pentest gives your board and your security team a realistic picture. A successful break-in in a test environment conveys something a list of risks never gets across.
Not every pentest is the same. Before you test, you determine the scope: what exactly is examined and with how much prior knowledge.
In terms of prior knowledge there are three variants. In a test without prior knowledge (black box) the tester starts with nothing, just like an outsider. In a test with full prior knowledge (white box) the tester gets documentation and access, which allows deeper digging. A test with partial prior knowledge (grey box) sits in between and is the most common in practice.
In terms of subject you can have various things tested, such as a web application, your external or internal network, a mobile app, a cloud environment or the deception of employees. That last form, testing whether employees are susceptible to deception, touches on your awareness and your security culture.
The choice depends on what you want to know and on your risks. A good tester advises you on this, but the final responsibility for the scope rests with you.
A pentest policy turns separate tests into a coherent approach. It is the framework in which you record how your organisation handles pentesting. A sound pentest policy describes at least the following points:
That last point is crucial. Without arrangements about follow-up, a pentest remains a snapshot without consequence.
Where the policy forms the framework, the pentest calendar schedules the tests concretely. The calendar prevents pentests from happening ad hoc and ensures that your critical systems come up for testing at a fixed regularity.
In the calendar you record which system is tested when and by whom. Usually you test your critical systems at least annually, and in addition you test at fixed moments, for instance before a new application goes into production, after a substantial change or with a major new version. This way you tie the calendar to your change management and your planning of new versions, and you test at the moments when the risk changes.
A calendar also helps with planning your budget and the availability of a suitable party, because good testers are not always available at short notice.
A pentest usually goes through a fixed set of phases. If you know what they look like, you can guide a test better.
The retest is often forgotten, while it is what gives you the certainty that a problem has really been solved.
The pentest report is the tangible result, but its quality determines how much you get out of it. A good report contains the following components:
A report that merely gives a list of vulnerabilities, without impact and prioritisation, forces you to do the real work yourself. Ask for these components in advance, so you can use the report right away.
Here sits the step that makes the difference between ticking a box and actually becoming safer. A report is only valuable once you follow up on the findings.
For each finding you assign an owner and set a remediation deadline based on the severity. You tackle a critical finding immediately; a minor finding can wait for a suitable moment. After remediation you have a retest carried out to confirm that the problem is really gone. You escalate the most severe findings to your risk register, so they remain visible at board level until they are resolved.
You can store pentest reports in a folder, but then you lose the overview as soon as you have more than a couple of tests done per year. The basis of a mature approach is therefore a findings register: a current overview of every finding, with its severity, owner, remediation deadline, status and retest date.
In Kantyra you register every finding from a pentest with the source "pentest", or you import the entire report in one go from Excel, with the report itself attached as evidence. From that register the lines run to the rest of your system of control. You link a finding to the affected assets and to the risks it touches, and for a finding with high or critical severity Kantyra automatically creates a reassessment task for the linked risk, just as with an incident. This way a severe vulnerability escalates to your risk register by itself, instead of remaining in a report. You record the remediation action on the finding itself, with an owner and a deadline, and after remediation you schedule the retest with its own retest date: as it approaches, the retest automatically appears as a task, so the most often forgotten step is no longer skipped. You manage the security measures that follow from a test as controls. This way pentesting connects directly to your information security and risk management (ISMS) in line with ISO 27001.
Of all the topics in this series, pentesting starts most clearly at the bottom of the model, with detect. A pentest is, first and foremost, a signal: it brings to light what can really go wrong.
It starts with detect: the calendar plans the test, that test finds the vulnerabilities, and you register every finding with the source "pentest". Then follows assess: you weigh each finding by severity, and you escalate the most severe to the risk register. In the resolve phase the pentest policy provides the systematic approach, you remediate by severity with an owner and a deadline, and you have a retest carried out; the retest date is monitored along the way. And in the demonstrate phase, the findings register, the retest evidence and the report together form the file for the auditor and the customer.
That is precisely why a pentest report is so often a dead document: many organisations get stuck at detect and never let the signal run through the cycle. A pentest only delivers value once the finding works through to a risk, a remediation action and ultimately the evidence that the problem is really gone. The model forces that flow-through, so the test is a starting point rather than an end point.
You can keep your pentest policy, your calendar and your findings in loose files, and as a start that is defensible. But as you test more and the regulator or your customer asks for demonstrability, you run into the same limits as in any other compliance effort. Loose files drift apart, and you lack the overview and the history you need.
In a GRC platform, you manage the pentest policy, the planning and the findings register within a single environment. Every finding has an owner, a status, a remediation deadline and a retest date, and the connection with your risk register and your tasks prevents an open risk from dropping out of sight.
With Kantyra you manage your pentest process in the same environment as your ISMS. You record the pentest policy as a policy document with version control and approval, you plan the recurring test as an effectiveness test on the control involved (the planned test date with an automatic reminder forms your calendar), and you process the report in the findings register. Whether you see pentesting as a stand-alone activity or as part of your broader security, your findings, your risks and your remediation actions come together in one place, in line with ISO 27001. This makes your pentest process just as demonstrable as the rest of your security.
What is the difference between a pentest and a vulnerability scan? A scan is automated and finds known vulnerabilities. A pentest goes further and shows whether those vulnerabilities are really exploitable in your context and what the impact is. A scan is broad and fast, a pentest is deep and targeted.
How often should you pentest? For critical systems, at least annually is common. In addition you test at fixed moments, for instance before a new application goes into production or after a substantial change. The right frequency depends on your risks.
Are you obliged to pentest? The law does not literally prescribe a pentest, but ISO 27001 and the duty of care in the Cbw require you to test your controls and manage technical vulnerabilities. A pentest is the common way to do that, and customers often make it contractually mandatory.
Who may carry out a pentest? An internal team can test, but an independent external party gives a more objective picture and more value towards customers and regulators. In all cases, clear authorisation and arrangements in advance are necessary.
What do you do with the findings? You assign an owner per finding, remediate within a deadline based on the severity, and have retests carried out. You escalate the most severe findings to your risk register, and you keep everything in a findings register.
Would you rather not manage your pentest process in loose files, but in one environment that connects to your information security? With Kantyra you record your pentest policy as a policy document, plan the recurring test as an effectiveness test on the control involved and process the report in the findings register, linked to your risks and your tasks, in line with ISO 27001. This makes your pentest process demonstrable and clear, and no finding drops out of sight. Request a demo and discover how to build pentesting on top of your existing ISMS.
Kantyra is a Dutch ISMS and GRC platform that lets organisations manage their information security, risk management and compliance demonstrably, in line with standards such as ISO 27001 and ISO 22301 and with legislation such as the GDPR, the Dutch Cyber Security Act and the AI Act.
In een demo van 30 minuten lopen we het model door aan de hand van jouw situatie.
Plan een demoThe GDPR sets rules for processing personal data and revolves around one core idea: accountability. This article covers the core principles, the six legal bases, the rights of data subjects and the data breach notification duty, and shows how compliance coincides with the four phases of the Kantyra model.
The AI Act works on a risk basis: the greater the risk of an AI system, the heavier the requirements. This article covers the four risk levels, your role as provider or deployer, the timeline and the AI literacy obligation, and shows how compliance coincides with the four phases of the Kantyra model.
Compliance management has a dusty reputation of ticking off lists, but designed well it is the process that translates requirements from legislation, standards and contracts into one set of controls with evidence. This article describes the five steps, the division of roles, and where the process sits in the Kantyra model.