1. Purpose
The Incident Trend Report provides a periodic analysis of information-security incidents and significant security events to identify patterns, recurring weaknesses, emerging risks, response-performance trends, and opportunities for improvement.
The report should help management answer:
- What types of incidents are occurring?
- Are incidents increasing or decreasing?
- Which systems, teams, suppliers, or processes are most affected?
- Are incidents becoming more severe?
- Are incidents being detected quickly enough?
- Are recurring root causes being addressed?
- Are corrective actions effective?
- Are there emerging security risks?
- Where should additional controls or resources be considered?
The report should focus on trends and decisions, not simply provide a list of incidents.
2. Reporting Period
Reporting Period:
From: __________ To: __________
Report Date:
Prepared By:
Reviewed By:
Approved By:
Report Frequency:
Monthly / Quarterly / Annual / Other
3. Executive Summary
Provide a concise management-level summary.
Overall Incident Position
Key Changes From Previous Period
Significant Incidents
Emerging Trends
Major Control Concerns
Corrective Action Position
Management Attention Required
4. Incident Volume
Summarize the number of incidents during the reporting period.
| Metric | Current Period | Previous Period | Change |
|---|---|---|---|
| Total Security Incidents | |||
| SEV-1 | |||
| SEV-2 | |||
| SEV-3 | |||
| SEV-4 | |||
| Reopened Incidents | |||
| Customer-Impacting Incidents | |||
| Personal Data Incidents | |||
| Supplier Incidents | |||
| Cloud Incidents |
When comparing periods, consider whether changes are due to actual security activity, improved detection, reporting behavior, changes in business scale, or changes in classification.
5. Incident Trend Over Time
Track incident volume by month or other appropriate period.
| Month | Total | SEV-1 | SEV-2 | SEV-3 | SEV-4 |
|---|---|---|---|---|---|
| January | |||||
| February | |||||
| March | |||||
| April | |||||
| May | |||||
| June | |||||
| July | |||||
| August | |||||
| September | |||||
| October | |||||
| November | |||||
| December |
Trend Observation
Do not automatically interpret a higher number of reported incidents as deteriorating security. Increased reporting and improved detection can also increase recorded incident volume.
6. Incident Categories
Analyze incidents by type.
| Incident Type | Number | % of Total | Previous Period | Trend |
|---|---|---|---|---|
| Account Compromise | ||||
| Phishing | ||||
| Malware | ||||
| Ransomware | ||||
| Data Breach | ||||
| Cloud Compromise | ||||
| Unauthorized Access | ||||
| Vulnerability Exploitation | ||||
| Availability Incident | ||||
| Supplier Incident | ||||
| Insider Incident | ||||
| Application Security | ||||
| CI/CD Security | ||||
| Other |
7. Severity Trend
Review how the severity distribution is changing.
| Severity | Current Period | Previous Period | Change |
|---|---|---|---|
| SEV-1 Critical | |||
| SEV-2 High | |||
| SEV-3 Medium | |||
| SEV-4 Low |
Observation
Questions to consider:
- Are high-severity incidents increasing?
- Are low-severity events being converted into incidents more frequently?
- Are classification criteria being applied consistently?
- Are incidents becoming broader in scope?
- Are improved detection controls increasing the number of lower-severity reports?
8. Security Event to Incident Conversion
Review how reported security events are being classified.
| Classification | Number |
|---|---|
| CE-0 False Positive | |
| CE-1 Routine Security Event | |
| CE-2 Security Weakness | |
| CE-3 Suspected Incident | |
| CE-4 Confirmed Incident | |
| CE-5 Major/Critical Incident |
Conversion Metrics
Confirmed Incident Conversion Rate:
Confirmed Incidents ÷ Security Events
Escalation Rate:
Escalated Events ÷ Security Events
Observation
A change in conversion rate may indicate changes in detection quality, reporting behavior, threat activity, or classification practices.
9. Incident Source
Determine how incidents were identified.
| Detection Source | Number | % |
|---|---|---|
| Employee Report | ||
| Customer Report | ||
| Security Monitoring | ||
| SIEM | ||
| EDR | ||
| Cloud Security | ||
| Vulnerability Assessment | ||
| Penetration Test | ||
| Supplier Notification | ||
| Audit | ||
| Automated Alert | ||
| External Party | ||
| Other |
Key Observation
This can reveal whether the organization is primarily detecting incidents internally or learning about them from customers, suppliers, or external parties.
10. Detection Trend
Analyze how incidents are being detected.
Consider:
- Automated detection
- Employee reporting
- Customer reporting
- Security team detection
- Supplier notification
- External notification
Key Questions
- Are automated controls detecting more incidents?
- Are employees reporting suspicious activity?
- Are customers discovering issues before the organization?
- Are suppliers providing timely notifications?
- Are certain incident types consistently detected late?
Finding
11. Time to Detect
Measure the time between initial known malicious activity and detection.
| Incident ID | Initial Activity | Detection | Time to Detect |
|---|---|---|---|
Metrics
Average TTD:
Median TTD:
Longest TTD:
Where the initial activity time is unknown, record the limitation rather than creating an unsupported estimate.
12. Time to Respond
Measure the time between detection and meaningful response.
| Incident ID | Detection | Response Started | Time to Respond |
|---|---|---|---|
Metrics
Average Time to Respond:
Median Time to Respond:
13. Time to Contain
Measure the time from detection or response activation until the immediate threat is contained.
| Incident ID | Detection | Containment | Time to Contain |
|---|---|---|---|
Observation
14. Time to Recover
Measure the time required to restore affected services or systems.
| Incident ID | Containment | Recovery | Time to Recover |
|---|---|---|---|
Metrics
Average Recovery Time:
Median Recovery Time:
15. Customer Impact Trend
Analyze customer impact.
| Metric | Current Period | Previous Period |
|---|---|---|
| Customer-Impacting Incidents | ||
| Customers Affected | ||
| Customer Data Accessed | ||
| Customer Service Disruption | ||
| Customer Notifications | ||
| Contractual Notifications |
Observation
16. Data Security Trend
Review incidents involving information.
| Information Type | Incidents |
|---|---|
| Personal Data | |
| Financial Data | |
| Authentication Data | |
| Customer Confidential Information | |
| Source Code | |
| Intellectual Property | |
| Employee Information | |
| Regulated Information | |
| Internal Information |
Data Impact
17. Attack Vector Trend
Identify common initial attack methods.
| Attack Vector | Incidents | % | Trend |
|---|---|---|---|
| Phishing | |||
| Stolen Credentials | |||
| Vulnerability Exploitation | |||
| Misconfiguration | |||
| Exposed Service | |||
| Malicious File | |||
| Supplier Compromise | |||
| Insider Activity | |||
| API Abuse | |||
| Cloud Credential Exposure | |||
| Other |
Observation
18. Root Cause Trend
Analyze root causes identified through investigations and RCAs.
| Root Cause Category | Number | % | Recurring? |
|---|---|---|---|
| IAM / Access Control | |||
| Human / Awareness | |||
| Vulnerability | |||
| Configuration | |||
| Application Security | |||
| Monitoring | |||
| Process | |||
| Governance | |||
| Supplier | |||
| Change Management | |||
| Backup / Recovery | |||
| Other |
Key Finding
The most important trend may not be the number of incidents but the recurrence of the same underlying root cause.
19. Recurring Incident Analysis
Identify incidents with similar causes or characteristics.
| Incident Type | Previous Occurrences | Current Occurrences | Recurring Cause | Existing Action Effective? |
|---|---|---|---|---|
Recurring Issue
Recommended Action
Recurring incidents should trigger review of whether previous corrective actions actually addressed the root cause.
20. Control Failure Trend
Identify controls associated with incidents.
| Control Area | Incidents | Control Status | Observation |
|---|---|---|---|
| MFA | |||
| IAM | |||
| Privileged Access | |||
| Logging | |||
| Monitoring | |||
| Vulnerability Management | |||
| Secure Development | |||
| Backup | |||
| Supplier Security | |||
| Security Awareness | |||
| Change Management |
Control Trend
21. Cloud / AWS Incident Trend
For a SaaS company operating in AWS, track cloud-related incidents separately.
| Cloud Area | Incidents | Key Issue |
|---|---|---|
| IAM | ||
| S3 | ||
| EC2 | ||
| ECS/EKS | ||
| RDS | ||
| Lambda | ||
| Security Groups | ||
| Secrets | ||
| KMS | ||
| CI/CD | ||
| Network | ||
| CloudTrail | ||
| Monitoring |
AWS Trend Observation
Example:
Multiple cloud events involved excessive IAM permissions. The trend indicates a need to review privileged-access governance and role ownership rather than treating each event as an isolated incident.
22. Supplier Incident Trend
Analyze third-party incidents.
| Supplier | Incident Type | Severity | Business Impact | Root Cause | Corrective Action |
|---|---|---|---|---|---|
Review:
- Critical suppliers
- Cloud providers
- SaaS providers
- Subprocessors
- Technology suppliers
- Managed service providers
Supplier Trend
23. Incident Response Performance
Evaluate response effectiveness.
| Response Area | Current Period | Previous Period | Observation |
|---|---|---|---|
| Detection | |||
| Reporting | |||
| Classification | |||
| Escalation | |||
| Containment | |||
| Investigation | |||
| Evidence Preservation | |||
| Communication | |||
| Recovery | |||
| Closure |
24. Escalation Trend
Review how incidents were escalated.
| Severity | Correctly Escalated | Delayed | Incorrectly Escalated | Observation |
|---|---|---|---|---|
| SEV-1 | ||||
| SEV-2 | ||||
| SEV-3 | ||||
| SEV-4 |
Escalation Finding
25. Corrective Action Trend
Connect incidents with the Corrective Action Tracker.
| Metric | Current Period |
|---|---|
| Actions Created | |
| Actions Closed | |
| Actions Overdue | |
| High-Priority Actions | |
| Reopened Actions | |
| Actions With Failed Effectiveness | |
| Recurring Findings |
Key Question
Are corrective actions reducing recurrence?
Finding
26. Lessons Learned Trend
Review lessons generated by incidents.
| Category | Lessons Identified | Actions Created | Actions Closed |
|---|---|---|---|
| IAM | |||
| Cloud | |||
| Phishing | |||
| Monitoring | |||
| Incident Response | |||
| Supplier | |||
| Training |
Key Observation
27. Vulnerability-to-Incident Trend
Determine whether vulnerabilities are becoming incidents.
| Vulnerability Category | Vulnerabilities Identified | Exploited | Incidents | Trend |
|---|---|---|---|---|
| Critical | ||||
| High | ||||
| Medium | ||||
| Low |
Observation
This can help identify whether vulnerability-management priorities are aligned with actual security events.
28. Incident Concentration
Identify areas generating a disproportionate number of incidents.
By System
By Business Unit
By Application
By Supplier
By Technology
By Geographic/Operational Area
Concentration does not automatically mean that the area is insecure; higher incident counts can result from greater exposure, greater monitoring, or higher reporting activity.
29. Emerging Risks
Identify new or increasing patterns.
Potential indicators include:
- New attack vectors
- Increasing cloud attacks
- Increasing credential compromise
- Repeated vulnerabilities
- New supplier risks
- Increased customer impact
- New technology-related incidents
- AI-related security events
- CI/CD compromise
- API security incidents
- Increased data-access incidents
Emerging Risk 1
Emerging Risk 2
Emerging Risk 3
30. Significant Incident Review
Summarize significant incidents during the reporting period.
| Incident ID | Type | Severity | Impact | Root Cause | Corrective Action | Status |
|---|---|---|---|---|---|---|
For each significant incident, management should be able to trace:
Incident → Investigation → RCA → Lesson → Corrective Action → Risk → Improvement
31. Management Observations
Summarize the most important observations.
Observation 1
Observation 2
Observation 3
32. Recommended Improvements
Based on the trends, identify improvements.
| Improvement | Reason | Owner | Priority | Target Date |
|---|---|---|---|---|
Potential improvements:
- IAM controls
- MFA
- Monitoring
- Logging
- Vulnerability management
- Secure development
- Cloud security
- Supplier management
- Security awareness
- Incident response
- Backup/recovery
- Business continuity
- Security testing
33. Management Decisions Required
Identify decisions requiring management involvement.
| Decision | Reason | Risk | Recommendation/Options | Decision |
|---|---|---|---|---|
Examples:
- Additional security tooling
- Additional staffing
- Cloud security improvements
- Supplier change
- Risk treatment
- Risk acceptance
- Security training
- Additional testing
- Policy changes
- Business continuity investment
34. Management Review
Management should review:
- Incident volume
- Severity trends
- Recurring incidents
- Root-cause trends
- Control failures
- Detection performance
- Response performance
- Customer impact
- Supplier incidents
- Corrective-action status
- Emerging risks
- Resource requirements
Management Comments
Management Decision
Actions Approved
35. Recommended KPIs
Useful incident-management metrics include:
Incident Volume
Total incidents during reporting period
High-Severity Incident Rate
SEV-1 + SEV-2 incidents ÷ Total incidents
Time to Detect
Detection time − known initial activity time
Time to Respond
Response start − detection
Time to Contain
Containment − detection
Time to Recover
Recovery − detection/containment, according to the organization’s defined measurement method
Recurrence Rate
Recurring incident types ÷ Total incident types
Corrective Action Closure Rate
Closed incident actions ÷ Total incident actions
Effectiveness Rate
Corrective actions verified effective ÷ corrective actions tested
Metrics should be interpreted with context. For example, a reduction in incident volume may result from fewer incidents, reduced reporting, or reduced detection capability.
36. Report Limitations
Document limitations that could affect interpretation.
Examples:
- Incomplete historical data
- Newly implemented monitoring
- Changes in incident classification
- Changes in business size
- New cloud environment
- Missing timestamps
- Unknown initial attack time
- Supplier data unavailable
- Incomplete incident records
Limitations
37. ISO 27001 Alignment
An Incident Trend Report supports the ISMS by providing management with information about information-security events, incidents, control effectiveness, risks, and opportunities for improvement.
It can support:
- Incident management
- Monitoring and measurement
- Risk management
- Control effectiveness review
- Corrective action
- Management review
- Continual improvement
The specific report format and reporting frequency are organizational implementation choices. ISO/IEC 27001 does not prescribe a particular “Incident Trend Report.”
The organization should determine appropriate metrics and reporting frequency based on:
- Risk
- Business context
- Incident volume
- Customer requirements
- Regulatory obligations
- Security maturity
38. Recommended Reporting Cycle
A practical SaaS startup model is:
Continuous: Incident Register updated
↓
Monthly: Operational incident metrics reviewed
↓
Quarterly: Incident Trend Report prepared
↓
Quarterly: Management reviews trends and recurring risks
↓
As Required: Corrective actions and risk treatment updated
↓
Annually: Incident trends incorporated into broader ISMS review and security planning
39. Final Incident Trend Audit Trail
Incidents Recorded → Data Validated → Incidents Classified → Trends Analyzed → Root Causes Compared → Control Performance Reviewed → Recurring Issues Identified → Corrective Actions Reviewed → Emerging Risks Identified → Management Review → Decisions Recorded → Improvements Assigned → Effectiveness Monitored
Final Principle
Don’t Just Count Incidents — Understand the Pattern.
Collect Reliable Data + Analyze Trends + Identify Recurring Causes + Review Control Effectiveness + Measure Response + Identify Emerging Risks + Track Corrective Actions + Reassess Risk + Inform Management + Drive Continual Improvement.