ISO 27001 A.5.26: Response to Information Security Incidents

Quick Reference: A.5.26 in 60 Seconds

What the Control Asks For

The Control in Brief

ISO 27001:2022 Annex A 5.26 asks organizations to respond to security incidents in line with documented procedures.

Do you need this control?

A.5.26 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 alongside A.5.24 and A.5.25. The depth of the response procedures should match your threats and size; small organisations often combine planning and response in one document.

ISO 27002:2022 Implementation Guidance (Section 5.26)

ISO 27002 5.26 asks that response procedures be established and communicated to all relevant interested parties, and that incidents be handled by a designated team with the required competency. Paraphrased, the response should cover: containing systems affected by the incident; collecting evidence as soon as possible (A.5.28); escalating, including crisis management and possibly business continuity plans; logging all response activities; communicating the incident to internal and external parties on a need-to-know basis; coordinating with authorities, external interest groups and forums, suppliers and clients to reduce the consequences for others; formally closing and recording the incident once handled; root cause analysis; and identifying lessons learned.

The elements below organise this into practice:

1. Activation of the response process: Once an information security event has been assessed and classified as an incident (per A.5.25), the documented response procedures must be activated without delay. Activation criteria, triggers, and authority should be pre-defined.

2. Timely response: Response actions should be commensurate with the classification and potential business impact of the incident. Critical incidents (e.g., ransomware, data breach, active adversary in the network) demand immediate response; set your own response targets by severity (27002 sets no timings).

3. Containment, eradication, and recovery: The response should follow a structured approach: contain the incident to prevent further damage, eradicate the root cause, and recover affected systems and services to normal operations.

4. Evidence preservation: Evidence should be collected and preserved in a manner that supports forensic analysis, legal proceedings, and regulatory reporting. Chain of custody must be maintained (see also A.5.28).

5. Communication and reporting: Internal stakeholders, customers, regulators, law enforcement, and other interested parties should be informed according to legal, regulatory, and contractual obligations.

6. Coordination with business continuity: For incidents that cause significant disruption, response activities should interface with business continuity and ICT continuity plans (A.5.29, A.5.30).

7. Documentation and logging: All response actions, decisions, and outcomes should be documented. Logs should be protected from tampering.

8. Post-incident review and learning: After the incident is resolved, lessons learned should be documented and used to improve the ISMS (see A.5.27).

Shall / Should / May Analysis

What Auditors Actually Check

Why This Control Matters

The Business Risk Narrative

An information security incident is not a technical glitch, it is a business crisis. Whether it is a ransomware attack encrypting your finance servers, a developer leaking API keys to a public repository, or an insider exfiltrating customer data, the organisation's ability to respond determines whether the event becomes a manageable disruption or a catastrophic failure.

A.5.26 sits at the heart of the incident management cluster (A.5.24–A.5.28). While A.5.24 requires you to plan and prepare, A.5.25 requires you to assess and decide, and A.5.27 requires you to learn, A.5.26 is the moment of truth: how you actually respond when the alarm goes off.

Without documented response procedures, organisations fall into chaos:

• No one knows who is in charge.
• Critical containment steps are skipped while teams debate.
• Evidence is overwritten or deleted.
• Customers and regulators are informed too late or inconsistently.
• The same incident type repeats because no one captured lessons learned.

The cost of poor incident response is measurable. IBM's "Cost of a Data Breach Report" consistently shows that organisations with formal incident response teams and tested incident response plans save millions of dollars per breach compared to those without. More importantly, they preserve customer trust, regulatory standing, and operational continuity.

Indian Regulatory Context

India's regulatory landscape makes incident response a legal obligation, not merely an ISO 27001 requirement.

CERT-In Directions, 2022

The Indian Computer Emergency Response Team (CERT-In) issued Directions under Section 70B(6) of the IT Act, 2000 on 28 April 2022; they took effect 60 days later, in late June 2022. These Directions mandate that service providers, intermediaries, data centres, body corporates, and government organisations must report the following cyber incidents to CERT-In within six hours of noticing or being brought to notice:

• Targeted scanning or probing of critical networks and systems
• Compromise of critical systems or information
• Unauthorised access to IT systems or data
• Defacement of website or intrusion into a website
• Malicious code attacks (ransomware, spyware, worms, trojans)
• Attacks on servers including database, mail, and DNS
• Identity theft, spoofing, and phishing attacks
• Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks
• Attacks on critical infrastructure, SCADA systems, and IoT devices
• Data breaches, leaks, and unauthorised data disclosure

Failure to report can result in penalties under the IT Act, 2000, and may expose senior management to liability.

Digital Personal Data Protection (DPDP) Act, 2023

Under the DPDP Act, 2023, a Data Fiduciary that suffers a personal data breach must give intimation to the Data Protection Board of India and each affected Data Principal in the manner prescribed. The DPDP Rules 2025, notified in November 2025, set the manner; the breach duties apply once the transition ends (about May 2027). Prepare for:

• Intimation to the Board and each affected Data Principal without delay, followed by a detailed report to the Board within 72 hours (no harm threshold)
• Detailed breach assessment and documentation
• Demonstration of reasonable security safeguards and prompt response
• Potential penalties up to ₹250 crore for failure to take reasonable security safeguards and up to ₹200 crore for failure to notify a breach

Your A.5.26 response procedures are the operational mechanism that enables DPDP Act compliance.

Reserve Bank of India (RBI) Guidelines

RBI-regulated entities (banks, NBFCs, payment system operators, fintechs) must comply with:

• RBI Cyber Security Framework: mandatory incident reporting to RBI, cyber crisis management plan, and prompt corrective action.
• Master Direction on Information Technology Framework for NBFCs: incident classification and reporting timelines.
• Digital Payment Security Controls: requirements for incident response and fraud monitoring.

Incident response failures in the financial sector can lead to restrictions on business operations, fines, and reputational damage.

Securities and Exchange Board of India (SEBI)

SEBI's CSCRF (2024) for regulated entities, including market infrastructure institutions (MIIs), stock brokers, depository participants, and mutual funds requires:

• Cyber crisis management plan
• Incident reporting to SEBI within specified timelines
• Annual cyber audit and tabletop exercises
• Business continuity and disaster recovery testing

Insurance Regulatory and Development Authority of India (IRDAI)

IRDAI's cybersecurity guidelines for insurers mandate:

• Cyber incident response team
• Reporting of cyber incidents to IRDAI
• Cyber crisis management plan
• Regular vulnerability assessments and penetration testing

Information Technology Act, 2000

Sections 43, 43A, 66, and 72A of the IT Act create liability for:

• Failure to implement reasonable security practices
• Compensation for failure to protect sensitive personal data or information
• Criminal penalties for hacking, data theft, and identity fraud

A documented, tested incident response capability is strong evidence of "reasonable security practices" under Section 43A read with the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011.

Industry-Specific Consequences

Cost of Non-Compliance: By the Numbers

• Average cost of a data breach in India (2024): about ₹19.5 crore (INR 195 million; IBM Cost of a Data Breach Report 2024), with the majority of costs driven by detection, escalation, notification, and lost business.
• Regulatory fine exposure: DPDP Act penalties can reach ₹250 crore for failure to take reasonable security safeguards.
• Customer churn after breach: lost business (customer turnover and reputational damage) is consistently one of the largest breach cost components in IBM's annual reports.

The Trust Argument

In the Indian B2B technology market, enterprise buyers increasingly demand proof of incident response maturity before signing contracts. A mature A.5.26 capability, complete with documented procedures, trained responders, regular exercises, and measurable outcomes, becomes a competitive differentiator. It signals that your organisation can be trusted with customer data and critical business processes.

Scope and Applicability

What This Control Covers

A.5.26 applies to the response phase of information security incident management. It covers:

• All events that have been assessed and classified as information security incidents under A.5.25.
• The documented procedures used to guide response actions.
• The people, processes, and technologies involved in detecting, analysing, containing, eradicating, recovering from, and communicating about incidents.
• Preservation of evidence for forensic, legal, and regulatory purposes.
• Coordination with business continuity, disaster recovery, legal, HR, communications, and third parties.
• Post-incident activities that feed into A.5.27 (learning from incidents).

What This Control Does NOT Cover

• Planning and preparation: primarily A.5.24.
• Assessment and decision on whether an event is an incident, primarily A.5.25.
• Collection of evidence as a standalone discipline: primarily A.5.28.
• Long-term learning and corrective action: primarily A.5.27.

That said, these controls are deeply interrelated, and a mature implementation will reference them continuously.

Who This Applies To

Size-Based Applicability

Incident Types in Scope

Key Definitions and Terminology

Relationship to Other Controls

Upstream Controls (Inputs to A.5.26)

Parallel Controls (Executed Concurrently)

Downstream Controls (Outputs from A.5.26)

Why This Mapping Matters

Auditors do not assess A.5.26 in isolation. They trace an incident from detection (A.8.16), through reporting (A.6.8), assessment (A.5.25), response (A.5.26), evidence handling (A.5.28), learning (A.5.27), and improvement (clause 10.1). Gaps in any of these controls undermine the effectiveness of A.5.26.

The Incident Response Lifecycle

Figure · Tiers

Maturity levels for response to information security incidents

A.5.26 is best understood through the lens of a structured incident response lifecycle. While A.5.24 covers preparation, A.5.26 focuses on detection/analysis, containment, eradication, recovery, and post-incident activity.

NIST SP 800-61 Lifecycle (Applied to A.5.26)

┌─────────────────────────────────────────────────────────────────────┐
│  PREPARATION                                                        │
│  (Primarily A.5.24 — but procedures are reviewed and ready)         │
└─────────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
┌─────────────────────────────────────────────────────────────────────┐
│  DETECTION & ANALYSIS                                               │
│  • Validate alerts                                                  │
│  • Determine scope and impact                                       │
│  • Classify the incident                                            │
│  • Activate the IRT                                                 │
└─────────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
┌─────────────────────────────────────────────────────────────────────┐
│  CONTAINMENT                                                        │
│  • Short-term containment (isolate affected systems)                │
│  • Long-term containment (segment network, block IOCs)              │
│  • Preserve evidence                                                │
└─────────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
┌─────────────────────────────────────────────────────────────────────┐
│  ERADICATION                                                        │
│  • Remove malware and backdoors                                     │
│  • Patch vulnerabilities                                            │
│  • Reset compromised credentials                                    │
│  • Remove persistence mechanisms                                    │
└─────────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
┌─────────────────────────────────────────────────────────────────────┐
│  RECOVERY                                                           │
│  • Restore systems from clean backups                               │
│  • Validate integrity and security                                  │
│  • Monitor for recurrence                                           │
│  • Resume normal operations                                         │
└─────────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
┌─────────────────────────────────────────────────────────────────────┐
│  POST-INCIDENT ACTIVITY                                             │
│  • Document timeline and actions                                    │
│  • Conduct post-incident review                                     │
│  • Update procedures and controls                                   │
│  • Report to regulators and stakeholders                            │
└─────────────────────────────────────────────────────────────────────┘

Incident Severity Classification

Response SLA Framework

Detailed Implementation Guidance

This section provides step-by-step guidance for implementing A.5.26, organised by phase of the incident response lifecycle.

Phase 0: Preparation and Readiness Review

Before any incident occurs, verify that the prerequisites for effective response are in place:

1. Approve the incident response policy and procedures.

   • Owner: CISO
   • Approver: CEO or delegated senior executive
   • Frequency: Annual review and after significant changes or incidents

2. Define and document the Incident Response Team (IRT).

   • Core members: Incident Commander, Technical Lead, Forensic Analyst, Communications Lead, Legal/Compliance Advisor, Business Continuity Representative
   • Contact details: 24x7 phone, email, Slack/Teams, escalation paths
   • Backup coverage for each role

3. Create and maintain playbooks.

   • Ransomware response playbook
   • Phishing / business email compromise playbook
   • Data breach response playbook
   • Insider threat playbook
   • DDoS response playbook
   • Cloud compromise playbook
   • Third-party / supply chain incident playbook

4. Establish a secure incident management system.

   • Dedicated ticketing system (e.g., Jira Service Management, ServiceNow, TheHive)
   • Restricted access to incident tickets
   • Encrypted storage for sensitive incident data
   • Integration with SIEM, SOAR, and communication tools

5. Prepare communication templates.

   • Internal status update template
   • Customer breach notification template
   • Regulatory notification template (CERT-In, RBI, SEBI, IRDAI, DPDP Board)
   • Media statement template
   • All-hands employee notification template

6. Build evidence handling capability.

   • Forensic workstation or jump host
   • Write blockers and imaging tools
   • Secure evidence storage with chain-of-custody tracking
   • Pre-approved forensic vendor contacts

7. Test the capability.

   • Tabletop exercises quarterly
   • Technical simulations twice yearly
   • Red team / purple team exercises annually
   • BCP/DR integration tests annually

Phase 1: Detection and Analysis

When an alert or report is received, the response process begins.

Step 1.1, Receive and log the event.

• Record source (SIEM alert, employee report, threat intel, vendor notification, customer complaint)
• Create an incident ticket immediately
• Assign a unique incident ID
• Record date/time in IST (India Standard Time) and UTC

Step 1.2, Perform initial triage.

• Verify the alert is not a false positive
• Identify affected systems, users, data, and locations
• Determine if the event is ongoing or historical
• Assess potential business impact

Step 1.3, Classify the incident.

• Apply the severity classification matrix (P1–P4)
• Confirm classification with incident commander
• Reclassify as new information emerges

Step 1.4, Activate the IRT.

• For P1/P2: convene war room (physical or virtual) within 15–30 minutes
• For P3/P4: assign to appropriate analyst and schedule review
• Notify stakeholders per the communication plan

Step 1.5, Preserve evidence.

• Capture volatile memory where relevant
• Preserve logs (firewall, DNS, endpoint, cloud, application)
• Take forensic images of affected systems before remediation
• Document chain of custody
• Prevent log rotation or deletion

Phase 2: Containment

Containment limits damage and buys time for thorough analysis.

Step 2.1, Choose containment strategy.

• Short-term containment: Isolate affected endpoints, disable compromised accounts, block malicious IPs/domains, revoke sessions
• Long-term containment: Apply interim fixes (firewall rules, patching, credential resets, network segmentation) while planning eradication

Step 2.2, Implement containment.

• Use automation where possible (SOAR playbooks, EDR isolation, cloud IAM revocation)
• Document every action with timestamp and rationale
• Verify containment effectiveness (e.g., stop C2 beaconing, halt data exfiltration)

Step 2.3, Assess business impact.

• Identify affected business processes
• Estimate downtime, data exposure, financial impact
• Determine whether to invoke business continuity plans

Step 2.4, Notify internal stakeholders.

• Management notification per SLA
• Legal/compliance notification if regulatory reporting is likely
• HR notification for insider threat incidents
• PR/communications notification if external disclosure is likely

Phase 3: Eradication

Eradication removes the threat from the environment.

Step 3.1, Identify root cause.

• Analyse logs, forensic images, malware samples
• Determine initial access vector (phishing, vulnerability, credential compromise, supply chain)
• Map attacker activity and persistence mechanisms

Step 3.2, Remove malicious artefacts.

• Delete malware, backdoors, and unauthorised accounts
• Revoke compromised credentials and certificates
• Reset API keys, service accounts, and privileged passwords
• Remove unauthorised rules, policies, or configurations

Step 3.3, Close vulnerabilities.

• Apply patches or compensating controls
• Harden configurations
• Update detection rules and IOCs
• Improve email filters and web proxies

Step 3.4, Validate eradication.

• Re-scan affected systems
• Hunt for residual persistence
• Confirm no active C2 communication
• Validate identity hygiene (no unknown admins, no stale credentials)

Phase 4: Recovery

Recovery restores systems and services safely.

Step 4.1, Plan recovery.

• Identify recovery priority order based on business impact
• Choose recovery source: clean rebuild, known-good backup, or failover site
• Verify integrity of recovery source (ensure backup is not compromised)

Step 4.2, Restore systems.

• Rebuild from gold images where possible
• Restore data from clean backups
• Re-enable systems in a segmented, monitored environment first
• Validate functionality and security before reconnecting to production

Step 4.3, Enhance monitoring.

• Deploy additional detection rules for the specific threat
• Increase log retention and monitoring on affected systems
• Run EDR hunts and network traffic analysis for 30–90 days

Step 4.4, Resume operations.

• Obtain sign-off from system owners and business stakeholders
• Communicate service restoration to users and customers
• Close war room and stand down extended IRT

Phase 5: Post-Incident Activity

Post-incident activity ensures the organisation learns and improves.

Step 5.1, Create final incident report.

• Executive summary
• Timeline of events
• Root cause and attack vector
• Impact assessment (systems, data, business, regulatory)
• Response actions taken
• Evidence collected
• Regulatory notifications made

Step 5.2, Conduct post-incident review.

• Within 72 hours for P1, within 2 weeks for P2, within 1 month for P3/P4
• Attendees: IRT members, affected business units, legal, compliance
• Use blameless post-mortem approach
• Identify what worked, what did not, and what to improve

Step 5.3, Update risk register and controls.

• Add or update risks based on root cause
• Implement corrective actions
• Update incident response procedures and playbooks
• Update detection rules and threat hunting queries

Step 5.4, Close the incident.

• Obtain formal sign-off from incident commander and CISO
• Archive incident records per retention policy
• Update metrics and KPIs

Tiered Implementation by Organisation Size

Small Organisations (1–100 employees)

Medium Organisations (101–500 employees)

Large Organisations (501+ employees)

Tools, Technologies, and Solutions

Category Overview

Vendor Comparison Matrix: SIEM

Vendor Comparison Matrix: EDR / XDR

Vendor Comparison Matrix: MDR Services (India-Focused)

Tool Selection Guidance

Free and Open-Source Tools

Policy and Procedure Templates

Template 1: Information Security Incident Response Policy

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

---

1. PURPOSE

This policy defines the framework for responding to information security
incidents at [Organization Name]. It ensures consistent, timely, and
effective response actions that minimise business impact, preserve evidence,
and support regulatory compliance.

2. SCOPE

This policy applies to all information security incidents affecting
[Organization Name]'s information assets, systems, networks, data, people,
and third-party services. It applies to all employees, contractors,
vendors, and other relevant interested parties.

3. OBJECTIVES

• Respond to all information security incidents in accordance with documented
  procedures.
• Minimise business disruption, data loss, and regulatory exposure.
• Preserve evidence in a forensically sound manner.
• Ensure timely internal and external communication.
• Learn from incidents and continuously improve the ISMS.

4. DEFINITIONS

• Information security event — identified occurrence indicating a possible
  breach of information security policy.
• Information security incident — unwanted or unexpected event that has a
  significant probability of compromising business operations or information
  security.
• Incident Response Team (IRT) — group responsible for managing incidents.

5. POLICY STATEMENTS

5.1 All information security incidents must be responded to using the
    documented incident response procedures and playbooks.

5.2 The IRT is activated for all confirmed P1 (Critical) and P2 (High)
    incidents, and for any P3/P4 incident at the discretion of the
    Information Security Manager.

5.3 Incidents must be classified and prioritised based on severity,
    impact, and regulatory exposure.

5.4 Response actions must preserve evidence and maintain chain of custody
    for forensic, legal, and regulatory purposes.

5.5 Regulatory notifications (CERT-In, RBI, SEBI, IRDAI, DPDP Board, etc.)
    must be made within applicable legal timelines.

5.6 Post-incident reviews must be conducted for all P1 and P2 incidents,
    and for P3/P4 incidents where lessons can be captured.

5.7 Incident response procedures must be reviewed annually and after any
    significant incident or organisational change.

6. ROLES AND RESPONSIBILITIES

• CEO / Board — strategic oversight; crisis decisions; major regulatory
  notifications.
• CISO / Information Security Manager — owns this policy; leads the IRT;
  ensures regulatory compliance.
• Incident Commander — manages the response to a specific incident.
• SOC / IT Team — detection, containment, eradication, recovery.
• Legal / Compliance — regulatory advice; privilege; evidence handling.
• HR — insider threat response; employee disciplinary actions.
• PR / Communications — internal and external communications.
• All Employees — report incidents promptly; cooperate with the IRT.

7. CLASSIFICATION AND ESCALATION

See the Incident Severity Classification Matrix and Response SLA Framework
maintained in the Incident Response Procedure.

8. COMMUNICATION

Internal and external communication during incidents must follow the
Incident Communication Plan. Only authorised spokespersons may communicate
externally.

9. EVIDENCE HANDLING

Evidence must be collected, stored, and transferred in accordance with the
Evidence Handling Procedure to maintain admissibility and chain of custody.

10. TRAINING AND AWARENESS

All employees must complete annual information security awareness training
that includes incident reporting. IRT members must receive role-specific
training and participate in regular exercises.

11. NON-COMPLIANCE

Failure to report incidents, interference with response activities, or
unauthorised disclosure of incident information may result in disciplinary
action.

12. REVIEW

This policy is reviewed annually and after significant incidents or changes.

---

APPROVED BY:

[CEO Name]
Managing Director
Date: [Date]

[CISO Name]
Chief Information Security Officer
Date: [Date]

Template 2: Incident Response Procedure

INCIDENT RESPONSE PROCEDURE
[Organization Name]
Version: 1.0
Owner: CISO
Review Date: [Date + 12 months]

---

1. PURPOSE

To provide step-by-step instructions for responding to information security
incidents at [Organization Name].

2. SCOPE

All information security incidents.

3. TRIGGER

This procedure is triggered when:
  • A security event is confirmed and classified as an incident, or
  • A relevant authority (e.g., CERT-In, customer, vendor) reports an
    incident involving [Organization Name], or
  • The CISO declares an incident.

4. PROCEDURE STEPS

Step 1: Detection and Reporting
  • Log the event in the incident management system with a unique ID.
  • Record date/time, reporter, source, initial description, and affected
    assets.

Step 2: Triage and Classification
  • Verify the event is not a false positive.
  • Classify severity as P1, P2, P3, or P4 using the severity matrix.
  • Assign an incident commander.

Step 3: Notification
  • Notify IRT members based on severity.
  • Notify management within defined SLAs.
  • Notify legal/compliance if regulatory reporting may be required.

Step 4: Containment
  • Implement short-term containment to stop immediate damage.
  • Implement long-term containment to prevent recurrence during analysis.
  • Preserve evidence before remediation.

Step 5: Eradication
  • Identify root cause.
  • Remove malware, backdoors, unauthorised accounts, and persistence.
  • Patch vulnerabilities and reset compromised credentials.

Step 6: Recovery
  • Restore systems from clean backups or rebuild from gold images.
  • Validate integrity before reconnecting to production.
  • Enhance monitoring on recovered systems.

Step 7: Post-Incident Activity
  • Prepare final incident report.
  • Conduct post-incident review.
  • Update procedures, playbooks, and controls based on lessons learned.
  • Track corrective actions to closure.

Step 8: Closure
  • Obtain sign-off from incident commander and CISO.
  • Archive records per retention policy.
  • Update metrics.

5. RECORDS

Records to be maintained:
  • Incident ticket
  • Timeline of events
  • Evidence inventory and chain-of-custody forms
  • Communication log
  • Final incident report
  • Post-incident review minutes
  • Corrective action tracker

6. REVIEW

This procedure is reviewed annually and after every P1/P2 incident.

Template 3: Ransomware Response Playbook (Extract)

RANSOMWARE RESPONSE PLAYBOOK
[Organization Name]
Version: 1.0
Owner: Incident Response Lead

---

1. DETECTION INDICATORS
  • Mass file encryption across multiple systems
  • Ransom notes appearing on desktops or file shares
  • Endpoint alerts for suspicious encryption activity
  • User reports of inaccessible files
  • Network alerts for suspicious lateral movement

2. IMMEDIATE ACTIONS (FIRST 15 MINUTES)
  • Declare P1 incident and activate IRT.
  • Do NOT pay the ransom. Contact legal and law enforcement first.
  • Isolate affected systems from the network (unplug cable / disable Wi-Fi
    / EDR isolation).
  • Preserve evidence: capture memory, preserve logs, take disk images if
    feasible before wiping.
  • Identify the ransomware variant (use ID Ransomware, VirusTotal, or
    forensic analysis).

3. CONTAINMENT (15–60 MINUTES)
  • Identify patient zero and initial access vector.
  • Block known C2 domains/IPs at firewall and DNS.
  • Disable compromised accounts and revoke active sessions.
  • Segment network to prevent further spread.
  • Take affected systems offline if they cannot be isolated individually.

4. ASSESSMENT (1–4 HOURS)
  • Determine scope: number of systems, data sets, and locations affected.
  • Identify backups: last known-good backup, location, integrity, air-gap
    status.
  • Assess whether data was exfiltrated (review logs, dark web monitoring).
  • Determine regulatory and customer notification obligations.

5. ERADICATION (4–24 HOURS)
  • Wipe affected systems and rebuild from gold images or clean backups.
  • Reset all privileged credentials, API keys, and service accounts.
  • Patch vulnerabilities exploited by the attacker.
  • Remove persistence mechanisms (scheduled tasks, registry entries,
    WMI event subscriptions).

6. RECOVERY (24–72 HOURS)
  • Restore data from clean backups in priority order.
  • Validate integrity of restored systems.
  • Reconnect to production only after security validation.
  • Implement enhanced monitoring for 30–90 days.

7. COMMUNICATION
  • Internal: status updates every 2–4 hours during active response.
  • Customers: breach notification if data was affected.
  • Regulators: CERT-In within 6 hours; others per applicable timelines.
  • Law enforcement: report to local cyber crime cell / CBI cyber crime.

8. POST-INCIDENT
  • Conduct blameless post-mortem within 72 hours.
  • Update backup strategy, network segmentation, and detection rules.
  • Provide ransomware-specific training to employees.

Template 4: CERT-In Incident Report Template (India-Specific)

CERT-IN INCIDENT REPORT
[Organization Name]
Report Date/Time (IST): [DD-MM-YYYY HH:MM]
Incident ID: [Internal ID]

1. ORGANISATION DETAILS
   Name: [Organization Name]
   Sector: [Banking / IT / Healthcare / etc.]
   Contact Person: [Name, Designation, Phone, Email]

2. INCIDENT SUMMARY
   Type of incident: [Ransomware / Data Breach / Phishing / DDoS / etc.]
   Date and time of detection: [IST]
   Date and time of occurrence (if known): [IST]
   Affected systems / services: [Description]

3. IMPACT ASSESSMENT
   Data affected: [Yes/No; type and volume]
   Business impact: [Description]
   Number of users / customers affected: [Count]

4. CONTAINMENT ACTIONS TAKEN
   [Describe containment steps]

5. ROOT CAUSE (PRELIMINARY)
   [Initial root cause if known]

6. EVIDENCE PRESERVATION
   [Yes/No; brief description]

7. NOTIFICATIONS MADE
   [Internal / external notifications]

8. ADDITIONAL INFORMATION
   [Any other relevant details]

Submitted by:
[Name]
[Title]
[Signature / Digital Approval]

Risk Assessment and Treatment

Risk Identification

Risk Assessment Matrix

Risk Treatment Plan

Residual Risk Acceptance

Any residual risks scored Medium or above must be reviewed by the CISO and accepted by the Risk Acceptance Committee. Low residual risks may be accepted by the Information Security Manager with documented justification.

Audit and Compliance Checklist

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

Documentation

Process Effectiveness

Competence and Testing

Common Audit Red Flags

Metrics and KPIs

Operational Metrics

Quality Metrics

Business and Compliance Metrics

Reporting Dashboard Template

MONTHLY INCIDENT RESPONSE DASHBOARD
[Organization Name] — [Month, Year]

Operational Performance
• Total incidents: [X]
• P1 Critical: [X] | P2 High: [X] | P3 Medium: [X] | P4 Low: [X]
• MTTD: [X hours]
• MTTR: [X hours]
• MTTC: [X hours]
• MTTRc: [X hours]

Quality
• Post-incident reviews completed: [X/Y]
• Corrective actions closed on time: [X/Y]
• Repeat incidents: [X]
• Evidence preservation rate: [X%]

Compliance
• Regulatory reports submitted on time: [X/Y]
• Incidents requiring customer notification: [X]
• Training completion: [X%]

Trends
• Top incident categories: [Phishing, Malware, Insider, etc.]
• Top root causes: [Credential compromise, unpatched systems, misconfiguration]
• Improvement actions: [List]

Common Pitfalls / Audit Failures & How to Avoid Them

Illustrative Scenarios: Indian Incident Response Failures and Recoveries

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

Illustrative Scenario 1: Indian NBFC Ransomware Recovery

Organisation: A mid-sized non-banking financial company (NBFC) in Mumbai with 400 employees, lending operations across Maharashtra and Gujarat.

The Incident: On a Sunday evening, attackers deployed ransomware across the NBFC's file servers, database servers, and virtual desktop infrastructure. The ransomware encrypted approximately 60% of production systems. Initial access was traced to a phishing email received by an accounts executive on Thursday. The user had clicked a link and entered credentials on a fake Microsoft login page. The attacker remained dormant for 72 hours, then moved laterally using compromised admin credentials and deployed ransomware via Group Policy.

Challenges:

• The NBFC had no documented incident response procedure.
• Backups were connected to the network and were also encrypted.
• No one knew who should declare an incident or contact regulators.
• The IT team attempted to recover by paying a partial ransom, which failed to produce working decryptors.
• Customer loan servicing was disrupted for 11 days.

Response Actions: After engaging an external security consultant and a forensic partner, the NBFC:

• Declared a P1 incident and activated a temporary IRT.
• Isolated all affected systems and rebuilt the network from scratch.
• Engaged RBI and CERT-In within the required timelines.
• Restored operations from a six-month-old offline backup, losing some transaction data.
• Implemented offline, immutable backups with weekly restore tests.
• Deployed EDR, MFA, network segmentation, and phishing-resistant authentication.
• Created and trained staff on incident response procedures and playbooks.

Results:

• Operations fully restored in 18 days.
• The regulator raised supervisory concerns about delayed reporting and weak controls.
• Customer churn increased by 12% in the following quarter.
• Within 12 months, the NBFC achieved a mature incident response capability with MTTD under 4 hours and MTTC under 2 hours.
• Passed the next RBI cyber audit with no major observations.

Lessons Learned:

• Network-connected backups are not backups.
• Documented procedures and trained responders save days of downtime.
• Early regulator engagement is better than delayed reporting.
• Executive sponsorship is essential for funding recovery and resilience investments.

Illustrative Scenario 2: Indian SaaS Company Data Breach Response

Organisation: A Bengaluru-based B2B SaaS company providing HR analytics to 800 enterprise customers, processing employee data for over 2 million individuals.

The Incident: A security researcher discovered that a cloud storage bucket containing customer export files was publicly accessible due to a misconfiguration introduced during a feature release. The bucket contained names, email addresses, employee IDs, and salary ranges. The researcher reported the issue through the company's bug bounty programme. Internal investigation confirmed the bucket had been exposed for approximately 47 days.

Challenges:

• The company had no data breach response playbook.
• Legal and security teams disagreed on whether the exposure constituted a "breach" requiring notification.
• There was no pre-approved customer communication template.
• The DPDP Act, 2023 was newly enacted, creating uncertainty about notification obligations.
• Several enterprise customers demanded detailed forensic evidence and root cause analysis within 48 hours.

Response Actions: The company engaged an external security consultant to:

• Classify the incident as P2 High and activate the IRT.
• Immediately revoke public access and audit all access logs.
• Engage a forensic firm to determine whether unauthorised access occurred.
• Draft customer notifications, regulator intimation, and FAQ documents.
• Conduct a blameless post-incident review.
• Implement CSPM, IAM governance, and automated misconfiguration scanning.
• Update the incident response procedure with a dedicated data breach playbook.

Results:

• Forensic analysis found no evidence of unauthorised download or exfiltration.
• Customers were notified transparently within 72 hours.
• No regulatory penalty was imposed, although a voluntary intimation was filed.
• The company retained 95% of affected customers due to prompt and honest communication.
• SOC 2 Type II audit passed six months later with no incident management exceptions.

Lessons Learned:

• A data breach playbook must be ready before the breach occurs.
• Transparent, timely communication preserves trust better than silence.
• Cloud misconfigurations require automated, continuous detection.
• Legal and security alignment before an incident prevents decision paralysis.

Illustrative Scenario 3: Indian Manufacturing Firm Insider Threat Containment

Organisation: A Pune-based automotive component manufacturer with 1,200 employees and Intellectual Property (IP) critical to global OEM supply contracts.

The Incident: A departing senior design engineer downloaded over 5,000 CAD drawings and technical specifications to a personal cloud storage account during the 30-day notice period. The activity was detected by the Data Loss Prevention (DLP) system after the engineer had already uploaded 80% of the data.

Response Actions:

• The SOC analyst escalated the DLP alert as a P2 insider threat incident.
• The IRT immediately suspended the user's access and preserved endpoint logs and DLP records.
• HR and Legal were notified within one hour.
• A forensic image of the user's laptop and cloud upload logs were collected as evidence.
• The company filed a complaint with the local cyber crime police station.
• The former employee was contacted by legal counsel and compelled to delete the data and sign an undertaking.

Results:

• No evidence of data sharing with competitors was found.
• The company avoided litigation by securing a signed undertaking and settlement.
• Access review and offboarding processes were strengthened.
• User behaviour analytics was deployed to detect abnormal data access patterns.

Lessons Learned:

• Offboarding access must be tightly controlled during notice periods.
• DLP alerts must be integrated into the incident response process.
• HR, legal, and security must coordinate quickly on insider threats.
• Evidence preservation is critical for both criminal and civil action.

Multi-Framework Mapping

Framework-Specific Implementation Notes

SOC 2 Trust Services Criteria (CC7.3–CC7.5)

• Document how monitoring tools detect anomalies.
• Show that anomalies are triaged and incidents are declared.
• Demonstrate that response actions are documented and reviewed.

PCI DSS v4.0.1 (Requirement 12.10)

• Maintain an incident response plan covering all system components.
• Test the plan at least annually and after significant changes.
• Include payment brand notification procedures.

NIST SP 800-53 Rev. 5

• Develop an Incident Response Plan (IR-8) with roles, procedures, and reporting.
• Monitor incidents (IR-5) and report to designated authorities (IR-6).
• Coordinate with external incident response assistance (IR-7).

CIS Controls v8

• Control 17 explicitly covers incident response management.
• Focus on designated personnel, established processes, testing, reviews, and SOC capability.

COBIT 2019

• Map incident response to DSS05 (Managed Security Services) and DSS01 (Managed Operations).
• Ensure governance and management objectives support incident management.

GDPR / DPDP Act 2023

• Personal data breaches must be reported to supervisory authorities within 72 hours under GDPR.
• Under the DPDP Act, 2023, intimation to the Data Protection Board and affected Data Principals is required.
• A.5.26 procedures must include breach assessment and notification workflows.

Implementation Roadmap: 6 Weeks

Week 1: Foundation

Week 2: Documentation

Week 3: Tools and Integration

Week 4: Training and Awareness

Week 5: Testing and Refinement

Week 6: Go-Live and Continuous Improvement

Ongoing Activities

FAQ

Q1: What is the difference between an information security event and an incident?

An event is any observable occurrence in a system or network. An incident is an event that has been assessed as having a significant probability of compromising business operations or information security. A.5.25 covers the assessment and decision process; A.5.26 covers the response to confirmed incidents.

Q2: Does A.5.26 require a dedicated incident response team?

ISO 27001 does not mandate a dedicated team, but it requires that incidents be responded to in accordance with documented procedures. For most organisations, this means defining an IRT with clear roles. Larger or regulated organisations typically need a dedicated CSIRT or SOC.

Q3: How quickly must we respond to an incident?

ISO 27001 does not specify fixed timelines. Your organisation must define response SLAs based on risk. Critical incidents (P1) should be acknowledged within minutes and contained within hours. Regulatory timelines (e.g., CERT-In's 6-hour reporting) are legally binding.

Q4: Do we need to report every incident to CERT-In?

No. Only the categories of cyber incidents listed in the CERT-In Directions, 2022 must be reported, and only by the entities covered by those Directions. However, all significant incidents should be assessed for reporting obligations.

Q5: How does the DPDP Act, 2023 affect incident response?

The DPDP Act requires Data Fiduciaries to give intimation of personal data breaches to the Data Protection Board of India and affected Data Principals. Your A.5.26 procedures must include a breach assessment and notification workflow that satisfies these requirements.

Q6: What evidence must be preserved during an incident?

Preserve any data that may support investigation, legal action, or regulatory reporting. This includes system logs, network logs, endpoint telemetry, memory dumps, disk images, emails, screenshots, and chain-of-custody records. See A.5.28 for detailed evidence collection guidance.

Q7: Should we pay a ransom?

Paying a ransom is generally discouraged by law enforcement and regulators. It does not guarantee data recovery and may expose the organisation to legal and reputational risk. Decisions should involve legal counsel, law enforcement, and senior management.

Q8: How often should we test incident response procedures?

At a minimum, conduct tabletop exercises quarterly and a technical simulation or red team exercise annually. Regulators such as RBI and SEBI may require more frequent testing for regulated entities.

Q9: What should be included in a post-incident review?

A post-incident review should include: timeline of events, root cause, impact assessment, response effectiveness, what worked well, what did not work, corrective actions, and updates to procedures, training, and controls.

Q10: Can we outsource incident response?

Yes. Many organisations use Managed Detection and Response (MDR) services or incident response retainers. However, accountability remains with the organisation. Contracts must define response SLAs, notification obligations, evidence handling, and escalation procedures.

Q11: How do we ensure incident response integrates with business continuity?

Define escalation criteria in your IR procedure that trigger invocation of BCP/DR plans. Include BCP/DR representatives in the IRT for P1/P2 incidents. Test integrated response during annual BCP exercises.

Q12: What are the most common A.5.26 audit findings?

Common findings include: missing documented procedures, no incident classification, untested procedures, no post-incident reviews, missing evidence preservation, delayed regulatory reporting, and unclear IRT roles.

References and Further Reading

Standards and Frameworks

• ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection, Information security management systems, Requirements
• ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection, Information security controls
• ISO/IEC 27035, Information security incident management (all parts)
• ISO/IEC 27037, Guidelines for identification, collection, acquisition and preservation of digital evidence
• NIST SP 800-61 Rev. 2, Computer Security Incident Handling Guide
• NIST Cybersecurity Framework Version 1.1 / 2.0
• CIS Controls Version 8, Control 17: Incident Response Management
• COBIT 2019, Governance and Management Objectives

Indian Regulations and Guidelines

• Information Technology Act, 2000 (as amended)
• Information Technology (The Indian Computer Emergency Response Team and Manner of Performing Functions and Duties) Rules, 2013
• CERT-In Directions, 2022 (under Section 70B of the IT Act, 2000)
• Digital Personal Data Protection Act, 2023
• Reserve Bank of India, Master Direction on Information Technology Framework for the NBFC Sector
• Reserve Bank of India, Cyber Security Framework in Banks
• SEBI, SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities, circular of 20 August 2024.
• IRDAI, Guidelines on Information and Cyber Security for Insurers

Industry Resources

• FIRST, Forum of Incident Response and Security Teams: https://www.first.org
• CERT-In, Indian Computer Emergency Response Team: https://www.cert-in.org.in
• NCIIPC, National Critical Information Infrastructure Protection Centre: https://nciipc.gov.in
• MeitY, Ministry of Electronics and Information Technology: https://www.meity.gov.in