Security incident management policy

Last revision on February 10, 2023

1. Purpose

• The purpose of the incident management policy is to provide organization-wide guidance to employees on proper response to, and efficient and timely reporting of, computer security related incidents, such as computer viruses, unauthorized user activity, and suspected compromise of data. It also addresses non-IT incidents such as power failure. Further, this policy provides guidance regarding the need for developing and maintaining an incident management process within Random Team.

2. Scope

• This policy applies to all Employees, Contractors, and Third Party Employees, who use, process, and manage information from individual systems or servers.

3. Definition & Examples

• An incident is an event that violates Random Team Security Policy or that threatens the confidentiality, integrity or security of Random Team’s information systems or their data.

• Examples of incidents include:

• Data breaches

• Unauthorized use of a system

• Unauthorized use of the system as a gateway to other systems

• Unauthorized use of another user’s account

• Execution of malicious code that destroys data

4. Stages & process

Stage 1: Preparation

• Develop and review Random Team’s policies and procedures

• Train employees on Random Team’s policies and procedures

Stage 2: Detection & escalation

• Detection may be the result of:

• External detection (i.e.: by customers)

• Internal detection, using monitoring tools and other detection strategies, or identified by Random Team’s Employees.

• In any case, procedures should include emailing [e-mail], messaging #general on Slack to notify the security team, and if applicable creating a Jira ticket following the procedure. Behave as if you were reporting a crime and include lots of specific details about what you have discovered.

• Security Team should take ownership as incident is reported on company-wide channel.

• Customer Success Managers are responsible for keeping informed involved customers, relaying only Security Team approved information.

Stage 3: Containment

• Identify, isolate and/or mitigate risks associated with the incident

• Notify affected parties, create of safety plan (if applicable)

• Decide whether or not to investigate incident

• Preserve physical and/or digital evidence

Stage 4: Investigation

• Determine the incident’s priority, scope and root cause

• Collect physical and/or digital evidence

• Conduct interviews with complainants and/or persons involved

Stage 5: Remediation

• Repair affected systems

• Communicate to and instruct affected parties about next steps

• Confirm that the threat has been contained

• File formal reports as per regulatory requirements (notably in the context of GDPR)

• Create post-incident report

Stage 6: Recovery

• Analyze the incident for its procedural and policy implications

• Gather metrics

• Review and edit established policies and procedures with lessons learned from the incident

5. Testing

• This policy is periodically tested. After each test is identified what needs to be improved, and how the improvements can be implemented. Testing ensures that key teams are familiar with their assignments.

• The executive team is in charge with making sure the plan is up to date & regularly tested.