Who Is Responsible for Each Action During a Cloud Security Incident?

Your cloud incident needs an action owner on each side of the service boundary. The provider operates and responds within the infrastructure and services it controls. Your organization must coordinate the customer response, make business decisions and arrange action on the identities, configurations and applications within its control. A managed service provider can perform delegated tasks, but only within its actual agreement, permissions and operating procedures. Assign someone to authorize each consequential action, someone able to execute it, and someone to verify the result.

That is the practical answer. The hard part is specifying the action. “Contain the account” can mean stopping new sign-ins, denying an existing role session, ending an application session, suspending a workload or preventing access to a particular dataset. Those changes can belong to different teams. A shared-responsibility diagram won't tell an investigator which one has happened.

I would turn the diagram into a small set of executable agreements for your critical services. This paper develops that method from official incident-response guidance and current provider documentation. It is an engineering synthesis, not a validated response-time model. The worked incident is fictional; no live tenant, customer environment or response service was tested. The question is whether each necessary action has a workable path from decision to verified effect.

Start with the affected service, not the cloud logo

Microsoft's responsibility guidance distinguishes infrastructure, platform and software services. Customers retain responsibility for data, identities and customer-controlled configurations, while responsibility for operating systems and other layers changes with the service model. Microsoft also explicitly describes this as governance guidance rather than a modification of contractual terms (Microsoft, 2026d). I would use that distinction to begin the investigation, then check the particular product and agreement before assigning an operation.

Consider a compromised application hosted on virtual machines. Your team may control the guest operating system and application deployment. Move the same business function to a managed application platform and a host-level investigation may no longer be something your administrators can perform. Move it again to SaaS and your practical controls may be tenant configuration, accounts, integrations and exports. The business outcome can remain identical while the available response actions change substantially.

The unit of analysis should therefore be a service instance with its dependencies: the tenant or account, resource, identity authority, application owner and relevant provider offering. “Azure handles infrastructure” is too broad to tell you whether a particular setting is yours to change. “Our MSP manages the cloud” is equally incomplete when the MSP manages workloads but another team controls identity federation.

I would also distinguish a customer-side compromise from a provider-side incident. Microsoft describes service-specific response teams coordinating investigation with affected service teams, which implement containment and recovery work (Microsoft, 2026c). That describes Microsoft's internal response organization. It does not establish that those teams will administer every customer's compromised application. Conversely, a customer action list cannot require access to provider infrastructure that the customer does not control.

For an uncertain incident, run both workstreams where justified. Investigate the customer-visible activity and submit a precise provider request about the inaccessible layer. You needn't settle responsibility for the original failure before taking authorized protective action. Fault attribution, contractual liability and operational execution are different questions, even when the same incident eventually requires answers to all three.

Replace the broad RACI row with a bounded action

A RACI chart identifies who is responsible, accountable, consulted and informed. AWS recommends clarifying these roles and involving application owners who understand affected resources and may hold access responders lack (Amazon Web Services [AWS], n.d.-a, pp. 10–11). I would retain the chart, but make its rows concrete enough to execute. “Security incident response” is a program; “deny this principal access to this production resource” is an action.

For each action, record the trigger, exact scope, decision authority, executor, required permissions, anticipated operational effect, verification method and fallback. Include a deadline or review condition appropriate to the scenario. This is a proposed action record, not another mandatory industry standard. Its purpose is to expose contradictions that role labels alone can hide.

The decision authority owns the accepted tradeoff. The executor has the technical capability to make the change. The verifier determines whether the intended boundary now holds. One person may perform several functions in a small organization, but the functions should remain distinguishable in the record. Otherwise, a successful administrative request can be mistaken for a successful security outcome.

NIST recommends documenting incident-response responsibilities and assigning the authority needed to discharge them, including responsibilities involving third parties (Nelson et al., 2025, GV.RR-02). I interpret that as a reason to test the agreement between organizational permission and technical permission. An incident commander who can authorize isolation but cannot reach a suitably privileged operator has a coordination problem. An operator with broad access but no delegated decision authority has a different problem.

Proposed action	Authority to settle beforehand	Execution and verification question
Restrict a compromised identity	Who may interrupt every dependent service within the proposed scope?	Which administrators control issuance, resource permissions and surviving application sessions?
Isolate a workload	Who may interrupt its business function, and under what trigger?	Which control changes traffic, and what evidence distinguishes new from established connections?
Preserve incident material	Who may approve collection, access and transfer?	Who can retrieve the required artifact and confirm its scope, provenance and destination?
Request provider intervention	Who represents the customer and approves requested changes?	Can an entitled contact reach the right support process and track the specific request?
Resume service	Who accepts the remaining security and business uncertainty?	Who validates the restored function and the removal or justified retention of emergency restrictions?

The table is a starting structure, not a universal assignment of teams. Populate it for your actual operating arrangement. An MSP might execute three rows and observe another. A provider might offer a contracted response service that performs an action on your behalf. Neither arrangement removes the need to establish scope and verify the result.

Identity containment crosses more than one administrative boundary

Identity is where a single “done” message can conceal several unfinished operations. AWS's documented role-session revocation attaches a deny policy with an issuance-time condition. It affects sessions issued before the relevant cutoff; later sessions are not covered by that same time condition. The mechanism applies across users of the role, and the documentation identifies exceptions, including service-linked roles and a separate procedure for IAM Identity Center permission-set sessions (AWS, n.d.-c).

The operational consequence is not “always revoke every role.” It is that the identity lead must identify the credential type and issuance path before the incident commander can understand the scope of the proposed restriction. If a compromised path can obtain fresh credentials, restricting older sessions is only part of the response. If legitimate applications share that role, the business effect is broader than the suspected actor.

Microsoft documents another boundary: an application can issue its own session token, and Microsoft Entra ID cannot directly revoke that application-issued token. Effective access removal depends on the application's behavior, including its own session controls and supported continuous access evaluation where applicable (Microsoft, 2026b). Your directory administrator's completion message may therefore need a corresponding application-owner action before the incident's containment objective is met.

Google's service-account guidance makes a related but product-specific distinction. Disabling a service-account key prevents its further use for authentication, but does not revoke short-lived credentials already issued from it. The documentation identifies disabling or deleting the service account as the way to revoke those credentials and warns about the effect on workloads using that account (Google Cloud, 2026c). That is a materially different scope from disabling one key.

I would record these as separate assignments under one containment objective. The identity administrator addresses the issuance or credential boundary; the resource owner addresses the target permission where appropriate; the application owner addresses any independent session. Verification should name the formerly permitted operation and the authority under which it was attempted. It should not collect reusable tokens in an incident chat simply to demonstrate possession.

The broader lifecycle question belongs in the workload identity ownership paper. Here, the point is the incident handoff: the team receiving a revocation result must know exactly what ended, what may survive and which other owner has the next action. Provider mechanisms are examples to validate against your configuration, not interchangeable commands for a multicloud runbook.

Network isolation needs a statement of what remains connected

The AWS Security Incident Response service documents an EC2 containment automation that replaces security groups with a restrictive group while leaving the instance running. It explicitly warns that changing security groups does not shut down existing tracked connections. The same page describes required permissions and preferences for service-operated containment (AWS, n.d.-b). A response service can act for you under an established arrangement; it is not reasonable to assume every cloud subscription has that arrangement.

I would require the executor to report the mechanism used and its known limits. “New network activity restricted; established-connection effect not yet verified” is useful information. “Host isolated” can be dangerously ambiguous if the commander interprets it as proof that all communication has ceased. The distinction changes which additional evidence or authorized control the team needs next.

The verifier should also consider what the restriction prevents your own responders from doing. A containment action may remove the management path used for collection or interrupt a business dependency needed for a safe transition. That does not make containment wrong. It makes its scope and ordering consequential. The response record should identify the lost capability and the alternate path, rather than discovering the conflict after the change.

Avoid turning reversibility into a promise of harmlessness. Even when a configuration can be restored, transactions missed during an interruption may need reconciliation. I would separate configuration rollback from business recovery in the approval. The decision maker should understand both the immediate restriction and what must happen before normal processing is safe to resume.

Make evidence requests specific enough for another organization to fulfill

A provider can acknowledge an incident without possessing every artifact your investigation needs. NIST's cloud forensic architecture identifies challenges involving provider cooperation, access to data and missing terms in contracts or service-level agreements (Herman et al., 2024, Section 2). I would treat those as reasons to establish an evidence exchange in advance, not as proof that a provider will refuse assistance.

A useful request identifies the service and resource, relevant interval with time-zone context, requested artifact or factual question, incident identifier and approved destination. It distinguishes material you can collect yourself from information only the provider can supply. “Send all relevant logs” makes the recipient infer your investigation and can return a large collection that still omits the decisive record.

The recipient's acknowledgment should distinguish acceptance of the request from completion of collection. Ask whether the stated interval is available, what limitations apply and whether the returned material is complete for the agreed scope. Record the source and collection method with the artifact. If you receive an explanatory summary instead of raw records, preserve it as a provider assertion; don't silently relabel it as direct forensic observation.

I would authorize parallel preservation where it is feasible and safe. If ongoing harm requires immediate containment, record what evidence could not be retained and why. NIST calls for recording investigation actions and preserving the integrity and provenance of incident information (Nelson et al., 2025, RS.AN-06–07). That supports a documented tradeoff, rather than a rigid rule that collection must always finish before protective action begins.

The cloud forensic-readiness paper addresses which records to preserve and how to establish usable coverage. This incident agreement answers a narrower question: who must request, supply, receive and interpret the particular evidence now needed? A handoff is incomplete when both organizations assume the other preserved it.

Separate the provider's response from your support case

Google describes a provider incident process with an incident commander, technical and communications functions, investigation, containment and recovery. Its data-incident definition and notification process concern incidents within a stated provider-controlled scope; customers receive information to support their own response and assessment (Google Cloud, 2026b). I would not treat that process as a promise that Google's incident commander will direct your internal teams.

A technical support case is another channel, with its own access and service conditions. Google's case-management documentation identifies separate roles for viewing and managing cases. It also distinguishes changing priority to reflect business impact from escalation when the support process is breaking down, and notes that available services depend on the support offering (Google Cloud, 2026a). Those distinctions belong in the runbook before someone needs them urgently.

Appoint one customer liaison to maintain the authoritative provider request, with a named alternate. The liaison should record case identifiers, requested actions, acknowledged scope, outstanding questions and the next expected update. This is not a reason to prevent technical specialists from speaking directly. It is a way to stop separate conversations from producing conflicting assumptions about what the provider agreed to do.

A response objective should be phrased as an observable result, not merely “contact support.” For example: obtain confirmation of whether a specified service-side event is available for investigation, with an agreed update point if the answer is pending. The liaison cannot compel unavailable evidence or guarantee resolution, but can make the uncertainty visible to the commander.

Keep your own communication decisions active while the provider investigates. A provider's customer notification, your internal executive update and your external obligations have different audiences and decision processes. This paper sets no universal reporting clock. Assign the legal and communications assessment to the appropriate people using the actual agreements and applicable requirements. An unresolved provider question should be recorded explicitly rather than converted into an unsupported assurance to your stakeholders.

The response path must survive loss of normal administration

An incident plan can depend on the identity system it is trying to contain. Suppose the ordinary approval tool, support portal and privileged access workflow all require the same unavailable sign-in path. Naming an alternate administrator does little if the alternate shares that dependency. I would examine the authentication and approval chain for the response itself, separately from the compromised workload.

Microsoft's emergency-access guidance recommends cloud-only emergency accounts, authentication arrangements different from ordinary administrator accounts, protection against lockout dependencies, monitoring and regular validation (Microsoft, 2026a). Those are product-specific recommendations, not authority to create ungoverned emergency access everywhere. The transferable design question is which dependencies must be absent from the emergency path for it to work in the failure you are planning for.

For your selected service, identify the authorized operator, secure access device, credential availability, required privilege and record of use. Then ask whether the provider-support contact can operate when ordinary tenant access is unavailable. Where a recovery or alternate contact process exists, verify the organization's enrollment and instructions in advance. Don't invent an unofficial bypass during the incident or assume a personal contact at the provider substitutes for entitlement.

MSP involvement adds another dependency. If the MSP's own identity platform is unavailable, the customer's emergency operator may need a separately established path. If the customer cannot make that path work, document the resulting dependence and the contingency decision. The answer may be a different operating arrangement, a limited delegated role or an accepted availability risk; it needn't be duplicate standing administration for everyone.

Emergency access also needs an end. I would require a review of the actions taken, removal of temporary permissions where appropriate and restoration of the normal approval process. Leaving the incident's broad access in place changes the future security boundary. The incident cannot be considered administratively closed while no one knows which temporary exceptions remain active.

A hypothetical response exposes the gaps in a neat responsibility chart

Consider a fictional organization whose reporting application runs on cloud virtual machines and calls a separate SaaS service. An MSP operates the virtual machines. The customer's identity team manages employee access, while an application team controls SaaS sessions and integrations. The provider operates the underlying infrastructure. These are invented conditions, not an account of a real incident.

At minute zero, an analyst identifies suspicious activity associated with an administrative identity. At minute three, the incident commander authorizes a bounded containment plan. At minute six, the identity team reports that the selected directory action completed. At minute eight, the MSP reports that its network restriction was applied. At minute fourteen, the application team finishes a separately authorized session action. At minute seventeen, a verifier confirms the selected test operations are denied and records the remaining uncertainty. These times are assumptions for examining coordination, not response benchmarks.

If the organization measures only the directory operation, it may report six minutes to containment. That would be a definition error in this scenario: the agreed objective also required the application action and verification. The interval from authorization to the final stated verification is fourteen minutes, from minute three to minute seventeen. It still does not prove that all attacker access ended, because the test scope covered selected paths.

Now introduce a complication: the MSP's virtual-machine restriction interrupts the collection channel, and the provider request remains open. The commander should receive two different facts. One customer-controlled path has been restricted; a source needed to resolve the wider incident remains unavailable. Neither fact cancels the other. The team should avoid both declaring universal success and describing every completed action as useless because the investigation is unfinished.

A second complication reveals the value of bounded delegation. Suppose the MSP was authorized to isolate a designated workload but not to suspend a shared identity used by unrelated business services. The MSP should escalate that separate action with its dependency consequences, rather than interpret the original approval as unrestricted authority. Meanwhile, work within the original scope can continue. The distinction prevents one unresolved decision from becoming a blanket freeze on the response.

A third complication concerns recovery. The provider later reports that its investigation found no relevant infrastructure fault. That answer narrows one hypothesis; it doesn't validate the customer's application configuration or explain every suspicious action. The customer team must still resolve its own recovery criteria. A provider case can close while the customer incident remains open, and the operational records should permit that state.

The example's lesson is about coordination under partial completion. Each action should carry its own status, scope and next dependency. An incident-level summary can then say what has been constrained, what is still being investigated and which decision is due. A single shared “contained” label loses precisely the distinctions the commander needs.

Recovery requires agreement on the boundary being reopened

I would treat removal of emergency restrictions as a new decision. Before reopening a path, identify why the restriction exists, what has changed and what evidence supports the proposed state. Reversing yesterday's command is not necessarily today's correct recovery action. A formerly legitimate integration may have become an unacceptable dependency once its role in the incident is understood.

NIST's recovery guidance calls for checking restored assets, addressing root causes before production use and confirming the adequacy of restoration actions (Nelson et al., 2025, RC.RP-05). I would translate that into coordinated acceptance: the platform owner checks the restored platform within its scope; the application owner checks service behavior; the identity owner checks the intended access relationships; the business owner accepts the proposed operating constraints.

Those checks need not produce an impossible guarantee of perfect security. They should identify the claims being made and the unresolved issues that matter to the reopening decision. For example, successful application processing demonstrates a selected business function, while a restricted unauthorized operation demonstrates a selected permission boundary. Neither observation proves the other's conclusion.

When teams disagree, record the disputed proposition and the authority needed to resolve it. The executive crisis-activation paper covers when decisions exceed the response team's delegation. Here, the acceptance condition is that each participating organization knows what it is restoring, what the other parties have actually verified and which emergency conditions remain in force.

Test the handoffs, and keep the limits visible

I would exercise one critical service before expanding the method across the estate. Use a controlled scenario with designated test resources and safe actions. Verify that the authorized person can approve the specified scope, the executor can reach the necessary control, the provider liaison can use the agreed contact process and the verifier can assess the result. A discussion-only tabletop can expose ambiguity, but it cannot establish that permissions or technical mechanisms work.

Record failures by cause. A missing permission, unavailable approver, unsupported provider request and misleading completion message need different fixes. Measure elapsed time for the defined task, including unfinished tasks rather than quietly dropping them. Retain the configuration and scope so a future reader can understand what was exercised. These are proposed acceptance practices, not an empirically validated maturity score.

The strongest objection is administrative burden. A small team cannot maintain a custom manual for every transient resource. I would standardize the action record by service pattern, then document consequential exceptions. Start with actions whose failure or misuse could materially change incident outcomes. The method is proportionate when it removes uncertainty at a real boundary; it is wasteful when it creates rows nobody uses.

Automation is another reasonable objection. Why wait for people when a response service can act? The answer is to delegate bounded actions in advance, with permissions, impact limits and verification built into the arrangement. Automation can execute a decision quickly; it cannot make an undefined scope clear after the fact. Human coordination remains necessary for exceptions and business consequences outside the delegated boundary.

The twelve references here are authoritative guidance and provider documentation, not twelve independent empirical studies. Provider documents describe intended behavior and current service arrangements; they don't establish your entitlement, configuration or observed performance. The proposed action record requires local testing and revision. I make no claim that it eliminates compromise, guarantees response times or resolves legal responsibility.

If your cloud response plan assigns teams but leaves these actions ambiguous, request a cloud incident-readiness briefing. Bring the architecture and service boundaries, without credentials or sensitive incident data. I would use that discussion to scope the critical handoffs, identify authority and access gaps, and define a rehearsal that can show whether the response you expect is the response your organization can actually carry out.