Penetration testing in short
A penetration test, or pentest, is an authorised and time-boxed attack on a defined system by a skilled tester, who shows which weaknesses can actually be exploited and reports how to fix them. As of September 2026, DongIT and Warpnet, two Dutch providers that publish prices, start at €2,500 to €2,960 for a small web application and at about €5,000 to €7,500 for larger scopes, excluding VAT where stated. DongIT puts active testing at 16 hours for a small web application and 80 hours or more for an extensive scope, with four to eight weeks from the first scoping call to the final report. You need one around a major release, when customers, auditors or insurers ask for evidence, and when your organisation falls under the Cyberbeveiligingswet and must periodically assess whether its security measures work.
This guide explains the difference between a pentest, a vulnerability scan and an audit, the main types of pentest, the standards testers use and what drives cost and duration. It also covers the legal side: in the Netherlands, entering a system without permission is a criminal offence. The information reflects official Dutch sources and published provider information as of September 2026. Prices and regulations change, so check the linked sources before you set a budget.
What is a pentest, and how does it differ from a vulnerability scan or audit?
The Dutch National Cyber Security Centre (NCSC) describes three technical tests. In a vulnerability assessment, a largely automated scan looks for known vulnerabilities, missing patches and weak configurations. In a penetration test, a trained tester takes the role of an attacker, searches for weaknesses and tries to exploit them. In a source code review, an expert inspects the application’s code for programming errors.
The NCSC summarises the difference neatly: a vulnerability assessment works in breadth, while a pentest goes in depth. That depth matters because a scan rarely tells you what a weakness means for your organisation. A pentest shows whether an attacker could actually reach customer data or take over an account, and it is better suited to finding unknown problems, such as flaws in authorisation or business logic.
The NCSC does advise starting with a vulnerability assessment and fixing its findings first. If you have never done one, a pentest is less effective, because the tester spends time on issues a cheaper scan would also have found.
A security audit answers a different question. An ISO/IEC 27001 audit, for example, checks whether policies, processes and controls exist and are followed; it does not normally involve attacking your systems. An auditor may, however, ask for a recent pentest report as evidence that technical measures work. The UK National Cyber Security Centre adds that a pentest can only show the state of your systems on the day of the test, so ongoing vulnerability management remains necessary between tests.
| Assessment | What happens | What you learn | Main limitation |
|---|---|---|---|
| Passive external scan | Looks only at what any visitor can see, such as pages, headers, certificates and DNS records | Visible configuration issues and missing basics | No login attempts, port scans or exploitation; not a pentest |
| Vulnerability scan (assessment) | Largely automated check for known vulnerabilities, missing patches and weak configurations | A broad overview of known issues | Usually does not show whether a weakness can be exploited or what the impact is |
| Penetration test | A tester takes the role of an attacker and tries to exploit weaknesses within an agreed scope and time | Whether and how far an attacker could get, and the likely impact | Time-boxed and best effort; a snapshot of the day of testing |
| Source code review | An expert examines the code, often combining automated analysis with manual review | Programming errors missed during development | Does not test the running environment and its configuration |
| Security audit (e.g. ISO/IEC 27001) | Checks whether policies, processes and controls are in place and followed | Whether your organisation manages security systematically | Usually does not attack systems; may ask for a pentest report as evidence |
Which types of penetration test are there?
Pentests are usually named after what is in scope. A small business rarely needs every type at once. Start with the systems where a breach would hurt most: the application that stores customer data, the API behind your app or the cloud account that runs everything.
Many assignments combine two types, for example a web application and the API it relies on. If you are adding AI automation that reads or updates customer data, include those integrations in the scope as well.
Web application pentest
The tester examines a website or web application the way both a user and an attacker would: login and password reset, session handling, input processing, file uploads, access rights between users and roles, and the logic of processes such as ordering or approving. The OWASP Web Security Testing Guide is the usual reference. For a web shop, customer portal or SaaS product, this is usually the first test to consider.
API pentest
Modern applications exchange data through APIs, often with a mobile app or partner systems. An API test checks whether every endpoint enforces authentication and authorisation, whether one customer can retrieve another customer’s records by changing an identifier, and how the API handles unexpected input and large numbers of requests. APIs are easy to overlook because they have no visible interface.
Mobile app pentest
A mobile test looks at the app itself and at its communication with the backend: how data is stored on the device, how tokens and keys are protected and whether the app trusts the server correctly. Because the app depends on its backend, mobile and API tests are often combined in one assignment.
Network and infrastructure pentest
An external test targets systems that are reachable from the internet, such as servers, VPN gateways and mail services. An internal test assumes that an attacker already has a foothold, for example through an infected laptop, and examines how far they can move through the network. Internal tests matter most for organisations with their own office network, servers or Active Directory.
Cloud and Kubernetes pentest
Here the focus is on configuration: identity and access management, storage permissions, network rules, secrets and the separation between environments. For Kubernetes, the tester looks at cluster access, workload permissions and container isolation. A misconfiguration in these layers can expose data without any flaw in the application code.
Social engineering
Some attacks target people rather than systems, for example through phishing emails or phone calls. A phishing simulation tests awareness and whether reporting procedures work. Because employees are involved, agree in advance how results are reported, avoid naming individuals and discuss the privacy implications with whoever is responsible for data protection.
Black box, grey box or white box: how much should the tester know?
Besides the scope, you decide how much information the tester receives beforehand. The NCSC distinguishes three perspectives. Each answers a different question, and each uses the testing time differently.
Black box
The tester receives no prior information beyond, for example, an IP address, domain name or company name. This matches an attacker who is not specifically targeting your organisation. It sounds realistic, but a large part of the budget then goes into discovering what you could simply have told the tester. Fewer hours remain for the parts that matter.
Grey box
The tester receives partial information, typically login details for one or more user roles. That shows what an attacker could do with a stolen account, or what a malicious customer or employee could see and change. For web applications and APIs with user accounts, grey box is a common choice because it covers the rights between roles.
White box
The tester receives extensive information: design documentation, credentials, example messages and source code, even if no full code review takes place. The OWASP Application Security Verification Standard strongly encourages this kind of documentation- or code-led testing, because many requirements cannot be verified from the outside. For the same budget, more information usually means more of the application can be examined.
Which methods and standards do pentesters use?
A pentest is not a standardised product. According to the NCSC, the market does not yet agree on exactly what is tested, how it is reported and what a test proves. Asking which methodology a provider follows is therefore one of the most useful questions you can ask. These are the references you are most likely to encounter.
OWASP Web Security Testing Guide (WSTG)
The WSTG is an open guide to testing web applications, from information gathering to authentication, authorisation, session management and business logic. Version 4.2 is the current stable release, and version 5.0 is in development. A provider that follows the WSTG can tell you which test areas were covered and which were not.
OWASP Application Security Verification Standard (ASVS)
The ASVS lists security requirements for applications, divided into three verification levels. Version 5.0.0 is the latest stable release. Level 1 contains around 20% of the requirements and is meant as a starting point; the standard states that most applications should strive for Level 2. The ASVS also notes that traditional pentest reports list only failures, whereas an ASVS assessment reports on every requirement checked.
Penetration Testing Execution Standard (PTES)
PTES divides a pentest into seven sections: pre-engagement interactions, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation and reporting. It helps you check that a proposal covers more than the technical work, particularly the agreements before the start and the report at the end.
NCSC guidance and MIAUW
The NCSC publication on testing technical security measures takes a client through the research question, scope, test type, provider selection, execution and follow-up, with checklists for each stage. MIAUW, the Methodiek voor Informatiebeveiligingsonderzoek met Auditwaarde, is an open-source methodology developed within the Dutch government to make pentests more structured and their results auditable. An NCSC expert blog from May 2025 uses it as a reference for agreeing a test plan.
When do you need a penetration test?
A pentest is most useful when the risk changes or when someone asks for evidence. The NCSC advises against scheduling a pentest immediately before going live: fixing findings takes time, and the system should not change during the test. These are the most common reasons to commission one.
Before or after a major release
A new customer portal, a payment flow, a public API or a major rebuild changes your attack surface. Test once the functionality is stable, on an environment that matches production, and leave time for fixes and a retest before launch. For smaller releases, secure development practices and automated checks in your CI/CD pipeline are usually more proportionate than a full pentest every time.
Customer, tender or partner requirements
Customers, especially larger organisations and public bodies, may ask suppliers for evidence of security testing, particularly when you process their data. Think of a recent report, a management summary or a retest statement in a security questionnaire or tender. Check exactly what is required: some ask for a specific scope, a maximum age of the report or a certified provider.
ISO/IEC 27001 and other audits
ISO/IEC 27001 does not prescribe a pentest by name, but an auditor will want to see how you manage technical vulnerabilities and test your security measures. A pentest report is common evidence. Dutch providers also offer reports aimed at sector frameworks, such as NEN 7510 in healthcare and DigiD assessments.
Cyber insurance
Insurers may ask about your security measures when you take out or renew a cyber policy. The CCV Keurmerk Pentesten, discussed below, was developed with parties including the Verbond van Verzekeraars, the Dutch Association of Insurers. If your policy or broker refers to testing, ask what they accept as evidence.
NIS2 and the Cyberbeveiligingswet
The Cyberbeveiligingswet (Cbw), the Dutch implementation of the EU NIS2 directive, entered into force on 15 August 2026. According to the NCSC, it covers more than 8,000 organisations that provide essential or important services in designated sectors, generally those with 50 or more FTE, or with both annual turnover and balance sheet total above €10 million. Article 21 requires policies and procedures to assess whether security measures are effective. The NCSC advises testing measures periodically, for example annually, and having technical measures tested in line with its own testing guidance.
The law does not oblige every business to commission a pentest. Organisations under the Cbw must, however, manage risks in their supply chain. If your business supplies such an organisation, you may be asked for evidence as well.
What does a penetration test cost in the Netherlands?
Most providers quote per assignment after a scoping conversation, because the price follows the number of testing hours. A few Dutch providers publish package prices, which give a useful reference point. As of September 2026, DongIT (Web Security Scan) lists a Quick Pentest for a straightforward web application at €2,960 excl. VAT, an Expert Pentest from €5,040 and an Extensive Pentest from €7,200. Warpnet lists packages from €2,500, €5,000 and €7,500, based on the number of pages, endpoints, roles and hosts; its page does not state whether VAT is included.
Check what the price covers. Warpnet includes a retest in its packages, while DongIT charges for a retest separately, depending on the number of findings. DongIT’s Basic Scan at €1,480 excl. VAT is a semi-automated vulnerability scan with limited manual verification, which the provider itself describes as a different type of research rather than a cheaper pentest.
Complex environments, multiple applications and large networks are quoted individually. The CCV, which manages the Dutch pentest quality mark, likewise notes that costs differ by type of test, scope and provider. The table at the end of this section summarises the published packages.
Scope and size
The number of pages, endpoints, user roles, API calls, IP addresses and cloud accounts determines how many hours are needed. Warpnet’s smallest package, for example, assumes fewer than 30 web pages or endpoints and one or two roles.
Depth and prior information
Grey box and white box testing use the hours more efficiently than black box. Extra depth, such as testing every combination of roles or reviewing source code, adds time. DongIT lists static code analysis as a separate service, from €3,500 excl. VAT as an indication.
Complexity and integrations
Payment providers, single sign-on, file processing, AI features and connections to other systems add scenarios to test. If an integration belongs to a third party, it stays out of scope unless that party gives permission.
Reporting requirements
A report that maps findings to ISO/IEC 27001, NEN 7510 or a customer’s questionnaire takes more time than a standard technical report. Mention such requirements during scoping, so the quote reflects them.
Timing and retest
Testing outside office hours, at short notice or in several rounds can cost more. Reserve budget for a retest after remediation, whether it is included in the price or invoiced separately.
| Package | Published price | Intended scope | Retest |
|---|---|---|---|
| Basic Scan (DongIT) | €1,480 excl. VAT | Semi-automated vulnerability scan based on the OWASP Top 10; not a pentest | Not included |
| Quick Pentest (DongIT) | €2,960 excl. VAT | Compact pentest of a straightforward web application with a limited scope | Separate, depending on findings |
| Expert Pentest (DongIT) | From €5,040 excl. VAT | Applications with several roles, APIs or integrations; network or cloud pentests | Separate, depending on findings |
| Extensive Pentest (DongIT) | From €7,200 excl. VAT | Complex applications and infrastructure; offered for NIS2 and ISO 27001 projects | Separate, depending on findings |
| Basic Pentest (Warpnet) | From €2,500 (VAT not stated) | Fewer than 30 web pages or endpoints, 1-2 roles, fewer than 25 API endpoints | Included |
| Standaard Pentest (Warpnet) | From €5,000 (VAT not stated) | 30-100 web pages or endpoints, 3-5 roles, 25-80 API endpoints | Included |
| Plus Pentest (Warpnet) | From €7,500 (VAT not stated) | More than 100 web pages or endpoints, more than 5 roles, more than 80 API endpoints | Included |
How long does a penetration test take?
The testing itself is often the shortest part. DongIT states that active testing ranges from 16 hours for a small web application to 80 hours or more for an extensive network or enterprise web application pentest. Its overall lead time from scoping call to final report is typically four to eight weeks: a quote within three working days, one to two weeks of preparation, five to 25 working days of execution depending on scope, and the report within five working days after that.
NFIR states that a pentest generally covers two to four weeks, including preparation, analysis and explaining the report. KPN notes that, depending on the size and complexity of what is tested, a pentest can take days, weeks or even months.
Plan backwards from your deadline. If a release is due in two months, start scoping now, reserve a testing window in which the application is stable and leave time for fixes and a retest before launch. Providers also have their own schedules, so ask about lead times when you request a quote. For an important release, we recommend booking the test as soon as the scope is clear.
How does a pentest work, from scoping to retest?
A well-run pentest follows a predictable sequence. The NCSC publication on testing technical security measures and its expert blog on pentesting describe what you arrange as the client at each step. Your preparation has a large influence on the result.
1. Scoping and the research question
Start with a question, not a list of systems. The NCSC gives an example: could all my customer data leak through a vulnerability in application A? Then decide with the system owner, the developers and the provider what is in and out of scope, which environment will be tested and how much information the tester receives.
Hold scoping conversations with more than one provider. According to the NCSC, a provider that asks many questions about your goals, scope and architecture is a good sign. Sign a confidentiality agreement before you share sensitive details.
2. Written authorisation and rules of engagement
Under Article 138ab of the Dutch Criminal Code, intentionally and unlawfully entering an automated system is computer trespass (computervredebreuk). The basic offence carries up to two years’ imprisonment or a fourth-category fine, and aggravated forms carry heavier penalties. A pentest is lawful because the entitled party gives permission in advance.
Record that permission in writing, together with the scope, IP addresses and URLs, testing period, permitted techniques and contact persons. If your application runs with a hosting provider, cloud platform or SaaS supplier, check their terms and obtain their consent where needed. The NCSC also recommends an indemnification clause, agreements on personal data under the GDPR and rules for storing, deleting and sharing test data and the report.
3. Testing window and environment
Agree when testing takes place and whether the tester works on production or on an acceptance environment. Production gives the most realistic picture, but a pentest can disrupt the system under test. That is why the NCSC advises deciding in advance whether brute-force attacks and tests that could cause a denial of service are allowed. Avoid major changes, backup and restore actions or other tests during the window, and inform stakeholders such as your hosting provider and identity provider.
4. During the test
Agree how the tester communicates: short progress updates and direct contact for urgent findings. If a critical vulnerability is found, you want to hear about it the same day, not in the final report. Record any scope changes during the test explicitly, so the report reflects what was actually tested.
5. The report and risk ratings
A good report states who tested what and when, what could not be tested, each finding with evidence, its impact and a recommendation, and a management summary that answers the original research question. Many providers rate findings with the Common Vulnerability Scoring System (CVSS), maintained by FIRST.
CVSS 4.0, first released in November 2023, maps scores to five ratings: None (0.0), Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9) and Critical (9.0-10.0). CVSS measures technical severity. FIRST notes that factors such as regulatory requirements, the number of customers affected and reputational impact fall outside CVSS, so set priorities in your own context.
6. Remediation and retest
The NCSC warns that reports too often end up in a drawer. Assign an owner and a deadline to each finding, address structural causes rather than individual symptoms and then ask for a retest, because fixes are not always correct the first time. The UK NCSC stresses that risk assessment and decisions about fixes remain your responsibility, not the tester’s.
How do you choose a pentest provider?
Price is only one factor. The NCSC advises comparing several quotes, asking about approach, experience, certifications and training, and above all requesting a sample report, because the report is the only tangible end product. These points help you compare providers.
A clear scope and methodology
A good proposal names the systems in scope, the approach (black, grey or white box), the number of testing days or hours, the methodology and what is explicitly excluded. Vague proposals make quotes impossible to compare.
The CCV Keurmerk Pentesten
The Centrum voor Criminaliteitspreventie en Veiligheid (CCV) manages a quality mark for pentest providers, developed with parties including the police, VNO-NCW/MKB-Nederland, Cyberveilig Nederland, the Digital Trust Center and the Verbond van Verzekeraars. It certifies companies, not individual testers.
Pentesters must hold a practical certificate from a list that is reviewed annually, and the scheme requires a certificate of conduct (VOG) no older than three years. Certification is not a legal requirement. The CCV publishes a register of certified companies and points out that clients remain responsible for checking a provider’s background.
Individual qualifications
Individual testers often hold practical certifications. For OSCP, from OffSec, candidates pass a 24-hour proctored exam in which they identify, exploit and report vulnerabilities in a lab. CREST is a not-for-profit organisation registered in the UK that accredits member companies and offers professional certifications.
The CCV considers entry-level certificates such as CEH and LPT too light to count as a qualification. A certificate says something about skills; a sample report and a conversation with the tester say more about how they will work on your system.
Insurance, confidentiality and data handling
Ask whether the provider carries professional and general liability insurance, how findings and credentials are stored during the test and when test data is deleted. Check who will actually do the work, whether subcontractors are involved and how urgent findings are reported.
Prepare your pentest: an eight-point checklist
Work through these points before the test starts. Each one saves testing hours or prevents a delay. Start with anything that would block the test or make its results hard to use.
These checkmarks are temporary; your answers are not saved or sent. The checklist helps you prepare and does not replace the agreements with your provider.
A practical next step
Start small and specific. Choose the application or API where a breach would hurt most, write down the research question and collect the documentation, test accounts and constraints a tester would need. Ask two or three providers for a proposal and compare scope, methodology, sample reports and retest terms, not only the price.
Pixel Dev performs web application and API penetration tests under a written agreement and a defined scope, alongside cloud and Kubernetes hardening and security checks in CI/CD pipelines. We report findings with evidence and remediation advice your developers can act on. Feel free to ask us the questions this guide recommends: how we scope, which methodology we follow and what a report looks like.
Not ready for a pentest yet? Our free AI visibility and security scan is a passive check of what any visitor can see: public pages, response headers, certificates and DNS records. It is not a pentest: we do not attempt logins, scan ports or exploit vulnerabilities. It can, however, show which basics to fix before you invest in deeper testing.
Frequently asked questions
Is a pentest mandatory in the Netherlands?
There is no general legal obligation for every business to commission a pentest. Organisations covered by the Cyberbeveiligingswet must have policies to assess whether their security measures are effective, and the NCSC advises testing them periodically. In practice, customers, tenders, auditors and sector frameworks can also require one.
How much does a penetration test cost for a small business?
As of September 2026, Dutch providers that publish prices list compact web application pentests from €2,500 (Warpnet, VAT not stated) and at €2,960 excl. VAT (DongIT). At both providers, packages for applications with several roles, APIs or integrations start at around €5,000. A retest may be included or charged separately, so compare what each quote covers.
What is the difference between a pentest and a vulnerability scan?
A vulnerability scan is largely automated and looks broadly for known weaknesses, missing patches and weak configurations. In a pentest, a tester manually tries to exploit weaknesses to show what an attacker could actually achieve. As the NCSC puts it, a scan works in breadth, while a pentest goes in depth.
How often should you have a pentest?
The NCSC’s guidance for the Cyberbeveiligingswet suggests testing the effectiveness of measures periodically, for example annually. Also test after major changes, such as a new application, a new API or a move to another platform. Between tests, keep vulnerability management and automated checks running.
Can a pentest disrupt my website or application?
Yes, a pentest can disturb the system under test. That is why you agree in advance whether production or an acceptance environment is tested, whether tests that could cause a denial of service are allowed and when testing takes place. Make sure backups are recent and a contact person is available during the testing window.
Can I have my own website tested, and what about my hosting provider?
You can commission a test of systems you own or control, provided the permission and scope are recorded in writing. Entering a system without permission is computer trespass under Article 138ab of the Dutch Criminal Code. If your website runs with a hosting or cloud provider, check their terms, because their infrastructure is not yours to authorise.
Does a pentest provider need the CCV quality mark?
No law requires it. The CCV Keurmerk Pentesten is a voluntary quality mark for companies, with requirements for tester qualifications, screening and agreements with clients. Some customers or tenders may ask for it, so check your requirements and the CCV register.
