Shadow Cloud Accounts Before a Merger

First: decision rights, not tooling. The organization has 47 accounts because no one owns the answer to "who may create a cloud account, and under what conditions." Buying a CSPM tool or writing a 60-page policy before that is settled will produce visibility without authority.

Sequence:

1. Charter a cloud governance body with named decision rights across architecture, security, and finance - a federated model, not a central bottleneck. Publish a one-page RACI covering account vending, architecture exceptions, and spend approval. The split reporting lines (CISO versus COO) make explicit escalation paths essential.
2. Publish a minimum guardrail baseline - encryption at rest, no public buckets, mandatory cost-allocation tags, approved account-creation path. Keep it short enough to enforce.
3. Stand up account vending so the compliant path is faster than the credit-card path. Governance fails when the sanctioned route takes three weeks.
4. Then layer tooling: CSPM, SCPs, tagging enforcement, chargeback.

Why not tagging or chargeback first: both are consequences of governance, not substitutes. Finance's one-quarter deadline is achievable only if tagging is mandated at creation going forward while existing spend is backfilled manually. Design the model to federate, because the merger will add a second provider and a culture that did not grow up under these rules.

Prioritize by data exposure, not by spend or account age.

Phase 1 - contain (days): Use read-only discovery across all accounts. Immediately remediate the two unencrypted buckets holding delivery addresses: block public access, enable default encryption, and determine from access logs whether the data was ever publicly readable. That determination drives breach-assessment obligations. This is the only genuinely urgent item.

Phase 2 - attribute (weeks): Assign every account an owner and business unit. Where records are incomplete, interview engineering leads and reconcile against billing data. Untagged spend cannot be charged back, so this also unblocks Finance. Publish the inventory; visibility alone changes behavior.

Phase 3 - normalize (one to two quarters): Migrate workloads into a landing zone with centralized logging, identity, and guardrails. Do not big-bang migrate; move by risk tier, starting with internet-facing and customer-data workloads. Apply preventive controls (SCPs denying public storage and unapproved regions) once the vending path exists, so teams are not simply blocked.

Phase 4 - institutionalize: An exceptions process with expiry dates and named risk acceptors; periodic recertification of account ownership.

Judgement: preserve delivery by making the compliant path fast and the exception path visible, rather than by declaring a freeze that engineers will route around with another credit card.

Intent is right; mechanism is wrong. A hard block addresses the symptom - uncontrolled accounts - by raising the cost of the sanctioned path to infinity. The observed behavior (47 accounts on corporate cards over eight months) shows engineers already prefer shadow routes when the official one is slow. A block predictably pushes more workloads onto personal cards, personal cloud accounts, or unsanctioned SaaS, where they are invisible to security. That is a worse risk posture than the current one.

Better alternative:

• Interim vending: a thin, fast provisioning path (target: two business days) with the minimum guardrails pre-applied - centralized logging, encryption, tagging, no public storage. It does not need to be the final landing zone.
• Preventive controls where they are cheap: deny public S3 ACLs and unapproved regions immediately via SCP; these block the specific harms without blocking delivery.
• Executive sponsorship: the block only works if the CIO and COO jointly own the mandate, and even then it should be time-boxed with a published end date.
• Compensating monitoring for any account created outside the process, with a defined consequence path.

Merger consideration: a freeze now makes the nine-month integration harder, because the acquired company's teams will arrive with their own habits and no sanctioned path to migrate onto. Use the merger as the forcing function to finish the landing zone and federate it, rather than as a reason to delay governance.