Incident Response Policy

1.0 OVERVIEW

NEO has established a dedicated Computer Security Incident Response Team (CSIRT) which consists of representatives from IT, Security, Internal Audit/Compliance, Finance, and our Third-Party Cybersecurity insurance vendor.

2.0 PURPOSE & BACKGROUND

The purpose of the Incident Response policy is to provide a framework to manage a cybersecurity event, or incident that limits damage, and increases the confidence of external stakeholders and reduces recovery time and costs. In addition, the policy provides company-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.

1. 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.
2. This document also provides implementing instructions for security incident response, to include definitions, procedures, responsibilities, and performance measures (metrics and reporting mechanisms).
3. This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by the organization (hereinafter referred to as “users”). This policy must be made readily available to all users.

A key objective of the organization’s Information Security Program is to focus on detecting information security weaknesses and vulnerabilities so that incidents and breaches can be prevented wherever possible. The organization 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, the organization 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, the organization 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:

i. 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.

ii. 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.

3.0 ELIGIBILITY

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

4.0 POLICY

The Incident Response Policy is a guide to considerations during or after an event, and focuses on key milestones as recommended in the NIST cybersecurity guide. All problems that escalate into an Incident have an associated Help Desk (JIRA) ticket for post-incident Root Cause Analysis (RCA). All Incidents are tracked through resolution.

Threats that NEO

could face include:

• Loss of PII
• Data corruption
• DDoS attack
• Network intrusion
• Customer account intrusion
• Malware infection

Recognize and Respond

• Assess the situation quickly and effectively
• Notify the appropriate individuals and departments about the incident
• Organize the company’s response activities
• Escalate the company’s response efforts based on the severity of the incident

Plan and Remember

• Incidents are detected as soon as possible and properly reported.
• Incidents are handled by appropriate authorized personnel with ‘skilled’ backup as required.
• Incidents are properly recorded and documented.
• All evidence is gathered, recorded and maintained in Help Desk Ticket that will withstand

Internal and External Scrutiny.

• The full extent and implications relating to an incident are understood.
• Incidents are dealt with in a timely manner and service(s) restored as soon as possible.
• Any weaknesses in procedures or policies are identified and addressed.
• All incidents shall be analyzed and reported to the designated officer(s).
• Lessons-learned from the incidents is recorded.

#	Guidelines
1	Response processes and procedures are executed and maintained, to ensure timely response to detected cybersecurity events.
2	CSIRT Personnel know their roles and order of operations when a response is needed.
3	Response activities are coordinated with internal and external stakeholders, as appropriate, to include external support from law enforcement agencies.
4	Notifications from detection systems are analyzed and investigated to ensure adequate response and support.
5	The impact of the incident is understood and forensics are performed as required to determine root-cause.
6	Incidents are categorized consistent with the response plans.
7	Incidents are contained, threat eradicated, and mitigation/recovery are documented and communicated.
8	Voluntary information sharing occurs with external stakeholders to achieve broader cybersecurity situational awareness.
9	Incident Monitoring may involve the Disaster Recovery and Business Continuity teams.

• All users must report any system vulnerability, incident, or event pointing to a possible incident to the Information Security Manager (ISM) as quickly as possible but no later than 24 hours. Incidents must be reported by sending an email message or a Slack message to 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 the Human Resources (HR) Manager for disciplinary action.
• Information and artifacts associated with security incidents (including but not limited to files, logs, and screen captures) must be preserved 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.
• In order to appropriately plan and prepare for incidents, the organization must review incident response procedures at least once per year for currency, and update as required.
• The incident response procedure must be tested on at least twice per year
• The incident response logs must be reviewed once per month to assess response effectiveness.
• NEO will notify customers promptly in the event that NEO learns that a processor or subprocessor has processed customers’ Personal or Confidential data for any purpose other than those related to performance. Additionally, upon learning of any incident related to the unauthorized use or disclosure of customers’ Personal or Confidential data, NEO will open a JIRA ticket and fully investigate and document the incident pursuant to the Incident Response Policy.
• NEO will obtain approval from customer prior to issuing press releases or public notices involving customers’ Personal or Confidential Data unless expressed by law.
• The VP of Engineering must notify customers without undue delay upon becoming aware of a data breach or of a security vulnerability related to handling customers’ data.

5.0 ROLES & RESPONSIBILITIES

AWS: The Amazon Incident Management team employs industry-standard diagnostic procedures to drive resolution during business-impacting events. Staff operators provide 24x7x365 coverage to detect incidents and to manage the impact and resolution.

NEO: See below for NEO procedures.

5.1. Procedure For Establishing an Incident Response System

1. Define on-call schedule and assign an Information Security Manager (ISM) responsible for managing incident response procedure during each availability window.
2. 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.
   
   Communication channel:Use Slack communication channel #production-on-fire
   
3. Assign management sponsors from the Engineering, Legal, HR, Marketing, and C-Suite teams.
4. Distribute Procedure for Execute Incident Response to all staff and ensure up-to-date versions are accessible in a dedicated company resource.
5. Require all staff to complete training for Procedure For Executing Incident Response at least twice per year.

5.2. Procedure for Executing Incident Response

1. Incident Notification

• 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:
  1. Description of the incident.
  2. Date, time, and location of the incident.
  3. Person who discovered the incident.
  4. How the incident was discovered.
  5. Known evidence of the incident.
  6. Affected system(s).

2. Preliminary Investigation and Risk Assessment

• 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 on the organization and assign a severity level, which will determine the level of remediation effort required:Severity Levels:
  • High: The incident is potentially catastrophic to the organization and/or disrupts the organization’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 the organization 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.

3. Incident Response Activities

• The ISM, in consultation with management sponsors, shall determine appropriate incident response activities 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. 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 informs 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 the organization’s incident log and include the following:
  1. Description of the incident.
  2. Incident severity level.
  3. Root cause (e.g., source address, website malware, vulnerability).
  4. Evidence.
  5. Mitigations applied (e.g., patch, re-image).
  6. Status (open, closed, archived).
  7. Disclosures (parties to whom the details of this incident were disclosed, such as customers, vendors, law enforcement, etc.).

4. Post-Incident Actions

• After an incident has been resolved, the ISM must conduct a post-mortem that includes root cause analysis and documentation of any lessons learned.
• 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.
• The ISM must notify all users of the incident, conduct additional training if necessary, and present lessons learned to prevent future occurrences. Where necessary, the HR Manager must take disciplinary action if a user’s activity is deemed malicious.

6.0 EXTERNAL COMMUNICATION PROTOCOL

NEO is committed to responsibly managing and communicating risks and impacts to external stakeholders when necessary. The organization will evaluate risks based on predefined criteria and decide whether communication is required to mitigate harm, comply with regulations, or uphold stakeholder trust.

6.1 Criteria for External Communication

The decision to communicate risks and impacts externally will be based on:

• Legal or Regulatory Requirements – Compliance with regulations such as GDPR (72-hour breach notification), CCPA, or other applicable laws.
• Customer or Partner Impact – Direct or indirect harm to customer data, service availability, or trust.
• Reputational Risk – Potential for significant public or media interest.
• Severity of the Risk – High-priority risks identified in the organization’s Risk Assessment Policy.
• Mitigation Potential – Whether external communication can prevent further harm or enable corrective actions.

6.2 Decision-Making Process

1. Identification and Evaluation – Risks and impacts are identified by the Incident Response Team or Risk Assessment Team. Severity is assessed using the organization’s Risk Matrix.
2. Consultation – Input is sought from Legal, Compliance, and Executive Leadership.
3. Approval – The final decision is approved by the CISO or the Incident Response Coordinator in consultation with Legal and Executive Management.
4. Documentation – The rationale for the decision, criteria considered, and final action are documented in the incident report or risk log.

6.3 Communication Methods

• Customers: Secure emails or notifications via customer portals.
• Regulators: Official reports submitted within required timeframes.
• Media/Public: Press releases, social media, or other public communication channels as deemed appropriate.

6.4 Responsibilities

• Incident Response Team: Evaluates risks and drafts proposed communication plans.
• Legal and Compliance Teams: Ensure all communications meet regulatory and contractual obligations.
• Executive Leadership: Provides final approval for public or high-impact communications.

6.5 Exceptions

If the decision is made not to communicate risks externally, the rationale must be documented and reviewed annually during the ISMS internal audit process.

6.0 THREAT INTELLIGENCE

The Incident Response Team (IRT) uses threat intelligence from internal and external sources to proactively identify and respond to emerging threats. Threat intelligence feeds are integrated into the incident response process and are reviewed regularly to ensure timely and effective response.

7.0 CLOUD INCIDENTS

The IRT is prepared to respond to incidents affecting cloud infrastructure, including AWS. Procedures for cloud incident response are reviewed and tested regularly to ensure compliance with ISO 27001:2022.

7.0 COMPLIANCE

Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.