HIPAA Security Rule Control Guide
Who implements each HIPAA Security Rule standard and implementation specification in a tiCrypt deployment, how tiCrypt addresses it, and what the university still owns. CMMC Level 2 guide NIST SP 800-171 Rev 3 guide
Quoted from 45 CFR 164.308 to 164.316 in the eCFR, current as of November 10, 2026. This is the Security Rule as amended in 2013. The changes HHS proposed on January 6, 2025 (90 FR 898) have not been adopted and are not shown.
Encrypted ePHI is still ePHI, so the storage and backup locations that hold tiCrypt's ciphertext stay in scope. Each covered entity or business associate decides which addressable specifications are reasonable and appropriate for it.
One row per standard and implementation specification in 45 CFR 164.308 to 164.316. An answer inherited from a CMMC Level 2 practice names the practice and keeps its wording, which speaks of CUI; the same mechanism protects ePHI. Select a row to read it in full.
| Citation | Title | Responsibility | Requirement | How tiCrypt addresses it | University action | Type | CMMC L2 practices | SSP control card (800-53) | Learn more |
|---|---|---|---|---|---|---|---|---|---|
Security management process | Shared | Implement policies and procedures to prevent, detect, contain, and correct security violations. | SI.L2-3.14.7The audit system detects and alerts on unauthorized access, failed authentication, and privilege escalation.CA.L2-3.12.2Tera Insights helps draft POA&M items for platform controls, provides templated workflows, and handles platform-side remediation. | SI.L2-3.14.7Investigate alerts as part of your monitoring program.CA.L2-3.12.2Own and track the POA&M and report milestones to the C3PAO. | Standard | ||||
Risk analysis | University | Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate. | University control, not addressed by tiCrypt | Required | |||||
Risk management | Shared | Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with § 164.306(a). | RA.L2-3.11.2Tera Insights scans tiCrypt's own components, issues advisories, and coordinates authenticated access for your scans.RA.L2-3.11.3Tera Insights identifies, patches, and releases fixes for platform components on a regular cadence, with critical fixes released out of band.CA.L2-3.12.2Tera Insights helps draft POA&M items for platform controls, provides templated workflows, and handles platform-side remediation. | RA.L2-3.11.2Scan host operating systems, network infrastructure, and non-tiCrypt software in the CUI boundary, and remediate findings.RA.L2-3.11.3Schedule and apply platform updates; remediate host-level findings.CA.L2-3.12.2Own and track the POA&M and report milestones to the C3PAO. | Required | ||||
Sanction policy | University | Apply appropriate sanctions against workforce members who fail to comply with the security policies and procedures of the covered entity or business associate. | University control, not addressed by tiCrypt | Required | No CMMC Level 2 counterpart | ||||
Information system activity review | Shared | Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports. | AU.L2-3.3.3tiCrypt supplies the audit data, query tools, and real-time alerting; the logged event set is defined by the product.AU.L2-3.3.5The separate audit system (ClickHouse) correlates events across users, resources, event types, and time ranges, and can forward alerts to Splunk, email, or other SIEMs.AU.L2-3.3.6A query builder, predefined compliance reports, direct SQL access, and Excel export support reduction and reporting without altering original records. | AU.L2-3.3.3Set a review cadence, assign reviewers, investigate alerts, and periodically confirm the logged events still meet your needs.AU.L2-3.3.5Use the audit tools in your review process; set review cadence and alert routing. | Required | ||||
Assigned security responsibility | University | Identify the security official who is responsible for the development and implementation of the policies and procedures required by this subpart for the covered entity or business associate. | University control, not addressed by tiCrypt | Standard | No CMMC Level 2 counterpart | ||||
Workforce security | Shared | Implement policies and procedures to ensure that all members of its workforce have appropriate access to electronic protected health information, as provided under paragraph (a)(4) of this section, and to prevent those workforce members who do not have access under paragraph (a)(4) of this section from obtaining access to electronic protected health information. | AC.L2-3.1.1Every user authenticates with a unique RSA-2048 key pair plus password (signed challenge-response); there is no backdoor or shared access path. A user can open a resource only if its AES key has been re-encrypted to that user's public key. | AC.L2-3.1.1Run the account lifecycle: approve new accounts, assign teams and permission profiles, and remove users who no longer need access. | Standard | ||||
Authorization and/or supervision | Shared | Implement procedures for the authorization and/or supervision of workforce members who work with electronic protected health information or in locations where it might be accessed. | AC.L2-3.1.1Every user authenticates with a unique RSA-2048 key pair plus password (signed challenge-response); there is no backdoor or shared access path. A user can open a resource only if its AES key has been re-encrypted to that user's public key. | AC.L2-3.1.1Run the account lifecycle: approve new accounts, assign teams and permission profiles, and remove users who no longer need access. | Addressable | ||||
Workforce clearance procedure | University | Implement procedures to determine that the access of a workforce member to electronic protected health information is appropriate. | University control, not addressed by tiCrypt | Addressable | |||||
Termination procedures | Shared | Implement procedures for terminating access to electronic protected health information when the employment of, or other arrangement with, a workforce member ends or as required by determinations made as specified in paragraph (a)(3)(ii)(B) of this section. | AC.L2-3.1.1Every user authenticates with a unique RSA-2048 key pair plus password (signed challenge-response); there is no backdoor or shared access path. A user can open a resource only if its AES key has been re-encrypted to that user's public key. | AC.L2-3.1.1Run the account lifecycle: approve new accounts, assign teams and permission profiles, and remove users who no longer need access. | Addressable | ||||
Information access management | Shared | Implement policies and procedures for authorizing access to electronic protected health information that are consistent with the applicable requirements of subpart E of this part. | AC.L2-3.1.1Every user authenticates with a unique RSA-2048 key pair plus password (signed challenge-response); there is no backdoor or shared access path. A user can open a resource only if its AES key has been re-encrypted to that user's public key.AC.L2-3.1.2Permission profiles limit which actions each user can perform, with per-user overrides by administrators. Access is enforced cryptographically, so the server cannot extend access on an owner's behalf.AC.L2-3.1.5Profiles grant only the actions a user needs, and data access is limited to resources whose keys were shared with the user. | AC.L2-3.1.1Run the account lifecycle: approve new accounts, assign teams and permission profiles, and remove users who no longer need access.AC.L2-3.1.2Define permission profiles and assign them to users and teams.AC.L2-3.1.5Define least-privilege profiles and review privilege assignments periodically.Write the policies and procedures for authorizing access to ePHI, consistent with the Privacy Rule. | Standard | ||||
Isolating health care clearinghouse functions | University | If a health care clearinghouse is part of a larger organization, the clearinghouse must implement policies and procedures that protect the electronic protected health information of the clearinghouse from unauthorized access by the larger organization. | University control, not addressed by tiCrypt | Required | No CMMC Level 2 counterpart | ||||
Access authorization | Shared | Implement policies and procedures for granting access to electronic protected health information, for example, through access to a workstation, transaction, program, process, or other mechanism. | AC.L2-3.1.1Every user authenticates with a unique RSA-2048 key pair plus password (signed challenge-response); there is no backdoor or shared access path. A user can open a resource only if its AES key has been re-encrypted to that user's public key.AC.L2-3.1.2Permission profiles limit which actions each user can perform, with per-user overrides by administrators. Access is enforced cryptographically, so the server cannot extend access on an owner's behalf. | AC.L2-3.1.1Run the account lifecycle: approve new accounts, assign teams and permission profiles, and remove users who no longer need access.AC.L2-3.1.2Define permission profiles and assign them to users and teams.Write the policies and procedures for granting access. | Addressable | ||||
Access establishment and modification | Shared | Implement policies and procedures that, based upon the covered entity's or the business associate's access authorization policies, establish, document, review, and modify a user's right of access to a workstation, transaction, program, or process. | AC.L2-3.1.1Every user authenticates with a unique RSA-2048 key pair plus password (signed challenge-response); there is no backdoor or shared access path. A user can open a resource only if its AES key has been re-encrypted to that user's public key.AC.L2-3.1.5Profiles grant only the actions a user needs, and data access is limited to resources whose keys were shared with the user. | AC.L2-3.1.1Run the account lifecycle: approve new accounts, assign teams and permission profiles, and remove users who no longer need access.AC.L2-3.1.5Define least-privilege profiles and review privilege assignments periodically.Document each user's right of access and review it under your access authorization policy. | Addressable | ||||
Security awareness and training | University | Implement a security awareness and training program for all members of its workforce (including management). | University control, not addressed by tiCrypt | Standard | |||||
Security reminders | University | Periodic security updates. | University control, not addressed by tiCrypt | Addressable | |||||
Protection from malicious software | Shared | Procedures for guarding against, detecting, and reporting malicious software. | SI.L2-3.14.2Malicious-code protection is configured in the VM image. On Linux images with ClamAV installed and clamAVEnabled = true, the VM Controller starts ClamAV at startup and runs a recursive clamscan of each drive when it is attached, writing any infected files to the controller log, which the VM's managers can read. On Windows images the anti-virus product in the image notifies the user. VM images reset at boot, which removes persistent malware, and outbound traffic is denied by default.SI.L2-3.14.4The anti-virus product and its signatures are part of the VM image. The controller server delivers the latest VM images and VM Controller at every boot, with current patches, so an updated image reaches each VM at its next start.SI.L2-3.14.5On Linux images with ClamAV enabled, the VM Controller scans each drive when it is attached and starts ClamAV's on-access client, whose coverage is set by the ClamAV configuration in the image. Boot resets restore a known-good state each session, and chunk-level encryption blocks file injection. | SI.L2-3.14.2Build an anti-virus product into your VM images and enable it (for example ClamAV on Linux, Microsoft Defender on Windows). Keep its signatures current and schedule periodic scans.SI.L2-3.14.4Keep the anti-virus product in your VM images and its signatures current.SI.L2-3.14.5Configure on-access scanning in the anti-virus product in your images and schedule periodic scans.Write the procedures for guarding against, detecting and reporting malicious software, and train the workforce on them. | Addressable | ||||
Log-in monitoring | Shared | Procedures for monitoring log-in attempts and reporting discrepancies. | AC.L2-3.1.8Accounts lock after a configurable number of consecutive failed login attempts (default 5) and stay locked until an administrator releases them.SI.L2-3.14.7The audit system detects and alerts on unauthorized access, failed authentication, and privilege escalation. | AC.L2-3.1.8Set the lockout threshold (default 5).SI.L2-3.14.7Investigate alerts as part of your monitoring program.Write the procedures for monitoring log-in attempts and reporting discrepancies, and train the workforce on them. | Addressable | ||||
Password management | Shared | Procedures for creating, changing, and safeguarding passwords. | IA.L2-3.5.7Configurable password-strength rules apply at registration and on change, and passwords are screened against weak or compromised lists. The password only protects the user's local private key.IA.L2-3.5.8The password protects the private key on the user's device and is never sent to the server, so tiCrypt cannot compare a new password with earlier ones. Tera Insights requires MFA and split credentials for every production deployment. With them enabled, a password change regenerates the server-held salt and IV, so an earlier key file and the password that went with it stop working.IA.L2-3.5.10Passwords are never sent to or stored on the server. The private key is AES-256 encrypted client-side. Tera Insights requires MFA and split credentials for every production deployment. With them enabled, the server holds the key's salt and IV and returns them only after MFA succeeds, so neither side can recover the key alone. | IA.L2-3.5.7Define password composition rules.IA.L2-3.5.8Set the rule against reusing earlier passwords in your password policy and enforce it.IA.L2-3.5.10Keep MFA and split credentials enabled, and choose the MFA provider.Write the procedures for creating, changing and safeguarding passwords, and train the workforce on them. | Addressable | ||||
Security incident procedures | University | Implement policies and procedures to address security incidents. | University control, not addressed by tiCrypt | Standard | |||||
Response and reporting | Shared | Identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity or business associate; and document security incidents and their outcomes. | IR.L2-3.6.2Audit logs and real-time, severity-tiered alerts provide detection data and forensic evidence for investigations. | Identify and respond to suspected or known security incidents, mitigate their harmful effects as far as practicable, and document each incident and its outcome. The deadlines for notifying people of a breach are set by the Breach Notification Rule (45 CFR 164.400 to 164.414), not by this specification. | Required | ||||
Contingency plan | University | Establish (and implement as needed) policies and procedures for responding to an emergency or other occurrence (for example, fire, vandalism, system failure, and natural disaster) that damages systems that contain electronic protected health information. | University control, not addressed by tiCrypt | Standard | No CMMC Level 2 counterpart | ||||
Data backup plan | Shared | Establish and implement procedures to create and maintain retrievable exact copies of electronic protected health information. | MP.L2-3.8.9Backups of file and drive contents contain only ciphertext because no decryption keys are stored on the infrastructure. A backup of the platform database also holds unencrypted file and directory names. | MP.L2-3.8.9Keep backup and replica targets inside your assessment scope: encrypted CUI is still CUI (CMMC FAQ, July 2026, question B-Q8). A cloud target must meet FedRAMP Moderate or its equivalent (CMMC FAQ, July 2026, question E-Q2).Create, keep and test the backups with your own backup tools. tiCrypt does not make them. | Required | ||||
Disaster recovery plan | University | Establish (and implement as needed) procedures to restore any loss of data. | University control, not addressed by tiCrypt | Required | No CMMC Level 2 counterpart | ||||
Emergency mode operation plan | University | Establish (and implement as needed) procedures to enable continuation of critical business processes for protection of the security of electronic protected health information while operating in emergency mode. | University control, not addressed by tiCrypt | Required | No CMMC Level 2 counterpart | ||||
Testing and revision procedures | University | Implement procedures for periodic testing and revision of contingency plans. | University control, not addressed by tiCrypt | Addressable | No CMMC Level 2 counterpart | ||||
Applications and data criticality analysis | University | Assess the relative criticality of specific applications and data in support of other contingency plan components. | University control, not addressed by tiCrypt | Addressable | No CMMC Level 2 counterpart | ||||
Evaluation | Shared | Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and, subsequently, in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which a covered entity's or business associate's security policies and procedures meet the requirements of this subpart. | CA.L2-3.12.1Tera Insights supplies SSP templates, assessment evidence packages, and direct support during C3PAO assessments.CA.L2-3.12.3The audit system continuously records user actions and security events and raises real-time alerts, providing telemetry for ongoing monitoring. | CA.L2-3.12.1Coordinate the C3PAO engagement, provide evidence for university controls, and make sure the assessment covers the full CUI boundary.CA.L2-3.12.3Run your continuous-monitoring program using tiCrypt telemetry, including server health (CPU, memory, disk), which tiCrypt does not monitor. | Standard | ||||
Business associate contracts and other arrangements | University | A covered entity may permit a business associate to create, receive, maintain, or transmit electronic protected health information on the covered entity's behalf only if the covered entity obtains satisfactory assurances, in accordance with § 164.314(a), that the business associate will appropriately safeguard the information. A covered entity is not required to obtain such satisfactory assurances from a business associate that is a subcontractor. | tiCrypt does not address business associate contracts. Tera Insights supplies tiCrypt as software and has no access to a deployment, unless the organization sends it data or engages it to administer the deployment. | Decide which parties are business associates and hold the written contracts. If you send Tera Insights ePHI or engage it to administer the deployment, make that determination for Tera Insights as well. | Standard | No CMMC Level 2 counterpart | |||
Subcontractors of a business associate | University | A business associate may permit a business associate that is a subcontractor to create, receive, maintain, or transmit electronic protected health information on its behalf only if the business associate obtains satisfactory assurances, in accordance with § 164.314(a), that the subcontractor will appropriately safeguard the information. | tiCrypt does not address business associate contracts. Tera Insights supplies tiCrypt as software and has no access to a deployment, unless the organization sends it data or engages it to administer the deployment. | Decide which parties are business associates and hold the written contracts. If you send Tera Insights ePHI or engage it to administer the deployment, make that determination for Tera Insights as well. | Standard | No CMMC Level 2 counterpart | |||
Written contract or other arrangement | University | Document the satisfactory assurances required by paragraph (b)(1) or (b)(2) of this section through a written contract or other arrangement with the business associate that meets the applicable requirements of § 164.314(a). | tiCrypt does not address business associate contracts. Tera Insights supplies tiCrypt as software and has no access to a deployment, unless the organization sends it data or engages it to administer the deployment. | Decide which parties are business associates and hold the written contracts. If you send Tera Insights ePHI or engage it to administer the deployment, make that determination for Tera Insights as well. | Required | No CMMC Level 2 counterpart | |||
Facility access controls | University | Implement policies and procedures to limit physical access to its electronic information systems and the facility or facilities in which they are housed, while ensuring that properly authorized access is allowed. | University control, not addressed by tiCrypt | Standard | |||||
Contingency operations | University | Establish (and implement as needed) procedures that allow facility access in support of restoration of lost data under the disaster recovery plan and emergency mode operations plan in the event of an emergency. | University control, not addressed by tiCrypt | Addressable | No CMMC Level 2 counterpart | ||||
Facility security plan | University | Implement policies and procedures to safeguard the facility and the equipment therein from unauthorized physical access, tampering, and theft. | University control, not addressed by tiCrypt | Addressable | |||||
Access control and validation procedures | University | Implement procedures to control and validate a person's access to facilities based on their role or function, including visitor control, and control of access to software programs for testing and revision. | University control, not addressed by tiCrypt | Addressable | |||||
Maintenance records | University | Implement policies and procedures to document repairs and modifications to the physical components of a facility which are related to security (for example, hardware, walls, doors, and locks). | University control, not addressed by tiCrypt | Addressable | No CMMC Level 2 counterpart | ||||
Workstation use | University | Implement policies and procedures that specify the proper functions to be performed, the manner in which those functions are to be performed, and the physical attributes of the surroundings of a specific workstation or class of workstation that can access electronic protected health information. | University control, not addressed by tiCrypt | Standard | |||||
Workstation security | University | Implement physical safeguards for all workstations that access electronic protected health information, to restrict access to authorized users. | University control, not addressed by tiCrypt | Standard | |||||
Device and media controls | Shared | Implement policies and procedures that govern the receipt and removal of hardware and electronic media that contain electronic protected health information into and out of a facility, and the movement of these items within the facility. | MP.L2-3.8.1File and drive contents are AES-256 encrypted before they reach any media, and decryption keys are never stored on the infrastructure. The media hold that ciphertext plus the unencrypted metadata database (file and directory names).MP.L2-3.8.5All transfers are logged, and data in transit is encrypted end to end. | MP.L2-3.8.1Physically control and securely store the media (disks, backups) that hold the ciphertext.MP.L2-3.8.5Keep custody, accountability, and handling records for physical media transported outside controlled areas. | Standard | ||||
Disposal | Shared | Implement policies and procedures to address the final disposition of electronic protected health information, and/or the hardware or electronic media on which it is stored. | MP.L2-3.8.3Cryptographic erasure: destroying a resource's per-file or per-drive key makes the remaining ciphertext unrecoverable. | MP.L2-3.8.3Sanitize physical media and the unencrypted metadata database per NIST SP 800-88 before disposal or reuse, and make sure escrowed and backup key copies are destroyed. | Required | ||||
Media re-use | Shared | Implement procedures for removal of electronic protected health information from electronic media before the media are made available for re-use. | MP.L2-3.8.3Cryptographic erasure: destroying a resource's per-file or per-drive key makes the remaining ciphertext unrecoverable. | MP.L2-3.8.3Sanitize physical media and the unencrypted metadata database per NIST SP 800-88 before disposal or reuse, and make sure escrowed and backup key copies are destroyed. | Required | ||||
Accountability | Shared | Maintain a record of the movements of hardware and electronic media and any person responsible therefore. | MP.L2-3.8.5All transfers are logged, and data in transit is encrypted end to end. | MP.L2-3.8.5Keep custody, accountability, and handling records for physical media transported outside controlled areas. | Addressable | ||||
Data backup and storage | Shared | Create a retrievable, exact copy of electronic protected health information, when needed, before movement of equipment. | MP.L2-3.8.9Backups of file and drive contents contain only ciphertext because no decryption keys are stored on the infrastructure. A backup of the platform database also holds unencrypted file and directory names. | MP.L2-3.8.9Keep backup and replica targets inside your assessment scope: encrypted CUI is still CUI (CMMC FAQ, July 2026, question B-Q8). A cloud target must meet FedRAMP Moderate or its equivalent (CMMC FAQ, July 2026, question E-Q2).Make the copy with your own backup tools before the equipment is moved. tiCrypt does not make backups. | Addressable | ||||
Access control | tiCrypt | Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in § 164.308(a)(4). | AC.L2-3.1.1Every user authenticates with a unique RSA-2048 key pair plus password (signed challenge-response); there is no backdoor or shared access path. A user can open a resource only if its AES key has been re-encrypted to that user's public key.AC.L2-3.1.2Permission profiles limit which actions each user can perform, with per-user overrides by administrators. Access is enforced cryptographically, so the server cannot extend access on an owner's behalf.AC.L2-3.1.5Profiles grant only the actions a user needs, and data access is limited to resources whose keys were shared with the user. | AC.L2-3.1.1Run the account lifecycle: approve new accounts, assign teams and permission profiles, and remove users who no longer need access.AC.L2-3.1.2Define permission profiles and assign them to users and teams.AC.L2-3.1.5Define least-privilege profiles and review privilege assignments periodically. | Standard | ||||
Unique user identification | tiCrypt | Assign a unique name and/or number for identifying and tracking user identity. | IA.L2-3.5.1Each user has a unique RSA-2048 identity; processes and VMs are identified by UUIDs and digital signatures.IA.L2-3.5.5User identifiers and UUIDs are unique and never reused, even after deletion.AU.L2-3.3.2Every action is tied to an authenticated user, session, and source IP, with millisecond UTC timestamps and a hash-chain position. | IA.L2-3.5.5Document the period during which identifiers may not be reused. tiCrypt never reuses an identifier, so any defined period is met. | Required | ||||
Emergency access procedure | Shared | Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency. | tiCrypt has no administrative override: administrators at every tier are cryptographically excluded from user data. The one recovery path is key escrow, which reconstructs a user's private key only with one member of every escrow group, three groups by default. Escrow is optional. | Write the emergency access procedure. Decide whether accounts are escrowed, define the escrow groups and say who may ask for a recovery. Without escrow, a lost key or forgotten password leaves that user's data unrecoverable. | Required | ||||
Automatic logoff | tiCrypt | Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity. | AC.L2-3.1.10Idle sessions lock after a configurable interval (default 15 minutes), hide the display, and purge keys client-side; the user must re-authenticate.AC.L2-3.1.11Command sessions end automatically after inactivity, graphical sessions lock and require re-authentication, and keys are purged on logout.SC.L2-3.13.9Tunnels close at session end and idle sessions disconnect; client keys are purged on termination. | AC.L2-3.1.10Set the idle-lock interval (default 15 minutes).AC.L2-3.1.11Set session-termination thresholds.SC.L2-3.13.9Set the idle-disconnect interval. | Addressable | ||||
Encryption and decryption | tiCrypt | Implement a mechanism to encrypt and decrypt electronic protected health information. | SC.L2-3.13.16CUI is AES-256 encrypted at rest: Vault files in 8 MB chunks with per-file keys, and VM drives with LUKS or BitLocker. Metadata such as file names is not encrypted at rest.SC.L2-3.13.11Every cryptographic operation that protects CUI runs through the OpenSSL 3.1.2 FIPS provider (CMVP #4985, FIPS 140-3) in approved mode: the key operations on the user's client and everything the VM controller does. tiCrypt implements no cryptography of its own. The backend encrypts no CUI; it verifies signatures and computes hashes with the Java runtime's libraries. Drive encryption inside VMs is performed by LUKS or BitLocker on the operating system's own validated modules, with the operating system's FIPS mode enabled.SC.L2-3.13.10Keys are generated client-side: a random 256-bit key per file and drive, wrapped with the user's RSA-2048 public key, and an RSA-2048 key pair per user. No key is stored unwrapped on the server. Key recovery uses escrow split across independent escrow groups, three by default. | SC.L2-3.13.16Keep the storage that holds the ciphertext, and the unencrypted metadata database, inside your assessment scope: encrypted CUI is still CUI (CMMC FAQ, July 2026, question B-Q8). Do not put CUI in file or directory names.SC.L2-3.13.10Define escrow groups (three by default) and their membership. | Addressable | ||||
Audit controls | tiCrypt | Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information. | AU.L2-3.3.1Audit logging is always on and cannot be disabled or bypassed. 200+ event types are recorded (authentication, files, sharing, VMs, keys, admin actions), and records are kept for the life of the deployment by default on your own audit server.AU.L2-3.3.2Every action is tied to an authenticated user, session, and source IP, with millisecond UTC timestamps and a hash-chain position.AU.L2-3.3.6A query builder, predefined compliance reports, direct SQL access, and Excel export support reduction and reporting without altering original records.AU.L2-3.3.8Audit records are SHA-512 hash-chained, so any change, insertion, or deletion is detectable. The backend pushes logs one way to a separate audit server with no return path. | AU.L2-3.3.1Confirm the retention period meets your records policy (default: retained indefinitely) and back up the audit server. | Standard | ||||
Integrity | Shared | Implement policies and procedures to protect electronic protected health information from improper alteration or destruction. | A user can read a resource only if its key has been re-encrypted to that user's public key, Permission Profiles restrict which operations each role may perform, and file and drive operations are recorded in the SHA-512 hash-chained audit log. The at-rest ciphers provide confidentiality: integrity of stored content relies on the surrounding platform controls, not on an authenticated-encryption mode. | Write the integrity policies and procedures, and keep backups from which improperly altered or destroyed ePHI can be restored. | Standard | ||||
Mechanism to authenticate electronic protected health information | Shared | Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner. | tiCrypt records file creation, deletion and chunk-level read and write events with the acting user in the SHA-512 hash-chained audit log, so a change to stored content can be traced to an authenticated user. It does not corroborate the content itself: Vault files and drives are not stored in an authenticated-encryption mode. | Decide in your risk analysis whether the audit trail is enough or a content-integrity mechanism of your own is needed. | Addressable | ||||
Person or entity authentication | tiCrypt | Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed. | IA.L2-3.5.2Users authenticate by signing a server challenge with their private key, no password is sent. Endpoints and VMs are authenticated by key material before any connection is established.IA.L2-3.5.3Tera Insights requires MFA for every production deployment. It runs through a provider such as Duo or Shibboleth and is layered on top of the private-key signature. The MFA assertion is signed and verified independently, and its identity must match the key holder or the session is denied.IA.L2-3.5.4Each login challenge uses a random single-use nonce, so a captured response cannot be replayed. | IA.L2-3.5.3Choose and configure the MFA provider (for example Duo or Shibboleth) and keep MFA enabled. Provide MFA for host-level admin access outside tiCrypt. | Standard | ||||
Transmission security | tiCrypt | Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network. | SC.L2-3.13.8Data in transit is double-encrypted (TLS 1.2+ plus Diffie-Hellman session keys) with FIPS-validated algorithms, and SHA-256 verifies integrity.AC.L2-3.1.13Remote sessions are double-encrypted: TLS plus a per-session Diffie-Hellman layer between client and VM, using FIPS-validated AES-256, RSA-2048, and SHA-256.SC.L2-3.13.15Sessions are authenticated by RSA challenge-response over mutually authenticated channels (TLS plus Diffie-Hellman), preventing hijacking and replay. | None, provided by tiCrypt | Standard | ||||
Integrity controls | Shared | Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of. | In transit, data is encrypted twice (TLS 1.2 or later plus Diffie-Hellman session keys) and SHA-256 verifies its integrity, so a modification on the network is detected. After receipt, tiCrypt records file creation, deletion and chunk-level read and write events with the acting user in the SHA-512 hash-chained audit log, so a change to stored content can be traced to an authenticated user. It does not corroborate the stored content itself: Vault files and drives are not stored in an authenticated-encryption mode. | Decide in your risk analysis whether the audit trail is enough for ePHI once it is stored, or whether a content-integrity mechanism of your own is needed until the data is disposed of, for example checksums in the storage or backup system. | Addressable | ||||
Encryption | tiCrypt | Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate. | SC.L2-3.13.8Data in transit is double-encrypted (TLS 1.2+ plus Diffie-Hellman session keys) with FIPS-validated algorithms, and SHA-256 verifies integrity.SC.L2-3.13.11Every cryptographic operation that protects CUI runs through the OpenSSL 3.1.2 FIPS provider (CMVP #4985, FIPS 140-3) in approved mode: the key operations on the user's client and everything the VM controller does. tiCrypt implements no cryptography of its own. The backend encrypts no CUI; it verifies signatures and computes hashes with the Java runtime's libraries. Drive encryption inside VMs is performed by LUKS or BitLocker on the operating system's own validated modules, with the operating system's FIPS mode enabled.AC.L2-3.1.13Remote sessions are double-encrypted: TLS plus a per-session Diffie-Hellman layer between client and VM, using FIPS-validated AES-256, RSA-2048, and SHA-256. | None, provided by tiCrypt | Addressable | ||||
Business associate contracts or other arrangements | University | The contract or other arrangement required by § 164.308(b)(3) must meet the requirements of paragraph (a)(2)(i), (a)(2)(ii), or (a)(2)(iii) of this section, as applicable. | tiCrypt does not address business associate contracts. Tera Insights supplies tiCrypt as software and has no access to a deployment, unless the organization sends it data or engages it to administer the deployment. | Decide which parties are business associates and hold the written contracts. If you send Tera Insights ePHI or engage it to administer the deployment, make that determination for Tera Insights as well. | Standard | No CMMC Level 2 counterpart | |||
Business associate contracts | University | The contract must provide that the business associate will— (A) Comply with the applicable requirements of this subpart; (B) In accordance with § 164.308(b)(2), ensure that any subcontractors that create, receive, maintain, or transmit electronic protected health information on behalf of the business associate agree to comply with the applicable requirements of this subpart by entering into a contract or other arrangement that complies with this section; and (C) Report to the covered entity any security incident of which it becomes aware, including breaches of unsecured protected health information as required by § 164.410. | tiCrypt does not address business associate contracts. Tera Insights supplies tiCrypt as software and has no access to a deployment, unless the organization sends it data or engages it to administer the deployment. | Decide which parties are business associates and hold the written contracts. If you send Tera Insights ePHI or engage it to administer the deployment, make that determination for Tera Insights as well. | Required | No CMMC Level 2 counterpart | |||
Other arrangements | University | The covered entity is in compliance with paragraph (a)(1) of this section if it has another arrangement in place that meets the requirements of § 164.504(e)(3). | tiCrypt does not address business associate contracts. Tera Insights supplies tiCrypt as software and has no access to a deployment, unless the organization sends it data or engages it to administer the deployment. | Decide which parties are business associates and hold the written contracts. If you send Tera Insights ePHI or engage it to administer the deployment, make that determination for Tera Insights as well. | Required | No CMMC Level 2 counterpart | |||
Business associate contracts with subcontractors | University | The requirements of paragraphs (a)(2)(i) and (a)(2)(ii) of this section apply to the contract or other arrangement between a business associate and a subcontractor required by § 164.308(b)(4) in the same manner as such requirements apply to contracts or other arrangements between a covered entity and business associate. | tiCrypt does not address business associate contracts. Tera Insights supplies tiCrypt as software and has no access to a deployment, unless the organization sends it data or engages it to administer the deployment. | Decide which parties are business associates and hold the written contracts. If you send Tera Insights ePHI or engage it to administer the deployment, make that determination for Tera Insights as well. | Required | No CMMC Level 2 counterpart | |||
Requirements for group health plans | University | Except when the only electronic protected health information disclosed to a plan sponsor is disclosed pursuant to § 164.504(f)(1)(ii) or (iii), or as authorized under § 164.508, a group health plan must ensure that its plan documents provide that the plan sponsor will reasonably and appropriately safeguard electronic protected health information created, received, maintained, or transmitted to or by the plan sponsor on behalf of the group health plan. | University control, not addressed by tiCrypt | Standard | No CMMC Level 2 counterpart | ||||
Plan document provisions | University | The plan documents of the group health plan must be amended to incorporate provisions to require the plan sponsor to— (i) Implement administrative, physical, and technical safeguards that reasonably and appropriately protect the confidentiality, integrity, and availability of the electronic protected health information that it creates, receives, maintains, or transmits on behalf of the group health plan; (ii) Ensure that the adequate separation required by § 164.504(f)(2)(iii) is supported by reasonable and appropriate security measures; (iii) Ensure that any agent to whom it provides this information agrees to implement reasonable and appropriate security measures to protect the information; and (iv) Report to the group health plan any security incident of which it becomes aware. | University control, not addressed by tiCrypt | Required | No CMMC Level 2 counterpart | ||||
Policies and procedures | University | Implement reasonable and appropriate policies and procedures to comply with the standards, implementation specifications, or other requirements of this subpart, taking into account those factors specified in § 164.306(b)(2)(i), (ii), (iii), and (iv). This standard is not to be construed to permit or excuse an action that violates any other standard, implementation specification, or other requirements of this subpart. A covered entity or business associate may change its policies and procedures at any time, provided that the changes are documented and are implemented in accordance with this subpart. | University control, not addressed by tiCrypt | Standard | No CMMC Level 2 counterpart | ||||
Documentation | University | (i) Maintain the policies and procedures implemented to comply with this subpart in written (which may be electronic) form; and (ii) If an action, activity or assessment is required by this subpart to be documented, maintain a written (which may be electronic) record of the action, activity, or assessment. | University control, not addressed by tiCrypt | Standard | |||||
Time limit | University | Retain the documentation required by paragraph (b)(1) of this section for 6 years from the date of its creation or the date when it last was in effect, whichever is later. | University control, not addressed by tiCrypt | Required | No CMMC Level 2 counterpart | ||||
Availability | University | Make documentation available to those persons responsible for implementing the procedures to which the documentation pertains. | University control, not addressed by tiCrypt | Required | No CMMC Level 2 counterpart | ||||
Updates | University | Review documentation periodically, and update as needed, in response to environmental or operational changes affecting the security of the electronic protected health information. | University control, not addressed by tiCrypt | Required | |||||
This guide maps Tera Insights' published shared-responsibility model for tiCrypt to the HIPAA Security Rule. It is not legal advice. Each covered entity or business associate decides how the rule applies to it and is responsible for its own compliance. Release baseline (ticrypt.com/releases, November 12, 2026): Frontend 2.19.0 · Backend 3.16.3 · Host Controller 1.3.2 · Audit 1.10.1 · SFTP 1.5.1