ISO 27001 A.5.24: Information Security Incident Management Planning and Preparation

Quick Reference (60 Seconds)

What the Control Asks For

The Control in Brief

ISO 27001:2022 Annex A 5.24 asks organizations to plan and prepare for managing security incidents by defining roles, responsibilities, and procedures.

Do you need this control?

A.5.24 is not mandatory in itself: under clause 6.1.3 you include it if your risk assessment calls for it, and record the decision in your Statement of Applicability. Almost always included, because any organisation can suffer an incident and CERT-In requires reporting within 6 hours. The plan can be short for a small company, as long as roles, contacts and procedures are ready before you need them.

ISO 27002:2022 Implementation Guidance

ISO 27002:2022 expands the intent of A.5.24 into practical implementation guidance. The core message is that effective incident response is not improvised during a crisis; it is deliberately designed, resourced, documented, rehearsed, and maintained before any incident occurs.

The implementation guidance can be summarized in eight planning domains:

1. Governance and policy framework: Establish a formal incident management policy approved by top management. Define the purpose, scope, objectives, and high-level accountabilities.
2. Roles and responsibilities: Designate an information security incident response team (often called CSIRT or CERT) with named primary and alternate members, a team lead, and clear decision rights.
3. Incident management process: Define end-to-end workflows covering detection, triage, assessment, containment, eradication, recovery, post-incident review, and evidence handling.
4. Classification and severity: Create an incident taxonomy with categories (malware, phishing, data breach, insider threat, DDoS, supply chain compromise, etc.) and severity levels (P1–P4 or Critical/High/Medium/Low) tied to business impact.
5. Technology and tooling: Deploy and configure detection, analysis, communication, forensics, ticketing, and orchestration tools before incidents occur.
6. Evidence collection and preservation: Prepare forensic procedures to preserve admissible evidence, maintain chain of custody, and align with legal and regulatory requirements.
7. Escalation and reporting: Define internal escalation paths, external notification obligations (regulators, law enforcement, affected data principals, media), and timing thresholds.
8. Testing and maintenance: Exercise the plan through tabletop exercises, technical drills, red-team/purple-team engagements, and update the plan based on lessons learned.

Points from 27002 5.24 that auditors often check (paraphrased), beyond the summary above:

• a common method for reporting events, with a point of contact (A.6.8)
• only competent personnel handle incidents, with procedure documentation and periodic training
• a process to identify the training, certification and ongoing professional development incident responders need
• incident management objectives agreed with management, including resolution time frames by consequence and severity
• a plan that considers different scenarios, with procedures for evaluating events against incident criteria, managing incidents to closure (including crisis management and continuity activation), logging activities, handling evidence (A.5.28), root cause analysis and lessons learned
• coordination with authorities, interest groups, suppliers and clients (A.5.5, A.5.6)
• reporting procedures: what to do when an event occurs, incident report forms, and feedback to the people who reported events once they are handled

Shall / Should / May Analysis

What Auditors Actually Check

Why Information Security Incident Management Planning Matters

Indian Regulatory Context

India has built one of the most demanding incident-notification regimes in the world. A.5.24 is not merely an ISO requirement; it is the operational backbone for complying with multiple Indian laws and regulations.

CERT-In Directions, 2022

The Indian Computer Emergency Response Team (CERT-In) issued mandatory Directions on April 28, 2022, requiring covered entities to report specified cyber incidents to CERT-In within six hours of noticing or being brought to notice of the incident. Covered entities include government organizations, intermediaries, data centers, corporate bodies, and service providers.

The Directions list 20 categories of reportable incidents, including:

• Targeted scanning or probing of critical networks or systems
• Compromise of critical systems or information
• Unauthorized access of IT systems or data
• Malicious code attacks (ransomware, spyware, worms, trojans)
• Attacks on DNS, servers, routers, or critical infrastructure
• Identity theft, spoofing, and phishing attacks
• Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS) attacks
• Attacks on critical infrastructure, SCADA systems, and industrial control systems
• Data breaches affecting data principals

A.5.24 planning must therefore include a CERT-In reporting runbook with pre-drafted notification templates, a clear decision authority, and a six-hour escalation clock.

Digital Personal Data Protection (DPDP) Act, 2023

The DPDP Act 2023 imposes breach-notification obligations on data fiduciaries. In the event of a personal data breach, the data fiduciary must notify the Data Protection Board of India and affected data principals in the manner and format prescribed by the Board. Failure to take reasonable security safeguards can attract a penalty of up to ₹250 crore, and failure to notify a breach up to ₹200 crore.

A.5.24 preparation directly supports DPDP compliance by:

• Defining what constitutes a personal data breach.
• Establishing a breach-assessment and decision workflow.
• Preparing notification templates for the Board and data principals.
• Maintaining records of breaches for regulatory examination.

Reserve Bank of India (RBI) Cyber Security Framework

RBI-regulated entities (banks, NBFCs, payment system operators) must comply with the Cyber Security Framework in Banks (2016) and the Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (2023), which replaced the 2017 NBFC IT framework. Key requirements include:

• A Board-approved cyber crisis management plan.
• A Security Operations Center (SOC) or managed SOC service.
• Incident response, forensic, and recovery capabilities.
• Reporting of cyber incidents to RBI, typically within 2 to 6 hours of detection, as the applicable direction specifies.
• Annual cyber drills and tabletop exercises.

A.5.24 is the control that ensures these RBI requirements are institutionalized, not just documented.

Securities and Exchange Board of India (SEBI)

SEBI's CSCRF (2024), which now covers stock brokers and depository participants requires:

• An incident response and management plan.
• Cybersecurity drills at least twice a year.
• Reporting of incidents to SEBI within specified timelines.
• Maintenance of logs and forensic readiness.

Insurance Regulatory and Development Authority of India (IRDAI)

IRDAI's Guidelines on Information and Cyber Security for Insurance Companies mandate an incident management framework, reporting to IRDAI, and periodic cyber crisis management drills.

Information Technology Act, 2000

Sections 43, 43A, 66, and 66C of the IT Act 2000 create civil and criminal liabilities for unauthorized access, data theft, identity fraud, and failure to maintain reasonable security practices. The Act recognizes ISO 27001 as a reasonable security practice under the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011.

Industry-Specific Consequences

Cost of Non-Compliance

The cost of inadequate incident management planning includes both direct and indirect components:

• Direct costs: Forensic investigation, legal fees, regulatory fines, customer notification, credit monitoring, public relations, ransom payments (strongly discouraged), system rebuilds.
• Indirect costs: Lost revenue, customer churn, increased cyber insurance premiums, extended sales cycles, talent attrition, reputational damage, and management distraction.

IBM's 2023 Cost of a Data Breach report found that organizations with high levels of incident response planning and testing had average breach costs USD 1.49 million lower than those with low levels. For Indian enterprises operating on thinner margins, this delta can be the difference between survival and insolvency.

Scope and Applicability

What A.5.24 Covers

A.5.24 applies to the planning and preparation phase of the incident management lifecycle. It covers all activities required to ensure the organization is ready to respond before an incident occurs. Specifically, it includes:

• Policy and governance: Incident management policy, objectives, scope, and authority.
• Organization: CSIRT/SOC structure, roles, responsibilities, and decision rights.
• Processes: Incident lifecycle workflows, classification, escalation, notification, and handoff procedures.
• Technology: Detection, analysis, containment, eradication, recovery, communication, and forensic tools.
• Documentation: Playbooks, runbooks, contact trees, evidence forms, notification templates, and lessons-learned templates.
• Training and awareness: CSIRT training, end-user reporting awareness, phishing simulations, and executive briefings.
• Testing and assurance: Tabletop exercises, technical drills, red-team/purple-team exercises, and plan reviews.
• Continuous improvement: Post-incident review, metrics analysis, plan updates, and threat-intelligence integration.

Who It Applies To

A.5.24 applies to every individual, team, and third party that touches information assets or could be affected by an information security incident:

Size-Based Applicability

Logical Boundaries

A.5.24 is about preparation. It does not require the organization to actually respond to a live incident during the audit (that is A.5.26), nor does it require the organization to have completed a post-incident review (that is A.5.27). However, the preparation must be strong enough to enable those downstream controls. Auditors will look for evidence that the organization has:

• A documented plan that could plausibly be executed.
• Trained people who understand their roles.
• Tools that are configured and accessible.
• Tested procedures that have been refined based on lessons learned.

Key Definitions and Terminology

Relationship to Other Controls

A.5.24 does not exist in isolation. It is the foundation of the incident management control cluster and feeds directly into detection, response, learning, and evidence controls.

Upstream Controls (Inputs to A.5.24)

Parallel Controls (Co-Dependent)

Downstream Controls (Outputs from A.5.24)

Detailed Implementation Guidance

Figure · Tiers

Maturity levels for incident management planning and preparation

Establish Governance and Policy

The first step is to obtain top-management commitment and publish a formal Information Security Incident Management Policy. The policy should be concise (4–6 pages), risk-based, and aligned with the organization's business context.

Minimum policy contents:

1. Purpose and scope: Why the policy exists and which systems, locations, and personnel it covers.
2. Objectives: Measurable goals such as "detect and contain high-severity incidents within 4 hours."
3. Definitions: Incident, event, breach, CSIRT, severity levels.
4. Roles and responsibilities: CISO, CSIRT lead, SOC manager, legal, HR, communications, executives.
5. Incident lifecycle: Detection, reporting, triage, assessment, containment, eradication, recovery, post-incident review.
6. Classification and severity: Taxonomy and response-time expectations.
7. Reporting and escalation: Internal channels, regulatory notifications, law enforcement.
8. Communication: Internal, customer, regulator, media, and legal communications.
9. Evidence handling: Chain of custody, forensic workstation, evidence retention.
10. Training and exercises: Frequency, audience, and documentation requirements.
11. Metrics and KPIs: What will be measured and reported.
12. Review and maintenance: Annual review and update triggers.

Who: CISO drafts; CEO / Managing Director approves.
When: Within 2 weeks of starting the program.
Evidence: Signed policy, version history, communication record.

Form the CSIRT / Incident Response Team

A CSIRT is not just the security team. It is a cross-functional group with defined roles.

Recommended CSIRT structure for a mid-sized organization:

For smaller organizations: roles can be combined. For example, the CISO may also be the technical lead, and legal support may be outsourced. The key is that every role has a named primary and alternate.

Who: CISO proposes; HR confirms contact details; top management approves.
When: Within 3 weeks.
Evidence: CSIRT roster with contact details, on-call schedule, and approval record.

Develop an Incident Classification and Severity Matrix

A strong severity matrix eliminates debate during a crisis. It links technical indicators to business impact and response obligations.

Example Severity Matrix:

Important: The matrix must define what triggers escalation from one severity to another. For example, "If the number of affected records exceeds 1,000, escalate from P2 to P1."

Build the Incident Response Plan (IRP)

The IRP is the operational document that turns policy into action. It should be scenario-agnostic at the top level, with specific playbooks for common scenarios.

Core IRP sections:

1. Activation criteria: When does the IRP become active?
2. Initial response: First 30 minutes: who is notified, what logs are preserved, what systems are isolated.
3. Triage and classification: How is severity determined?
4. Containment strategies: Short-term (stop the bleeding) vs. long-term (remove persistence).
5. Eradication procedures: Remove malware, patch vulnerabilities, reset credentials, rebuild systems.
6. Recovery procedures: Restore from backups, validate integrity, reintroduce systems gradually.
7. Post-incident activities: Forensic report, lessons learned, evidence archiving, regulatory closure.
8. Communication protocols: Who says what, to whom, and when.
9. Appendices: Contact lists, tool credentials (secured), network diagrams, system inventories.

Prepare Scenario-Specific Playbooks

While the IRP is the master document, playbooks provide step-by-step guidance for common incident types.

Recommended playbooks for Indian enterprises:

Implement Detection and Monitoring

You cannot respond to what you cannot detect. The monitoring layer must feed actionable alerts to the SOC/CSIRT.

Minimum detection capabilities:

• Endpoint Detection and Response (EDR) on all endpoints and servers.
• Network Detection and Response (NDR) or intrusion detection/prevention systems (IDS/IPS).
• Security Information and Event Management (SIEM) for centralized log correlation.
• Email security gateway with anti-phishing, sandboxing, and DMARC/SPF/DKIM enforcement.
• Identity threat detection for anomalous logins, impossible travel, and privilege escalation.
• Vulnerability scanner and attack-surface management for exposed assets.
• Threat intelligence feeds: government feeds (CERT-In), commercial feeds, and industry ISACs.

Establish Communication Channels

During an incident, normal communication channels may be compromised. The organization must have out-of-band (OOB) communication methods.

Communication architecture:

Prepare Evidence Collection and Forensic Capability

Evidence collected during an incident may be required for criminal prosecution, civil litigation, regulatory proceedings, or insurance claims. Preparation includes:

• A forensic workstation with write blockers, imaging tools, and memory analysis tools.
• Chain-of-custody templates for physical and digital evidence.
• Secure evidence storage with access controls, hashing, and retention policies.
• Engagement letters with external forensic firms for incidents exceeding internal capability.
• Legal hold procedures to preserve relevant documents and communications.

Train, Exercise, and Maintain

Preparedness decays without practice. The organization must:

• Train CSIRT members annually on tools, procedures, and legal obligations.
• Awareness training for all staff on recognizing and reporting incidents.
• Conduct phishing simulations at least quarterly.
• Run tabletop exercises at least annually, covering realistic Indian scenarios (CERT-In reporting, DPDP breach, ransomware).
• Perform technical drills (e.g., isolated ransomware recovery) at least annually.
• Update the IRP and playbooks within 30 days of any significant incident, exercise, or change in threat landscape.

Plan for Cloud, SaaS, and Hybrid Environments

Modern Indian enterprises operate across on-premises data centers, private clouds, public clouds (AWS, Azure, GCP), and SaaS platforms (Microsoft 365, Google Workspace, Salesforce, Zoho). Incident preparation must account for shared responsibility models and distributed telemetry.

Cloud-specific preparation steps:

1. Map shared responsibilities: Document what the cloud provider secures (e.g., physical infrastructure, hypervisor) versus what the organization secures (e.g., data, identities, configurations, guest OS).
2. Centralize cloud logs: Enable CloudTrail (AWS), Azure Activity Logs, GCP Cloud Audit Logs, and SaaS audit logs, and ingest them into the SIEM.
3. Prepare CSP incident response contacts: Maintain support plans (e.g., AWS Business Support, Azure Premier Support) and emergency escalation paths.
4. Automate cloud containment: Use cloud-native tools (AWS IAM, Azure AD, GCP IAM) to disable accounts, revoke tokens, isolate VPCs, and snapshot volumes programmatically.
5. Address SaaS compromise: Prepare playbooks for Office 365 account takeover, unauthorized Google Drive sharing, and rogue SaaS integrations.
6. Test cloud recovery: Validate restoration of cloud workloads, databases, and object storage from backups.

Integrate Threat Intelligence into Preparation

Threat intelligence transforms incident preparation from generic to targeted. Indian organizations should subscribe to multiple intelligence sources:

• CERT-In alerts and advisories: Government-issued warnings on Indian threat actors and campaigns.
• Industry ISACs: Sector-specific intelligence for banking, finance, and critical infrastructure.
• Commercial feeds: IoCs, malware signatures, and actor profiles.
• Open-source feeds: MISP, AlienVault OTX, abuse.ch.
• Internal intelligence: Lessons learned from past incidents and red-team findings.

Integration actions:

1. Distribute weekly threat briefings to the CSIRT.
2. Automate IoC ingestion into SIEM, EDR, firewall, and email gateway.
3. Map common Indian threat actors (e.g., ransomware groups targeting Indian SMEs) to defensive controls.
4. Update playbooks based on current tactics, techniques, and procedures (TTPs).
5. Participate in industry information-sharing forums where legally permissible.

Design Effective Tabletop Exercises

A poorly designed exercise is a wasted opportunity. Effective tabletops include:

1. Realistic scenario: Based on actual threats to the organization and industry.
2. Clear objectives: E.g., test CERT-In notification within 6 hours, validate CISO escalation.
3. Injects: New facts introduced at timed intervals to simulate evolving incidents.
4. Decision pressure: Force participants to make choices with incomplete information.
5. Cross-functional participation: Include IT, security, legal, HR, communications, and executives.
6. Documented timeline: Capture every decision, delay, and communication.
7. After-action review: Identify gaps, assign owners, and update the IRP.

Sample scenario for an Indian fintech:

"At 9:15 a.m. on a Monday, the SOC receives alerts of mass file encryption across accounting servers. Ransom note demands payment in Bitcoin. Customer-facing payment APIs are unaffected, but internal loan disbursement is halted. By 10:00 a.m., the attacker threatens to leak 50,000 customer records. The media begins asking questions."

This single scenario can test ransomware containment, backup recovery, CERT-In reporting, DPDP breach assessment, customer notification, media response, and executive decision-making.

Tools, Technologies, and Solutions

Capability Map

Build vs. Buy vs. Managed Service

For Indian organizations, a hybrid model is often optimal: retain internal CSIRT leadership and legal/compliance decisions while outsourcing 24/7 SOC monitoring to an Indian MSSP/MDR with local data residency.

Policy and Procedure Templates

Information Security Incident Management Policy (Extract)

INFORMATION SECURITY INCIDENT MANAGEMENT POLICY
[Organization Name]
Version: 1.0
Approved by: [CEO / Managing Director Name]
Date: [Date]
Review Date: [Date + 12 months]
Classification: Internal

1. PURPOSE
This policy establishes the framework for planning, preparing for, detecting,
assessing, responding to, and recovering from information security incidents
in a manner that minimizes business impact and meets legal and regulatory
obligations.

2. SCOPE
This policy applies to all employees, contractors, vendors, customers, and
third parties who access, process, store, or transmit [Organization Name]'s
information assets.

3. POLICY STATEMENT
[Organization Name] is committed to:
   a) Maintaining a formal incident management capability led by the CISO.
   b) Defining, training, and exercising a Computer Security Incident Response
      Team (CSIRT).
   c) Classifying incidents by severity and responding within defined SLAs.
   d) Reporting incidents to regulators, law enforcement, and affected parties
      as required by law.
   e) Preserving evidence in a forensically sound manner.
   f) Learning from incidents and continuously improving the program.

4. ROLES AND RESPONSIBILITIES
   a) Board of Directors: Approve policy, provide resources, and oversee crisis
      management.
   b) CISO: Own the incident management program, chair the CSIRT, and approve
      regulatory notifications.
   c) CSIRT: Execute incident response activities.
   d) All Employees: Report suspected incidents immediately through the defined
      channel.
   e) Legal / Compliance: Advise on regulatory obligations and evidence
      preservation.

5. INCIDENT CLASSIFICATION
Incidents are classified as P1 (Critical), P2 (High), P3 (Medium), or P4 (Low)
based on business impact, data sensitivity, and regulatory exposure.

6. REPORTING AND ESCALATION
All suspected incidents must be reported to security@[org].in or the 24/7
hotline +91-XXXXXXXXXX. Severity determines escalation path and response time.

7. REGULATORY NOTIFICATIONS
The Legal / Compliance Lead will assess and execute notifications to CERT-In,
RBI, SEBI, IRDAI, the Data Protection Board of India, and affected data
principals within statutory timelines.

8. TRAINING AND EXERCISES
The CSIRT will undergo annual training. All employees will complete annual
incident-reporting awareness. Tabletop exercises will be conducted at least
annually.

9. REVIEW
This policy will be reviewed annually and after any significant incident or
change in legal/regulatory requirements.

First 60 Minutes Response Procedure (Extract)

PROCEDURE: FIRST 60 MINUTES OF AN INCIDENT RESPONSE

Step 1: Detection and Reporting (0–15 min)
- SOC or user detects anomalous activity.
- Create incident ticket in [Ticketing System].
- Notify CSIRT Lead and SOC Manager.
- Preserve volatile evidence: memory dumps, running processes, network
  connections (if safe).

Step 2: Triage and Classification (15–30 min)
- Gather initial facts: affected systems, data involved, attack vector,
  observed impact.
- Classify severity using the Severity Matrix.
- Activate the CSIRT bridge and war room if P1 or P2.

Step 3: Containment (30–60 min)
- Short-term containment: isolate affected endpoints, disable compromised
  accounts, block malicious IPs/domains at firewall.
- Preserve evidence before containment where feasible.
- Communicate containment status to CSIRT Lead.

Step 4: Escalation and Notification (within 60 min for P1)
- CSIRT Lead notifies CISO, Legal, and business owner.
- Legal assesses CERT-In, DPDP Act, RBI/SEBI/IRDAI notification requirements.
- If applicable, begin drafting regulatory notification.

Step 5: Transition to Investigation
- Hand over to technical lead for forensic analysis.
- Maintain chain-of-custody log for all evidence.
- Document timeline in the incident ticket.

Regulatory Notification Decision Tree (Extract)

START: Personal data breach suspected or confirmed
│
├─ Is the affected data "personal data" under DPDP Act 2023?
│  ├─ YES → Proceed to assessment
│  └─ NO  → Assess other notification obligations (RBI, SEBI, IRDAI, contract)
│
├─ Was there a personal data breach (any unauthorised processing, disclosure, loss or access)?
│  ├─ YES → Intimate the Data Protection Board and each affected Data Principal without delay;
│  │        detailed report to the Board within 72 hours (DPDP s.8(6), DPDP Rules). No harm threshold.
│  └─ NO  → Document the assessment
│
├─ Is the entity covered by CERT-In Directions, 2022?
│  ├─ YES (applies to all body corporates) → Is the incident a type listed in the Directions' Annexure I?
│  │        YES → Report to CERT-In within 6 hours
│  └─ NO  → Document assessment
│
├─ Is the entity RBI/SEBI/IRDAI regulated?
│  ├─ YES → Notify respective regulator per sectoral timeline
│  └─ NO  → Continue
│
└─ Are contractual or insurance notification obligations triggered?
   ├─ YES → Notify customers, cyber insurer, partners per contract
   └─ NO  → Close notification assessment

Risk Assessment and Treatment

Risk Scenarios Relevant to A.5.24

Risk Treatment Methodology

Risks rated High must be treated with preventive and detective controls immediately. Medium risks require treatment plans with defined owners and deadlines. Low risks are accepted or monitored.

For A.5.24 specifically, the primary treatment strategy is control implementation: build the incident management capability before an incident occurs. Residual risk is managed through cyber insurance, external DFIR retainers, and crisis communications support.

Audit and Compliance Checklist

Use this checklist to prepare for internal audits, certification audits, and regulator inspections.

Metrics and KPIs

Reporting Dashboard Template

A monthly incident management dashboard should include:

1. Executive summary: Top 3 risks, top 3 incidents, and overall program health.
2. Incident trend chart: Volume by severity over the last 12 months.
3. MTTD/MTTR trend chart: Performance against targets.
4. Open incidents: Aging and status of unresolved incidents.
5. Post-incident actions: Open actions and overdue items.
6. Exercise schedule: Upcoming and completed drills.
7. Regulatory notifications: Count and timeliness.
8. Training status: CSIRT and general staff completion rates.

Common Pitfalls / Audit Failures & How to Avoid Them

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1: Indian Fintech Company, Ransomware Response Failure and Recovery

Organization: A Bengaluru-based fintech startup with 220 employees offering SME lending and payment aggregation services.

Challenge: In early 2024, the company fell victim to a ransomware attack that encrypted approximately 60% of its production servers, including its loan origination system and customer database. The attack began with a phishing email received by an accountant, who clicked a malicious link and entered credentials on a fake Microsoft login page. The attacker lingered in the environment for 11 days before deploying ransomware.

The company had no formal incident response plan. The IT manager attempted to handle the crisis alone, initially trying to negotiate with the ransomware group and later restoring from backups that were also encrypted because they were online and reachable from production. The attack caused a 72-hour complete service outage, affecting 45,000 SME customers and interrupting loan disbursements.

Regulatory and Business Impact:

• The company missed the CERT-In 6-hour reporting window because no one knew the requirement.
• RBI, which regulated the company as a payment aggregator, initiated a supervisory review.
• Customers flooded social media with complaints, causing significant reputational damage.
• The company bore remediation, legal and customer-compensation costs.
• Cyber insurance claim was partially denied due to lack of documented incident response controls.

Solution: The company engaged an external security consultant to rebuild its incident management capability from the ground up over 10 weeks:

1. Week 1–2: Approved an Information Security Incident Management Policy and formed a CSIRT with named primary and alternate members from IT, security, legal, HR, and communications.
2. Week 3–4: Developed a customized IRP and playbooks for ransomware, phishing, data breach, and insider threat.
3. Week 5–6: Deployed EDR across all endpoints, configured a SIEM, and implemented immutable backups with quarterly recovery testing.
4. Week 7–8: Conducted CSIRT training and a company-wide phishing awareness campaign.
5. Week 9–10: Ran a ransomware tabletop exercise with RBI and CERT-In notification injects, followed by a technical recovery drill.

Results:

• Achieved ISO 27001:2022 certification 6 months later with zero major nonconformities in the incident management area.
• Reduced phishing click rate from 34% to 6% within two quarters.
• Established a 24/7 incident hotline and on-call CSIRT rotation.
• The next RBI cyber security review raised no issues on crisis preparedness.
• Renewed cyber insurance at a lower premium due to improved controls.

Lessons Learned:

• Incident response cannot be improvised; planning and preparation are mandatory.
• Online backups are not ransomware-proof; immutable and air-gapped backups are essential.
• Regulatory notification timelines must be embedded in the IRP, not left to memory.
• Tabletop exercises with realistic injects reveal gaps that documents hide.

Illustrative Scenario 2: Indian Healthcare Provider, Data Breach Preparedness Prevents Regulatory Action

Organization: A multi-city hospital chain in India with 1,800 employees, 12 hospitals, and a central electronic medical record (EMR) system.

Challenge: In late 2023, the hospital chain's SOC detected anomalous database queries from an internal administrative account. The queries were accessing patient demographic and diagnosis records outside normal working hours. The SOC analyst flagged the event within 15 minutes, and the CSIRT was activated.

The challenge was to determine quickly whether this was a malicious insider, a compromised account, or a legitimate business process gone wrong. The hospital was subject to the DPDP Act 2023 (once notified), state clinical establishment regulations, and cyber insurance notification requirements. A misstep could trigger regulatory action, patient lawsuits, and media scrutiny.

Preparedness State: The hospital had invested in incident management planning 18 months earlier:

• A Board-approved incident management policy.
• A CSIRT with a forensic investigator, IT director, legal counsel, and communications manager.
• A severity matrix that classified unauthorized access to patient records as P2 (High) with escalation to P1 if more than 500 records were involved.
• Pre-drafted notification templates for patients, regulators, and media.
• An EDR and SIEM deployed across all endpoints and servers.
• An external DFIR retainer for incidents exceeding internal capability.

Response:

1. Detection (0–15 min): SIEM alert triggered; SOC analyst created a P2 ticket and notified the CSIRT Lead.
2. Triage (15–45 min): Forensic investigator reviewed logs and found that the administrative account had been accessed from an unrecognized device and IP address. The account was immediately disabled.
3. Containment (45–90 min): Affected database session terminated; firewall rules blocked the suspicious IP; EMR access logs preserved.
4. Investigation (Day 1–2): External DFIR confirmed the account was compromised via password reuse from a third-party breach. Approximately 320 patient records were viewed but not exfiltrated.
5. Notification (Day 2): Legal determined that, while no mass exfiltration occurred, viewing 320 patient records without authorisation was a personal data breach. The hospital intimated the affected patients and the Data Protection Board without delay and sent the Board a detailed report within 72 hours (DPDP s.8(6) and the DPDP Rules), reported to CERT-In within 6 hours, and informed its insurer as its policy required.
6. Recovery (Day 3): Compromised credentials reset; MFA enforced for all administrative accounts; affected user retrained.
7. Post-Incident Review (Week 2): Identified need for password spraying detection and privileged access management (PAM) hardening.

Results:

• Total business downtime: 2 hours (limited to one EMR module).
• No regulatory penalty; notifications were timely and complete.
• Patient trust was preserved through proactive communication.
• Cyber insurance claim was limited to DFIR costs and was paid in full.
• The hospital's ISO 27001 surveillance audit praised the maturity of the incident management program.

Lessons Learned:

• Preparedness converts a potential crisis into a controlled, evidence-based response.
• Pre-drafted notification templates and a clear severity matrix enable fast, defensible decisions.
• Integration between SOC, CSIRT, legal, and communications is essential.
• Post-incident reviews must produce concrete improvements, not just reports.

Multi-Framework Mapping

How to Use This Mapping

• SOC 2 auditors will look for documented incident response procedures, testing records, and evidence that incidents are tracked to closure.
• PCI DSS assessors will verify the incident response plan includes roles, testing, and notification to payment brands.
• NIST 800-53 assessors will map to IR-4, IR-8, and related audit controls.
• CIS Controls auditors will check incident response management (Control 17) and logging (Controls 8.x).
• COBIT governance reviewers will examine DSS05 processes for incident management.
• GDPR/DPDP compliance teams will focus on breach assessment, notification timelines, and records of processing.

By designing A.5.24 completely, an Indian organization can satisfy most of the incident management requirements across these frameworks simultaneously.

Implementation Roadmap

Phase 1: Foundation (Weeks 1–2)

Phase 2: Design (Weeks 3–5)

Phase 3: Enablement (Weeks 6–8)

Phase 4: Validation (Weeks 9–10)

Phase 5: Sustain (Ongoing)

FAQ

Q1: Is A.5.24 only about having an incident response plan?

No. A.5.24 is broader. It covers the entire planning and preparation capability: governance, roles, processes, technology, evidence handling, communication, training, and testing. The plan is one output, but the control expects a living, exercised program.

Q2: Do small organizations need a full CSIRT?

Small organizations can combine roles, but they must still have named individuals responsible for incident response, a documented plan, and a way to escalate to external experts. A virtual CSIRT supported by an MSSP is acceptable.

Q3: How often must we test the incident response plan?

ISO 27001 does not prescribe a frequency, but best practice and most regulators expect at least an annual tabletop exercise and periodic technical drills. RBI-regulated entities typically conduct exercises at least annually; SEBI mandates twice-yearly drills for brokers and DPs.

Q4: What is the difference between an event and an incident?

An event is any observable occurrence in a system or network. An incident is an event (or series of events) that has a significant probability of compromising information security or business operations. Not every event becomes an incident.

Q5: What must be reported to CERT-In?

CERT-In Directions, 2022 list 20 categories of reportable incidents, including targeted attacks, malware infections, unauthorized access, data breaches, DDoS, and attacks on critical infrastructure. Covered entities must report within 6 hours of noticing the incident.

Q6: How does A.5.24 relate to the DPDP Act 2023?

A.5.24 prepares the organization to detect, assess, and respond to personal data breaches. The DPDP Act requires data fiduciaries to intimate every personal data breach to the Data Protection Board and to each affected data principal (s.8(6)); there is no harm threshold. Under the DPDP Rules 2025 the intimation is made without delay, with a detailed report to the Board within 72 hours (from commencement, about May 2027). A well-prepared IR program enables timely, defensible breach notification.

Q7: Should we pay a ransom if hit by ransomware?

CERT-In (the national CSIRT) and law enforcement, including the Indian Cyber Crime Coordination Centre (I4C) and state police cyber cells, strongly discourage paying ransoms. Payment does not guarantee data recovery and may expose the organization to legal and sanctions risk. Preparation, immutable backups, and tested recovery are the correct defenses.

Q8: What evidence do auditors expect for A.5.24?

Key evidence includes the approved incident management policy, CSIRT roster, IRP, playbooks, severity matrix, training records, exercise records, incident tickets, communication templates, evidence-handling forms, and metrics reports.

Q9: Can we use an MSSP instead of an in-house SOC?

Yes. Many Indian organizations use an MSSP or MDR provider for 24/7 monitoring and Tier-1 response. However, the organization retains accountability. The contract must define SLAs, escalation paths, data residency, and incident notification obligations.

Q10: How do we keep the plan current?

Trigger a review after any significant incident, material organizational change (merger, divestiture, major cloud migration), change in threat landscape, or change in regulation. At minimum, review annually and update the document version.

Q11: What is the difference between A.5.24 and A.5.26?

A.5.24 is about planning and preparation, building the capability before an incident happens. A.5.26 is about response, actually executing the plan during a live incident. You cannot have effective response without preparation, which is why A.5.24 is foundational.

Q12: Should incident management be integrated with business continuity management?

Yes. A major cyber incident can trigger business continuity plans. The IR team and BCM team should share a crisis management framework, communication channels, and escalation paths. Joint exercises are highly recommended.

Q13: How do we handle an incident involving a cloud provider or SaaS vendor?

Your IRP should include vendor-specific contact information, escalation paths, and contractual notification obligations. Engage the vendor's security team immediately, preserve logs from their admin portals, and understand the shared responsibility model for the service.

Q14: What should be in a CSIRT "go bag" or jump kit?

A jump kit includes: CSIRT contact list, IRP and playbooks (offline copy), laptop with forensic tools, write blockers, USB drives, network cables, legal hold forms, chain-of-custody forms, notebook, voice recorder, and out-of-band communication device.

Q15: How do we measure the maturity of our incident management program?

Use a five-level maturity model: (1) ad-hoc, (2) developing, (3) defined, (4) managed, (5) optimized. Assess each capability area, policy, roles, detection, response, forensics, communication, training, and testing, and track improvement over time.

References and Further Reading

Standards and Frameworks

1. ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection, Information security management systems, Requirements.
2. ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection, Information security controls.
3. ISO/IEC 27035, Information security incident management (all parts).
4. NIST SP 800-61 Rev. 3 (April 2025), Incident Response Recommendations and Considerations for Cybersecurity Risk Management (aligned to CSF 2.0).
5. NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations.
6. CIS Controls v8, Center for Internet Security.
7. COBIT 2019, ISACA.

Indian Regulations and Guidelines

8. CERT-In Directions, 2022, Directions relating to information security practices, procedure, prevention, response and reporting of cyber incidents for safe & trusted Internet.
9. Digital Personal Data Protection Act, 2023, Ministry of Electronics and Information Technology, Government of India.
10. Reserve Bank of India, Cyber Security Framework in Banks and Master Direction on Information Technology Framework for the NBFC Sector.
11. Securities and Exchange Board of India, Cyber Security and Cyber Resilience Framework for Stock Brokers/Depository Participants.
12. Insurance Regulatory and Development Authority of India, Guidelines on Information and Cyber Security for Insurance Companies.
13. Information Technology Act, 2000 (as amended).
14. Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011.
15. Indian Cyber Crime Coordination Centre (I4C), Ransomware advisories.

Industry Reports

16. IBM Security, Cost of a Data Breach Report 2024.
17. Ponemon Institute, Cost of a Data Breach Study.
18. Data Security Council of India (DSCI), Annual Cyber Security Report.
19. ENISA, Threat Landscape reports.

Practical Guidance

20. SANS Institute, Incident Handler's Handbook.
21. FIRST.org, CSIRT Services Framework and CVSS.
22. MITRE ATT&CK Framework, Adversary Tactics and Techniques.
23. NIST National Cybersecurity Center of Excellence, Data Integrity.

End of ISO 27001:2022 Annex A 5.24, Information Security Incident Management Planning and Preparation: The Definitive Implementation Guide.