# Arckit Nl Exit > [COMMUNITY] Produce a mandatory cloud exit plan under Rijksbreed cloudbeleid clause 3.2 — planned exit and disruptive interruption scenarios, provider data destruction, and annual self-test - Skill: `tractorjuice/arckit-nl-exit` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tractorjuice/arckit-nl-exit` - Raw SKILL.md: https://api.skillmd.com/api/skills/tractorjuice/arckit-nl-exit/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: tractorjuice (https://skillmd.com/u/tractorjuice) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tractorjuice/arckit-nl-exit --- > ⚠️ **Community-contributed command** — not part of the officially-maintained ArcKit baseline. Output should be reviewed by qualified counsel, the departmental CISO, and CISO Rijk before reliance. Citations to Dutch government policy may lag the current text — verify against the source. You are helping an enterprise architect produce a **Cloud Exit Plan** required under clause 3.2 of the Herziening rijksbreed cloudbeleid 2026 (Ministerie van Economische Zaken en Klimaat, 3 July 2026, definitief). The exit plan is mandatory, documented, and self-tested wherever materieel publiek cloudgebruik applies, and must cover **two scenarios**: a planned exit and a disruptive interruption of service. It must address destruction of data at the provider after migration, and is reviewed annually. Existing cloud use has a four-year transition; the exit plan itself has a twelve-month production deadline. ## User Input ```text $ARGUMENTS ``` ## Instructions > **Note**: Before generating, scan `projects/` for existing project directories. For each project, list all `ARC-*.md` artifacts, check `external/` for reference documents, and check `000-global/` for cross-project policies. If no external docs exist but they would improve output, ask the user. ### Step 0: Read existing artifacts from the project context **MANDATORY** (warn if missing): - **REQ** (Requirements) — Extract: system description, hosting model, dependencies, data volumes - If missing: warn that a credible exit plan requires a defined hosting and dependency picture **RECOMMENDED** (read if available, note if missing): - **RBCLOUD** (Rijksbreed Cloudbeleid Compliance Assessment, from `$arckit-nl-cloud`) — Extract: the materieel cloudgebruik determination that triggers this obligation, and whether this plan is being produced to satisfy clause 4.5(b) for an email/file-storage service - If missing: warn that the trigger for this exit plan has not been formally established, and recommend running `$arckit-nl-cloud` first - **RISK** (Risk Register) — Extract: existing provider-concentration or lock-in risks **OPTIONAL** (read if available, skip silently): - **DATA** (Data Model) — Extract: data formats and volumes relevant to portability ### Step 0b: Read external documents and policies - Read any **external documents** in `external/` — extract existing provider contracts, service-level agreements, prior exit or continuity plans - Read any **global policies** in `000-global/policies/` — extract business continuity policy, data retention policy ### Step 1: Identify or Create Project Identify the target project from the hook context. If the project doesn't exist: 1. Use Glob to list `projects/*/` directories and find the highest `NNN-*` number 2. Calculate the next number (zero-padded to 3 digits) 3. Slugify the project name 4. Use the Write tool to create `projects/{NNN}-{slug}/README.md` 5. Set `PROJECT_ID` and `PROJECT_PATH` ### Step 2: Read Source Artifacts Read all documents from Step 0. Extract the hosting model, actual contracted provider(s), data volumes, and existing continuity arrangements. ### Step 3: Template Reading **Read the template** (with user override support): - **First**, check if `.arckit/templates-custom/nl-exit-template.md` exists in the project root - **If found**: Read the user's customized template - **If not found**: Read `.arckit/templates/nl-exit-template.md` Also read `.arckit/templates/_partials/RENDERING.md` — the template's `` marker is resolved against these rules before the artefact is written (see Step 11). ### Step 4: Establish the Trigger State why this plan is being produced: materieel publiek cloudgebruik per `$arckit-nl-cloud`, and/or as one of the three cumulative conditions under clause 4.5(b) for an email or document/workplace/file-storage service. If no prior `$arckit-nl-cloud` assessment exists, note this as an open item rather than inventing a trigger. ### Step 5: Scenario A — Planned Exit Document the export method, target environment, timeline, cost (including egress fees and rebuild effort), dependencies, and owner for a planned, orderly exit — e.g. contract expiry or a policy decision to move. ### Step 6: Scenario B — Disruptive Interruption of Service Document the same elements for an unplanned, disruptive interruption — e.g. provider insolvency, a sanctions event, or a sudden withdrawal of service. This scenario assumes the provider may not cooperate; the plan must not depend on provider goodwill for data recovery. State the minimum viable continuity path, RTO, and RPO. **Both scenarios are mandatory.** A plan that only documents a planned, orderly exit does not satisfy clause 3.2. ### Step 7: Destruction of Data at the Provider Document the contractual basis, method, and verification for destroying data held by the provider after migration completes, in either scenario. ### Step 8: Self-Test Plan and Evidence Document the test cadence (at minimum annual, aligned to the clause 3.2 review requirement), the last test date and scope, findings, and remediation actions. A plan with no test evidence is aspirational, not compliant — flag this explicitly if no test has yet occurred. ### Step 9: Annual Review Set the review cycle to annual with a named owner and next review date. ### Step 10: Residual Risk Identify residual risks — e.g. data-format lock-in, proprietary managed-service coupling, provider non-cooperation under the disruptive scenario — with likelihood, impact, and mitigation. ### Step 11: Generate the Exit Plan **CRITICAL**: Use the **Write tool** to create the exit plan document. 1. Use `node scripts/generate-document-id.mjs NLEXIT --filename` for the artefact filename. 2. **Auto-populate Document Control**: - Document ID: the filename from step 1, without the `.md` extension - Status: DRAFT - Created Date: {current_date} - Next Review Date: {current_date + 12 months} 3. Resolve the `` marker per `RENDERING.md` before writing the artefact. `RENDERING.md` hard-routes the NL regime to `_partials/document-control-nl.md`, which already carries the VIRBI 2025 rubricering ladder — no per-command classification override is needed. 4. Populate the External References section per `.arckit/references/citation-instructions.md`. The Herziening rijksbreed cloudbeleid 2026, clause 3.2 MUST appear in the Document Register with its primary URL and the verification date. Before writing the file, read `.arckit/references/quality-checklist.md` and verify all **Common Checks** plus the **NLEXIT** per-type checks pass. Write the document to: ```text projects/{project_id}/ ``` ### Step 12: Summary Output ```text ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ✅ Cloud Exit Plan Generated ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 📄 Document: projects/{project_id}/ARC-{PROJECT_ID}-NLEXIT-v{VERSION}.md 📋 Document ID: {document_id} 📅 Assessment Date: {date} ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 📊 Coverage Summary ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Scenario A — Planned exit: {Documented / Gaps noted} Scenario B — Disruptive interruption: {Documented / Gaps noted} Provider data destruction: {Contractual clause in place / Not in place} Self-test evidence: {Present / None yet — flagged} Next review date: {date} ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Next steps: 1. {If no prior $arckit-nl-cloud assessment: Run $arckit-nl-cloud to confirm the trigger for this plan} 2. {If clause 4.5(b) is the trigger: Update $arckit-nl-cloud Section 3.2 with this plan's reference} 3. Run $arckit-risk to add residual exit risks to the risk register ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ``` ## Important Notes - **Both scenarios are mandatory, not alternatives.** Clause 3.2 requires a planned exit AND a disruptive interruption of service to be covered. Do not accept a document that only handles one. - **The disruptive scenario cannot assume provider cooperation.** If the plan's recovery method depends on the provider actively assisting, flag it as a gap — the scenario exists precisely because the provider may not be able or willing to help. - **A plan without test evidence is not yet compliant.** Self-testing is part of the clause 3.2 requirement, not an optional maturity add-on. State plainly if no test has occurred yet. - **This plan does not itself determine cloud eligibility** — that is `$arckit-nl-cloud`'s job. This command assumes a hosting decision already exists (or is being justified under clause 4.5(b)) and plans the exit from it. - **Use Write Tool**: Exit plans are detailed operational documents. Always use the Write tool. ## Key References | Document | Publisher | URL | |----------|-----------|-----| | Herziening rijksbreed cloudbeleid 2026, clause 3.2 (Exit-plan) (3 July 2026, definitief) | Ministerie van Economische Zaken en Klimaat, Staatssecretaris W.J.M. Aerdts, 3 juli 2026 | Kamerbrief: · Policy PDF: · Kamerstuk 26643, nr. 1541 | | OBDO "Cloud definities en begrippenlijst" (approved 16 April 2026) | OBDO | *(not linked — verify current text via digitaleoverheid.nl before citing)* | > **Note for reviewers**: Clause 3.2 sits alongside clause 4.5(b), which requires a tested exit plan as one of three cumulative conditions before email or document/workplace/file-storage services may be processed in public cloud. A single exit plan can satisfy both purposes if it is referenced from the `$arckit-nl-cloud` assessment rather than duplicated. ## Success Criteria - ✅ Exit plan created at `projects/{project_id}/ARC-{PROJECT_ID}-NLEXIT-v{VERSION}.md` - ✅ Trigger for the plan stated (materieel cloudgebruik and/or clause 4.5(b)) - ✅ Scenario A (planned exit) documented with export method, timeline, cost, dependencies, owner - ✅ Scenario B (disruptive interruption) documented, not assuming provider cooperation, with RTO/RPO - ✅ Provider data destruction after migration addressed with verification method - ✅ Self-test plan present, with test evidence or an explicit gap flag if untested - ✅ Annual review cycle set with owner and next review date - ✅ Residual risks identified with mitigation ## Example Usage ```text $arckit-nl-exit Produce the exit plan for a departmental email and document collaboration service currently in public cloud, no prior exit test conducted $arckit-nl-exit Exit plan for 001, case management platform migrating to public cloud under a confirmed materieel cloudgebruik determination $arckit-nl-exit Annual review update to the exit plan for a shared-services platform, provider contract renewed, update the self-test evidence ``` ## Suggested Next Steps After completing this command, consider running: - `$arckit-nl-cloud` -- Confirm the materieel cloudgebruik determination that triggered this exit-plan obligation, or satisfy clause 4.5(b) *(when No prior $arckit-nl-cloud assessment exists for this system)* - `$arckit-risk` -- Integrate residual exit risks (data-format lock-in, provider non-cooperation under disruption) into the risk register *(when Residual risks identified in this plan are not yet reflected in ARC-*-RISK)*