A test tells you where it hurts. It does not fix it.
More and more customers, insurers and auditors ask for a penetration test. This page explains when one pays off, what it delivers, what it does not deliver, and what has to happen afterwards so the report does not end up in a folder.
We do not carry out penetration tests ourselves. We tell you whether you need one and what to look for when choosing a provider, and we take on the part that starts once the report lands.
A vulnerability scan is not a penetration test. The scan matches your systems against known vulnerabilities and returns a list. The test tries to actually exploit vulnerabilities and chain them together. Both have their place, but the scan does not replace the test, and the test does not replace the scan.
A test is a snapshot. It describes the state on the day of the assessment. Every patch, every new interface and every new provider changes that picture again afterwards.
The report is not the result. The result is the findings that have been fixed. A test with no time planned for remediation and no retest is an expensive stocktake.
A passed test is not a compliance certificate. Neither NIS2 nor DORA nor ISO 27001 requires a penetration test as such. They require risk management, and a regular technical assessment can be one building block within it.
Before the test
- A non-disclosure agreement is signed before the first substantive conversation, not after it
- A written proposal covering scope, methodology, timeframe and price, instead of a flat fee with no boundaries
- A named methodology, commonly OWASP for web applications, NIST or OSSTMM for infrastructure, and the requirements from PCI DSS for payment environments
- A clear definition of which systems are in scope and which are explicitly not, including an emergency contact in case something goes down
At the provider itself
- Verifiable certifications held by the testers, commonly OSCP for hands-on offensive work and CISSP for the conceptual side
- Research of their own, for example published vulnerabilities with a CVE number. Someone who finds and reports gaps themselves searches differently from someone operating a tool
- An information security management system at the provider itself, because they are getting access to your systems
- References from your industry and in your language, especially when results have to be explained to regulators or customers
In the report
- Every finding with proof that it can be exploited, not just a tool name and a risk rating
- An assessment of criticality in the context of your company, instead of a generic score
- Concrete remediation advice that your development team or your provider can actually implement
- A retest of the fixed findings, ideally included in the proposal and not billed as an extra
A test describes a single day. These four building blocks describe the time in between, and that stretch is considerably longer.
Before a new application or customer portal becomes publicly reachable, because after that every gap is a gap in live operation
After a migration, a new interface or a change of provider, because that is exactly where the attack surface shifts
When a major customer, an insurer or a regulator asks for one. What counts then is not only the test, but how solid the evidence is afterwards
Penetration testing
Does CAVRIX carry out penetration tests itself?
No. We do not test offensively and we do not run attack simulations. That is a discipline of its own with its own certifications, and anyone promising both from a single source ends up assessing their own work. We tell you whether a test makes sense and at what scope, we help with the selection and with reading the proposal, and we take on the part that comes afterwards.
What is the difference between a penetration test, a vulnerability scan and red teaming?
The vulnerability scan is automated, broad and cheap, and it finds what is already known. The penetration test is manual, deep and limited to an agreed scope, and it tries to actually exploit vulnerabilities. Red teaming does not assess a system but your organisation, meaning technology, people and processes together, usually without IT being told in advance. For most mid-sized companies a regular scan plus a targeted test is the sensible route, and red teaming only pays off once your defences are mature.
What does a penetration test cost?
No serious provider can name a flat figure, because the price follows the scope, meaning the number of applications, interfaces and access paths. What you can check: a proposal without a defined scope is not a proposal. And a price well below the market usually means fewer testing days, not more efficiency.
Does NIS2 require a penetration test?
Not explicitly. NIS2 requires risk management measures and procedures to assess their effectiveness, and the management level is liable for putting them in place. A regular technical test is a common way to demonstrate that effectiveness, but it is not the only one, and on its own it is not sufficient either. In the financial sector the situation is stricter: DORA explicitly provides for threat-led testing at certain institutions.
How often should testing happen?
There is no legally set frequency. In practice an annual rhythm works well for the systems reachable from outside, complemented by a test whenever something material changes in your architecture, your access paths or your providers. Between the tests it is continuous monitoring that carries you, not the calendar.
What happens after the report?
The actual work. Prioritise the findings, plan and support the remediation, schedule the retest, and document the results so they hold up in front of customers, insurers and regulators. In parallel the monitoring keeps running, because new vulnerabilities appear between two tests and credentials turn up in leaks. That part is exactly our part.
First work out whether you need a test. Then work out which one
We look at where you stand and tell you honestly whether a penetration test is the right next step or whether something else comes first. Write to us at info@cavrix.de.