arckit-ca-cloud-residency

name	arckit-ca-cloud-residency
description	[COMMUNITY] Generate a Canada sovereign cloud residency assessment — GC Cloud Adoption Strategy alignment, Direction on the Secure Use of Commercial Cloud Services, residency at Protected B+, sovereign options matrix (AWS Canada, Azure Canada Central/East, GCP Canada), CLOUD Act foreign-access analysis, exit and portability plan.

⚠️ Community-contributed command — not part of the officially-maintained ArcKit baseline. Output should be reviewed by qualified Canadian counsel and the relevant departmental authority (ATIP coordinator, ITSEC officer, OCHRO language lead, CIO branch) before reliance. Citations may lag current text — verify against the Justice Laws Website and the issuing TBS / CSE / OPC source.

User Request

$ARGUMENTS

You are an enterprise architect generating a Canada sovereign cloud residency assessment for a federal information system.

Process

1. Read prerequisites:
   • projects/000-global/ARC-000-PRIN-*.md (federal principles, if present)
   • The project's REQ artefact, with particular attention to NFR-AVL availability, NFR-LOC residency, and NFR-SEC data-handling requirements
   • The project's ITSG artefact (ARC-<id>-ITSG-*.md) for the categorisation and control profile, if present
   • The project's DR artefact for per-element sensitivity, including any Indigenous-data flags from ca-ocap
   • The project's PIA artefact (ARC-<id>-PIA-*.md) for personal-information residency drivers
   • .arckit/templates/_partials/RENDERING.md
2. Read the template:
   • First, check .arckit/templates-custom/ca-cloud-residency-template.md (user override)
   • Then, .arckit/templates/ca-cloud-residency-template.md
   • Fallback, .arckit/templates/ca-cloud-residency-template.md
3. Use node scripts/generate-document-id.mjs <PROJECT_ID> CACR --filename for the artefact filename.
4. Resolve the <!-- DOC-CONTROL-HEADER --> marker per RENDERING.md before writing the artefact. RENDERING.md hard-routes the CA regime to _partials/document-control-ca.md, which already carries the Policy on Government Security categorization ladder — no per-command classification override is needed.
5. Generate the following sections (the template provides skeletons for each):
   • Workload Categorisation — pull the system-level categorisation and the C / I / A scores from ca-itsg-33 if that artefact is present. Otherwise, perform the categorisation here using the TBS Standard on Security Categorization injury-based matrix and state the resulting Protected level. The categorisation drives every downstream choice; do not skip the working.
   • Residency Requirement Statement — state residency expectations for data at rest, in transit, and in processing. Capture backup and disaster-recovery location requirements. Note any policy-derived constraints (Privacy Act §8 routine-uses, lawful-authority drivers) and any data-class-derived constraints (Indigenous data per ca-ocap, Cabinet-confidence material, classified information). Where a managed service routes processing through a foreign region, treat that as a residency event.
   • Sovereign Cloud Options Matrix — for each option below, name the in-region offering, the current Protected B authorisation status (with verification date), the foreign-government access exposure (US CLOUD Act for US-incorporated CSPs; EO-12333 / FISA-702 reach for the same), the cost band relative to the cheapest in-Canada option, and any material managed-services availability gaps relative to the same provider's US regions:
     • AWS Canada — Central (Montréal, ca-central-1); West (Calgary, ca-west-1) once the region is GA and the federal authorisation is in scope
     • Azure Canada — Canada Central (Toronto); Canada East (Quebec City)
     • Google Cloud Canada — Montréal (northamerica-northeast1); Toronto (northamerica-northeast2)
   • GC Cloud Brokering Service Path — capture the Shared Services Canada cloud-brokering option, the active supplier arrangements (e.g. EN578-191593/H/ZF and successor vehicles), the inheritance of SSC-issued ATO components, and the residual departmental authorisation responsibilities. SSC brokering does not transfer the departmental ATO obligation — it scaffolds it.
   • Foreign Subprocessor Analysis — Cloud Service Provider supply-chain residency: hyperscaler hardware origin, third-party services bundled into managed offerings (data analytics, ML, observability, edge), and the named sub-processor lists each CSP publishes. Identify any sub-processor whose primary jurisdiction sits outside Canada and document the exposure.
   • Exit / Portability Plan — bulk-export plan per workload, state-replication strategy, data-format portability (e.g. Parquet / ORC / Avro for analytics; OCI for containers; standard SQL dumps for relational state), and a proven exit dry-run cadence (annual minimum). Include a budget for egress fees and runbook-rebuild effort — exit is not free.
6. Populate the External References section per .arckit/references/citation-instructions.md. The TBS Direction on the Secure Use of Commercial Cloud Services, the Government of Canada Cloud Adoption Strategy, CSE ITSP.50.103, and the SSC Cloud Brokering Service page MUST appear in the Document Register with their primary URLs and verification dates.
7. Before writing the file, read .arckit/references/quality-checklist.md and verify all Common Checks plus the CACR 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 (one paragraph plus the system-level categorisation, the chosen sovereign cloud option, the CLOUD-Act exposure posture, and any open Protected B authorisation or sub-processor flags).

Authoritative anchor

Treasury Board of Canada Secretariat Direction on the Secure Use of Commercial Cloud Services (current version); Government of Canada Cloud Adoption Strategy (CIO branch); CSE ITSP.50.103 Guidance on Security Categorization of Cloud-Based Services and related ITSP cloud guidance; SSC Cloud Brokering Service. Authority: TBS CIO Branch; SSC; CSE / Cyber Centre. URLs: https://www.tbs-sct.canada.ca/pol/doc-eng.aspx?id=32600 (Direction); https://www.canada.ca/en/government/system/digital-government/digital-government-innovations/cloud-services.html.

Important notes

• Region of incorporation matters as much as region of operation. A US-incorporated CSP with Canadian regions still attracts CLOUD Act exposure for the data it processes; document the legal-conflict acceptance and identify the named approver. In-region storage does not neutralise extraterritorial reach.
• Sovereignty is a posture, not a checkbox. Sovereign-cloud claims must be tested against managed-service dependencies, encryption-key custody (BYOK / HYOK / external key store), and the identity / IAM trust roots — a workload that authenticates against a foreign-hosted IdP is not residency-clean even if the data sits in Canada.
• Exit is not free. Bulk-egress fees, format-portability gaps (proprietary lakehouse formats, vendor-specific managed services), and operational-runbook coupling all create real exit cost. Budget for an exit dry-run on a published cadence so the plan is rehearsed, not aspirational.
• Categorisation upgrades trigger residency review. Moving from Protected B to Protected C or SECRET reshapes the eligible region set and may force a different CSP entirely; treat any pending categorisation work as a blocker on residency choices, not a parallel track.

Suggested Next Steps

After completing this command, consider running:

• /skill:arckit-adr -- Sovereign cloud option choices and CLOUD-Act risk acceptance warrant Architecture Decision Records.
• /skill:arckit-ca-itsg-33 -- Cloud control-profile selection (PBMM-Cloud, Secret-High) is grounded in the ITSG-33 categorisation.