The EU Residency Contract, the Region Guardrail, and the Account Nobody Owns

Decision: add a governed OU, do not widen the root policy.

• Editing the root SCP to add eu-central-1 opens the region to Sandbox and every other workload. That converts a residency control into an honour system and would force the auditor to test 62 accounts instead of one scope.
• Create an EU-Regulated OU under Workloads and attach an SCP that denies all regions except eu-central-1 for that OU. The deny must use NotAction to exempt global services (IAM, STS, Organizations, Route 53, CloudFront, Support, Health, billing) so that federation and support cases keep working; a naive Deny * on aws:RequestedRegion breaks console login and Cost Explorer.
• Provision the account through the account factory into the new OU, not by hand. Reuse the existing landing zone baseline (log delivery, Config recorder, Security Hub, backup vault) so the six-week date is realistic without a second landing zone.
• Data-layer controls in-region: CMKs created in eu-central-1 only, no multi-region keys replicating to us-east-1, S3 replication targets reviewed, and RDS/S3 encryption checked by Config rules scoped to the OU.

Evidence for the auditor: the SCP JSON and its change history from CloudTrail, a Config conformance pack report showing every resource in the OU carries the residency:eu tag and lives in an approved region, the account-vending ticket, and a region-allow-list register that maps each OU to a contract clause. The control is preventive (SCP) with detective backstop (Config), which is what makes the attestation defensible rather than aspirational.

Do not delete or suspend the account first. Deletion destroys the resource inventory and may destroy logs that are the only record of what happened; suspension can also break a workload that turns out to be revenue-relevant. Order the response as preserve, contain, understand, then remediate.

1. Notify and open a case. Security incident process, legal/privacy (unapproved storage of company data, possible personal data), finance (corporate card spend), and procurement. A named owner and a timeline record are audit evidence in themselves.
2. Preserve. Confirm whether the account appears in the organization trail; if it was created outside Organizations it may have no trail at all. Export the IAM credential report, S3 bucket policies and ACLs, bucket public-access-block settings, resource inventory, and any existing CloudTrail. Capture as exported JSON with hashes, not screenshots.
3. Contain without destroying. Apply a quarantine SCP to the account denying all actions except a forensic role and log export, disable the console passwords and deactivate (not delete) the two users' access keys. Deactivation stops abuse while keeping the identifiers searchable.
4. Scope the data. Classify what is in the 14 buckets and whether it is public; if personal data is present, start the 72-hour GDPR assessment now, not after forensics.
5. Disposition. Migrate any legitimate workload into a vended account with guardrails, then close the account after legal hold expires.

Root cause and control: the real gap is that account creation outside the organization was invisible. Add alerting on Organizations account events, an approved-email-domain rule, and a monthly reconciliation of billing accounts against the Organizations account list.

Evaluate against the contract, not the schedule.

• First question: what data will actually be in the environment? If it is synthetic or fully de-identified test data, an exception may be defensible; if policyholder data lands there even once, the residency clause is breached and the customer's right to audit is triggered. Get legal's written interpretation, not the delivery lead's.
• Second question: is there a compensating path? Because the OU work is roughly two weeks, staging could start in eu-central-1 early and only the go-live date is at risk. An exception that buys two weeks is not worth an audit finding and a contract amendment.

If an exception is genuinely granted, make it a controlled artefact:

• Time-bound and mechanically visible: an entry in the exception register with an owner, an expiry date, and a Config rule plus a scheduled ticket that fails loudly on expiry. SCPs cannot express time conditions, so the enforcement is calendar-driven and must be owned by a person.
• Narrowly scoped: specific accounts, specific roles, with compensating controls (mandatory encryption with a named key, public-access block, DLP scanning, no cross-region replication).
• Risk-accepted in writing by the risk owner who owns the customer relationship, with the number of open exceptions and their age reported to the risk committee monthly.

Judgement: exceptions without expiry are how guardrails decay. The healthy answer is to refuse the blanket exception, grant a two-week scoped one if data classification permits, and use the exception count as a governance metric.