Purpose

This security incident response policy is intended to establish controls to ensure detection of security vulnerabilities and incidents, as well as quick reaction and response to security breaches. This document also provides implementing instructions for security incident response, to include definitions, procedures, responsibilities, and performance measures (metrics and reporting mechanisms).

Scope

This policy applies to all users of information systems within Breakout Learning Inc. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by Breakout Learning Inc (hereinafter referred to as “users”). This policy must be made readily available to all users.

Background

A key objective of Breakout Learning Inc’s Information Security Program is to focus on detecting information security weaknesses and vulnerabilities so that incidents and breaches can be prevented wherever possible. Breakout Learning Inc is committed to protecting its employees, customers, and partners from illegal or damaging actions taken by others, either knowingly or unknowingly. Despite this, incidents and data breaches are likely to happen; when they do, Breakout Learning Inc is committed to rapidly responding to them, which may include identifying, containing, investigating, resolving , and communicating information related to the breach.

This policy requires that all users report any perceived or actual information security vulnerability or incident as soon as possible using the contact mechanisms prescribed in this document. In addition, Breakout Learning Inc must employ automated scanning and reporting mechanisms that can be used to identify possible information security vulnerabilities and incidents. If a vulnerability is identified, it must be resolved within a set period of time based on its severity. If an incident is identified, it must be investigated within a set period of time based on its severity. If an incident is confirmed as a breach, a set procedure must be followed to contain, investigate, resolve, and communicate information to employees, customers, partners and other stakeholders.

Within this document, the following definitions apply:

• Information Security Vulnerability:

A vulnerability in an information system, information system security procedures, or administrative controls that could be exploited to gain unauthorized access to information or to disrupt critical processing.

• Information Security Incident:

A suspected, attempted, successful, or imminent threat of unauthorized access, use, disclosure, breach, modification, or destruction of information; interference with information technology

operations; or significant violation of information security policy.

• Information Security Event

An occurrence or change in the normal behavior of systems, networks or services that may impact security and organizational operations (e.g., possible compromise of policies or failure of controls).

Roles and Responsibilities

Chief Information Security Officer (CISO):

The CISO is responsible for the overall implementation and effectiveness of the Incident Response Plan. This includes ensuring that the plan is aligned with business objectives, compliance requirements, and industry best practices.

• Updating the Policy: The CISO is responsible for reviewing and updating the Incident Response Plan at least annually or as needed to reflect changes in the threat landscape, technology, or business operations.
• Reviewing the Policy: The CISO is responsible for conducting periodic reviews to assess the effectiveness of the Incident Response Plan, including testing the plan through simulations and exercises.
• Maintaining the Policy: The CISO ensures that the Incident Response Plan is properly maintained, and any updates are communicated to relevant stakeholders. The plan should be accessible to all users and regularly communicated to ensure awareness.

Policy

• All users must report any system vulnerability, incident, or event pointing to a possible incident to the Security Officer as quickly as possible but no later than 24 hours.
• Incidents must be reported by sending an email message with details of the incident.
• Users must be trained on the procedures for reporting information security incidents or discovered vulnerabilities, and their responsibilities to report such incidents. Failure to report information security incidents shall be considered to be a security violation and will be reported to HR for disciplinary action.
• Information and artifacts associated with security incidents (including but not limited to files, logs, and screen captures) must be preserved appropriately in the event that they need to be used as evidence of a crime.
• All information security incidents must be responded to through the incident management procedures defined below.

Periodic Evaluation

It is important to note that the processes surrounding security incident response should be periodically reviewed and evaluated for effectiveness. This also involves appropriate training of resources expected to respond to security incidents, as well as the training of the general population regarding Breakout Learning Inc's expectation for them, relative to security responsibilities. The incident response plan is tested annually.

Procedure For Establishing Incident Response System

• Define on-call schedules and assign an Information Security Manager (ISM) responsible for managing incident response procedures during each availability window.
• Define a notification channel to alert the on-call ISM of a potential security incident. Establish a company resource that includes up to date contact information for on-call ISM.
• Assign management sponsors from the Engineering, Legal, HR, Marketing, and C-Suite teams.
• Distribute Procedure For Executing Incident Response to all staff and ensure up-to-date versions are accessible in a dedicated company resource.
• Require all staff to complete training for Procedure For Executing Incident Response at least once per year.

Reporting Incidents

The following situations are to be considered for information security event reporting:

• Ineffective security control;
• Breach of information integrity, confidentiality or availability expectations;
• Human errors;
• Non-compliances with policies or guidelines;
• Breaches of physical security arrangements;
• Uncontrolled system changes;
• Malfunctions of software or hardware;
• Access violations; and,
• Malfunctions or other anomalous system behavior indicative of a security attack or actual security breach.

Reporting Incidents - Cloud Service

(For Cloud Service Customers) Breakout Learning Inc will acquire information from cloud service providers about the procedures for:

• Reporting a detected information security incident to the cloud service provider;
• Cloud service providers receiving reports concerning a detected information security incident;
• Monitoring the status of a reported information security incident.

Agreements between Breakout Learning Inc and cloud service providers will outline the processes for responding to requests for potential digital evidence or other information from within the cloud computing environment.

(For Cloud Service Providers) Breakout Learning Inc will establish mechanisms for:

• Its cloud service customers to report an information security;
• Breakout Learning Inc to report an information security incident to its cloud service customers;
• Its cloud service customers to track the progress of a reported information security incident.

Agreements between Breakout Learning Inc and its cloud service customers will outline the processes for responding to requests for potential digital evidence or other information from within the cloud

computing environment.

Procedure For Executing Incident Response

• When an information security incident is identified or detected, users must notify their immediate manager within 24 hours. The manager must immediately notify the ISM on call for proper response. The following information must be included as part of the notification:
  • Description of the incident
  • Date, time, and location of the incident
  • Person who discovered the incident
  • How the incident was discovered
  • Known evidence of the incident
  • Affected system(s)
• Within 48 hours of the incident being reported, the ISM shall conduct a preliminary investigation and risk assessment to review and confirm the details of the incident. If the incident is confirmed, the ISM must assess the impact to Breakout Learning Inc and assign a severity level, which will determine the level of remediation effort required:
  • High: the incident is potentially catastrophic to Breakout Learning Inc and/or disrupts Breakout Learning Inc’s day-to-day operations; a violation of legal, regulatory or contractual requirements is likely.
  • Medium: the incident will cause harm to one or more business units within Breakout Learning Inc and/or will cause delays to a business unit’s activities.
  • Low: the incident is a clear violation of organizational security policy, but will not substantively impact the business.
• The ISM, in consultation with management sponsors, shall determine appropriate incident response activities in order to contain and resolve incidents.
• The ISM must take all necessary steps to preserve forensic evidence (e.g. log information, files, images) for further investigation to determine if any malicious activity has taken place. The collection of evidence will be managed by appropriate members with proper understanding and training in forensic evidence collection. In the absence of such members, certified third-party professionals will be used. All such information must be preserved and provided to law enforcement if the incident is determined to be malicious.
• If the incident is deemed as High or Medium, the ISM must work with the VP Brand/Creative, General Counsel, and HR Manager to create and execute a communications plan that communicates the incident to users, the public, and others affected.
• The ISM must take all necessary steps to resolve the incident and recover information systems, data, and connectivity. All technical steps taken during an incident must be documented in Breakout Learning Inc’s incident log, and must contain the following:
  • Description of the incident
  • Incident severity level
  • Root cause (e.g. source address, website malware, vulnerability)
  • Evidence
  • Mitigations applied (e.g. patch, re-image)
  • Status (open, closed, archived)
  • Disclosures (parties to which the details of this incident were disclosed to, such as customers, vendors, law enforcement, etc.)
• After an incident has been resolved, the ISM must conduct a post-mortem that includes root cause analysis and documentation of any lessons learned.
  • In the event that the incident involves the breach of sensitive privacy data (e.g., PII), (1)

an assessment will also be conducted to determine the extent of harm, embarrassment, inconvenience, or unfairness to affected parties; (2) all affected parties and appropriate organizations (e.g., Law Enforcement) will be notified; and (3) every effort will be made to mitigate the harm to affected parties.

• Depending on the severity of the incident, the Chief Executive Officer (CEO) may elect to contact external authorities, including but not limited to law enforcement, private investigation firms, and government organizations as part of the response to the incident.
• The ISM must notify all users of the incident, conduct additional training if necessary, and present any lessons learned to prevent future occurrences. Where necessary, the HR Manager must take disciplinary action if a user’s activity is deemed as malicious.

APPENDIX A:

Security Incident Report Template

1. Last Name:
2. First Name:
3. Position:
4. Company/Org Name:
5. Telephone No:
6. E-mail:

1.0 Reported by

1. Name of organization:
2. Type of organization:
3. Street Address:

2.0 Organization Details

1. At this time, is it known that other organizations are affected by this incident? (If so, list names, addresses, telephone number, email addresses & contact persons):

3.0 Incident Details Including Injury and Impact Level

3.1 Date: ^3.2

Time:

1. Location of affected site:
2. Brief summary of the incident (what has happened, where did it happen, when did it happen):
3. Description of the project/program and information involved, and, if applicable, the name of the specific program:
4. Classification level of the information involved:
5. System compromise (detail):
6. Data compromise (detail):
7. Originator and /or Official Classification Authority of the information involved? (List name, address, telephone no., email and contact person).
8. Is Foreign Government Information involved? Originating country or International organization?
9. Did the incident occur on an accredited system authorized to process and store the information in question?
10. Estimated injury level/sector:
11. Estimated impact level: (any compromise or disruption to service?)
12. Incident duration:
13. Estimated number of systems affected:
14. Percentage of organization systems affected:
15. Action taken:
16. Supporting documents attached (describe if any)
17. Multiple occurrences or first time this type of incident occurs within this location?

3.0 Incident Details Including Injury and Impact Level

1. Incident Status (resolved or unresolved)
2. Has the matter been reported to other authorities? If so, list names, addresses, telephone no., email and contact person.

• Status of Mitigation Actions

1. Mitigation details to date: (List any actions that have been taken to mitigate incident and by whom)
2. Results of mitigation:
3. Additional assistance required?

• Computer Network Defense Incident Type (if applicable)

1. Malicious code (Worm, virus, trojan, backdoor, rootkit, etc.):
2. Known vulnerability exploit (List the Common Vulnerabilities and Exposures (CVE) number for known vulnerability):
3. Disruption of service:
4. Access violation (Unauthorized access attempt, successful unauthorized access, password cracking, Etc.):
5. Accident or error (Equipment failure, operator error, user error, natural or accidental causes):
6. If the incident resulted from user error or malfeasance, reasons (training, disregard for policy, other) and responsible parties:
7. Additional details:

5.8. Apparent Origin of Incident or Attack:

Source IP and port: URL:

Protocol: Malware: Additional details:

• Systems Affected

1. Network zone affected (Internet, administration, internal, etc.):
2. Type of system affected (File server, Web server, mail server, database, workstation (mobile or desktop), etc.):
3. Operating system (specify version):
4. Protocols or services:
5. Application (specify version):

• Post Incident Activities

1. Has information contained in this report been provided to the authorities? When?
2. Complete a root cause analysis to determine the reason for the incident and steps to prevent re- occurrence.

Revision History