AWS updated its Security Blog post on the AWS Customer Incident Response Team, and the practical point is simple: customers now have a clearer path for getting help during active AWS security events, plus better public material for preparing before one happens.
The post was originally published in July 2022 and updated on May 26, 2026. AWS says the update reflects current engagement options, new threat intelligence resources such as the Threat Technique Catalog for AWS, additional open-source tools, and a clearer distinction between AWS CIRT support and the AWS Security Incident Response managed service.
That distinction matters. In an incident, confusion burns time. A team that does not know which AWS path to use, what evidence AWS can see, or where AWS support stops will lose useful hours at the worst moment.
What changed in AWS Security Blog#
AWS is presenting CIRT as a specialized, 24/7 global team inside AWS that supports customers during active security events on the customer side of the AWS Shared Responsibility Model. The examples AWS gives are direct: unauthorized access, data exfiltration, and ransomware.
The engagement path is operational, not abstract. AWS tells affected customers to open a support case from the impacted AWS account through the AWS Support Center Console, choose the service closest to the event, and request assistance. The examples include EC2, IAM, and S3. Opening the case from the affected account helps AWS confirm ownership and gives the customer a case number for tracking.
If the customer has an AWS account team — a TAM, Account Manager, or Solutions Architect — AWS says they can also be alerted to start an escalation. If account access is lost, AWS says a request for assistance can still be submitted.
The updated post also adds more public preparation material. The most important addition is the Threat Technique Catalog for AWS, or TTC. AWS describes it as a public catalog based on the MITRE ATT&CK Cloud Matrix, built from tactics, techniques, and procedures observed by AWS CIRT in customer engagements. Each entry includes AWS-specific detection guidance and mitigations, and AWS says customers can filter it by services in their accounts.
This is the useful shift: incident response knowledge that started as internal CIRT pattern-tracking is now being pushed into public guidance. That does not make it complete. It does make it easier for a security operations team to align controls, detections, and tabletop scenarios around techniques AWS says it has actually seen.
Why welcoming AWS CIRT matters for security operations#
The main value is not that AWS can “take over” an incident. The source does not say that. The value is that AWS can help analyze what appears in AWS service logs and the AWS control plane, then support triage, analysis, containment, recommendations, and follow-up best practices.
That scope is important. AWS has infrastructure knowledge and visibility into its own service layer. Customers still own much of what happens inside their environment. Under the shared responsibility model, AWS is responsible for security of the cloud, while customers are responsible for security in the cloud.
For security operations teams, that means AWS CIRT can be a high-value partner when the incident touches IAM activity, service logs, S3 activity, control-plane behavior, or other AWS-side evidence. It is less useful as the only response path when the investigation requires host forensics, memory analysis, operating system artifacts, or application code review. AWS explicitly recommends complementing CIRT support with specialized digital forensics and incident response capabilities for those deeper layers.
This is also where privacy risk and evidence handling come into view. A customer asking for incident help should know which account is affected, which logs exist, which teams can authorize engagement, and which third-party responders may need access. A rushed escalation with poor account ownership clarity or weak logging can turn a real incident into a blind investigation.
The TTC is useful because it gives teams something concrete to work against before the incident. It can help answer a practical question: are our alerts mapped to the techniques AWS keeps seeing, or are we mostly relying on generic cloud security assumptions?
For related context on making security artifacts usable rather than decorative, see GigaTap’s note on OpenSSF’s April signal: https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational
What to check before you need help#
The strongest operational check is basic: confirm your team knows how to open an AWS support case from the impacted account and who is allowed to do it. That sounds small until the affected identity system, account owner, or response lead is unavailable.
Teams should also check whether they can still request help if account access is lost. AWS says that path exists, but it should not be discovered for the first time during ransomware, suspected exfiltration, or credential compromise.
A useful pre-incident review should cover:
- Which AWS accounts are most critical, and who can prove ownership.
- Which support path the response team will use for an active security event.
- Whether the account team, if one exists, is included in the escalation plan.
- Whether service logs needed for control-plane investigation are enabled and retained.
- Whether IAM, S3, EC2, EKS, and other high-risk services have detection coverage.
- Whether the team has a DFIR partner or internal capability for host, memory, and application-level analysis.
- Whether TTC techniques relevant to the customer’s AWS services have been reviewed.
AWS also points to several open-source tools and training resources. The post names public response frameworks, logging enablement tooling, tools for testing controls and alerts with simulated events, and Athena Security Analytics Bootstrap for investigating AWS service logs archived in S3 buckets. It also points to public workshops covering unauthorized IAM credential use, ransomware on S3, cryptomining, SSRF on IMDSv1, and incident response preparedness tooling.
These resources should not be treated as a replacement for a security program. They are better read as rehearsal material. If a workshop scenario resembles a real attack path in your environment, the useful question is not whether the workshop was completed. The useful question is whether your production logging, alerts, containment steps, and authority model would survive the same pattern.
For customers trying to turn cloud evidence into a cleaner risk process, the same theme appears in AWS’s KY3P report path: https://gigatap.top/en/articles/aws-ky3p-report-gives-customers-a-cleaner-risk-evidence-path
What not to overclaim#
The AWS post is not a promise that CIRT will perform every layer of incident response. It is not a substitute for customer-owned logging, endpoint evidence, application review, legal process, or business recovery planning.
It also should not be read as proof that every AWS incident will fit neatly into the TTC. Catalogs help teams prepare for known patterns. Attackers still chain weak identities, exposed services, misconfigurations, and business-specific gaps in ways that may not look clean in a matrix.
The open-source angle deserves the same restraint. Public tools are useful because they lower the setup cost and expose response patterns. They do not remove the need to test controls in the customer’s own environment. Tooling that is never wired into alerting, retention, ownership, and escalation is shelfware with a GitHub URL.
The practical takeaway is narrower and stronger: AWS is making its customer-side incident response path and threat-pattern knowledge easier to act on. Security teams should use that clarity now, while they are calm enough to check account access, support routing, logging, TTC coverage, and DFIR gaps.
Do that before the incident. During the incident, “welcoming AWS” should mean opening the right case with the right evidence from the right account — not searching the blog post under pressure.