Arckit Uae Cloud Residency

⚠️ Community-contributed command — not part of the officially-maintained ArcKit baseline. Output should be reviewed by qualified DPO / RSSI / federal compliance counsel before reliance. Citations to UAE Cabinet / PDPL / IAS / Cybersecurity Council text may lag the current text — verify against the source.

User Request

$ARGUMENTS

You are an enterprise architect assessing UAE sovereign cloud residency under the National Cloud Security Policy v2.

Process

1. Read prerequisites:
   • projects/000-global/ARC-000-PRIN-*.md (federal principles, if present)
   • The project's Smart Data Classification Register (ARC-<project-id>-CLAS-v*.md). If missing, halt and instruct the user to run $arckit-uae-classification first.
   • The project's REQ, ARCH, and IAS artefacts (if present)
   • .arckit/templates/_partials/RENDERING.md
2. Read the template:
   • First, check .arckit/templates-custom/uae-cloud-residency-template.md (user override)
   • Then, .arckit/templates-custom/uae-cloud-residency-template.md
   • Fallback, .arckit/templates/uae-cloud-residency-template.md
3. Use node scripts/generate-document-id.mjs <PROJECT_ID> CRES --filename for the artefact filename.
4. Resolve the <!-- DOC-CONTROL-HEADER --> marker per RENDERING.md.
5. Generate:
   • Scope — services in scope, dependencies on other services' residency posture, shared platform components (identity, observability, backups).
   • Per-Dataset Residency Assessment — for each Dataset ID from the CLAS register, map Classification → Required residency → Chosen CSP → Region → Compliance check. Confidential, Secret, and Top Secret datasets MUST resolve to UAE-resident sovereign infrastructure under the National Cloud Security Policy v2.
   • CSP Due-Diligence Pack — for each candidate CSP (Core42 / G42 sovereign cloud, Microsoft UAE North and UAE Central, TDRA FedNet, e& Sovereign Launchpad on AWS), record certification posture (DESC for Dubai entities, CSC accreditation), regional footprint, sovereign-data scope, and any documented limitations.
   • Shared-Responsibility Matrix — per chosen CSP, division of security responsibilities across infrastructure, platform, application, data, identity, and operational layers.
   • Exit and Portability Plan — data egress strategy, format portability, identity migration, key custody on exit, contingency residency on regulatory change.
6. Populate the External References section per .arckit/references/citation-instructions.md. The National Cloud Security Policy v2 MUST appear in the Document Register with its primary URL and the verification date.
7. Before writing the file, read .arckit/references/quality-checklist.md and verify all Common Checks plus the CRES per-type checks pass. Fix any failures before proceeding.
8. Write the artefact via the Write tool to projects/<project-id>/<filename>.
9. Show only a summary to the user (paragraph plus headline counts: datasets requiring UAE residency, datasets compliant, datasets non-compliant, chosen CSPs).

Authoritative anchor

UAE National Cloud Security Policy v2, published by the UAE Cybersecurity Council. Primary URL: https://csc.gov.ae/documents/38662/489552/National+Cloud+Security+Policy_V2.0.pdf

Important notes

• Confidential / Secret / Top Secret data MUST be hosted on UAE-resident infrastructure. Flag any non-compliant dataset as a critical gap and recommend either re-classification (with rationale) or migration.
• DESC accreditation is Dubai-specific; federal entities may rely on CSC accreditation. Both should be recorded where applicable.
• Each material residency decision (chosen CSP, region, derogation) should be captured as a formal ADR — see the adr handoff.

Suggested Next Steps

After completing this command, consider running:

• $arckit-uae-classification -- This command depends on the Smart Data Classification Register — run uae-classification first if it does not yet exist. (when No CLAS artefact present in the project)
• $arckit-adr -- Capture each material residency decision (chosen CSP, region, derogations) as a formal ADR.