Cyber Security Incident Response Plan

This Cyber Incident Response Policy and Process is tailored for a SaaS application based in India and is designed to meet the strict legal requirement of reporting incidents to CERT-In (Indian Computer Emergency Response Team) within six hours of noticing or being brought to notice of the incident, as mandated by the CERT-In Direction 20(3)/2022.

1. Purpose & Scope
  • Purpose: To define a systematic, phased approach for managing security incidents to minimize impact, ensure business continuity, protect customer data, and comply with all regulatory requirements, especially the CERT-In 6-hour reporting mandate.
  • Scope: Applies to all systems, networks, applications (all Zeonix Global Ltd. Products), and personnel involved in the operation and maintenance of the company’s SaaS infrastructure.
2. Incident Response Team (IRT)
  • The IRT is led by the IR Team Lead (e.g., CTO or Head of Security) and includes members from Technology/Engineering, Legal, Management, and Communications.
RoleResponsibility
IR Team LeadOverall command, decision-making, coordinating containment.
Technical TeamDetection, analysis, containment, eradication, recovery.
Legal/ComplianceMandatory CERT-In reporting, regulatory compliance, evidence handling.
ManagementBusiness impact assessment, resource allocation, external communication approval.
3. Cyber Incident Response Process (CIRP)

The CIRP follows six key phases to ensure a structured and compliant response.

Phase 1: Preparation (Proactive)

This phase ensures the company is ready to respond before an incident occurs.

  • Asset Inventory: Maintain an up-to-date register of all critical assets, systems, and data locations.
  • Tools & Access: Ensure the IRT has necessary tools (logging, forensic software) and secured, tested out-of-band communication channels.
  • Playbooks: Develop and test scenario-specific response playbooks (e.g., Ransomware, Data Breach, DDoS).
  • Training: Conduct mandatory, regular incident response training and simulations (tabletop exercises).
Phase 2: Detection & Analysis (The Clock Starts Here)

This phase focuses on identifying and understanding the incident.

  1. Detection: Identify a potential incident via monitoring system alerts, user reports, or third-party intelligence.
  2. Initial Triage: The Technical Team immediately verifies the incident’s legitimacy and classifies its severity (e.g., Low, Medium, High, Critical).
  3. Evidence Preservation: Immediately isolate and snapshot logs, system memory, and network data from affected systems before any changes are made.
  4. Root Cause Analysis (Initial): Determine the initial vector (e.g., phishing, unpatched vulnerability, compromised credential) and scope.
⏰ CRITICAL ACTION: CERT-In 6-Hour Reporting Mandate
ActionDeadlineDetail
Internal NotificationIMMEDIATENotify the IR Team Lead and Management.
Mandatory Regulatory ReportingWithin 6 hours of noticing or being brought to notice of the incident.The Legal/Compliance team must report the incident to CERT-In (Indian Computer Emergency Response Team) via email (incident@cert-in.org.in) and/or phone (1800-11-4949). The initial report must include the nature of the incident, time of detection, and preliminary scope.
Phase 3: Containmenter
  1. The goal is to stop the incident from spreading and causing further damage.
  2. Short-Term Containment: Isolate the compromised component (e.g., disconnecting a server from the internet, blocking a malicious IP at the firewall).
  3. Long-Term Containment: Change compromised passwords/keys, deploy patches, and implement stronger access controls across the network.
  4. Backup Integrity: Ensure that clean, verified backups are maintained and secured from the threat.
Phase 4: Eradication & Recovery
  1. This phase removes the threat and restores operations.
  2. Eradication: Completely remove all malicious components, backdoors, and rootkits identified during analysis.
  3. System Rebuild: Rebuild or restore critical systems from the verified, clean backups. Never restore a system without confirming the root cause is fixed.
  4. Validation: Monitor systems aggressively post-recovery to confirm the threat is completely gone and service integrity is restored.
  5. Communication: Inform stakeholders (internal and external/customers, if necessary, as advised by Legal) that service has been fully restored.
Phase 5: Post-Incident Review (Lessons Learned)
  1. Document: Create a final, comprehensive report detailing:
    Incident timeline.
    Root cause analysis and contributing factors.
    Actions taken and their effectiveness.
    Data and financial impact.
    Final reports submitted to CERT-In or other regulators.
  2. Lessons Learned: Identify failures in the process, technology, or people that allowed the incident to occur or hindered the response.
  3. Policy Update: Propose and implement corrective actions (e.g., new monitoring rules, security architecture changes, revised playbooks).

Interested in joining our team?