If your CIO office has asked for a plan of approach on cloud exit plans, its first page is about scope. The revised Dutch central-government cloud policy, adopted on 3 July, requires a documented exit plan for every material use of public cloud. Where the cloud is already in use, the plan is due around July 2027. The policy leaves the decision on what is material to you: a one-paragraph definition, no test, no thresholds, no examples, and no review step for a "not material" call. That check can come later, from auditors. So write a short materiality test, run your whole cloud inventory through it, and record each call with a name and a reason. That record is what makes your scope defensible.
What the policy gives you
The definition has three triggers. Cloud use is material when the service carries out the primary or core task of your organisation. For an implementing agency, the core tasks are the ones laid down in its organisation decree (organisatiebesluit) or, for an independent administrative body, its founding act (instellingswet). Important supporting processes can count as well, but the policy does not say when. The 2023 implementation framework it tells you to follow, due for an update, counts them only insofar as they are of essential importance to the primary tasks. And large-scale processing of personal data is material by definition, though the policy does not define large-scale. It points to the Dutch data protection authority, which names four criteria (number of people, volume of data, duration, geographic reach) but no numbers.
Your organisation registers the result, and two routes lead to the centre. Each material use is notified to CISO Rijk, the central government's chief information security officer, who assesses the use and its exit plan. Once a year, ministries report to CIO Rijk, the central government's chief information officer. Both routes carry material use only, so a service you classify as not material reaches neither. The policy asks that risk decisions by the accountable executive (verantwoordelijk bestuurder) be reviewable and auditable.
Why the record matters more than the definition
Whoever later asks why a service was left out will be asking about your reasoning, because the policy offers none. For its January 2025 report, the Netherlands Court of Audit asked ministries for their non-material cloud use as well. It counted 700 public cloud services, of which ministries had designated 126 as material, and found that they used different definitions of the term. It listed what some had added: data that is sensitive, essential and hard to replace; a significant share of business data; serious consequences for citizens if an application is down for several days. For 84 of the 126 material services, two thirds, no risk assessment had been made.
A call with a name, a reason and a date can be challenged and defended. A call nobody wrote down can only be made again.
A five-question test
Answer five questions per service, in this order; the first answer that points to material settles the call. The questions are my suggestion; the policy does not prescribe them. They cover its three triggers, plus what an auditor will ask about a service you left out.
| # | Question | What to write down | Points to |
|---|---|---|---|
| 1 | Is it email or documents? | Which part of the service | Separate track: allowed only under three conditions; existing use has a 4-year transition |
| 2 | Which core task does it support? | The task, as named in your organisation decree or founding act | Material if it carries a core task |
| 3 | What stops if it is down for a week? | The process, and who notices: citizens, partners, staff | Material if a core task stops, or a supporting process stops and that halts a core task; borderline if work only slows down |
| 4 | Does it hold personal data at scale? | How many people, how much data, for how long | Material above your own threshold |
| 5 | What depends on it? | The services that fail when this one fails | Material if a material service depends on it |
Question 1 comes first because the policy treats email and documents separately. They may be in the public cloud only if three conditions all hold. There must be an independent finding that continuity would otherwise be at risk, a tested risk analysis and exit plan, and approval by the minister concerned together with the member of government responsible for digitalisation. Existing use has four years, or the remaining contract term if longer. That clock is separate from the July 2027 deadline for exit plans. Systems exempted for international cooperation, worldwide operations or the National Cyber Security Centre still need a risk analysis and exit plan, so put them in the inventory too.
Question 4 needs a number the policy does not give. Pick one, write down why, and apply it to every service in the same way. A consistent threshold you can explain will hold up better than a precise one you cannot.
Borderline calls, and what a row looks like
Record a service that does not resolve cleanly as borderline rather than not material. The accountable executive decides it, with the reason in the record, and the call is revisited each year at the annual report to CIO Rijk. One row in the register needs eight fields: the service, the provider, the call (material, not material or borderline), the question that decided it, the reason in one sentence, the name and role of whoever decided, the date, and the next review.
Payroll shows how a borderline call arises. On my reading, paying staff is not a task in the organisation decree of most agencies, so question 3 decides. If a week without payroll would halt work on a core task, it is material. If staff are paid late and the core work goes on, it is borderline, and the executive signs. Question 4 can still tip it to material.
In Microsoft 365, email and documents go to the separate track at question 1; the rest of the suite goes through questions 2 to 5 like any other service. The policy frames its email-and-documents section as workplace services but does not say whether collaboration tools such as Teams fall under it, so record Teams as borderline too.
Who does the work, and the gap the test leaves
The test takes the people who know each service: application owners for questions 2 and 3, the privacy officer for question 4, an architect for question 5. It also misses something I have not solved. Many small services on one provider can each be not material and together make a core task depend on that provider. The policy mentions such accumulation in two places. CIO and CISO Rijk might spot it in notifications, and each material risk analysis must answer a question about dependence on a small group of suppliers. Neither reaches the services you called not material. My provisional answer is a count of non-material services per provider, with a borderline call when the count gets high. I am not sure that is enough.
Where to start
Before the plan of approach is due, agree the five questions with your CISO, run every service in the cloud inventory through them, and record each call in the register. The material services and the email-and-documents track become the list of exit plans, each worked through with the four questions per system. The borderline list is the page of the plan the executive signs.
Jacques Domenie led the IT function of a bank under central-bank supervision and answered to its board, its supervisors and its auditor. He works for organisations part of the week through Delfen (delfen.com).
Contact: domenie@delfen.com or delfen.com/en/contact. The exit map is described at delfen.com/en/diensten.
Sources & further reading
- Herziening rijksbreed cloudbeleid 2026 — the revised central-government cloud policy; Dutch government, adopted 3 July 2026. Section 2: scope (public cloud, and hybrid, community and private cloud from an external supplier). Section 4.1 and footnotes 15–16: the definition of material public cloud use, core tasks in the "organisatiebesluit" or, for independent administrative bodies, the "instellingswet", and the registration duty. Section 3.1: risk analysis (including dependence on suppliers); residual risk accepted within the organisation; decisions by the "verantwoordelijk bestuurder" reviewable and auditable; the implementation framework must be followed. Section 3.2 and footnote 12: two-scenario exit plan, yearly review, twelve months for existing material use. Section 3.3: notification to CISO Rijk, assessment, instructions (footnote 14: civil service only); accumulation risk. Section 3.4: registration and annual reporting by ministries to CIO Rijk. Section 4.5: email and documents ("werkplekdiensten"), three conditions (condition c: "de betrokken minister in overeenstemming met de bewindspersoon voor digitalisering"), four-year transition for existing use. Section 5.1: systems exempted for international cooperation, worldwide operations and the National Cyber Security Centre still need a risk analysis and exit plan, reported to CISO Rijk. No vendor is named anywhere in the text.
- Kamerbrief Herziening Rijksbreed Cloudbeleid 2026 — letter to parliament presenting the policy, State Secretary for Economic Affairs and Climate, 3 July 2026 (Kamerstuk 26 643, nr. 1541); gives the adoption date (twelve months from 3 July 2026 is the basis for "around July 2027") and announces the update of the implementation framework
- Implementatiekader risicoafweging cloudgebruik v1.1 — CIO Rijk, 5 January 2023, the implementation framework the 2026 policy says must be followed; Article 2(a): supporting processes count "voor zover van wezenlijk belang voor de primaire taken" (insofar as they are of essential importance to the primary tasks)
- Het Rijk in de cloud — Algemene Rekenkamer (Netherlands Court of Audit), January 2025; section 4.2.2: request covered material and non-material use; 700 public cloud services, 126 designated material, different definitions per ministry and the criteria they added; summary: no risk assessment for 84 (67%)
- Verwerken van persoonsgegevens — Autoriteit Persoonsgegevens (Dutch Data Protection Authority); the four criteria for large-scale processing (in Dutch)
- What an exit strategy means in practice: four questions per system — Delfen, October 2026