Incident Management and
Report Document

Cloud IT Security Incident Management Overview with Sample Incident Report

The goal of IT Security Incident Management is to get IT services back up and operating as quickly as possible. An IT Security Incident Management process should include automated detection and remediation tools, a clear workflow process, and detailed incident reports. IT Service Management (ITSM) has been around for a while but with the modern world of cloud computing, there are a few new tools that need to be incorporated.
For both cloud and on-prem environments, an IT Security Incident Report is a vital record that tracks the details of specific incident occurrences. It is used by software development, cybersecurity operations, cloud security, customer service, compliance and risk management organizations.
An effective incident report includes details, such as what happened, when it happened, the nature of the occurrence, the business impact, and so on. A clear and detailed incident report is a key resource to analyze problems, identify solutions, and improve service delivery. There is a sample blank incident report form at the end of this document that you can use as a resource.

Types of Incidents

Three distinct types of incidents occur in IT infrastructure — major incidents, repeated incidents, and complex incidents.
  • Major incidents: Large-scale incidents such as application failures, cyber attacks, and so on don’t happen very often. However, when they do, they can cause disruptions in businesses, which can have a significant impact on the business. Businesses must be ready to deal with major incidents swiftly and effectively.
  • Repetitive Incidents: Misconfiguring IT devices or applications can lead to a recurrence of incidents. Escalating and prioritizing the problem is the best way to deal with it. Such incidents may or may not have a significant impact, but they will accumulate and will require time to resolve.
  • Complex Incidents: The majority of the incidents that occur are of a medium or low severity, which are fairly simple to resolve. However, occasionally, a critical or high level incident will occur that requires an immediate response.
Incidents are often categorized based on severity, such as critical, high, medium, and low or L1, L2, L3. Severity ratings are connected to the overall business impact and urgency of the issue.

Automated Incident Response Tools

Deploy tools to automate and assist with detection, analysis, and remediation of security problems. For modern cloud environments these tools would include:
  • Cloud Security Posture Management (CSPM) to continuously detect misconfigurations and regulatory compliance issues
  • Cloud Workload Protection Platform (CWPP) to continuously monitor workloads for vulnerabilities, malware, etc.
  • Cloud Data Loss Prevention (DLP) and Data Security Posture Management (DSPM) to classify and protect confidential data
  • Network and traffic analysis with microsegmentation to limit the lateral movement of an attack or confidential data
  • Cloud-Native Application Protection Platform (CNAPP), a combination of CSPM and CWPP
  • Anti-malware, Extended Detection and Response (XDR), to detect threats and attacks
  • Security Information and Event Management (SIEM), to correlate security information and events from multiple sources
  • Security Orchestration, Automation, and Response (SOAR), to coordinate and execute tasks between people and tools
  • Firewall, intrusion prevention, and denial of service (DoS), to block attacks at the

Incident Management Workflow

Incident reporting and management is required and should be prioritized. It should be a well-organized approach for the organization to use to respond to non-compliance, system failures, incidents, accidents, cyber-attacks, outages, and breaches, among other things.
Be prepared before an incident occurs. Roles and responsibilities should be clearly defined based on skills and requirements. It must be clear who is responsible for what actions in the case of an incident. Employees need to be trained on the incident management workflow.
An incident management workflow should include:
  1. Identify the incident and assign severity based on impact and urgency
  2. Notify all impacted stakeholders
  3. Assigning tasks to the correct individuals
  4. Tracking the incident from detection to resolution and closure
  5. Escalation (if required) for breach of SLAs
  6. Generate reports and documentation for investigation and root cause analysis
  7. Resolution and remediation
  8. Closure
*Note: You should have a no-approval process for resolving incidents
Communication with stakeholders is essential. Stakeholders are not only members of the IT and Risk and Compliance organizations, stakeholders also include employees, customers, partners, and regulators. Regularly share announcements, notifications, and status updates as appropriate with all stakeholders. Do not rely solely on email, often this requires phone calls and meetings.

Essential Elements of an Incident Report

The person experiencing the problem or the team supporting related operations creates an incident report with input from others involved in resolving it.
A brief report is appropriate if the occurrence is minor and has little impact. However, if the incident is serious, all information must be recorded while preparing an extensive major incident report. The person creating the incident report uses input from others involved in resolving the incident.

Key information to include

  • Name of the individual who prepared the incident report
  • Correct date and time the incident was detected and resolved
  • Identification of which services were affected and/or unavailable
  • A concise and relevant description of the incident with the actual details
  • Whether or not any SLAs (service level agreements) were breached, and if the incident requires a penalty or escalation
  • Compliance requirements
  • Document all remediation actions and troubleshooting methods
  • Record any business impacting details including outages, investigations, publicity, customer remediation, regulatory, etc.

Incident Report DOs

  • Describe relevant issues in detail
  • Focus on the facts
  • Assume that the report will be made public (even if it is initially confidential)
  • Make sound professional decisions based on severity and business impact
  • Consider mitigating circumstances
  • Determine if the incident indicates a security breach has occurred
  • Developed a feasible remediation strategy
  • Understand your incident reporting policy and procedure
  • Use professional terms and write legibly
  • Include the names and addresses of any person (employees, contractors, partners, customers, etc.) who are aware of the situation

Incident Report DON’Ts

  • Speculate and assume without knowing the facts
  • Discuss previous similar occurrences
  • Talk about money, costs, and spending decisions
  • Discuss failures or delays in acting
  • Predict what will happen if nothing is done
  • Include insignificant facts that implicate or blame anyone for the occurrence

Sample Incident Report

Incident response teams should make an initial incident report and then continue to report updates and additional information to their Chain of Command/Security Specialist (as collected).
1. Contact
Full name
Job title
Division or office
Work phone
Mobile phone
Email address
Additional contact information:
2. Issue (check all that apply)
Account Compromise (lost password, suspicious account behavior,…) Social Engineering (phishing, scams)
Denial-of-Service (including distributed) Technical Vulnerability
Malware (virus, worm, trojan, crypto,…) Theft/Loss of equipment or media
Misuse of Systems (acceptable use) Unauthorized Access (cloud, systems, applications, storage, devices
Reconnaissance (scanning, probing) Data Exposure (public access, public share, breach of sensitive data)
Open Port Misconfigurations (exposed secrets, default passwords, risky settings,…
Description of incident:
3. Severity and Scope (check all that apply)
Critical (affects system-wide information resources)
High (entire network, cloud, or critical business systems)
Medium (affects infrastructure, network, cloud, servers, or admin accounts)
Low (only affects workstations or user accounts)
Unknown/Other (please describe below)
NOTE: All incidents deemed critical or high require additional notification by phone
Estimated quantity of assets affected
Estimated quantity of users affected
Third parties involved or affected (vendors, contractors, partners)
Additional information:
4. Impact (check all that apply)
Loss of Access to Services Propagation (other regions, segments, assets, partners, customers…)
Loss of Productivity Unauthorized Disclosure of Information
Loss of Reputation Unauthorized Modification of Information
Loss of Revenue Unknown/Other (please describe below)
Additional Impact Information:
5. Sensitivity of Affected Data/Information (check all that apply)
Critical Information Personally Identifiable Information (PII)
Non-Critical Information Intellectual/Copyrighted Information
Publicly Available Information Secrets (critical infrastructure/key resources)
Financial Information Protected Healthcare Information (PHI)
Payment Card Information (PCI) Unknown/Other (please describe below)
Data encrypted?
Location of data (bucket/blob, file, queue, attached volume, persistent volume, network segment)
Quantity of data affected (number of records, files, accounts, locations, assets…)
Additional affected data information:
6. Systems Affected (provide as much detail as possible)
Attack Sources (IP address, port,...)
Attack Destinations (IP address, port,…)
IP Addresses
Domain Names
Primary Functions of Affected Systems (web server, domain controller,…)
Operating Systems of Affected Systems (version, service pack, configuration,…)
Patch Level of Affected Systems (latest patches loaded, hotfixes,…)
Security Software on Affected Systems (anti-malware, firewall, versions, date of latest update,...)
Affected Systems/Assets (cloud platform, region, account, security group, asset ID,... )
Additional System Details:
7. Users Affected (provide as much detail as possible)
Names and Job Titles
System Access Levels or Rights of Affected Users (e.g., regular user, domain administrator, root)
Additional User Details:
8. Timeline (provide as much detail as possible)
Date and time when security officer first detected, discovered, or was notified about the incident
Date and time when the actual incident occurred (estimate if exact date and time unknow)
Date and time when the incident was contained or when all affected systems were restored (use most recent date and time)
Elapsed time between when the incident occurred and when it was discovered
Elapsed time between when the incident was discovered and the incident was contained or all affected systems were restored
Detailed Incident Timeline:
9. Remediation (provide as much detail as possible)
Actions taken to identify affected resources
Actions taken to remediate incident
Actions planned to prevent similar future incidents
Additional Remediation Details:

In Conclusion

Incidents happen and every incident is an opportunity to learn and improve. Don’t play the blame game, it must be safe for employees to report incidents when they are detected. You do not want team members hiding incidents to avoid negative repercussions. Clear documentation and a postmortem analysis of an incident is a valuable tool to improve team execution. If you always close out an incident with a review of what you have learned and how you can improve, you’ll perform better when faced with similar issues in the future.


Get easy-to-deploy, runtime visibility, protection, and compliance monitoring for cloud serverless, VM, and Kubernetes environments. Microsec.AI is the only agentless, data-centric, runtime cloud-native application protection platform (CNAPP) that protects your data and applications with data loss prevention (DLP), east-west network traffic control with self-healing micro segmentation, security posture management, and compliance analysis in one unified solution.