What is VSE?
VSE is the set of technical cybersecurity requirements from the CSIR that defines how the ICT and industrial automation (IA) of an asset such as a pumping station, lock or bridge must itself be secured. The abbreviation comes from the contracting practice of Rijkswaterstaat, the Dutch public works agency, where the Vraagspecificatie Eisen (VSE, the requirements specification) is the contract document holding the requirements for the works to be delivered. In the generic requirements list that CERT-WM publishes alongside the CSIR, the section is spelled out as “Vraagspecificatie Systeemtechnische Eisen” (system engineering requirements). VSE has a counterpart, VSP, which holds the requirements for processes and ways of working. Put simply, VSE describes what the system must technically do and protect, while VSP describes how the contractor organises and manages that security.
📜 Where do the abbreviations VSE and VSP come from?
VSE and VSP were not coined by the CSIR. At Rijkswaterstaat, the request specification (vraagspecificatie) of an integrated contract under the UAV-GC, such as Design & Construct, has traditionally consisted of two parts:
- Vraagspecificatie Eisen (VSE) - the requirements for the works themselves, often grouped per object in an object breakdown structure.
- Vraagspecificatie Proces (VSP) - the requirements for the contractor’s processes, such as project management, quality assurance and verification.
The CSIR follows that split. In the guideline, the controls for the technology are called “Systeemeisen (VSE) controls” and the controls for the way of working “Proceseisen (VSP) controls”. This makes it immediately clear which contract document a cybersecurity requirement ends up in. In the CERT-WM requirements list, the headings are written out as “Vraagspecificatie Systeemtechnische Eisen (VSE)” and “Vraagspecificatie Proces Eisen (VSP)“. That is why you will come across both expansions of VSE; they refer to the same document.
🎯 Why do VSE requirements exist?
The CSIR (Cybersecurity Implementatierichtlijn Objecten, the cybersecurity implementation guideline for assets) of Rijkswaterstaat and Het Waterschapshuis, the shared IT organisation of the Dutch water authorities, translates the BIO to industrial automation and supplements it with measures from IEC 62443. The guideline itself, however, is not a contract document. The CSIR states explicitly that in tenders it cannot become part of the request specifications in its current form. The controls from chapter 1 first have to be translated into requirements that fit Dutch procurement conditions such as ARBIT/ARVODI or the UAV-GC for integrated contracts.
VSE and VSP are exactly that translation step. A contractor cannot simply be held to a guideline of more than a hundred pages with annexes, but can be held to numbered contract requirements that point into it. The CSIR is therefore attached to the contract as an annex. The guideline splits its baseline controls into two groups:
- Process requirements (VSP) - section 1.1 of the CSIR, covering organisation, plans, audits, incident handling and personnel.
- System requirements (VSE) - section 1.2 of the CSIR, covering the technical design of the asset’s ICT and IA.
This tells a contractor exactly which part of the requirements must end up in the design and construction of the installation, and which part in its own way of working.
🧠 How does VSE work?
In chapter 1 of the CSIR, “Generic controls and control objectives”, every control sits in a table with three columns: the BIO source (the number of the original BIO control), the translation of that control into a baseline for IA, and the VSE or VSP control set. The numbering follows the chapters of the original BIO, which is based on ISO 27002:2013, such as 9 (access control), 10 (cryptography), 11 (physical and environmental security), 12 (operations security) and 13 (communications security).
The VSE controls almost always refer to an in-depth section in chapter 2 of the CSIR or to an annex (CSR). Chapter 2 contains ten packages of measures, broken down by cybersecurity resilience level. The level follows from the function box classification of the asset, which you determine with a business impact analysis:
| Function box | Cybersecurity resilience level | Explanation |
|---|---|---|
| A | 4 | Highest function box, heaviest package of measures |
| B | 3 | Heavier package than level 2 |
| C | 2 | Heavier package than the baseline |
| D | 1 | Baseline; largely equivalent to Security Level 1 in IEC 62443 |
The higher the function box, the more resilient the asset must be against cyber attacks. The top-level VSE requirement states that resilience level 1 applies unless a different level has been specified for the asset. Standalone IA components in the field without a function box always get level 1 as well. A chain rule applies too: if asset A is operated or managed from a lower-classified asset B, asset B is raised to the level of asset A.
🔧 Which requirements does VSE contain?
Rijkswaterstaat has worked the system requirements out into contract wording. CERT-WM publishes them for market parties as a spreadsheet titled “VSE + VSP eisen generieke versie CSIR 3.4”, produced with the ICO wizard (Inkoopeisen Cybersecurity Overheid, the Dutch government tool for putting BIO requirements into tenders). Version 1.1 dates from 14 July 2022. The sheet is called “RWS proces (VSP) en systeem (VSE) eisen” and names as its source the D&C process request specification and the cybersecurity base specification (GRIP). It numbers the system requirements VSE01 to VSE39, each of which concerns “the ICT and IA of the managed asset”.
| Theme | What the VSE requirements demand | Reference in the CSIR |
|---|---|---|
| Top-level requirement | VSE01: prevent danger or damage caused by disruption, failure or misuse of ICT and IA | Section 1.2 |
| Architecture | VSE03: security built on the principle of layered security (Defense in Depth) | Section 1.2 |
| Access and passwords | Identification, authentication and authorisation; password functionality | Section 2.2, annex CSR 7 |
| Cryptography | Only encryption rated “good” in the TLS guidelines of the Dutch NCSC | NCSC guidelines; section 2.4.2 for wireless |
| Physical security | Site, control rooms and technical rooms; cabinets outside buildings that raise an alarm when opened | Section 2.1, annex CSR 24 |
| Vulnerabilities | Anti-malware, Hardening and patch management | Section 2.5, annexes CSR 8, 9 and 11 |
| Logging and detection | Log files, a central Syslog server for SIEM and SOC, analysis ports in the asset network | Section 2.6, annex CSR 10 |
| Network | Minimal external connections, a dedicated compartmentalised network separated from office IT, separated DTAP environments | Section 2.4.1, annex CSR 3 |
| Other | Wireless networks, IoT, virtualisation, backups, web applications for management, CIP Secure Software Development | Annexes CSR 5, 6, 18 and 22 |
| Testing | Demonstrate compliance and operation of security functions during FAT, SAT and SIT | Section 1.2 |
| Safe state | VSE39: drive the system to a predefined safe state in case of an attack, incident or emergency | Section 2.3 |
For that last requirement the CSIR gives examples of a fail-safe design: unpowered, hold or fixed. For a movable bridge or a weir, that is a genuine design decision, not an IT setting. VSE13 also stands out: IA outside secured buildings must, based on a risk assessment, sit in lockable cabinets that raise an alarm when opened, and that alarm must be acted upon. That affects the panel builder just as much as the network designer.
🔄 How does VSE relate to VSP?
VSE and VSP are two halves of the same baseline. Both derive from the same BIO controls and refer to the same in-depth sections, but they address a different subject.
| Aspect | VSE (system requirements) | VSP (process requirements) |
|---|---|---|
| Contract document | Vraagspecificatie Eisen | Vraagspecificatie Proces |
| Place in the CSIR | Section 1.2, “Systeemeisen (VSE) controls” | Section 1.1, “Proceseisen (VSP) controls” |
| Subject | The ICT and IA of the managed asset | The contractor and its way of working |
| Examples | Hardening, segmentation, logging, physical protection, safe state | Cybersecurity plan, person responsible for cybersecurity, annual audit, incident response, change management |
| Evidence | Design, configuration and test results (FAT, SAT, SIT) | Plans, procedures, reports and audit reports |
Patching shows the difference clearly. VSE requires the installation to be patched in line with section 2.5.3 and annex CSR 8. VSP requires the contractor to have the processes to keep that up, such as controlled change in line with section 2.8. An installation that is up to date at handover but maintained by nobody therefore only complies on the day of handover. Installing a firewall achieves little if nobody is responsible for managing it.
🏭 How do you apply VSE in a project?
For a client, such as a water authority or Rijkswaterstaat, and for a contractor or system integrator, practice usually looks like this:
- Classify the asset - use a business impact analysis to determine the function box and therefore the resilience level. Without a classification, level 1 applies.
- Select the relevant requirements - the client includes the controls declared applicable in the request specification. Not every requirement applies to every contract; a project without wireless links needs no Wi-Fi requirement.
- Design according to the references - every VSE requirement points to a section or CSR annex holding the concrete measures for the chosen resilience level. If the CSIR lacks a measure, the contractor follows ISO 27002 and/or parts of IEC 62443.
- Record it - alongside the requirements list, CERT-WM offers a template for the cybersecurity security plan and an Excel data model for a CMDB of IA/PA/OT assets.
- Test and demonstrate - security functions become part of FAT, SAT and SIT. This is where you test, for example, whether the installation really moves to its predefined safe state.
- Handle deviations - a deviation from the baseline must be justified with a risk analysis and trade-off and handled through the comply-or-explain procedure.
Because the VSE requirements are technical, they land early in the design. Anyone who only looks at them at handover often has to rework networks, cabinets or controllers. That is in line with Security by Design.
❓ Frequently asked questions
What does the abbreviation VSE stand for?
In Rijkswaterstaat contracts, VSE stands for Vraagspecificatie Eisen, the contract part holding the requirements for the works themselves. In the CSIR requirements list published by CERT-WM, the cybersecurity part is spelled out as Vraagspecificatie Systeemtechnische Eisen. Both refer to the technical requirements; the process counterpart is called VSP.
Where can you find the official VSE requirements?
The VSE controls are in section 1.2 of the CSIR and, as contract wording, in the spreadsheet “VSE + VSP eisen generieke versie CSIR 3.4”. CERT-WM publishes both on its page of documents for market parties. That page also offers a template for the cybersecurity security plan and a CMDB template.
How many VSE requirements are there?
The generic requirements list of July 2022 numbers the system requirements from VSE01 to VSE39. A specific contract may contain fewer, because the client includes only the relevant requirements. The underlying measures depend on the resilience level of the asset.
Do VSE requirements apply only to Rijkswaterstaat?
No, since version 3.0 the CSIR has been formally adopted for both Rijkswaterstaat and the Dutch water authorities. Other owners of assets with industrial automation can include the VSE requirements in their request specifications too. This covers assets such as pumping stations, locks, bridges and treatment plants.
Are VSE requirements the same as IEC 62443?
No, VSE requirements are derived from the BIO, but the underlying CSIR measures are linked to IEC 62443 per resilience level. Resilience level 1 largely matches Security Level 1 in IEC 62443. Where the CSIR offers no measure, the contract requirements refer to ISO 27002 or IEC 62443.
Must a contractor comply with both VSE and VSP?
Yes, a contractor under a contract with cybersecurity requirements usually has to meet both. VSE determines how the delivered installation is technically secured. VSP determines how the contractor organises, records and manages security during the work.
📌 In summary
VSE is the technical half of the CSIR baseline, translated into contract requirements for the ICT and IA of assets; the name comes from the Vraagspecificatie Eisen in Rijkswaterstaat contracts.
The generic requirements VSE01 to VSE39 cover layered security, access, cryptography, physical security, hardening, patching, logging, network separation, testing and a safe state during an attack. Each requirement points to a section or annex of the CSIR, where the measures are set out per resilience level. Together with the process requirements in VSP, they form the basis for cybersecurity in tenders for the water sector and infrastructure.