The Residency Commitment Was Signed Before Anyone Mapped the Workloads

The answer came from a region selector

The sentence goes into the agreement early, while the commercial terms are being settled and the technical people are answering questions between other meetings. Data stays in the country. Somebody with console access checks, sees the region on the screen, and confirms.

The confirmation is accurate about the resource they were looking at. The commitment is written about the data, and data moves in more directions than a workload does. The gap between the two is there from the moment the sentence is signed, and it shows itself when somebody asks for the evidence behind it.

Residency is a standing condition in Canadian federal and Quebec public sector procurement, so the sentence is a condition of being allowed to bid. It gets agreed before anyone examines the estate, because the bid has a date and the examination has no owner.

The person who answered was looking at something real, and it was one of these:

• A provider contract term stating a service can be operated in a given region, which describes what the platform offers and leaves what your estate actually selected as a separate reading.
• A diagram from the original build, showing the application and its database, drawn before the logging pipeline and the analytics export existed.

The legs of the path were configured one at a time

Residency is a property of a path, and a path has legs. The application and its primary datastore are the leg everybody can name, because that is the leg the diagram was drawn for. The others were configured later, by different teams, each picking a region while thinking about something other than the agreement.

Every one of them has an answer available. Somebody has to go and read each of these:

• A backup or replication destination gets selected while durability is the question in the room, and a durability argument pushes toward distance, so the setting outlives the conversation.
• Logs, traces and metrics describe the workload and routinely carry data from inside it: identifiers, a record in an error payload, a query string. The region they aggregate in was the monitoring team's to pick.
• A content delivery network caches responses and writes access logs at points of presence chosen for latency, which puts copies of the data outside the country while every origin resource still passes the region check.
• Running a managed service involves metadata about your resources, and where that metadata lives has its own regional answer that the provider documents, selectable in some services and global by design in others.
• A support session or a break-glass login puts a person outside the boundary in front of the data on a screen while the data itself stays where it is.
• The vendor platform in your estate runs somewhere and uses vendors of its own, and those regions are inherited by you while sitting outside every diagram your team drew.

Data stays in the country was agreed in a commercial meeting. The estate was configured over four years by people who were never in it.

Access is a form of movement

Five of those legs are resting places, and a resting place can be evidenced from configuration. One of them is a person reading the data from somewhere else, evidenced from a record somebody was already keeping. Two populations produce it.

Your provider's support organization is the first, and all three major providers now put a per case decision in your hands over whether a support engineer reaches your content. AWS Support raises a permit request, and you answer it by issuing a scoped permit or by rejecting it. Each permit is signed with a customer managed KMS key, bounded by action and resource, given an optional time window, deactivated when the linked case closes, and recorded in CloudTrail. Azure Customer Lockbox routes an approve or deny decision to named approvers, requires at least a Developer support plan, and expires a request after four days, with documented exclusions covering break-glass emergencies and external legal demands. Google Access Approval sits on top of Access Transparency, is open to any Google Cloud customer, and Google states that support response time lengthens while a request waits on your approval.

All three arrive at a per case approval and get there differently, and the differences are what an auditor asks about, so read each one against the accounts you hold. Operating a permit model is a heavier job than clicking a single approval, and the exclusions and the list of covered services decide whether a control satisfies the commitment you signed. Which of them you have enabled, and the evidence they produce, is yours.

The second population is your own team and its vendors. A break-glass account exists so somebody can get in when the normal path is broken, and it gets used at the worst hour by whoever is awake. A follow the sun rotation with engineers outside the jurisdiction gives the residency commitment an implication for the on-call roster, and the on-call roster was staffed against a different requirement.

For this leg, write down:

• Which provider support controls are enabled, per account, subscription and project, with the person who enabled them and the date.
• The break-glass accounts, who holds them, where those people work from, and what the record of a use looks like afterward.
• Vendors and service providers with support access into the environment, and the countries their staff operate from.
• Screen sharing and remote sessions, where the data is displayed outside the boundary while nothing is copied.

A storage location can be proved from configuration. A support session at two in the morning can only be proved from a record somebody was already keeping.

The controls exist, and the estate has to be read against them

Every provider publishes where its services run, documents which components are regional, and offers configuration to constrain them. The gap opens on your side of that line, where a setting was chosen for a sound reason by somebody answering a different question.

CWS runs tool agnostic posture assessment across AWS, Azure and Google Cloud, scored against CIS Benchmarks, the Cloud Controls Matrix and the NIST Cybersecurity Framework. The Cloud Controls Matrix earns its place here because its domains state which side of the shared responsibility boundary a control falls on, which is what every leg of the path raises.

The legs are configuration, so an assessment can read them. Whether the reading means anything is decided by scope, and residency scope has to run wider than the scope a posture assessment is normally drawn against. Scope it to include:

• Every account, subscription and project, enumerated from your own billing hierarchy before the scope is frozen, because a workload missing from the list still holds data.
• Backup, archive and replica configuration, read separately from the primary storage configuration.
• The destination of every log, metric and trace stream, including the ones a vendor platform ships on your behalf.
• The content delivery configuration, covering which points of presence serve and cache responses and where their access logs are held.
• The regions enabled in each account, including one enabled for a test and left on afterward.

Writing a claim that survives the follow up question

The artifact is a statement per leg. Assembled, they produce the single line the customer or the audit committee asked for, and the line carries its exceptions inside it.

It reads something like this. The application and its datastore run in the region. Backups and replicas are constrained to it. One telemetry stream aggregates outside it and carries no customer records. Provider support access is restricted, with the control named. That is longer than yes, and it holds when somebody pushes on it.

Where a leg cannot be constrained, the artifact is a documented exception with an owner, a date and a compensating control, raised with whoever owns the commitment while there is time to act on it. Whether it is acceptable under the agreement belongs to counsel and to the contract. Producing the facts they decide from is the security team's work.

Treating residency as a property of the whole data path, writing a statement per leg, and settling failover authorization in advance are CWS positions. Nothing here is a legal determination. Each leg statement carries:

• Where the data goes, at the granularity the commitment is written in.
• The setting or contract term that constrains it, the person who owns it, and the date it was last verified.
• The exception, where there is one, with its compensating control and the name of the person who accepted it.

The failover target was chosen by somebody else

One event moves the data across the boundary deliberately, on a plan, with senior approval. A failover. The continuity plan and the residency sentence were written by different people in different years, and the failover region was selected against a requirement about distance and independent failure, which is the requirement the person choosing it was handed.

So the day the continuity plan works exactly as designed is the day the data leaves the boundary, and the people executing it are following a runbook during an outage at three in the morning.

The decision is cheap while nothing is on fire. Pick the target region with the commitment on the table, write the authorization condition into the runbook, and name who authorizes a crossing. Whether the agreement permits a temporary one is a question for counsel, asked now.

Everything else that moves the answer is ordinary engineering work, done at a distance from the agreement, so the checks attach to events that already have a project manager on them:

• The failover target for every workload covered by the commitment, and whether it sits inside the boundary.
• A residency question on the architecture review, asked of any new managed service before it holds data.
• A residency question at vendor onboarding, covering where the vendor runs and who it subcontracts to.
• The version of the register, and the date each leg was last verified, reported wherever the commitment is reported.

Somebody authorized the failover target years ago, in a continuity plan, without being asked a residency question.