Does AWS handle incident response for me?

Only for incidents inside AWS's half of the shared responsibility model — the underlying physical infrastructure, the hypervisor, and the managed-service control planes. Everything you configure on top of that — IAM, S3 bucket policies, security groups, application code, customer data — is yours to detect, contain, and report. AWS will notify you of incidents on their side but will not file regulatory reports on your behalf.

Which APAC country has the shortest cyber incident reporting clock?

Singapore's MAS TRM Guidelines for financial institutions require notification within one hour of a relevant incident. For non-FSI workloads, India's CERT-In rule (6 hours from noticing) is the tightest universal deadline. Several countries have 2-hour clocks for critical-infrastructure operators (Singapore CSA, the Philippines BSP for major incidents).

Do I need to report the same incident in every country where I have users?

Often yes. Most APAC privacy and cybersecurity laws are jurisdiction-of-the-data-subject, not jurisdiction-of-the-controller. A breach affecting users in Australia, Singapore, and India can trigger three parallel notification duties to OAIC, PDPC, and CERT-In — each with its own clock and format. Build your runbook to fan out, not to file once.

Does using AWS managed services like Lambda or DynamoDB change my incident response obligations?

It changes the evidence available, not the obligation. With EC2 you can capture memory and disk; with Lambda you only have the logs AWS exposes (CloudWatch, X-Ray, CloudTrail). Plan your forensics strategy around what data the managed service emits — and turn on data-event logging where you depend on it.

Can an MSSP or IR partner file the regulatory report on my behalf?

Most regulators accept reports filed by an authorised representative, but the legal obligation remains with the data controller or service provider. Have a written authorisation in place before an incident, and confirm your partner has the right contact details registered with each regulator — CERT-In in particular requires a named Point of Contact.

What's the difference between cyber incident reporting and data breach notification?

Cyber incident reporting (CERT-In, NACSA, CSA Singapore, ACSC) is about the attack — what happened, how, who is affected. Data breach notification (OAIC, PDPC, NPC, PDP Commissioner, etc.) is about personal data exposure — whose data, what data, what risk to them. The same incident usually triggers both, with different content, different audiences, and different clocks.

How long do I have to keep AWS logs for APAC compliance?

The strictest universal requirement is India's CERT-In rule: 180 days, in-country. Australia (APRA CPS 234) requires retention sufficient to support incident analysis — practical interpretation is 12 months. Singapore MAS TRM specifies 3 years for FSI. As a default, target 12 months of CloudTrail and security-relevant logs in every region you operate in, with longer retention for regulated workloads.

Are there AWS regions in every APAC country?

No. AWS regions exist in Australia (Sydney, Melbourne), Singapore, Malaysia, Thailand, Indonesia (Jakarta), India (Mumbai, Hyderabad), Japan (Tokyo, Osaka), and Korea (Seoul). Vietnam, the Philippines, and most of mainland Southeast Asia rely on adjacent regions. If your country's data residency rules require in-country storage, this matters — confirm before you architect.

Should I notify customers before or after regulators?

Most APAC frameworks require regulator notification first or in parallel, with customer notification following once impact is understood. Australia's NDB scheme requires notifying affected individuals and OAIC together. Singapore's PDPA allows the regulator filing first. Always check the specific country rule — getting the order wrong is its own compliance breach.

How much does a CloudTrail + GuardDuty + Security Hub stack cost in APAC regions?

For a single AWS account with modest activity, expect roughly USD $50–150 per month per region for the trio. The cost scales with event volume — busy accounts can run into the low thousands. The cost is small relative to the cost of being unable to respond to an incident, and is usually a prerequisite for satisfying any regulator's evidentiary expectations.

AWS Incident Response in APAC: A Regulatory and Technical Playbook

TL;DR

This is the pillar guide for AWS incident response across Asia-Pacific. APAC has the world’s most fragmented incident reporting landscape — every country runs its own regulator, its own clock, and its own definition of what counts as a reportable incident. The right strategy is not one runbook per country but a single AWS-native detection and response capability that can fan out into multiple reports in parallel. This guide covers what AWS does and does not do for you, the country-by-country clock table, the AWS services that make up an effective IR stack in this region, and a 30-day plan for getting ready.

What AWS incident response actually means
The APAC regulatory reporting clock
The AWS-native IR toolchain
The first 60 minutes on AWS
Region selection and data residency
When to call an external IR partner
Building an APAC-ready IR plan in 30 days
Frequently asked questions

What AWS incident response actually means

AWS operates on a shared responsibility model: AWS is responsible for security of the cloud (data centres, hypervisor, hardware, managed-service control planes), and you are responsible for security in the cloud (IAM, network configuration, application code, customer data, and everything you build on top of AWS services).

In incident response terms, this maps to two non-negotiable points:

AWS will not file regulatory reports for you. If your S3 bucket leaks because of a misconfigured policy, that is your incident, your investigation, and your CERT-In or OAIC report.
AWS will notify you of incidents on their side. If AWS detects a compromise of infrastructure that affects your account, they will tell you — and they sometimes detect things in your account before you do, via abuse signals from peers. The AWS Trust & Safety team is real and reachable.

Most APAC regulatory obligations sit cleanly on your side of the line. This guide assumes that and focuses on what you can and should do with AWS-native tools.

The APAC regulatory reporting clock

This is the highest-value reference on this page. APAC incident reporting deadlines vary by an order of magnitude — from 1 hour to 72 hours — and the same incident can trigger several in parallel. Snapshot as of mid-2026:

Country	Regulator	Trigger	Clock	Sector
Australia	OAIC (Privacy Act NDB)	Eligible data breach	As soon as practicable after assessment (assessment due within 30 days)	All
Australia	APRA (CPS 234)	Material information security incident	72 hours	Regulated FSI
Australia	ACSC / Home Affairs (SOCI Act)	Critical / significant cyber incident	12 hours (critical) / 72 hours (relevant)	Critical infrastructure
Singapore	PDPC (PDPA)	Notifiable data breach (≥500 individuals or significant harm)	3 calendar days	All
Singapore	MAS (TRM Guidelines)	Relevant incident	1 hour	FSI
Singapore	CSA (Cybersecurity Act)	Cybersecurity incident on CII	2 hours	Critical information infrastructure
India	CERT-In (2022 Directions)	Any of 20 listed incident types	6 hours from noticing	All
India	Data Protection Board (DPDP Act 2023)	Personal data breach	Without delay	All
India	RBI (Master Directions)	Cyber incident	2–6 hours	Banks, NBFCs
Malaysia	PDP Commissioner (PDPA 2024 amendments)	Personal data breach	72 hours	All
Malaysia	NACSA (Cyber Security Act 2024)	Cyber incident affecting NCII	6 hours	National critical info infrastructure
Thailand	PDPC (PDPA 2019)	Personal data breach	72 hours	All
Thailand	NCSA (Cybersecurity Act 2019)	Cyber threat to CII	Per regulator direction	Critical infrastructure
Indonesia	Personal Data Protection Agency (PDP Law 2022)	Personal data breach	3×24 hours	All
Indonesia	BSSN (GR 71/2019)	Electronic system incident	Immediate	ESPs
Philippines	NPC (Data Privacy Act)	Personal data breach (real risk of serious harm)	72 hours	All
Philippines	BSP	Major cyber incident	2 hours	Banks
Vietnam	MPS / A05 (Cybersecurity Law)	Cyber incident	Immediate	All
Vietnam	(PDP Decree 13/2023)	Personal data breach	72 hours	All

Caveat: these are snapshot summaries and many of these regimes are evolving — India’s DPDP rules and Malaysia’s NACSA framework in particular are still being operationalised. Confirm the current rule for your sector before relying on this table during a live incident.

Deep dives per jurisdiction (cluster guides — some live, others coming):

Meeting CERT-In’s 6-hour incident reporting rule on AWS — live
MAS TRM and AWS incident response for Singapore FSI — coming soon
APRA CPS 234 notification obligations on AWS — coming soon
OAIC Notifiable Data Breach scheme on AWS — coming soon
PDPA Singapore breach notification on AWS — coming soon
DPDP Act 2023 + CERT-In overlay for India — coming soon

The AWS-native IR toolchain

The most economical IR stack on AWS for APAC regulatory expectations is built from six services. None of them are exotic and most of them are cheap to run.

CloudTrail — the audit log of every API call. Non-negotiable. Configure as an organisation trail with the S3 destination in your primary regulated region.
GuardDuty — managed threat detection. Turn it on in every region you use, including ones you do not actively operate in (attackers will spin resources up in unused regions).
Security Hub — aggregates findings from GuardDuty, IAM Access Analyzer, Macie, Inspector, and partner tools. Your single pane of glass for triage.
Detective — investigative graph view that lets you trace an alert across accounts, users, and resources. Optional but valuable in fast triage.
CloudWatch Logs + VPC Flow Logs — your evidence baseline for network and application activity.
Macie — for any account holding personal data; flags S3 buckets with unusual access patterns or exposed sensitive data.

The mapping of these services to the incident categories that regulators care about is covered scenario-by-scenario in the technical playbook cluster: compromised IAM keys, ransomware on EC2, S3 exfiltration, GuardDuty CryptoCurrency findings, EKS control-plane compromise, and root account compromise. All coming as separate guides.

The first 60 minutes on AWS

A generic AWS incident response runbook, jurisdiction-agnostic. The first hour is the same regardless of which regulator you eventually report to.

Minute 0 — Detect and confirm. An alert fires (GuardDuty, custom CloudWatch alarm, customer report, AWS abuse notification). An analyst confirms it is a real incident. Record this timestamp — most regulatory clocks start here.
Minutes 0–10 — Mobilise. Page the incident commander. Open a war-room channel. Identify the affected accounts, regions, and services.
Minutes 10–25 — Contain. Quarantine compromised resources without destroying evidence. For compromised IAM keys: deactivate the key, not the user. For compromised EC2: isolate via security group swap, do not terminate. For S3 exfiltration: block public access at the account level, tighten bucket policies.
Minutes 25–40 — Preserve evidence. Snapshot EBS volumes, copy CloudTrail and VPC flow logs for the relevant time window into a forensics S3 bucket, capture memory if your EDR supports it.
Minutes 40–55 — Assess scope. What was accessed, by whom, from where, when. This is where Detective and CloudTrail Athena queries earn their cost.
Minute 55–60 — Decide on notifications. Apply the regulatory clock table above to determine who needs to know and within what timeframe. If you have users in multiple APAC countries, you may be filing several reports.

A 60-minute window is the right design target — it leaves headroom under every clock in the table except MAS TRM’s 1-hour rule, which requires its own dedicated runbook.

Region selection and data residency

APAC has more AWS regions than any other continent. The current map (mid-2026):

Australia — ap-southeast-2 (Sydney), ap-southeast-4 (Melbourne)
Singapore — ap-southeast-1
Malaysia — ap-southeast-5 (Kuala Lumpur)
Thailand — ap-southeast-7
Indonesia — ap-southeast-3 (Jakarta)
India — ap-south-1 (Mumbai), ap-south-2 (Hyderabad)
Japan — ap-northeast-1 (Tokyo), ap-northeast-3 (Osaka)
Korea — ap-northeast-2 (Seoul)
Hong Kong — ap-east-1

Three IR-relevant patterns:

Data residency rules narrow your options. India and Indonesia have explicit in-country storage rules for certain data classes. Singapore and Australia do not, but sector regulators (MAS, APRA) impose effective in-country preferences.
Service availability is uneven across regions. SES, Bedrock, and several newer services are not available in every APAC region. Plan IR notification and analytical tooling around the regions where they actually exist.
Cross-region log replication is your friend. Replicate CloudTrail and security logs to a secondary region within the same jurisdiction for resilience. Do not replicate across jurisdictions if residency rules apply.

When to call an external IR partner

Three triggers usually justify external help:

Capacity. Your team can handle one incident; a serious incident often runs three or four parallel workstreams (containment, forensics, communications, recovery). External hands fill the gap.
Specialist skills. Cloud-native forensics, malware reverse engineering, regulatory drafting in non-English jurisdictions — most internal teams do not maintain these year-round.
Independence. Some regulators and most insurers expect an external party’s signoff on the post-incident report.

Establish a retainer before you need one. Time-to-engage matters more than hourly rate. Opcode’s MDR service covers AWS incident response with APAC regulatory awareness baked in.

Building an APAC-ready IR plan in 30 days

A realistic 30-day work programme to move from “we have GuardDuty turned on” to “we can hit every APAC reporting clock that applies to us.” A four-week sprint:

Week 1 — Inventory and obligations. Map your AWS accounts, regions, and the countries you serve. Cross-reference to the regulatory clock table. Identify the tightest deadline that applies to you and design the rest of the plan around it.

Week 2 — Detection and logging baseline. Confirm CloudTrail organisation trail is live, GuardDuty is on everywhere, Security Hub is aggregating, log retention meets the strictest applicable rule (180 days in-India for CERT-In if you have Indian exposure, longer for regulated sectors elsewhere).

Week 3 — Runbooks and notification readiness. Draft scenario runbooks for the five most likely incident types: compromised IAM keys, S3 exfiltration, ransomware on EC2, account takeover, GuardDuty critical finding. Pre-stage reporting templates for each regulator that applies to you. Register or refresh your point-of-contact details with CERT-In if applicable.

Week 4 — Tabletop. Run a timed exercise against a realistic scenario. Measure time from “alert fires” to “report submitted.” Find the bottlenecks. Iterate.

This skeleton is the starting point. Every section above has a deeper guide either live or in development — start with the CERT-In playbook if India is in scope, or get in touch if you would like to short-cut the 30-day plan with a structured review.

Frequently asked questions

Common questions about AWS incident response in APAC are answered in the FAQ schema attached to this page — scroll back to the top of the rendered article for the structured-data version, or search the page for the question you have in mind.