Incident Reporting Procedure
This section provides detailed steps to report a security incident to the relevant authorities (UIDAI, RBI, NABARD, and CERT-IN) within defined timelines.
4.1 Initial Notification
- Timeframe: The incident must be reported within 2 hours of detection.
- Incident Detection: Incidents may be detected through system alerts, user complaints, monitoring tools, or manual identification.
- Action: The Security Incident Response Team (SIRT) should immediately assess the incident and take the necessary actions for containment.
Initial Incident Report Template
- Incident ID: [Unique Identifier]
- Reported By: [Employee Name/Role]
- Date and Time of Incident Detection: [DD/MM/YYYY, HH:MM:SS]
- Nature of Incident: [Data Breach, Malware Attack, Unauthorized Access, etc.]
- Systems/Services Affected: [List of affected systems/services]
- Initial Containment Measures: [Details of any immediate containment actions taken]
4.2 Reporting to UIDAI, RBI, NABARD, and CERT-IN
Upon detecting a security incident, a detailed incident report should be submitted to the relevant authorities based on the following guidelines:
- UIDAI: Any incident involving Aadhaar data (biometric or demographic) must be reported to UIDAI via the UIDAI Data Security Incident Portal or through official communication channels.
- RBI/NABARD: Incidents that affect banking operations or involve financial transactions must be reported to RBI or NABARD as soon as possible.
- CERT-IN: Any cybersecurity incident that could affect the national security framework or critical infrastructure should be reported to CERT-IN.
Reporting Timeline
- UIDAI: 2 hours (initial) and 24 hours (detailed report).
- RBI and NABARD: 6 hours (if applicable, related to financial transactions).
- CERT-IN: 6 hours (if applicable, involving national security or critical systems).
Detailed Incident Report Submission
Timeframe: Within 24 hours after initial detection.
The report must include:
- Description of Incident: Nature of the breach, how it was detected, and affected systems.
- Scope of Incident: Specific data, users, and systems impacted.
- Containment Actions Taken: Immediate steps to contain the incident.
- Impact Analysis: Preliminary impact on Aadhaar data and business operations.
- Preliminary Root Cause Analysis: Initial findings on the cause of the incident.
4.3 Root Cause Analysis (RCA)
A detailed Root Cause Analysis (RCA) should be conducted to understand the underlying causes of the incident, assess its impact, and determine how the breach occurred. The RCA must be submitted to relevant authorities as part of the detailed incident report.
The RCA report must include:
- Cause(s) of Incident: System failure, human error, cyberattack, or external threats.
- Incident Timeline: Detailed account of the sequence of events from detection to resolution.
- Analysis of Impact: Data compromised, systems affected, and business disruptions.
4.4 Corrective and Preventive Measures
Corrective Measures: Actions taken to immediately resolve the incident and minimize damage. For example:
- System Isolation: Disconnect compromised systems to prevent further damage.
- Patch and Update: Apply patches to vulnerable systems.
- Access Revocation: Revoke compromised credentials or unauthorized access.
Preventive Measures: Long-term steps to prevent recurrence, including:
- Enhanced Monitoring: Implement more robust monitoring systems and intrusion detection systems (IDS).
- Employee Training: Increase awareness and training programs on data security and incident response.
- Access Control Review: Review and strengthen access control policies.
- Security Audits: Conduct regular audits and penetration testing of systems.
4.5 Post-Incident Review
Once the incident is resolved, a post-incident review meeting should be conducted to:
- Evaluate the incident response process.
- Identify gaps in the incident management process.
- Ensure that corrective and preventive measures are implemented and effective.
The review meeting should involve key stakeholders such as the Information Security Officer (ISO), Data Protection Officer (DPO), legal, and compliance teams.
4.6 Continuous Improvement
After each incident, the Security Incident Response Plan should be updated based on lessons learned and areas for improvement. This includes revising procedures, adding new security controls, and conducting additional employee training.