6.1 The Importance of Incident Documentation
When a data breach occurs, documentation becomes critical for multiple purposes: regulatory compliance, legal defense, insurance claims, and organizational learning. Poor documentation can transform a manageable incident into a compliance disaster, while excellent documentation demonstrates due diligence and supports effective response.
Why Documentation Matters
- Regulatory Compliance: DPDPA requires notification to the Data Protection Board; documentation proves timely and adequate response
- Legal Defense: In litigation, documented response demonstrates reasonable security practices
- Insurance Claims: Cyber insurers require detailed documentation for claims processing
- Stakeholder Communication: Basis for notifications to affected individuals, partners, and investors
- Organizational Learning: Post-incident analysis drives security improvements
- Evidence Preservation: Proper documentation maintains chain of custody for potential prosecution
Under DPDPA Section 8(6), Data Fiduciaries must notify the Data Protection Board of personal data breaches in the prescribed form and manner. The Central Government will prescribe specific timelines and formats. Documentation must support: (1) timely notification, (2) scope determination, (3) mitigation measures, and (4) remediation actions.
Types of Incident Documentation
| Document Type | Purpose | Primary Audience | Timing |
| Initial Incident Report | Document discovery and initial assessment | Internal response team | Within hours of detection |
| Incident Timeline | Chronological record of events and actions | Legal, regulatory | Ongoing throughout response |
| Regulatory Notification | Comply with DPDPA notification requirements | Data Protection Board | Per prescribed timeline |
| Affected Party Notice | Inform Data Principals of breach | Individuals affected | Per DPDPA requirements |
| Post-Incident Report | Root cause analysis and lessons learned | Management, Board | After incident closure |
6.2 Initial Incident Report Templates
The initial incident report captures critical information at the moment of discovery. It forms the foundation for all subsequent documentation and decision-making. Speed and accuracy are equally important -- capture facts quickly while avoiding speculation.
INITIAL INCIDENT REPORT
CONFIDENTIAL - ATTORNEY-CLIENT PRIVILEGED
SECTION 1: INCIDENT IDENTIFICATION
Incident ID: [INC-YYYY-XXX]
Report Date/Time: [DD-MM-YYYY HH:MM IST]
Report Prepared By: [Name, Title]
Contact: [Phone, Email]
SECTION 2: DISCOVERY INFORMATION
Date/Time Discovered: [DD-MM-YYYY HH:MM IST]
Discovered By: [Name, Role, Department]
Method of Discovery:
[ ] Security monitoring/alert
[ ] User/employee report
[ ] Third-party notification
[ ] Regulatory inquiry
[ ] Other: [specify]
Initial Discovery Details:
[Factual description of what was observed/reported that indicated
a potential incident. Be specific about what triggered the discovery.]
SECTION 3: INITIAL ASSESSMENT
Incident Category (Preliminary):
[ ] Unauthorized access to systems
[ ] Unauthorized access to personal data
[ ] Malware/ransomware infection
[ ] Data exfiltration (suspected/confirmed)
[ ] Denial of service
[ ] Insider threat
[ ] Physical security breach
[ ] Third-party/vendor incident
[ ] Other: [specify]
Systems Potentially Affected:
[List systems, applications, databases identified so far]
Data Potentially Affected:
[ ] Personal data (DPDPA scope)
[ ] Sensitive personal data
[ ] Financial data
[ ] Health data
[ ] Business confidential
[ ] Customer data
[ ] Employee data
Estimated Number of Records: [Known / Unknown / Estimated range]
Estimated Individuals Affected: [Known / Unknown / Estimated range]
SECTION 4: IMMEDIATE ACTIONS TAKEN
[Document specific containment and initial response actions with timestamps]
Example:
- [HH:MM] Isolated affected server from network
- [HH:MM] Disabled compromised user accounts
- [HH:MM] Engaged forensic investigation team
- [HH:MM] Notified CISO and Legal
SECTION 5: ESCALATION
Incident Severity (Initial): [ ] Critical [ ] High [ ] Medium [ ] Low
Notifications Made:
| Role | Name | Time | Method |
|------|------|------|--------|
| CISO | [Name] | [HH:MM] | [Phone/Email] |
| Legal Counsel | [Name] | [HH:MM] | [Phone/Email] |
| CEO/Management | [Name] | [HH:MM] | [Phone/Email] |
| DPO | [Name] | [HH:MM] | [Phone/Email] |
SECTION 6: NEXT STEPS
[Immediate priorities for the next 24 hours]
1. Complete forensic preservation of affected systems
2. Determine scope and extent of data access/exfiltration
3. Identify root cause and attack vector
4. Assess regulatory notification obligations
SECTION 7: ATTACHMENTS
[ ] Security alert screenshots
[ ] System logs (preserved)
[ ] Network traffic captures
[ ] Other: [list]
Avoid speculation: Document facts, not theories ("Server X was accessed" not "Hackers stole data").
Privilege protection: Mark documents privileged and involve legal counsel early.
Timestamps: Use consistent timezone (IST) and 24-hour format.
Version control: Each update creates new version, preserving history.
6.3 Timeline Documentation
The incident timeline is the most important document for legal and regulatory purposes. It provides a chronological record of the incident and response, demonstrating when the organization knew what, and what actions were taken in response. A well-maintained timeline is essential for defending response decisions.
Timeline Best Practices
- Contemporaneous Recording: Document events as they happen, not from memory later
- Timestamp Everything: Date, time, timezone for every entry
- Cite Sources: Note how each fact was determined (log, interview, forensics)
- Separate Facts from Analysis: What happened vs. what it means
- Maintain Integrity: Use append-only format; corrections noted, not deleted
INCIDENT TIMELINE
Incident ID: [INC-YYYY-XXX]
Timeline Maintained By: [Name]
Last Updated: [DD-MM-YYYY HH:MM IST]
CONFIDENTIAL - ATTORNEY-CLIENT PRIVILEGED
PHASE 1: PRE-INCIDENT (Attacker Activity)
| Date/Time (IST) | Event | Source | Notes |
|-----------------|-------|--------|-------|
| [DD-MM HH:MM] | Initial compromise (phishing email opened) | Forensic analysis | User: [username] |
| [DD-MM HH:MM] | Malware installed on workstation | Endpoint logs | Hash: [malware hash] |
| [DD-MM HH:MM] | Lateral movement to server | Network logs | Source IP: [IP] |
| [DD-MM HH:MM] | Database access initiated | DB audit logs | Table: [table name] |
| [DD-MM HH:MM] | Data exfiltration began | Network analysis | ~[X] GB transferred |
PHASE 2: DETECTION AND INITIAL RESPONSE
| Date/Time (IST) | Event | Source | Owner |
|-----------------|-------|--------|-------|
| [DD-MM HH:MM] | SIEM alert generated | Security monitoring | SOC |
| [DD-MM HH:MM] | Alert triaged, incident declared | SOC notes | [Analyst name] |
| [DD-MM HH:MM] | CISO notified | Phone call log | [Name] |
| [DD-MM HH:MM] | Affected systems isolated | Change record | IT Ops |
| [DD-MM HH:MM] | Legal counsel engaged | Email record | [Firm/Name] |
| [DD-MM HH:MM] | Forensic firm engaged | Contract executed | [Firm name] |
PHASE 3: INVESTIGATION
| Date/Time (IST) | Event | Source | Findings |
|-----------------|-------|--------|----------|
| [DD-MM HH:MM] | Forensic image acquired | Forensic report | [X] systems imaged |
| [DD-MM HH:MM] | Scope determination: [X] records | Forensic analysis | Personal data confirmed |
| [DD-MM HH:MM] | Root cause identified | Forensic report | Unpatched vulnerability |
| [DD-MM HH:MM] | Exfiltration confirmed | Network forensics | [X] GB to [destination] |
PHASE 4: CONTAINMENT AND REMEDIATION
| Date/Time (IST) | Event | Source | Status |
|-----------------|-------|--------|--------|
| [DD-MM HH:MM] | Malware eradicated from all systems | IT confirmation | Complete |
| [DD-MM HH:MM] | Vulnerability patched | Change record | Complete |
| [DD-MM HH:MM] | All credentials reset | IAM logs | Complete |
| [DD-MM HH:MM] | Systems cleared for return to production | Security sign-off | Complete |
PHASE 5: NOTIFICATION AND CLOSURE
| Date/Time (IST) | Event | Source | Reference |
|-----------------|-------|--------|-----------|
| [DD-MM HH:MM] | DPB notification submitted | DPB portal | Ref: [number] |
| [DD-MM HH:MM] | Affected individuals notified | Email/postal | [X] notifications |
| [DD-MM HH:MM] | Post-incident review completed | Report | [Report ID] |
| [DD-MM HH:MM] | Incident closed | Management approval | [Approver] |
Timeline Visualization
Day 0 - 14:30
Initial Compromise
Phishing email opened, malware installed
Day 3 - 09:15
Detection
SIEM alert triggered, incident declared
Day 3 - 11:00
Containment
Affected systems isolated from network
Day 5 - 16:00
Scope Determined
50,000 records confirmed affected
Day 6 - 10:00
DPB Notification
Regulatory notification submitted
6.4 Regulatory Notification Drafts
Regulatory notification is a legal obligation under DPDPA. The notification must be accurate, complete, and timely. Errors or omissions can create additional liability. This section provides a template aligned with anticipated DPDPA requirements.
PERSONAL DATA BREACH NOTIFICATION
To: Data Protection Board of India
Date: [DD-MM-YYYY]
Reference: [Organization Reference Number]
1. DATA FIDUCIARY INFORMATION
Name: [Legal entity name]
Address: [Registered address]
SDF Registration (if applicable): [Registration number]
Contact Person: [Name, Title]
Contact Details: [Phone, Email]
DPO Contact: [Name, Email]
2. NATURE OF THE PERSONAL DATA BREACH
Type of Breach:
[ ] Confidentiality breach (unauthorized disclosure/access)
[ ] Integrity breach (unauthorized alteration)
[ ] Availability breach (loss of access)
Description:
[Clear, factual description of what occurred. Avoid speculation.
Include: How the breach occurred, what systems were affected, type of
attack/failure that led to the breach.]
Date/Time Breach Occurred: [DD-MM-YYYY HH:MM IST or "Unknown"]
Date/Time Breach Discovered: [DD-MM-YYYY HH:MM IST]
Date/Time Breach Contained: [DD-MM-YYYY HH:MM IST or "Ongoing"]
3. CATEGORIES OF PERSONAL DATA AFFECTED
[ ] Name, address, contact details
[ ] Identification numbers (Aadhaar, PAN, Passport)
[ ] Financial information (bank account, credit card)
[ ] Health information
[ ] Biometric data
[ ] Location data
[ ] Children's data (under 18)
[ ] Other: [specify]
4. CATEGORIES AND NUMBER OF DATA PRINCIPALS AFFECTED
Categories of Data Principals:
[ ] Customers
[ ] Employees
[ ] Vendors/Partners
[ ] Other: [specify]
Number of Data Principals Affected:
- Confirmed: [number]
- Estimated (if not yet confirmed): [range]
Geographic Scope: [States/regions, or "Pan-India"]
5. LIKELY CONSEQUENCES OF THE BREACH
[Assessment of potential harm to Data Principals, e.g.:
- Risk of identity theft or fraud
- Financial loss
- Reputational damage
- Physical safety concerns
- Other material harm]
Risk Level Assessment: [ ] High [ ] Medium [ ] Low
6. MEASURES TAKEN TO ADDRESS THE BREACH
Containment Measures:
[List specific actions taken to stop the breach and prevent further
unauthorized access, e.g., system isolation, credential reset,
vulnerability patching]
Mitigation Measures for Data Principals:
[Measures to reduce harm to affected individuals, e.g., credit
monitoring, identity protection services, enhanced authentication]
Preventive Measures:
[Steps being implemented to prevent recurrence, e.g., security
enhancements, policy changes, training]
7. NOTIFICATION TO DATA PRINCIPALS
Will Data Principals be notified directly? [ ] Yes [ ] No
If Yes:
- Method of notification: [Email, SMS, Postal, Website, etc.]
- Timeline for notification: [Date or "Within X days"]
- Content summary: [Brief description of what individuals will be told]
If No, reason: [Legal basis for not notifying]
8. ADDITIONAL INFORMATION
[Any other relevant information the Board should be aware of]
9. DECLARATION
I hereby declare that the information provided in this notification is
true and accurate to the best of my knowledge as of the date of this
notification. I understand that this notification may be updated as
additional information becomes available.
Signature: _______________________
Name: [Authorized signatory name]
Title: [Title]
Date: [DD-MM-YYYY]
Be factual, not defensive: Stick to facts, avoid spin or minimization.
Acknowledge uncertainty: "Investigation is ongoing" is better than false precision.
Update promptly: File supplemental notifications as new information emerges.
Coordinate messaging: Align regulatory notification with public statements.
Preserve privilege: Do not include privileged legal analysis in regulatory filings.
6.5 Post-Incident Analysis
The post-incident report transforms a painful experience into organizational learning. It documents root cause, evaluates response effectiveness, and recommends improvements. This document drives security maturity and demonstrates continuous improvement to regulators and stakeholders.
POST-INCIDENT ANALYSIS REPORT
Incident ID: [INC-YYYY-XXX]
Report Date: [DD-MM-YYYY]
Prepared By: [Name, Title]
Distribution: [Management, Board Audit Committee]
1. EXECUTIVE SUMMARY
[2-3 paragraph summary covering: what happened, impact, response
effectiveness, and key recommendations. Written for executive audience.]
2. INCIDENT OVERVIEW
Incident Type: [e.g., Ransomware attack, Data exfiltration]
Duration: [From initial compromise to full containment]
Discovery Time: [Time from compromise to detection]
Response Time: [Time from detection to containment]
Impact Summary:
- Data Principals Affected: [number]
- Records Compromised: [number]
- Systems Affected: [number]
- Downtime: [hours/days]
- Estimated Financial Impact: Rs. [amount]
3. ROOT CAUSE ANALYSIS
Primary Cause: [Technical root cause, e.g., unpatched vulnerability]
Contributing Factors:
- [Factor 1, e.g., Delayed patch management]
- [Factor 2, e.g., Insufficient network segmentation]
- [Factor 3, e.g., Lack of MFA on critical systems]
Attack Vector Analysis:
[Detailed technical description of how the attack progressed]
Why Existing Controls Failed:
[Analysis of why preventive and detective controls did not prevent
or detect the incident earlier]
4. RESPONSE EVALUATION
| Phase | Target Time | Actual Time | Assessment |
|-------|-------------|-------------|------------|
| Detection | [X hours] | [X hours] | [Met/Exceeded/Failed] |
| Escalation | [X hours] | [X hours] | [Met/Exceeded/Failed] |
| Containment | [X hours] | [X hours] | [Met/Exceeded/Failed] |
| Notification | [X hours] | [X hours] | [Met/Exceeded/Failed] |
| Eradication | [X days] | [X days] | [Met/Exceeded/Failed] |
| Recovery | [X days] | [X days] | [Met/Exceeded/Failed] |
What Worked Well:
- [Positive aspect 1]
- [Positive aspect 2]
What Needs Improvement:
- [Gap/issue 1]
- [Gap/issue 2]
5. LESSONS LEARNED AND RECOMMENDATIONS
| # | Finding | Recommendation | Priority | Owner | Deadline |
|---|---------|----------------|----------|-------|----------|
| 1 | [Finding] | [Recommendation] | Critical | [Name] | [Date] |
| 2 | [Finding] | [Recommendation] | High | [Name] | [Date] |
| 3 | [Finding] | [Recommendation] | Medium | [Name] | [Date] |
6. REGULATORY AND LEGAL STATUS
DPB Notification: [Submitted/Pending] - Reference: [number]
DPB Response: [None yet/Acknowledged/Under review]
Individual Notifications: [number] sent on [date]
Litigation: [None/Pending/Details]
Insurance Claim: [Filed/Pending/Amount]
7. SIGN-OFF
Report Reviewed By: [CISO, Legal, Management]
Recommendations Approved By: [Executive/Board]
Next Review Date: [Date for follow-up on recommendations]
"Every incident is an expensive lesson. The organization that documents thoroughly, analyzes honestly, and implements recommendations diligently transforms crisis into competitive advantage. Those that do not are doomed to repeat the lesson."
Adv. (Dr.) Prashant Mali