Cloud Security Incident Readiness: Playbooks, Forensics and CERT-In
Security incident readiness is the preparation that lets an organisation respond to a cloud breach in hours rather than days: defined roles, tested playbooks, pre-built forensic and isolation tooling, and regulator reporting procedures. NTSPL builds this for Indian enterprises on AWS, Azure and Google Cloud, including CERT-In six-hour reporting and DPDP Act breach notification, and proves it through tabletop and technical exercises.
Delivered on
In scope
Why Cloud Incidents Are Lost in the First Six Hours
Incidents are rarely lost in the first minute; they are lost in the first six hours. The on-call engineer sees a GuardDuty or Defender alert at 2 a.m., does not know who can authorise shutting down a production account, deletes the compromised instance and with it the evidence, and nobody starts the CERT-In report because nobody owns it. By the time legal, the CISO and the cloud vendor's support are aligned, the reporting window has passed and the attacker has had a day to move. These failures are organisational and procedural, not technical.
NTSPL prepares the response before it is needed. We define an incident command structure with named deputies, severity criteria and decision rights, and write playbooks for the eight to ten cloud scenarios most likely for your business. Forensic accounts, isolation automation and evidence capture scripts are pre-deployed and permissioned. Regulator and customer notification steps are drafted with legal. Then we test everything with a tabletop for leaders and a technical exercise in a live-like account.
Gaps That Show You Are Not Ready for a Cloud Breach
Signals you need Security Incident Readiness
- There is no written cloud incident response plan, or the existing plan predates the move to cloud
- Nobody can say who files a CERT-In report or who approves isolating a production account
- Your last tabletop or incident exercise was more than 12 months ago, or never
- There is no pre-built forensic account, subscription or project with tooling and permissions in place
- A peer in your sector suffered ransomware or a data breach and the board has asked whether you are ready
When to choose something else
- You need the detection pipeline, log sources and SIEM rules that generate alerts: see Logging & Threat Detection.
- You need an outsourced team to monitor and respond 24x7; readiness complements a managed SOC but does not replace one.
Roles, Playbooks, Forensic Tooling and Reporting We Prepare
Incident command structure
Define incident commander, technical lead, communications, legal and regulatory roles with named deputies, severity levels and decision rights for isolation and shutdown.
Cloud playbooks
Write step-by-step playbooks for scenarios such as leaked access keys, compromised admin identity, ransomware on VMs, public data exposure, crypto-mining and malicious insider.
Forensic and isolation tooling
Pre-deploy a forensic account, subscription or project, snapshot and memory capture scripts, quarantine security groups or NSGs and identity revocation runbooks.
Regulatory and customer notification
Draft CERT-In six-hour reporting, DPDP breach notification to the Data Protection Board and affected individuals, and sector regulator steps with templates and owners.
Exercises
Run an executive tabletop and a technical exercise in a controlled account, record gaps and retest fixes.
Prepare, Detect, Contain, Report: The Readiness Model
Cloud Incident Response Readiness Model with Pre-Staged Forensics
Alerts from detection systems open an incident with a severity that triggers the command structure and the matching playbook. Isolation and evidence capture run through pre-permissioned automation into a separate forensic environment, while the reporting track drafts CERT-In and DPDP notifications in parallel.
Select any component
Cloud Incident Response Readiness Model with Pre-Staged Forensics: click any of its 8 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Isolation and Evidence Capture on AWS, Azure and Google Cloud
Systems Manager Automation runbooks attach a quarantine security group and snapshot volumes; Detective builds entity timelines from CloudTrail and VPC Flow Logs.
Sentinel playbooks on Logic Apps can isolate VMs, disable accounts and open tickets; Defender XDR correlates cloud, identity and endpoint evidence.
SOAR playbooks automate isolation through firewall tags and service account disablement; a forensic project with organisation-level read access is pre-provisioned.
Decision Rights, Evidence Preservation and Retainer Choices
Who can isolate production
Give the on-call security lead authority to isolate a single compromised instance or identity immediately, without approval. Isolating a whole account, subscription or customer-facing service should need the incident commander plus a business owner, reachable within 30 minutes. Write these thresholds down; ambiguity is the main reason responders wait hours while an attacker moves.
Preserve evidence or restore fast
Always snapshot disks, export relevant logs and record running state before terminating or rebuilding anything; with automation this takes 10-20 minutes. Never delete a compromised resource during containment. Isolate it, capture evidence, then rebuild from known-good images. Teams that terminate first usually cannot answer CERT-In or customer questions later. Hash every artefact on capture.
Retainer or in-house response
Most mid-size Indian firms should combine in-house first response with an external incident response retainer for forensics, negotiation and surge capacity. Choose a retainer with cloud forensics experience, India presence and agreed response times under four hours. Pre-sign the contract and share access procedures; signing during an incident costs a day.
How many playbooks
Write 8-10 playbooks for the scenarios most likely for your business, each two to four pages, rather than 40 generic ones. Typical must-haves: leaked cloud key, compromised admin identity, ransomware on servers, public data exposure, malicious insider, crypto-mining and compromised CI pipeline. Test at least two in each technical exercise.
Eight Weeks to a Tested Incident Response Capability
Current-state review and scenario selection
Review existing plans, contacts, tooling and logging, and select priority scenarios with the CISO.
Roles, severities and decision rights
Agree incident command roles, deputies, severity criteria and isolation authority with leadership.
Playbooks and regulatory track
Write cloud playbooks and CERT-In, DPDP and sector regulator notification procedures with legal.
Forensic and isolation tooling
Deploy the forensic environment, evidence capture scripts and isolation automation in every cloud.
Tabletop and technical exercise
Run an executive tabletop and a hands-on exercise, record gaps and close the top fixes.
What you receive
Response Speed and Exercise Outcomes We Track
| KPI | Typical target |
|---|---|
| Time from alert to declared incident with commander assigned | Under 30 minutes |
| Time to isolate a compromised resource with evidence preserved | Under 20 minutes |
| Time to draft a CERT-In report in exercises | Within 4 hours of detection |
| Exercise gaps closed before the next exercise | 90% or more |
Evidence Destruction, Missed Deadlines and Untested Plans
| Risk | How NTSPL prevents it |
|---|---|
| Responders destroy evidence by terminating compromised resources | Playbooks and automation isolate and snapshot first; termination permissions are removed from first-response roles. |
| The CERT-In six-hour window is missed | A named reporting owner and deputy, pre-filled templates and a timer started at declaration. |
| The plan exists but nobody has practised it | Exercises are scheduled for the year at kick-off, with attendance tracked for every named role. |
Incident response retainer or building readiness in-house?
You need both, and readiness comes first. A retainer gives you forensic specialists and surge capacity, but they arrive hours later and depend on what your team has done in the meantime: whether evidence was preserved, logs exist, access is ready and decisions were taken. In-house readiness covers the first hours, which decide most outcomes and the CERT-In deadline. Build roles, playbooks, forensic tooling and reporting internally, then sign a retainer with cloud forensics capability and pre-agreed access so the external team can start work in minutes when they join, not after a day of onboarding.
Key facts: Security Incident Readiness
Security Incident Readiness in Practice
2 Security Incident Readiness scenarios, from EdTech (competitive exam test preparation) and Healthcare diagnostics (pathology lab network), plus related platform case studies.
Test-prep edtech drafts a CERT-In report in 2 hours 10 minutes during its first drill
Diagnostics chain rehearses ransomware containment on AWS and isolates hosts in 9 minutes
Health-tech SaaS moves patient data behind KMS and Identity Center ahead of DPDP
Three directories become one: identity consolidation after two acquisitions
Security Incident Readiness: Frequently Asked Questions
How much does incident readiness preparation cost?
NTSPL's eight-week readiness engagement, including playbooks, forensic tooling for one or two clouds and two exercises, typically costs INR 8-15 lakh. An external incident response retainer is separate and usually priced as pre-paid hours. Forensic environment running costs are low because analysis instances start only when needed.
What does CERT-In require when an incident happens?
CERT-In's April 2022 directions require service providers, intermediaries, data centres and body corporates to report specified cyber incidents to CERT-In within six hours of noticing them, and to provide logs and information on request. The list includes data breaches, unauthorised access and ransomware.
How does the DPDP Act affect incident response?
The DPDP Act 2023 requires a data fiduciary to notify the Data Protection Board and each affected data principal of a personal data breach. Your playbooks therefore need a track for assessing whether personal data was affected, gathering facts and preparing notices alongside the CERT-In report.
What happens in a tabletop exercise?
Leaders and responders walk through a realistic scenario, such as ransomware spreading from a compromised vendor account, as injects arrive over two to three hours. Each decision is recorded, gaps in roles, information and authority surface quickly, and we produce a report with prioritised fixes.
Why do we need a separate forensic account?
A compromised account cannot be trusted for analysis, and evidence must be protected from tampering. A dedicated forensic account, subscription or project with read-only access to evidence and no trust from production keeps snapshots and logs safe and lets analysts start immediately.
Can we rely on the cloud provider during an incident?
Providers help within the shared responsibility model: they secure the underlying platform, and offer services such as AWS Security Incident Response or Mandiant retainers. Investigating your accounts, identities, workloads and data, and reporting to regulators, remains your responsibility. Pre-agree how provider support will be engaged.