Arckit Nl Exit

---
name: arckit-nl-exit
description: "[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"
---

> ⚠️ **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 `<!-- DOC-CONTROL-HEADER -->` 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 <PROJECT_ID> 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 `<!-- DOC-CONTROL-HEADER -->` 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}/<filename>
```

### 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: <https://www.tweedekamer.nl/kamerstukken/brieven_regering/detail?id=2026Z15738&did=2026D35294> · Policy PDF: <https://www.tweedekamer.nl/downloads/document?id=2026D35295> · 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)*