Incident Response Compliance: Requirements, Frameworks & Best Practices

A security incident rarely follows the response plan exactly as it was written. 

An unusual login may turn out to be a false alarm. It could also be the first sign that an attacker has gained access to an employee account and is moving through the environment. 

Once an incident is confirmed, the security team must simultaneously understand what happened, contain the threat, preserve relevant evidence and determine whether the incident creates any regulatory, contractual or reporting obligations. 

This is where incident response compliance becomes important. 

The requirements can vary considerably between organisations. They depend on where the organisation operates, the type of information it handles, the services it provides and the regulatory or assurance frameworks that apply to its business. 

For example, organisations operating in India may need to consider CERT-In requirements and the Digital Personal Data Protection (DPDP) Act, 2023. Organisations that process personal data within the scope of GDPR may need to consider its breach requirements. ISO/IEC 27035 provides specific guidance for information security incident management, while SOC 2 focuses on controls relevant to areas such as security, availability, confidentiality and privacy. 

The important point is that incident response should account for the requirements that actually apply to the organisation. 

Key Takeaways 

• Incident response compliance means aligning detection, investigation, containment, and reporting with the regulatory, contractual, and security requirements that apply to an organisation. 

• Not every security incident triggers a mandatory notification -- the obligation depends on what the investigation confirms was affected. 

• CERT-In requires specified cyber incidents to be reported within six hours; GDPR requires qualifying personal data breaches to be reported within 72 hours where feasible. 

• ISO/IEC 27035 provides the incident-management lifecycle, while SOC 2 assesses whether related controls are operating effectively -- neither replaces the other. 

• Incident response plans need regular testing, reliable logging, and clear coordination between security, privacy, legal, and compliance teams to remain effective. 

What Is Incident Response Compliance?

Incident response compliance means managing and documenting security incidents in line with the regulatory, contractual, and security requirements that apply to an organisation, built into detection, investigation, containment, and reporting rather than treated as a separate exercise. 

It is part of the wider process of preparing for, investigating and managing security incidents while meeting applicable regulatory, contractual and security requirements. 

A typical incident response process may involve: 

The process will vary depending on the nature and severity of the incident. This lifecycle mirrors the structure used in established models such as NIST SP 800-61 and the SANS PICERL framework. 

A suspicious login may require a relatively straightforward investigation. A compromised privileged account could require the security team to review identity activity, endpoint data, network traffic, application logs and access records before determining the extent of the compromise. 

Preparation therefore matters. 

Before an incident occurs, organisations should know who is responsible for leading the investigation, who needs to be informed, how evidence will be collected, when an incident needs to be escalated and which teams are responsible for assessing regulatory or contractual obligations. 

When Does a Security Incident Become a Compliance Issue?

A security incident becomes a compliance issue once an investigation confirms what was affected and whether that triggers a regulatory, contractual, or reporting obligation. 

The organisation first needs to understand what happened and what was affected. 

During an investigation, the team may need to establish: 

• Which systems, accounts or applications were affected?  
• Was personal or sensitive information involved?  
• When did the activity begin?  
• When was it discovered?  
• Was information accessed, modified or removed?  
• What evidence needs to be preserved?  
• Which regulatory or contractual requirements apply?  
• Who needs to be involved in the decision?  

The answers can change the response significantly. 

For example, an employee account compromise may initially appear to be an access-control issue. If the investigation shows that the account was used to access personal data, the incident may also have data-protection implications. 

This is why incident response often requires coordination between the SOC or IT team and other functions such as privacy, legal, compliance, communications and business teams. 

The security team provides the technical facts. The relevant stakeholders can then use those facts to determine the appropriate next steps. 

Which Regulations and Frameworks Are Relevant to Incident Response?

Several regulations and frameworks can apply to incident response depending on where an organisation operates and the type of data it handles, including CERT-In, the DPDP Act, GDPR, ISO/IEC 27035, SOC 2, and NIST SP 800-61. 

Different regulations and frameworks address different requirements. 

The organisation first needs to determine which requirements apply to its environment. Organisations in regulated sectors such as banking, securities, or insurance may also need to account for directions issued by sectoral regulators such as the RBI, SEBI, or IRDAI. 

The purpose of incident response is then to incorporate those requirements into the operational process rather than treating compliance as a separate exercise. 

What Are CERT-In's Incident Response Requirements in India?

For organisations operating in India, CERT-In is an important consideration when developing an incident response process. 

Under directions issued under Section 70B of the Information Technology Act, 2000, CERT-In has established requirements relating to cybersecurity practices, prevention, response and reporting of specified cyber incidents. 

What is the CERT-In incident reporting timeline?

Specified cyber incidents must be reported to CERT-In within six hours of noticing the incident or being brought to notice, in accordance with the applicable directions. 

• Reporting timeline: within six hours of detection 
• Legal basis: Directions issued under Section 70B, Information Technology Act, 2000 
• Scope: specified cyber incidents, including data breaches, unauthorised access, and ransomware attacks 

This makes the early stages of incident response particularly important. 

An organisation needs to establish the basic facts quickly, preserve relevant information and involve the appropriate stakeholders. The investigation may continue as additional information becomes available, but the response process cannot simply wait until every detail is known. 

CERT-In requirements also make areas such as incident analysis, communication, coordination, reporting and record retention important parts of an organisation's incident response capability. 

For a more detailed explanation, see Eventus' CERT-In Compliance in India. 

Official reference: CERT-In Directions under Section 70B 

How Does the DPDP Act Affect Incident Response in India?

The Digital Personal Data Protection Act, 2023 (DPDP Act) is another consideration for organisations operating in India when an incident involves digital personal data. Under the DPDP Act, a Data Fiduciary must notify the Data Protection Board of India and the affected Data Principals when a personal data breach occurs. 

CERT-In and the DPDP Act address different areas. 

CERT-In focuses on specified cybersecurity incidents and related reporting and security requirements, while the DPDP Act addresses the protection and processing of digital personal data. 

An incident may therefore require an organisation to consider both sets of obligations, depending on the circumstances. 

This also highlights why incident response cannot sit entirely within the security team. Where personal data may be involved, security teams may need to work with privacy, legal and compliance stakeholders to assess the incident and determine the appropriate response. 

For organisations reviewing their readiness, Eventus DPDPA Compliance Checklist covers areas including security safeguards, breach response, governance and compliance readiness. 

How Does GDPR Apply to Personal Data Breach Response?

GDPR applies to organisations within its scope, including certain organisations outside the European Union that process personal data in connection with offering goods or services to individuals in the EU or monitoring their behaviour. 

One important distinction is that not every security incident is automatically a reportable personal data breach. 

The organisation needs to understand what happened and assess the circumstances before determining whether notification is required. 

Does GDPR require every security incident to be reported within 72 hours?

No. 

Under Article 33 of GDPR, where a personal data breach is likely to result in a risk to the rights and freedoms of individuals, the controller must notify the relevant supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach. 

The investigation may therefore need to establish: 

• What personal data was involved?  
• How many individuals could be affected?  
• Was the data accessed, changed or disclosed?  
• When did the organisation become aware of the breach?  
• What steps were taken to contain the incident?  

The security team may not be responsible for making the final legal or regulatory decision. Its role is to provide reliable technical information that allows privacy, legal and compliance teams to assess the situation. 

Good logging and evidence preservation are therefore important not only for technical investigation but also for making informed compliance decisions. 

Official reference: GDPR Article 33 — EUR-Lex 

What Does ISO/IEC 27035 Cover for Incident Management?

When discussing incident management specifically, ISO/IEC 27035 is more directly relevant than ISO 27001. 

ISO/IEC 27035 provides guidance for managing information security incidents, covering areas such as preparation, detection, reporting, assessment, response and lessons learned. 

The standard takes a lifecycle approach to incident management. 

An organisation needs to be prepared before an incident occurs. When a potential incident is detected, it needs to be reported and assessed. Once an incident is confirmed, appropriate response activities can be initiated, followed by recovery and post-incident activities. 

Consider a phishing attack that results in a compromised employee account. 

The immediate priority may be to secure the account, investigate the activity and determine whether the attacker reached other systems. 

Once the immediate threat has been contained, the organisation also needs to understand what allowed the incident to occur. 

1. Was the account appropriately protected? 
2. Were the user's privileges suitable? 
3. Could the activity have been detected earlier? 
4. Are other accounts exposed to the same weakness? 
5. What controls need to be improved? 

This is where lessons learned become important. Incident management should not end when the affected system is restored. Findings from an incident can help improve processes and security controls. 

ISO/IEC 27001, meanwhile, provides the broader framework for establishing and continually improving an Information Security Management System (ISMS). ISO/IEC 27035 can complement that broader information-security management approach by providing more specific guidance on incident management. 

Official reference: ISO/IEC 27035 — ISO 

Where Does SOC 2 Fit Into Incident Response?

SOC 2 is not an incident response standard. 

It focuses on controls related to areas such as security, availability, processing integrity, confidentiality and privacy. These control areas are defined in the AICPA's Trust Services Criteria, which SOC 2 assessments are based on. 

Incident-related controls may form part of a SOC 2 assessment depending on the scope of the engagement. 

For an organisation, this can mean demonstrating that relevant processes and controls are not simply documented but are operating as intended. 

The question is therefore not only whether an incident response policy exists. Organisations may also need to demonstrate that relevant controls and processes were followed and that appropriate evidence was maintained. 

For organisations that need hands-on support, Eventus' Incident Response Service supports incident response planning, investigation, containment, remediation, recovery, and reporting. 

Where Do Incident Response Plans Commonly Fall Short?

Most organisations already have some form of incident response capability. 

They may have a response plan, security tools, escalation procedures and people responsible for different parts of the process. 

The difficulties often become apparent when all of these elements have to work together during an actual incident. 

A response plan may have been written some time ago. Since then, people may have changed roles, systems may have been replaced and new applications may have been introduced. 

The document may still exist, but it may no longer reflect the current environment. 

Security data can create a similar challenge. An organisation may have large volumes of logs but still struggle to find the specific information required during an investigation. 

SIEM (Security Information and Event Management) and EDR (Endpoint Detection and Response) are two common categories of security tooling used to collect, correlate, and investigate activity across an environment. 

Technologies such as SIEM and EDR can improve visibility, but technology alone does not determine how an incident is handled. 

For organisations that require continuous visibility, 24×7 SOC monitoring can help security teams detect suspicious activity, investigate alerts and escalate potential incidents. 

Communication can also become a problem. The SOC may know that an account has been compromised while the privacy or compliance team is still determining whether personal data was involved. 

Recovery is another point where organisations can lose valuable information. Systems may be restored and the immediate threat removed, but if the underlying cause is not investigated, the same weakness may remain. 

For this reason, incident response plans need to be reviewed and tested periodically rather than treated as documents that are completed once and stored. 

How Does Eventus Security Support Incident Response?

Eventus Security supports organisations across incident response, incident readiness, digital forensics and incident response (DFIR), and 24×7 security operations. 

Its Incident Response Service covers areas such as incident response planning, response playbooks, security-gap assessment, threat hunting, compromise assessment, digital forensics, root-cause analysis and recovery guidance. 

Preparation is also an important part of incident readiness. Organisations can use activities such as tabletop exercises, maturity assessments and ransomware simulations to evaluate how their response processes perform before facing a real incident. 

For organisations that require continuous monitoring, SOC as a Service provides 24×7 security monitoring, detection and response capabilities. 

Eventus is also CERT-In empanelled, supporting organisations with cybersecurity assessment and compliance-related requirements in India. 

The focus is on helping organisations prepare for incidents, investigate them effectively and use the findings to strengthen their security posture. 

What Should Organisations Include in an Incident Response Compliance Plan?

A practical incident response compliance plan should connect security operations with the requirements that apply to the organisation. 

At a minimum, organisations should consider: 

• Clear incident classification and severity levels  
• Defined roles and escalation responsibilities  
• Up-to-date incident response procedures  
• Reliable logging and evidence preservation  
• Regulatory and contractual reporting requirements  
• Communication procedures for internal and external stakeholders  
• Regular testing of response plans  
• Documentation of significant incidents  
• Root-cause analysis and remediation  
• Post-incident reviews and improvement  

These elements help ensure that incident response is not limited to detecting and containing a threat. They also help organisations demonstrate how an incident was managed and what was done to reduce the likelihood of recurrence. 

Frequently Asked Questions

What is incident response compliance?

Incident response compliance means managing and documenting security incidents in accordance with the regulatory, security and contractual requirements applicable to an organisation. 

Does every organisation have to follow CERT-In requirements?

CERT-In requirements apply to organisations and entities within the scope of the applicable Indian cybersecurity directions. Organisations should assess their specific obligations rather than assuming that every requirement applies to every business. 

Does GDPR require every security incident to be reported within 72 hours?

No. The 72-hour requirement applies to qualifying personal data breaches where the conditions under Article 33 are met. 

Is ISO 27001 the same as ISO/IEC 27035?

No. ISO/IEC 27001 provides a broader framework for an Information Security Management System (ISMS), while ISO/IEC 27035 focuses specifically on information security incident management. 

Does SOC 2 cover incident response?

SOC 2 is not an incident response standard. However, relevant incident-management controls may be assessed depending on the scope of the SOC 2 engagement. 

How Can Organisations Build a More Prepared Incident Response Capability?

Incident response requirements differ from one organisation to another. What remains consistent is the need to understand what happened, contain the threat, preserve relevant evidence and make informed decisions about the next steps. 

Regular testing, reliable security visibility, clear responsibilities and effective evidence management can help organisations respond more effectively when an incident occurs. 

For organisations looking to strengthen their incident response capability, Eventus Security provides incident response, incident readiness, DFIR and 24×7 security operations. 

Explore Eventus Incident Response Services