Acceptable Encryption Policy

Version1.0.2 Last Updated2023-11-29 APPROVED

1. Overview

The purpose of this policy is to provide guidance on the acceptable use of encryption technologies within AccuCode AI, Inc. to ensure the protection of sensitive data, compliance with Federal regulations, and adherence to industry best practices.

2. Purpose

The purpose of this policy is to limit the use of encryption to algorithms that have undergone substantial public review and have been proven to work effectively.

3. Scope

This policy applies to all employees of AccuCode AI, Inc.

4. Policy

4.1 Algorithm Requirements

• 4.1.1 Ciphers in use must meet or exceed the set defined as “AES-compatible” or “partially AES-compatible” according to the IETF/IRTF Cipher Catalog, or the set defined for use in the United States National Institute of Standards and Technology (NIST) publication FIPS 140-3, or any superseding documents according to the date of implementation. The use of the Advanced Encryption Standard (AES) with a minimum key size of 256 bits (AES256) is required for symmetric encryption.

• 4.1.2 Algorithms in use must meet the standards defined for use in NIST publication FIPS 140-3 or any superseding document, according to the date of implementation. The use of the RSA and Elliptic Curve Cryptography (ECC) algorithms is strongly recommended for asymmetric encryption.

• 4.1.3 Signature Algorithms:

  • ECDSA: P-256
  • RSA: 2048 bits minimum (Must use a secure padding scheme, such as PKCS#7)
  • LDWM: SHA256

4.2 Hash Function Requirements

AccuCode AI, Inc. adheres to the NIST Policy on Hash Functions.

4.3 Key Agreement and Authentication

• 4.3.1 Key exchanges must use one of the following cryptographic protocols: Diffie-Hellman, IKE, or Elliptic curve Diffie-Hellman (ECDH).

• 4.3.2 End points must be authenticated prior to the exchange or derivation of session keys.

• 4.3.3 Public keys used to establish trust must be authenticated prior to use. Examples of authentication include transmission via cryptographically signed message or manual verification of the public key hash.

• 4.3.4 All servers used for authentication (for example, RADIUS or TACACS) must have installed a valid certificate signed by a known trusted provider.

• 4.3.5 All servers and applications using SSL or TLS must have the certificates signed by a known, trusted provider.

4.4 Key Generation

• 4.4.1 Cryptographic keys must be generated using hardware-based random number generators (RNGs) and stored securely in key vaults to prevent loss, theft, or compromise.

• 4.4.2 Key generation must be seeded from an industry-standard random number generator (RNG) that complies with NIST Annex C: Approved Random Number Generators for FIPS PUB 140-3.

• 4.4.3 Key rotation must be performed regularly, with the frequency determined by the sensitivity of the data and the criticality of the system.

5. Policy Compliance

5.1 Compliance Measurement

The InfoSec team will verify compliance to this policy through various methods, including but not limited to, 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.

6. Related Standards, Policies, and Processes

• National Institute of Standards and Technology (NIST) publication FIPS 140-3
• NIST Policy on Hash Functions

Data Breach Response Policy

Version1.0.1 Last Updated2023-12-12 APPROVED

1. Introduction

AccuCode AI Inc. is committed to protecting the privacy and security of the personal and sensitive information it collects, processes, and stores. This Data Breach Response Policy establishes the goals and procedures for responding to data breaches involving protected health information (PHI) and personally identifiable information (PII).

2. Scope

This Policy applies to all employees, contractors, and third-party partners of AccuCode AI who have access to PHI or PII in the course of their duties.

3. Definitions

• Data Breach: An unauthorized acquisition of computerized data that compromises the security, confidentiality, or integrity of PII maintained by the Company.
• Personally Identifiable Information (PII): An individual’s first name, or first initial and his or her last name, in combination with any one or more of the following data elements when either the name or the data element is not encrypted or redacted:
  • Social Security number;
  • Driver’s license number or state identification card number;
  • Account number, credit card number, or debit card number in combination with any required security code, access code, or password that would permit access to an individual’s financial account;
  • Medical information (any individually identifiable information, in electronic or physical form, regarding the individual’s medical history or medical treatment or diagnosis by a health care professional);
  • Biometric data (data generated by automatic measurements of an individual’s biological characteristics) and any other unique biological characteristics of an individual if used to uniquely authenticate the individual’s identity for access to a system of account.

4. Roles and Responsibilities

• Information Security Officer (ISO): Responsible for overseeing the implementation of this Policy and ensuring compliance with applicable laws and regulations.
• Incident Response Team (IRT): Responsible for investigating and responding to data breaches, as directed by the ISO. The IRT shall include representatives from Legal, IT, Human Resources, and other departments as necessary.
• All Employees: Responsible for immediately reporting any suspected data breaches to the ISO or IRT.

5. Incident Response Procedures

1. Identification: Any employee who becomes aware of a potential data breach must immediately notify the ISO or IRT.
2. Investigation: The IRT will promptly investigate the reported incident to determine whether a data breach has occurred and the scope of the breach.
3. Containment: If a data breach is confirmed, the IRT will take immediate steps to contain the breach and prevent further unauthorized access or disclosure.
4. Notification: The ISO will notify affected individuals, clients, and regulatory authorities as required by applicable laws and regulations.
   • Notification to affected Arkansas residents shall be made in the most expedient time and manner possible and without unreasonable delay, subject to any measures necessary to determine the scope of the breach and to restore the reasonable integrity of the data system.
   • Notification is not required if after a reasonable investigation the Company determines there is no reasonable likelihood of harm to consumers.
   • If the affected class of persons to be notified exceeds 1,000, the Company must disclose the breach to the Attorney General at the same time it notifies the affected class, or 45 days after it determines there is a reasonable likelihood of harm to individuals, whichever is first.
5. Remediation: The IRT will work with IT and other departments to identify and address any vulnerabilities that contributed to the breach.
6. Documentation: The ISO will document the incident, including the response actions taken and any remediation measures implemented. The Company must retain a copy of the determination of the breach and any supporting documentation for five years from the date the breach was determined.

6. Training and Awareness

All employees will receive regular training on data privacy and security best practices, as well as their responsibilities under this Policy. The ISO will ensure that the Policy is widely communicated and easily accessible to all personnel.

7. Policy Review and Update

This Policy will be reviewed and updated annually, or more frequently as needed, to ensure it remains effective and compliant with applicable laws and regulations.

8. Enforcement

Violations of this Policy may result in disciplinary action, up to and including termination of employment or contract. AccuCode AI, Inc. reserves the right to report violations to appropriate law enforcement authorities.

By implementing this Data Breach Response Policy, AccuCode AI Inc. demonstrates its commitment to protecting the privacy and security of the sensitive information entrusted to it, and to responding promptly and effectively to any data breaches that may occur in compliance with Arkansas law.

Database Credentials Policy

Version1.0.1 Last Updated2023-11-01 APPROVED

Purpose

This policy establishes the requirements for securely storing and managing database credentials used by applications and systems to access AccuCode AI’s production databases containing sensitive healthcare information, including Protected Health Information (PHI). Proper credential management is critical to prevent unauthorized access to databases that could lead to data breaches.

Scope

This policy applies to all employees, contractors, and third-parties responsible for developing and maintaining applications and systems that connect to AccuCode AI’s production databases. It covers all databases used to store sensitive data, including but not limited to patient records, billing information, and analytics data.

Policy Statements

1. Credential Storage

   • Database credentials must never be hard-coded or stored in clear text in application source code, configuration files, or repositories.
   • Credentials must be stored securely using a password manager, secrets management system, or secure configuration management tool approved by the Security team.
   • Access to stored credentials must be strictly limited to authorized personnel on a need-to-know basis.

2. Credential Usage

   • Applications must only retrieve database credentials immediately prior to use and not store them in memory longer than necessary.
   • Memory containing credentials must be cleared immediately after use.
   • Credentials must never be logged, exposed in error messages, or transmitted over the network in an unencrypted format.

3. Credential Uniqueness

   • Each application, service or script must use its own unique database credentials. Sharing of credentials between applications is prohibited.
   • Database accounts must be created with the minimum privileges required for the application to function.

4. Credential Rotation

   • Database credentials must be rotated at least every 90 days, or more frequently for critical systems.
   • Credentials must also be rotated immediately in the event of a suspected compromise or personnel changes.

5. Encryption Requirements

   • Stored credentials must be encrypted using strong, industry-standard encryption algorithms (e.g. AES-256).
   • Encryption keys must be managed securely and access limited to authorized personnel.
   • Client-specific encryption keys must be used in the database to provide an additional layer of security. These keys should be stored in a secure key vault.

6. Logging and Monitoring

   • All access to databases must be logged and monitored for suspicious activity.
   • Failed login attempts must be logged and investigated.
   • Anomalous usage patterns (e.g. increased volume, off-hour access) must trigger alerts.

7. Third-Party Access

   • Third-party access to production databases is prohibited unless explicitly approved by the Security team.
   • Third-parties must adhere to all provisions of this policy when granted access.
   • Third-party accounts must be disabled immediately upon termination of the contract or services.

8. PHI Protection

   • Any PHI stored in databases must be isolated and encrypted at rest.
   • Databases containing PHI must not be directly exposed to the internet. Network segmentation must be used as a defense in depth strategy.

Enforcement

The InfoSec team will verify compliance with this policy through periodic audits and ongoing monitoring of database access logs. Employees found to have violated this policy may face disciplinary action up to and including termination. Violations by contractors or vendors may result in contract termination. Applications not adhering to this policy will not be approved for production use.

Exceptions

Any exceptions to this policy must be approved in advance by submitting a written request to the InfoSec team detailing the business justification, scope and duration of the exception. Exceptions will be granted on a case-by-case basis.

Review Cadence

This policy will be reviewed and updated annually or more frequently as needed to respond to changes in regulations, technology, and business practices.

End User Encryption Key Protection Policy

Version1.0.0 Last Updated2023-11-21 APPROVED

1. Overview

Encryption Key Management, if not done properly, can lead to compromise and disclosure of private keys used to secure sensitive data and hence, compromise of the data. While users may understand it’s important to encrypt certain documents and electronic communications, they may not be familiar with minimum standards for protecting encryption keys.

2. Purpose

This policy outlines the requirements for protecting encryption keys that are under the control of end users at AccuCode AI Inc. These requirements are designed to prevent unauthorized disclosure and subsequent fraudulent use. The protection methods outlined will include operational and technical controls, such as key backup procedures, encryption under a separate key, and use of tamper-resistant hardware.

3. Scope

This policy applies to any encryption keys used for business purposes and to protect data owned by AccuCode AI Inc. The public keys contained in digital certificates are specifically exempted from this policy.

4. Policy

All encryption keys covered by this policy must be protected to prevent their unauthorized disclosure and subsequent fraudulent use.

4.1 Secret Key Encryption Keys

Keys used for secret key encryption, also called symmetric cryptography, must be protected as they are distributed to all parties that will use them. During distribution, the symmetric encryption keys must be encrypted using a stronger algorithm with a key of the longest key length for that algorithm authorized in AccuCode AI’s Acceptable Encryption Policy.

Symmetric encryption keys, when at rest, must be protected with security measures at least as stringent as the measures used for distribution of that key.

4.2 Public Key Encryption Keys

Public key cryptography, or asymmetric cryptography, uses public-private key pairs. The public key is included in the digital certificate issued to the end user. The private key should only be available to the end user to whom the corresponding digital certificate is issued.

4.2.1 AccuCode AI’s Public Key Infrastructure (PKI) Keys

The public-private key pairs used by AccuCode AI’s public key infrastructure (PKI) are generated and managed using Microsoft Azure. The private key associated with any encryption certificates must be escrowed in compliance with policies.

4.2.2 Other Public Key Encryption Keys

If the keys are generated in software, the end user is required to create at least one backup of these keys and store any backup copies securely using a password manager protected by 2FA. The user is also required to create an escrow copy of any private keys used for encrypting data and deliver the escrow copy to the InfoSec team for secure storage in Azure Key Vault.

All backups, including escrow copies, shall be protected with a password or passphrase that is compliant with the Password Policy. InfoSec representatives will store and protect the escrowed keys as described in the Certificate Practice Statement Policy.

4.3 Hardware Token Storage

Hardware tokens storing encryption keys, such as YubiKeys, will be treated as sensitive company equipment when outside company offices. Hardware tokens will not be stored or left connected to any end user’s computer when not in use. For end users traveling with hardware tokens, they will not be stored or carried in the same container or bag as any computer.

4.4 Passwords and Passphrases

All passwords or passphrases used to protect encryption keys must meet complexity and length requirements described in AccuCode AI’s Password Policy.

4.5 Loss and Theft

The loss, theft, or potential unauthorized disclosure of any encryption key covered by this policy must be reported immediately to the InfoSec Team. InfoSec personnel will direct the end user in any actions that will be required regarding revocation of certificates or public-private key pairs.

5. Policy Compliance

5.1 Compliance Measurement

The InfoSec team will verify compliance to this policy through various methods, including but not limited to, 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.

HIPAA Workstation Security Policy

Version1.0.4 Last Updated2023-10-16 APPROVED

1. Purpose

The purpose of this policy is to provide guidance for workstation security for AccuCode AI Inc. workstations in order to ensure the security of information on the workstation and information the workstation may have access to. Additionally, the policy provides guidance to ensure the requirements of the HIPAA Security Rule “Workstation Security” Standard 164.310(c) are met.

2. Scope

This policy applies to all employees, contractors, workforce members, vendors and agents with an AccuCode AI Inc.-owned or personal-workstation connected to the AccuCode AI Inc. network.

3. Policy

Appropriate measures must be taken when using workstations to ensure the confidentiality, integrity and availability of sensitive information, including protected health information (PHI) and that access to sensitive information is restricted to authorized users.

3.1 Workforce Members

Workforce members using workstations shall consider the sensitivity of the information, including protected health information (PHI) that may be accessed and minimize the possibility of unauthorized access.

3.2 Physical and Technical Safeguards

AccuCode AI Inc. will implement physical and technical safeguards for all workstations that access electronic protected health information to restrict access to authorized users.

3.3 Appropriate Measures

Appropriate measures include:

1. Restricting physical access to workstations to only authorized personnel.
2. Securing workstations (screen lock or logout) prior to leaving area to prevent unauthorized access.
3. Enabling a password-protected screen saver with a short timeout period to ensure that workstations that were left unsecured will be protected. The password must comply with AccuCode AI Inc. Password Policy.
4. Complying with all applicable password policies and procedures. See Password Construction Guidelines for more details.
5. Ensuring workstations are used for authorized business purposes only.
6. Never installing unauthorized software on workstations.
7. Storing all sensitive information, including protected health information (PHI) on network servers.
8. Keeping food and drink away from workstations in order to avoid accidental spills.
9. Securing laptops that contain sensitive information by using cable locks or locking laptops up in drawers or cabinets.
10. Installing privacy screen filters or using other physical barriers to alleviate exposing data.
11. Ensuring workstations are left on but logged off in order to facilitate after-hours updates.
12. Exit running applications and close open documents.
13. Ensuring that all workstations use a surge protector (not just a power strip) or a UPS (battery backup).
14. If wireless network access is used, ensure access is secure by following the AccuCode AI Inc. Wireless Communication policy.

3.4 Remote Employees

Remote employees must adhere to the following additional measures:

1. Ensure the workstation is used in a private, secure location to prevent unauthorized access to sensitive information.
2. Use company-provided virtual private network (VPN) to securely access the AccuCode AI Inc. network and resources.
3. Avoid using public Wi-Fi networks. If necessary, use the company-provided VPN to ensure secure connection.
4. Ensure the workstation’s operating system, antivirus software, and other security software are up to date.
5. Report any security incidents or suspected breaches immediately to the InfoSec team.

4. Policy Compliance

4.1 Compliance Measurement

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

4.2 Exceptions

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

4.3 Non-Compliance

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

Removable Media Policy

Version1.0.0 Last Updated2024-01-29 APPROVED

1. Overview

Removable media is a well-known source of malware infections and has been directly tied to the loss of sensitive information in many organizations. AccuCode AI Inc. processes sensitive healthcare documents such as patient charts from hospitals and clinics, making it crucial to minimize the risk of data loss or exposure and reduce the risk of acquiring malware infections on company computers.

2. Purpose

The purpose of this policy is to minimize the risk of loss or exposure of sensitive information maintained by AccuCode AI Inc. and to reduce the risk of acquiring malware infections on computers operated by the company.

3. Scope

This policy covers all computers and servers operating in AccuCode AI Inc.

4. Policy

1. AccuCode AI Inc. staff may only use removable media in their work computers when strictly necessary for performing their assigned duties.
2. The use of removable media is discouraged, and staff should seek alternative methods for data transfer and storage whenever possible.
3. Removable media may not be connected to or used in computers that are not owned or leased by AccuCode AI Inc. without explicit permission from the InfoSec team.
4. Sensitive information should be stored on removable media only when required in the performance of assigned duties or when providing information required by other state or federal agencies.
5. When sensitive information is stored on removable media, it must be encrypted in accordance with the AccuCode AI Inc. Acceptable Encryption Policy.
6. Exceptions to this policy may be requested on a case-by-case basis through the AccuCode AI Inc. exception procedures.

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.