Who Can Act During an Incident in a Customer-Controlled AWS Tenant?

Define customer, vendor and delivery partner incident authority with action-specific access, evidence handoffs, stop conditions and a reusable support record.

Before launching a customer-controlled AWS tenant, assign authority for each consequential incident action. Name who decides, who executes, who supplies permitted evidence and who confirms the result. Account ownership, a support subscription and a delivery partner's access are separate facts. None settles whether that partner may stop a job, change a policy or restore customer data during an incident.

This article helps a SaaS product owner and customer operations lead establish the handoff between their teams and a delivery partner. It assumes a supported dedicated placement already exists or is being prepared. It does not select the tenancy architecture, negotiate emergency rights or prescribe a destructive response. All incident records below are fictional. No customer incident, AWS action, access test or recovery was executed. The proposed evidence checks need an approved environment, safe data and the actual organization's authorization before use.

1. Separate account control from application responsibility

The customer can own the AWS account while the vendor remains responsible for application defects. A delivery partner might maintain infrastructure without owning product behavior or customer communication. A customer's security lead might authorize containment but lack the application's data-reconciliation knowledge. Put these differences in the operating record before everyone relies on the phrase fully managed.

The AWS shared-responsibility model describes AWS and customer security duties according to the selected service. It does not divide the application work among your customer, SaaS vendor and delivery partner. That additional allocation needs a separately accepted operating arrangement. Avoid assigning everything above infrastructure to the account holder merely because that holder pays the bill.

Start with the affected business workflow. For a reporting tenant, identify who can determine whether an export contains correct data, whether another export would duplicate a delivery and whether the receiving system has acknowledged it. A platform engineer may identify a stopped worker without answering those questions. Returning infrastructure to a healthy status may restore capacity while leaving an uncertain external effect unresolved.

Record duties that continue when access disappears. If the customer withdraws the vendor's diagnostic role, the vendor can still receive a case and describe required evidence, but cannot honestly promise independent inspection. The accepted support mode might change to customer-operated diagnostics. Agree the response to that change rather than silently asking the partner to use a retained credential or a different account path.

2. Bind authority to the action, target and decision window

An incident commander coordinates the response; that title should not implicitly grant every cloud or business permission. Break broad instructions into actions with different consequences: inspect a safe diagnostic packet, suspend new exports, restart a worker, change a resource policy, restore into a recovery target and resume customer traffic. Each action needs a scope, deciding owner, proposed executor and expected confirmation.

AWS incident-management guidance recommends defined responsibilities and communication plans, including backup communication. Apply those questions to your three-party arrangement. A document that identifies contacts but cannot say who authorizes containment leaves the central incident decision unanswered. A policy that permits an action does not establish that a responsible person approved using it in this case.

Specify the time boundary without inventing a universal response threshold. A diagnostic grant can expire while an investigation is still open. Decide whether the operator stops, requests a renewed grant or moves to an approved customer-supplied evidence path. Expiry should never trigger automatic privilege expansion. Emergency delegation, if available, must already have an approved basis, safe scope and reviewable activation procedure.

Avoid ambiguous target descriptions such as the tenant database. Use a restricted reference to the exact environment and resource class, with the permitted action and excluded neighbors. Public records should use sanitized aliases. The receiving operator must resolve the actual target through approved evidence, not infer it from a customer name or a familiar console tab. A request for help is neither a credential nor an authority record.

3. Confirm technical access separately from business permission

For customer-account access, AWS documents delegating to third parties through IAM roles, rather than sharing long-term credentials. Trust admission and the role's permissions are separate controls. Where a third party serves multiple customers, an external ID helps address the confused-deputy problem. It is not a secret, an approval signature or permission to perform every resource action.

The actual access review must cover the selected principal, target resources, relevant policy layers and required operations. A role assumption succeeding does not demonstrate permission to inspect an encrypted recovery copy. A query failing because a resource is unavailable does not establish correct denial. Use valid intended and unintended test identities in a separately authorized safe scope, and preserve the actual reason for their outcomes.

Keep diagnostic and change access distinct when the implementation supports it. An ordinary on-call role may read approved health evidence without changing resources. A separately authorized operator may perform a bounded containment action. A partner's central console should not let selecting one customer's case accidentally address another customer's account. The action record binds that case to its reviewed target and principal.

Credential withdrawal also needs a scoped incident procedure. Changing a trust relationship and handling already issued credentials can involve different semantics. The workload identity paper owns that deeper review. This handoff record asks which access state the incident actually depends on and which owner can establish it. Do not label all partner access removed based on a contact being deleted from a ticket.

4. Walk through a failed three-party handoff

In fictional incident I7, the customer reports a delayed report delivery at 10:00 UTC. The vendor identifies a worker timeout in a sanitized customer-supplied packet at 10:04. The delivery partner has a current diagnostic role. One export attempt has no receiving-system receipt. The customer's agreed containment decision reference is missing. These times and observations are stipulated teaching inputs, not monitored production events.

The unsafe response would be to treat diagnostic access as permission to restart the job and repeat the export. The timeout does not establish that delivery failed. The missing approval does not establish authority to contain the worker. The team can review the existing permitted packet and escalate to the customer incident lead, while preserving the export's uncertain state. Any new read or change still needs its actual permitted scope.

Affected workflow

I7, fictional tenant T7, report delivery. One prior export effect remains uncertain.

Decision owner

Customer incident lead owns the containment decision. Required decision reference is missing; authority remains on hold.

Vendor duty

Product lead identifies safe application evidence and the supported reconciliation path. No claim that a timeout means no delivery.

Partner duty

Case lead can inspect the already permitted diagnostic representation. Diagnostic access does not authorize a restart or new export.

Next evidence

Authorized receiving owner must establish destination disposition; customer lead must establish any permitted containment action.

Review disposition

Hold consequential action and preserve uncertainty. Communicate what is known and which references are missing.

The offline companion checks this supplied record as hold because authority and receipt are missing and the effect is uncertain. It can also recognize a fully populated record as reviewable. Reviewable means the fields meet the teaching rule, not that a contract is valid, permissions are enforced or recovery succeeded. The checker cannot authenticate the references it receives.

5. Define what changes the response

If the customer lead supplies a valid bounded containment decision, the nominated executor still needs verified access and an understood target. The action may now be ready for its own approved execution check; it does not authorize unrelated repair or repeat delivery. If the receiving owner confirms the earlier export, the team should avoid treating it as absent. If the receiving owner cannot determine its state, preserve uncertainty and use the workflow's supported reconciliation process.

If the vendor identifies a product defect that affects several placements, it should coordinate the shared release response without silently entering customer accounts. Each placement retains its access and change authority. If the customer prohibits an essential diagnostic field, the support owners must identify an acceptable substitute or state the resulting limit. A sales assurance cannot make unavailable evidence observable.

Service degradation can have an agreed bounded mode, such as holding new exports while ordinary reads continue. This is a product-specific proposal, not authority granted by this article. Define who selects it, which dependencies it requires and how the customer is informed. A degraded mode that depends on the same unavailable administrator channel needs a different recovery path or an honest unavailability statement.

Reopen the operating agreement when account ownership, partner personnel, product scope, access restrictions or customer communication duties change. A delivery handover can leave infrastructure maintained while nobody owns application escalation. Confirm both normal and alternate contacts. Rehearse their handoff with safe fictional evidence before assuming a round-the-clock service that the parties have never accepted.

6. Preserve evidence through stop and recovery

Stop a proposed consequential action when its authority is unknown, the target cannot be established, the selected principal is unexpected or the intended recovery would erase needed evidence. Record the reason and the current service effect. A stop should leave an owned next step, not a ticket that silently ages while every team expects another to act. Preserve existing records in their approved location without copying sensitive evidence into broader communication channels.

Recovery should address the particular gap. Renewing an approved diagnostic grant can restore inspection. Correcting a resource locator can restore target certainty. Obtaining a destination receipt can resolve an uncertain export. None of those automatically approves another change. Record the affected action, refreshed evidence and receiving owner so that the team can explain why progression became acceptable.

After a permitted action, distinguish attempted, observed and accepted. A command receipt may establish submission while the application outcome remains unverified. An approved restart can resume processing while backlog or uncertain deliveries still need reconciliation. Ask the responsible customer and vendor owners to confirm the bounded workflow result, rather than closing from a green resource status alone.

Administrative case closure can be appropriate with unresolved items assigned elsewhere, but it should say so. Keep remaining access expiry, retained evidence, product repair and customer communication obligations visible. A partner finishing its task does not establish that the entire incident is resolved. The final handoff should show who now owns every open consequence.

7. Create the reusable launch and incident record

Before launch, complete one record for a likely failure and one for denied diagnostic access. Include the workflow, customer decision owner, vendor product owner, partner executor, separately approved action, target reference, permitted evidence and expiry response. Add an out-of-band communication path, a receiving-result owner and the condition that stops progression. Use actual controlled references during your review; the public example supplies none.

Ask a second operator to read the record without the original author's explanation. Can they identify the next permitted action when a receipt is missing? Can they distinguish no access from no authority? Can they route an unresolved product defect without granting a partner global privileges? Missing answers are changes to the operating design, not reasons to add more logos to a responsibility chart.

Use the enterprise tenant operating paper for funded duties and the incident-response playbook for the broader response process. For this narrower task, bring the customer and vendor incident leads one action whose executor or acceptance owner is unclear. Resolve that action before promising that the tenant is fully supported.

Download the editable offline boundary records. The ZIP contains blank records and inert fixtures. Reading and downloading require no email; it does not transmit inputs or perform AWS operations.