/
Compliance - Incident Report Policy & Template

Compliance - Incident Report Policy & Template

 

Incident overview

Postmortem owner

Incident

Related incidents

Priority

status:P1 / status:P2 / status:P3+

Affected services

Incident date

Incident duration

Incident response teams

Incident responders

 Executive summary

 

 Incident Evidence

. Application - cloudwatch

. Infarstructure - cloudtrail

. Network - WAF

 

Policy

The XStak pay team is responsible for responding to reports of incidents, compromises, and breaches computers, data, and network resources. The purpose of the Incident Response Plan is to establish procedures in accordance with applicable legal and regulatory requirements to address instances of unauthorized access.

The Incident Response Plan defines the policy, roles and responsibilities for the involved personnel when reacting to an information security threat. The primary emphasis of activities described within this plan is the return to a secure state as quickly as possible, while minimizing the adverse impact. Depending on the circumstances, the Information Technology Administrator (IT Administrator) may decide to modify or bypass one or more of the procedures outlined in this plan in response to a particular security incident, with the understanding that the IT Administrator will take all reasonable steps to investigate and resolve any security issues. The capture and preservation of incident relevant data (e.g., network flows, data on drives, access logs, etc.) is performed primarily for the purpose of problem determination and resolution, as well as classification of the incident. The team shall provide timely and appropriate notice to affected individuals and departments when there has been a security incident, a compromise, or a breach involving data, computers, or networks. The IT Administrator, Finance Department Director, and Administrator shall be responsible for reviewing breaches to determine whether notification is required, and directing responsible departments in complying with the notification obligation. All known or suspected security incidents must be reported to the IT Administrator.

 

Security Incident

Security Incident - A vulnerability which may compromise the security of resources has been discovered and is underway. Generally, this means a weakness in intrusion prevention has been found, an attempted exploit has taken place, or reconnaissance by a hacker has been thwarted. Examples include systematic unsuccessful attempts to gain entry, a PC or workstation infected with a virus, worm, Trojan, botnet, or other malware that has been discovered and removed.

Security Compromise – An escalation of a security incident where the attacker has gained control of a account, system, or device, and is leveraging that position to control and utilize compromised resources for the purpose of unauthorized acquisitions. At this point, it has been determined that data has not been compromised or stolen.

Security Breach – A confirmed, unauthorized acquisition, modification or destruction of private data has taken place. At this point, a breach has been forensically determined and evidence supports that data was compromised.

Private data - Data about individuals that is classified by law as private or confidential and is maintained in electronic format or medium. “Private data” means data classified as not public and available to the subject of the data, and "confidential data" means data classified as not public but not available to the subject of the data.

Unauthorized acquisition - For the purposes of this plan, this means that a person has obtained data without statutory authority or the consent of the individual who is the subject of the data, and with the intent to use the data for non-city purposes

Systematic unsuccessful attempts - continual probes, scans, or login attempts where the perpetrators obvious intent is to discover a vulnerability and inappropriately access and compromise that device.

 

 Postmortem report

Instructions

Report

Instructions

Report

 Leadup


List the sequence of events that led to the incident.

 Fault


Describe what didn't work as expected. If available, include relevant data visualizations.

 

 Impact


Describe how internal and external users were impacted during the incident. Include how many support cases were raised.

 

 Detection


Report when the team detected the incident and how they knew it was happening. Describe how the team could've improved time to detection.

 

 Response


Report who responded to the incident and describe what they did at what times. Include any delays or obstacles to responding.

 

 Recovery


Report how the user impact was mitigated and when the incident was deemed resolved. Describe how the team could've improved time to mitigation.

 

Five whys root cause identification


Run a 5-whys analysis to understand the true causes of the incident.

 

Related records


Check if any past incidents could've had the same root cause. Note what mitigation was attempted in those incidents and ask why this incident occurred again.

 

 Lessons learned


Describe what you learned, what went well, and how you can improve.

 

 

 Incident timeline

 

 Follow-up tasks

Issue

Owner

Action items

Documentation

Issue

Owner

Action items

Documentation