A multi-cloud security operations center (SOC) needs one operating workflow, not one security product, one detection language, or one containment action: a shared triage queue, a SOC-owned priority model, common case ownership and escalation rules, and provider-specific response branches.
Normalize only the fields that drive triage and case handling. Preserve every cloud's raw evidence and native detection context, then route AWS, Azure, and GCP findings into one queue with the original severity, confidence, asset context, and source retained.
Don't translate a GuardDuty Critical directly into a Defender for Cloud High or a Security Command Center Critical. GuardDuty uses a 1.0–10.0 scale mapped to four labels; Defender for Cloud's labels combine detection confidence with confidence in malicious intent; Security Command Center uses its own severity categories. Your SOC has to convert those into a separate response-priority policy, not assume they already mean the same thing.
In brief:
- Workflow fragmentation causes multi-cloud security failures even when coverage exists. Separate queues force analysts to translate alerts and switch containment procedures, adding cost above the tools underneath them.
- Provider severity labels aren't interchangeable: they combine different mixes of detection confidence, intent, and technical impact, so a shared operating layer needs its own priority scale, not a direct relabeling of GuardDuty, Defender for Cloud, and Security Command Center values.
- The Open Cybersecurity Schema Framework (OCSF) can reduce schema friction, but it doesn't define your severity policy, ownership model, or containment authority. That's still an operational layer you build.
- Identity containment stays cloud-specific by design. AWS, Azure, and GCP credential models were never built to map to one another, and every identity runbook needs per-cloud execution branches.
The three layers a multi-cloud SOC actually needs
A workable operating model has three layers, and conflating them is what makes "single workflow" sound like giving up cloud-native fidelity. The native evidence layer keeps raw logs in provider-native form. The shared SOC operating layer normalizes only the fields needed for ownership, triage, prioritization, and escalation. The provider-specific response layer executes tested containment branches per cloud, each with its own permissions and rollback checks.
Keeping these layers distinct is what lets a SOC run one workflow without pretending three clouds produce comparable data.
Replace provider labels with your own SOC priority scale
A provider's severity label mixes confidence, intent, impact, and business context differently. GuardDuty's Critical comes from a 1.0–10.0 range; Defender for Cloud's High reflects confidence in the finding and the intent behind it. These aren't equivalent, so mapping both into shared labels implies a severity that doesn't exist. Build a SOC priority scale instead: a response priority, not a provider-neutral severity.
SOC priority
Example routing condition
P1
Credible active compromise affecting a crown-jewel workload, privileged identity, or material data path
P2
High-confidence malicious activity requiring same-day investigation or containment
P3
Suspicious activity requiring investigation within the defined SLA
P4
Informational, compliance, posture, or enrichment signal with no immediate investigation requirement
Closed/Suppressed
Duplicate, benign, expected, expired, or otherwise governed out of the active queue
GuardDuty maps a 1.0–10.0 score to four labels. Defender for Cloud uses High through Informational, based on confidence, not a score. Security Command Center uses its own categories too. The fix is a mapping table the SOC owns, applied at ingestion, feeding each native value into your priority scale while keeping the original, the pattern AWS Security Hub uses internally with Severity.Label and FindingProviderFields.Severity.Original.
One triage queue, whatever cloud the alert came from
OCSF reduces schema friction, but it doesn't define your severity policy, ownership model, or containment authority; treat it as a normalization aid, not an operating model. Amazon Security Lake normalizes logs into OCSF, Sentinel normalizes to ASIM, its own model, and Google SecOps ingests OCSF into its own Unified Data Model. None of these replace the SOC-owned queue above them.
Most SOCs must prioritize, since review capacity is finite, and unowned findings accumulate without consistent triage or disposition. GuardDuty gets operationally weak specifically when findings lack routing and playbooks, not from anything inherent to the service. Build one cross-cloud operating queue in the alert-management layer, on top of whatever schema each provider ships, and route findings through your SOC priority scale.
Provider-neutral decisions, cloud-specific execution
Use a provider-neutral, human-readable decision layer and an execution layer that forks per cloud in the runbook that works. The decision layer can specify revoking compute network access, and an AWS branch applies the relevant isolation control while the Azure branch changes network controls and the GCP branch applies firewall restrictions.
Each branch carries its own caveats. AWS security-group changes don't immediately interrupt tracked connections; the group keeps allowing packets until connections time out, so isolation needs a tested method for cutting sessions, not just replacing the group. A disk snapshot preserves disk state, not memory, and can be inconsistent if writes were mid-transit. Automation can isolate correctly and then get reversed by autoscaling or IaC reconciliation, so test that first.
Where the clouds resist a single workflow
Engineering can resolve the schema friction above, but IAM credential models in AWS, Azure, and GCP were never built to map to each other, so identity-response stays provider-specific. AWS treats roles as central, and CloudTrail maps AssumeRole activity to a session principal, though human attribution depends on federation setup. Azure separates identity objects from roles, while GCP may identify a service account instead of a human where credentials are used without attribution controls.
Disabling an identity requires a different mechanism, and a different set of caveats, in each provider:
- AWS: Disabling or changing a principal isn't enough by itself in every scenario. AWS does support revoking active sessions for a compromised role, but your runbook has to identify whether active role sessions, IAM Identity Center sessions, access keys, or federation sessions also need explicit revocation.
- Azure: Revocation branches by the type of credential involved: user sessions, refresh tokens, enterprise application and service principal credentials, application secrets or certificates, Azure RBAC assignments, and workload identities each need their own containment step. Don't collapse these into one generic "revoke access" action.
- GCP: Disabling a service account key does not revoke short-lived credentials already issued from it; revoking those requires disabling or deleting the service account itself. Policy changes can also take time to propagate, so runbooks should verify effective access and record the propagation window before declaring containment complete.
Normalize the workflow before consolidating tooling
Tool consolidation can create migration, tuning, and coverage risk if it removes useful telemetry or detection logic before replacements are validated, and a lower vendor count can leave the operating model underneath completely unchanged. I've watched a unified interface conceal separate back-end systems that still needed different tuning and telemetry checks, with operational ownership remaining just as fragmented as before.
In my experience, the severity mapping document has outlived the tools in every vendor selection I've run. Start there: write the cross-provider map as a one-page policy the SOC owns, apply it at ingestion, and route every console into one layer, whether the shortlist is Expel, Arctic Wolf, ReliaQuest, or CrowdStrike Falcon Complete. Keep immutable raw logs per provider as the forensic source of truth, since native records retain context normalization loses.
What stays cloud-specific, and why that's fine
Provider mechanics require provider-specific detection logic; forcing it into a shared model degrades fidelity. Provider-specific taxonomies keep separate log-source definitions for AWS, Azure, and GCP by design, since a rule firing on CloudTrail AssumeRole isn't portable and each provider enriches records differently. Azure illicit consent grant detection depends on Entra ID audit activity and OAuth scopes, with no direct CloudTrail or GCP equivalent.
Normalize the fields required for detection, triage, correlation, and reporting, and retain raw provider records for fidelity and forensics. Estimate the storage and transformation cost before normalizing high-volume telemetry, since bulk normalization adds overhead that most queues don't actually need.
Test it before you buy or renew anything
Before you buy or renew, give the vendor one real finding from AWS, Azure, and GCP. Ask them to show the native evidence, the SOC priority assigned, the queue owner, the case workflow, the applicable containment branch, and how the analyst verifies that containment held. If the answer is a dashboard tour, the workflow isn't consolidated.
My own severity mapping document is one page and has outlasted two SIEM contracts. That's the bar I hold every vendor to now.
Frequently asked questions about multi-cloud security
What is multi-cloud security?
Multi-cloud security protects cloud workloads across two or more providers, including the identities and data associated with them. AWS, Azure, and GCP ship incompatible alerts and IAM structures, so a SOC ends up running parallel operations unless it normalizes at the workflow layer, which gives analysts a shared queue and consistent response decisions while preserving cloud-specific execution.
How do you run one SOC workflow across AWS, Azure, and GCP?
Map each provider's native severity into your own SOC priority scale at ingestion, and preserve the original value alongside it. Use that mapping in a single triage queue whose prioritization logic connects to provider-neutral response decisions and tested per-cloud containment branches.
Do you need separate tools for each cloud?
Keep per-cloud telemetry sources and native detection services, since those signals originate inside each provider. Fix the workflow before consolidating tooling: a workflow layer can normalize across whatever stack you already run by routing findings from existing consoles into one queue while preserving each provider's native payload.
What should stay cloud-specific?
AWS AssumeRole chains, Entra ID consent grant detection, and GCP service-account key abuse all stay cloud-specific, since each requires its provider's own log semantics. Raw log retention per provider and the execution branches of identity containment runbooks stay cloud-specific too. The shared severity and triage model sits above these, not in place of them.