The Second Cloud Arrived With an Acquisition. The Guidance Assumes a Strategy.

The estate was assembled by decisions nobody wrote down

How the second cloud arrived is a question about a deal, or a deadline, or a vendor contract, and the answer comes back as a story about one of those. A deal closed and the target's engineering ran on a platform your team had never operated. A vendor the business depends on runs where it runs, and integrating with it put your data there.

The published material addresses a different reader. Reference architectures open with criteria for placing a workload, governance guidance with a target operating model built before the first account exists. Both assume a decision point that never happened here.

Production already runs in all three. Several of the people who made the original calls have moved on. The question you get is whether the estate is safe, asked about all three at once. The routes in are ordinary:

• An acquisition, where the second cloud arrives with a company, its engineers, its contracts and security decisions somebody else made.
• A team that needed a managed service faster than the central request queue moved, and had a corporate card.
• A vendor platform the business runs on, hosted where that vendor's engineering chose, holding your data there.
• A data residency requirement met once, for one contract, in the only place it could be met then.
• A proof of concept that was never meant to hold production and does.

Nobody chose a multi-cloud estate. Three separate problems got solved, and this is what they left behind.

Converging the platforms is its own program

The instinct in the first month is to pick one platform and move everything onto it. It is a clean idea and it is sometimes right. It is also a program measured in years, and the bill is set by what surrounds the workloads.

That case belongs to whoever owns platform engineering. Hiring, contract terms and the cost of running two deployment models are its inputs, and it may well be strong. The security question sits beside it, with an answer available long before a migration finishes.

This next part is a CWS position. A security leader needs a small number of things to read the same everywhere: identity, the control plane record, and a short baseline. The platforms underneath can stay different.

The workload is the visible part of a migration. The surrounding work is where the time goes:

• Deployment pipelines written against one provider's primitives, and the engineers who maintain them.
• Runbooks the on-call rotation knows without opening.
• A managed service with no direct counterpart on the destination, which turns a migration into a rebuild.
• Committed spend agreements with terms that outlast the migration plan.

Identity is the first thing that has to match

Identity comes first because it is what already joins the clouds to each other. A pipeline in one provider deploys into another. A workload in one holds a federated credential into a second. Those paths exist whether or not anyone drew them, and here they were built by separate teams at separate times.

Standardizing identity means a short list of answers holds everywhere: where a human is granted access, how that grant ends the day they leave, and which machine identities cross a provider boundary. The mechanism can differ per cloud. The answers cannot.

The acquisition case is the sharpest version. The acquired company had a working identity practice on its own terms, and its leaver process may still be running through its own HR system months after the deal closed, on a schedule nobody in your team set.

Enumeration comes before engineering. Before anyone federates anything, somebody should answer these for every provider in the estate:

• Which humans can reach production, and which directory that answer comes from.
• What happens to that access on the day someone leaves, and who executes it.
• Every trust relationship that crosses a provider boundary, in both directions, with a named owner.
• Which credentials are long lived, where they are stored, and when each was last rotated.
• Who can create a new account, subscription or project, and whether that is visible outside the team that did it.

No one drew the paths between the three clouds. The credentials drew them anyway.

One place the record lands

The second thing to standardize is the record. Each provider emits a durable account of what happened on its control plane, and each does it well. What happens to that record afterwards is where the estate comes apart.

Each cloud sends its record wherever its own team chose. A tool the acquired company was already paying for. A retention period set on a day when the question in the room was storage cost. All three clouds are logging. One query reaches across them once all three streams land in the same place, and in an estate assembled this way each stream still lands where its own team sent it, so the retention on all three is something you find out by asking three people.

Settle the retention number first, because it is the only item here that cannot be repaired afterwards. An investigation opened today reaches back as far as the shortest retention in the estate, and in an estate nobody designed, nobody chose that number. It came from a default, or a cost conversation, or an engineer at a company you acquired.

The rest of the standard is narrow enough to finish. Four things to write down:

• One retention period for the estate, with every exception recorded and owned by a person.
• One destination, and a named list of who can read it.
• The fields that carry the same meaning in all three streams: who acted, on what, when, and from where.
• Control plane events first, so the record of who changed the estate is complete before anyone argues about data plane volume.

A baseline written as conditions of entry

The third thing to standardize is the security baseline, written as a short list of conditions a cloud has to meet before it holds production work. It states what has to be true of the three clouds you have, and the next time a deal brings in a fourth it is what the integration lead works from. The security slot in an integration plan is short, and a list already written is what lets you use it.

Keep it short enough that a platform lead holds it in their head. Once it runs long it becomes an assessment. Conditions of entry are the subset you would stop a production launch over, and each one names no service, so it survives the move between providers.

CWS assesses estates put together this way, scoring AWS, Azure and Google Cloud against CIS Benchmarks, the Cloud Controls Matrix and the NIST Cybersecurity Framework, with the same practice that implements Prisma Cloud and Wiz. Which of those controls you enforce identically everywhere, and which you let each platform meet in its own way, is a judgment the frameworks leave to you.

Standardizing identity, the control plane record and a short baseline while deliberately leaving the rest of the estate divergent, together with the divergence register that records those choices, are CWS design. One version follows, offered so you can build a different one:

• Human access to production is granted from the estate's directory, and it ends when employment does.
• The control plane record lands in the estate's destination, at the estate's retention period.
• Every account, subscription and project has a named owner recorded outside the account itself.
• Data at rest is encrypted, and you can name the people who can reach the keys.
• Public exposure of storage and compute is a decision on the record, with a name against it.

What you leave different, on purpose

Everything else can stay different, and saying so out loud is the step that gets skipped. Divergence nobody wrote down reads as debt to the next person who inherits the estate, and their first proposal will be a program to clear it.

The mechanism is a register: what differs, why, who owns each side, and what would make you revisit it. The entries are unglamorous. Two infrastructure as code tools, kept because two teams are fluent and neither is being retrained this year. Different network designs, because the workloads have different shapes.

It pays for itself in two rooms. In an audit conversation, a divergence with a reason and an owner is a position you can defend a year later. An undocumented one is a finding. In the next integration, the register tells you which questions to put to the acquired team in week one.

Each entry needs enough on it to be useful when the person who wrote it has moved on:

• The thing that differs, described so somebody outside the team recognizes it.
• The reason, written at the time by the person who made the call.
• The owner on each side of the difference.
• The cost of leaving it, counted as a second pipeline, a second set of runbooks and a second on-call skill.
• The trigger that reopens it, whether a contract renewal, a team change or a workload moving.

You do not have to converge the estate. You have to be able to say which parts had to match, and be right about it.