Disaster Recovery Plan Policy

Version1.0.3 Last Updated2024-01-31 APPROVED

1. Overview

AccuCode AI Inc. recognizes the importance of having a robust Disaster Recovery Plan (DRP) to ensure business continuity and minimize the impact of any disaster or major outage on our operations. This policy outlines the requirements for developing, implementing, and maintaining a comprehensive DRP.

2. Purpose

The purpose of this policy is to establish a baseline for creating and maintaining a DRP that describes the process to recover IT systems, applications, and data from any type of disaster causing a major outage. The DRP aims to minimize the impact of disasters on our business operations and protect the confidentiality, integrity, and availability of our clients’ data.

3. Scope

This policy applies to all IT management staff responsible for developing, testing, and updating the DRP. The policy focuses on the requirement to have a DRP and does not provide specific requirements for the content of the plan or its subplans.

4. Policy

4.1 Contingency Plans

The following contingency plans must be created as part of the DRP:

• Computer Emergency Response Plan: Outlines who to contact, when, and how, as well as the immediate actions to be taken in the event of certain occurrences.
• Succession Plan: Describes the flow of responsibility when normal staff is unavailable to perform their duties.
• Data Study: Details the data stored on the systems, its criticality, and its confidentiality.
• Criticality of Service List: Lists all the services provided and their order of importance, explaining the order of recovery in both short-term and long-term timeframes.
• Data Backup and Restoration Plan: Details which data is backed up, the media to which it is saved, where that media is stored, and how often the backup is done. It should also describe how that data can be recovered.
• Equipment Replacement Plan: Describes what equipment is required to begin providing services, lists the order in which it is necessary, and notes where to purchase the equipment.
• Mass Media Management: Identifies who is in charge of giving information to the mass media and provides guidelines on what data is appropriate to be provided.

4.2 Backup Security and Ransomware Prevention

All client data backups must be encrypted with the same strong, client-specific encryption used for data at rest. Backups should be retained for 180 days and securely destroyed thereafter. To protect against ransomware, AccuCode AI Inc. employs:

• Regular backups isolated from the main network and inaccessible to unauthorized users
• Immutable backups that cannot be altered or deleted once written
• Strict access controls and network segmentation to contain potential attacks
• Continuous monitoring for suspicious activity and prompt incident response
• Disaster Recovery and Business Continuity plans to ensure data availability and integrity

4.3 Testing and Updating the DRP

After creating the plans, it is important to practice them to the extent possible. Management should set aside time to test the implementation of the DRP. Table-top exercises should be conducted annually to discover and correct issues that may cause the plan to fail in an environment with few consequences. The DRP should be reviewed and updated on an annual basis at a minimum.

5. Policy Compliance

5.1 Compliance Measurement

The InfoSec team will verify compliance to this policy through various methods, including but not limited to, periodic walk-throughs, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner.

5.2 Exceptions

Any exception to the policy must be approved by the InfoSec team in advance.

5.3 Non-Compliance

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

Computer Emergency Response Plan

Version1.0.0 Last Updated2024-03-29 APPROVED

Purpose

The purpose of this Computer Emergency Response Plan is to outline the procedures and actions to be taken in the event of a computer emergency or security incident at AccuCode AI Inc. This plan is designed to minimize the impact of such incidents on the company’s operations, protect sensitive healthcare data, and ensure the timely restoration of critical systems and services.

Scope

This plan applies to all employees, contractors, and third-party vendors who have access to AccuCode AI Inc.’s computer systems, networks, and data.

Incident Reporting

In the event of a computer emergency or security incident, the following steps should be taken:

1. Immediately notify the InfoSec team by emailing security@accucodeai.com or calling the Engineering team lead.

2. Provide a detailed description of the incident, including the date and time it occurred, the systems and data affected, and any actions taken so far.

3. Do not attempt to investigate or resolve the incident on your own, as this may compromise the integrity of the investigation and recovery efforts.

Incident Response Team

The Incident Response Team (IRT) is responsible for managing and coordinating the response to computer emergencies and security incidents. The team consists of the following members:

• Chief Technology Officer (CTO)
• InfoSec Team Lead
• Legal Counsel

Incident Response Procedures

Upon receiving a report of a computer emergency or security incident, the IRT will:

1. Assess the severity and scope of the incident.
2. Contain the incident to prevent further damage or unauthorized access.
3. Investigate the incident to determine its cause and identify any compromised systems or data.
4. Develop and implement a recovery plan to restore affected systems and data.
5. Document the incident, including a timeline of events, actions taken, and lessons learned.
6. Notify relevant stakeholders, including management, legal counsel, and affected clients, as appropriate.

Incident Severity Levels

Incidents will be classified according to the following severity levels:

• Level 1 (Critical): Incidents that pose an immediate threat to the confidentiality, integrity, or availability of sensitive healthcare data or critical systems.
• Level 2 (High): Incidents that have the potential to cause significant damage or disruption to operations, but do not pose an immediate threat to sensitive data or critical systems.
• Level 3 (Medium): Incidents that have a limited impact on operations and do not pose a threat to sensitive data or critical systems.
• Level 4 (Low): Incidents that have minimal impact on operations and do not pose a threat to sensitive data or critical systems.

Incident Communication

During an incident, the IRT will provide regular updates to management and affected stakeholders via email, phone, or in-person meetings, as appropriate. The frequency and method of communication will depend on the severity of the incident and the needs of the stakeholders.

Post-Incident Review

After an incident has been resolved, the IRT will conduct a post-incident review to:

1. Evaluate the effectiveness of the incident response procedures.
2. Identify areas for improvement in the incident response plan and related policies and procedures.
3. Develop and implement any necessary changes to prevent similar incidents from occurring in the future.

Plan Maintenance

This Computer Emergency Response Plan will be reviewed and updated annually, or more frequently as needed, to ensure that it remains current and effective. All employees, contractors, and third-party vendors will be trained on the plan and their roles and responsibilities in the event of an incident.

Incident Response Plan Policy

Version1.0.3 Last Updated2023-10-16 APPROVED

1. Overview

The Incident Response Plan Policy provides a framework for the InfoSec team and business units at AccuCode AI Inc. to collaborate effectively in managing and responding to security incidents. This policy ensures that when a security vulnerability is identified or exploited, the organization can swiftly mitigate and remediate the issue. The Incident Response Plan (IRP) defines the product description, contact information, escalation paths, expected service level agreements (SLA), severity and impact classification, and mitigation/remediation timelines.

2. Purpose

The purpose of this policy is to establish the requirement for all business units supported by the InfoSec team to develop and maintain an Incident Response Plan. This ensures that the security incident management team has all the necessary information to formulate a successful response when a specific security incident occurs.

3. Scope

This policy applies to all established and defined business units or entities within AccuCode AI Inc.

4. Policy

The development, implementation, and execution of an Incident Response Plan (IRP) are the primary responsibility of the specific business unit for which the IRP is being developed, in cooperation with the InfoSec team. Business units are expected to properly facilitate the IRP for services or products they are accountable for. The business unit security coordinator or champion is further expected to work with the InfoSec team in the development and maintenance of the Incident Response Plan.

4.1 Service or Product Description

The product description in an IRP must clearly define the service or application to be deployed, with additional attention to data flows, logical diagrams, and architecture, which are considered highly useful.

4.2 Contact Information

The IRP must include contact information for dedicated team members to be available during non-business hours should an incident occur and escalation be required. This may be a 24/7 requirement depending on the defined business value of the service or product, coupled with the impact on customers. The IRP document must include all phone numbers and email addresses for the dedicated team member(s).

4.3 Triage

The IRP must define triage steps to be coordinated with the security incident management team in a cooperative manner with the intended goal of swift security vulnerability mitigation. This step typically includes validating the reported vulnerability or compromise.

4.4 Identified Mitigations and Testing

The IRP must include a defined process for identifying and testing mitigations prior to deployment. These details should include both short-term mitigations and the remediation process.

4.5 Mitigation and Remediation Timelines

The IRP must include levels of response to identified vulnerabilities that define the expected timelines for repair based on severity and impact to consumers, brand, and company. These response guidelines should be carefully mapped to the level of severity determined for the reported vulnerability.

5. Policy Compliance

5.1 Compliance Measurement

Each business unit must be able to demonstrate they have a written IRP in place, and that it is under version control and available via the web. The policy should be reviewed annually.

5.2 Exceptions

Any exception to this policy must be approved by the InfoSec team in advance and have a written record.

5.3 Non-Compliance

Any business unit found to have violated this policy (no IRP developed prior to service or product deployment) may be subject to delays in service or product release until such a time as the IRP is developed and approved. Responsible parties may be subject to disciplinary action, up to and including termination of employment, should a security incident occur in the absence of an IRP.