1. Purpose
The Incident Timeline Template provides a structured record of events before, during, and after an information security incident.
A well-maintained timeline helps the investigation team establish:
- What happened
- When it happened
- Who or what was involved
- Which systems were affected
- How the incident progressed
- When the organisation detected the incident
- What response actions were taken
- Whether containment and recovery were successful
The timeline should be based on verified evidence wherever possible. Assumptions and unconfirmed events should be clearly identified.
2. Incident Information
| Field | Details |
|---|---|
| Incident ID | |
| Incident Title | |
| Incident Type | |
| Severity | Critical / High / Medium / Low |
| Date Detected | |
| Investigation Lead | |
| Incident Manager | |
| Business Owner | |
| Current Status | Open / Investigating / Contained / Recovering / Closed |
| Investigation Start | |
| Investigation End |
3. Timeline Status
Timeline Version:
Last Updated:
Prepared By:
Reviewed By:
Timezone:
Important: Record the timezone used for all timestamps. For distributed systems, also retain the original timestamp and source timezone where relevant.
4. Timeline Event Register
| Event ID | Date | Time | Event | Source | Actor/System | Evidence ID | Confidence | Investigator Notes |
|---|---|---|---|---|---|---|---|---|
| T-001 | Confirmed / Probable / Unknown | |||||||
| T-002 | ||||||||
| T-003 | ||||||||
| T-004 | ||||||||
| T-005 |
Recommended Event ID
Use a sequential identifier such as:
T-001, T-002, T-003…
This makes it easier to reference individual events in the investigation report.
5. Event Classification
Each timeline event should be classified where practical.
| Category | Description |
|---|---|
| Detection | First indication of suspicious activity |
| Initial Access | Suspected entry or compromise |
| Authentication | Login or identity-related activity |
| Privilege | Privilege escalation or role change |
| Persistence | Mechanism allowing continued access |
| Discovery | Attacker/system discovery activity |
| Lateral Movement | Movement between systems/accounts |
| Collection | Information gathered |
| Exfiltration | Information transferred externally |
| Impact | Disruption, modification, deletion, encryption, etc. |
| Containment | Action taken to stop the incident |
| Investigation | Investigation activity |
| Eradication | Removal of threat |
| Recovery | Restoration of systems/services |
| Communication | Internal/external communication |
| Decision | Management/legal/privacy decision |
| Monitoring | Post-recovery monitoring |
| Closure | Final closure activity |
6. Detailed Event Record
Use this section when an individual event requires additional detail.
Event ID
Date and Time
Event Type
Description
Describe exactly what occurred.
Source
☐ Cloud log
☐ Application log
☐ Endpoint log
☐ Authentication log
☐ Network log
☐ Email
☐ User report
☐ Security alert
☐ Ticket
☐ Supplier notification
☐ Customer notification
☐ Investigation finding
☐ Other
Source:
Actor / System
Affected Asset
Evidence Reference
Confidence
☐ Confirmed
☐ Probable
☐ Possible
☐ Unknown
Investigator Notes
7. Pre-Incident Timeline
Where possible, investigate activity occurring before the incident was detected.
| Date/Time | Event | Source | Evidence | Significance |
|---|---|---|---|---|
Look for:
- Previous failed login attempts
- Credential exposure
- Vulnerability exploitation
- Configuration changes
- Suspicious emails
- Unusual authentication
- New accounts
- Privilege changes
- Malware alerts
- Security control changes
- Unusual network activity
Earliest Known Suspicious Activity
Earliest Confirmed Compromise
Detection Gap
Estimated time between compromise and detection:
8. Initial Access
Document how the incident appears to have started.
| Date/Time | Activity | Identity/System | Evidence | Confirmed? |
|---|---|---|---|---|
Suspected Initial Access Method
☐ Phishing
☐ Stolen credentials
☐ Exposed API key
☐ Vulnerability exploitation
☐ Malware
☐ Misconfiguration
☐ Insider activity
☐ Supplier access
☐ Compromised SaaS account
☐ Cloud account compromise
☐ Unknown
☐ Other
Details:
9. Authentication and Identity Timeline
| Date/Time | Identity | Authentication Event | Source/IP | Device | Result | Evidence |
|---|---|---|---|---|---|---|
Investigate:
- Successful logins
- Failed logins
- MFA events
- Password changes
- Session creation
- Token use
- API key use
- Role assumption
- Privilege changes
- New account creation
- OAuth authorization
10. Privilege Escalation Timeline
| Date/Time | Identity | Previous Privilege | New Privilege | Action | Evidence |
|---|---|---|---|---|---|
Questions:
- Was additional privilege obtained?
- Was an administrator account compromised?
- Was a new role created?
- Was an existing policy modified?
- Was MFA disabled?
- Were security controls changed?
Findings:
11. System Activity Timeline
| Date/Time | System | Activity | User/Process | Result | Evidence |
|---|---|---|---|---|---|
Include relevant:
- Servers
- Databases
- Cloud resources
- Storage
- Applications
- Endpoints
- Network devices
- SaaS applications
- APIs
- CI/CD systems
- Source-code repositories
12. Lateral Movement Timeline
Document movement from the initially compromised system or identity to other resources.
| Date/Time | Source | Destination | Identity | Activity | Evidence |
|---|---|---|---|---|---|
Lateral Movement Confirmed?
☐ Yes
☐ No
☐ Possible
☐ Unable to determine
Findings:
13. Data Access / Exfiltration Timeline
| Date/Time | Information/System | Activity | Volume | Destination | Evidence |
|---|---|---|---|---|---|
Record:
- Data viewed
- Data downloaded
- Data modified
- Data deleted
- Data transferred
- Data disclosed
- Database queries
- Storage access
- API extraction
Data Exfiltration
☐ Confirmed
☐ Suspected
☐ Not identified
☐ Unable to determine
Details:
14. Impact Timeline
Record when the business or information systems were affected.
| Date/Time | System/Process | Impact | Duration | Evidence |
|---|---|---|---|---|
Potential impacts:
- Service outage
- Data loss
- Data corruption
- Data exposure
- Account compromise
- Customer impact
- Financial impact
- Regulatory impact
- Operational disruption
- Reputational impact
15. Detection Timeline
| Date/Time | Detection Event | Detection Source | Person/System | Evidence |
|---|---|---|---|---|
First Suspicious Indicator
First Confirmed Detection
First Human Report
Detection Delay
16. Response Timeline
Record each major response action.
| Date/Time | Response Action | Owner | System/Asset | Result | Evidence |
|---|---|---|---|---|---|
| Incident declared | |||||
| Account contained | |||||
| System isolated | |||||
| Credentials revoked | |||||
| Investigation started |
17. Containment Timeline
| Date/Time | Containment Action | Target | Owner | Result |
|---|---|---|---|---|
Examples:
- Disable account
- Revoke session
- Disable API key
- Isolate endpoint
- Block IP
- Restrict network access
- Disable compromised integration
- Isolate cloud resource
- Restrict IAM permissions
- Protect backup systems
Containment Achieved
Date/Time:
18. Evidence Preservation Timeline
| Date/Time | Evidence Preserved | Source | Preserved By | Location | Integrity Verified |
|---|---|---|---|---|---|
| Yes/No |
Record preservation of:
- Logs
- Disk images
- Memory captures
- Network records
- Cloud audit logs
- Configuration records
- Tickets
- Screenshots
- Alerts
- System snapshots
19. Eradication Timeline
| Date/Time | Eradication Action | Target | Owner | Result | Evidence |
|---|---|---|---|---|---|
Examples:
- Remove malware
- Remove unauthorized accounts
- Remove persistence
- Revoke credentials
- Rotate secrets
- Patch vulnerability
- Rebuild system
- Remove malicious code
- Correct configuration
- Remove unauthorized access
20. Recovery Timeline
| Date/Time | Recovery Action | System | Owner | Validation | Evidence |
|---|---|---|---|---|---|
Record:
- System restoration
- Data restoration
- Configuration restoration
- Credential recovery
- Application recovery
- Network recovery
- Security control restoration
- Monitoring restoration
- Business service validation
21. AWS Cloud Incident Timeline Example
For an AWS SaaS environment, the timeline could look like this:
| Time | Event | Source | Status |
|---|---|---|---|
| 09:12 | Developer access key used from unfamiliar IP | CloudTrail | Confirmed |
| 09:15 | S3 access activity observed | CloudTrail/S3 logs | Confirmed |
| 09:18 | Unusual API activity detected | Security monitoring | Confirmed |
| 09:22 | Security team notified | Incident ticket | Confirmed |
| 09:27 | Access key disabled | IAM | Confirmed |
| 09:31 | Active sessions reviewed/revoked | IAM | Confirmed |
| 09:45 | S3 access reviewed | CloudTrail | Confirmed |
| 10:10 | RDS and ECS activity investigated | CloudTrail/application logs | Confirmed |
| 10:40 | No additional persistence identified | Investigation | Confirmed |
| 11:15 | Credentials rotated | IAM/Secrets Manager | Confirmed |
| 12:00 | AWS configuration validated | AWS Config/security review | Confirmed |
| 14:00 | Investigation completed | Investigation report | Confirmed |
The actual timeline should always use the organisation’s available logs and evidence rather than this example.
22. Communication Timeline
Record important internal and external communications.
| Date/Time | Communication | Sender | Recipient | Purpose | Decision/Outcome |
|---|---|---|---|---|---|
Include, where applicable:
- Incident team notification
- Management notification
- Customer communication
- Supplier communication
- Legal advice
- Privacy assessment
- Regulatory communication
- Law enforcement communication
- Insurance notification
23. Decision Timeline
Important decisions should be recorded separately from technical events.
| Date/Time | Decision | Decision Maker | Reason/Evidence | Outcome |
|---|---|---|---|---|
Examples:
- Incident severity classification
- System isolation
- Customer notification
- Regulatory notification
- Service shutdown
- Credential rotation
- Disaster recovery activation
- Supplier escalation
24. Unknowns and Investigation Gaps
Not every event will be recoverable.
Document uncertainties rather than presenting assumptions as facts.
| Question | Status | Reason | Further Action |
|---|---|---|---|
| Unknown | |||
| Unknown |
Important Unknowns
Evidence That Was Unavailable
Investigation Limitations
25. Timeline Analysis
Earliest Known Suspicious Activity
Earliest Confirmed Compromise
Initial Access
First Detection
Containment
Eradication
Recovery
Final Verification
26. Key Time Metrics
| Metric | Time |
|---|---|
| Time to Detect (TTD) | |
| Time to Report | |
| Time to Respond (TTR) | |
| Time to Contain | |
| Time to Eradicate | |
| Time to Recover | |
| Total Incident Duration | |
| Estimated Dwell Time |
Definitions
Time to Detect:
Time between the relevant suspicious activity/compromise and detection.
Time to Respond:
Time between detection/reporting and initiation of the response.
Time to Contain:
Time between response initiation and effective containment.
Time to Recover:
Time between containment/eradication and restoration of verified business operations.
Dwell Time:
Estimated period during which an attacker or malicious activity remained undetected.
27. Timeline Integrity Review
Before finalising the timeline, verify:
☐ All timestamps use a documented timezone
☐ Important events have evidence references
☐ Logs were preserved where appropriate
☐ Duplicate events were removed or identified
☐ Clock differences were considered
☐ System-generated timestamps were distinguished from human reports
☐ Confirmed facts are separated from assumptions
☐ Unknown events are clearly identified
☐ Timeline covers pre-incident activity
☐ Initial access was investigated
☐ Detection was documented
☐ Containment was documented
☐ Eradication was documented
☐ Recovery was documented
☐ Communication and decisions were recorded
☐ Final verification was recorded
28. Final Timeline Summary
What Happened?
When Did It Start?
When Was It Detected?
How Was It Detected?
How Did the Incident Progress?
When Was It Contained?
When Was the Threat Removed?
When Was Recovery Completed?
What Evidence Supports the Timeline?
Remaining Unknowns
29. Timeline Approval
| Role | Name | Review | Date | Approval |
|---|---|---|---|---|
| Investigation Lead | ||||
| Incident Manager | ||||
| Security Owner | ||||
| Business Owner | ||||
| Management |
30. Audit Evidence Trail
A completed Incident Timeline should demonstrate:
Suspicious Activity
→ Initial Access
→ Compromise
→ Privilege/Access Activity
→ System Activity
→ Lateral Movement
→ Data/System Impact
→ Detection
→ Incident Reported
→ Response Activated
→ Evidence Preserved
→ Containment
→ Eradication
→ Recovery
→ Verification
→ Post-Incident Monitoring
→ Lessons Learned
→ Incident Closure
31. ISO 27001 Connection
The Incident Timeline supports the organisation’s incident management and investigation activities by providing evidence of the sequence of events, response actions, decisions, and outcomes.
It can also provide supporting evidence for activities related to:
- Incident management
- Event monitoring
- Logging
- Access control
- Privileged access
- Cloud security
- Vulnerability management
- Malware protection
- Backup and recovery
- Supplier incidents
- Data protection
- Business continuity
- Corrective action
- Information security risk management
The level of detail should be proportionate to the incident’s severity, business impact, information involved, and investigation requirements.
32. Startup Implementation Approach
For a startup, the timeline does not need to become a complex forensic report.
A simple incident can use:
Timestamp → Event → Evidence → Action → Owner
A major incident should additionally capture:
Initial Access → Identity → Privilege → Systems → Data → Lateral Movement → Detection → Containment → Eradication → Recovery → Communication → Decisions
The important principle is to make the timeline evidence-driven rather than assumption-driven.
Final Principle
Establish What Happened + Establish When It Happened + Link Events to Evidence + Separate Facts From Assumptions + Record Every Major Response Action + Verify the Final Outcome.