Skip to main content

HIPAA Certification Readiness Checklist

Not legal advice

This page describes technical features that can support your compliance work. It is not legal advice, and it does not establish that any system is compliant with any law, regulation or standard. You remain responsible for your own compliance assessment, independent testing and validation, and review by qualified legal and compliance professionals. See the Compliance Disclaimer.

Framework: Excalibur Standard: HIPAA (Health Insurance Portability and Accountability Act) Focus: Security Rule + Privacy Rule technical safeguards Status: Framework capabilities mapped to HIPAA requirements Last Updated: 2026-09-12

Verify every SSP statement against your own deployment before you adopt it

The SSP Statement blocks on this page are written to be copied into your own System Security Plan, so treat each one as a draft about your system rather than as a finding about it. A review of these statements is in progress and is not complete.

A statement that has not yet been reviewed may describe a capability that is opt-in and not active unless you register it, that is configured differently in your deployment, or that the framework does not provide. Several controls documented here are inactive until explicitly enabled.

Before pasting any statement into a document an assessor will read, confirm it against the configuration you actually run.

Overview​

This checklist provides step-by-step guidance for HIPAA compliance preparation using the Excalibur framework. While HIPAA compliance requires both technical and organizational controls, this checklist focuses on the technical safeguards provided by the framework.

HIPAA Scope: Protected Health Information (PHI) for covered entities and business associates Compliance Approach: Framework-provided technical safeguards + consumer organizational policies

IMPORTANT DISCLAIMER: HIPAA compliance requires comprehensive organizational policies, workforce training, and business associate agreements beyond the scope of this framework. Consult with a HIPAA compliance specialist and legal counsel to ensure full compliance.

HIPAA Security Rule Overview​

CategorySafeguardsRequired?Framework Support
Administrative Safeguards§164.308Required⚠️ Partial (policies + training consumer responsibility)
Physical Safeguards§164.310Required⚠️ Partial (data center security consumer responsibility)
Technical Safeguards§164.312Required✅ Full (encryption, access control, audit, transmission security)

Focus: This checklist covers Technical Safeguards (§164.312) where the framework provides direct implementation.

Control Mapping Table​

Technical Safeguards (§164.312)​

StandardImplementation SpecR/AFramework ImplementationConsumer ActionEvidence Location
§164.312(a)(1)Access ControlR✅ [RequirePermission], RBACConfigure access controlsAuthorization
§164.312(a)(2)(i)Unique User IDR✅ User identity in audit logsAssign unique user IDsAudit event properties
§164.312(a)(2)(ii)Emergency AccessR⚠️ PartialConfigure emergency proceduresBusiness policy
§164.312(a)(2)(iii)Automatic LogoffA⚠️ PartialConfigure session timeoutsApplication configuration
§164.312(a)(2)(iv)Encryption & DecryptionA✅ AES-256-GCM (IEncryptionProvider)Enable encryptionAES-256-GCM encryption
§164.312(b)Audit ControlsR✅ IAuditLogger (tamper-evident)Configure audit loggingAudit logging
§164.312(c)(1)IntegrityR✅ Hash chain, versioningVerify integrity controlsHash chain integrity
§164.312(c)(2)Mechanism to AuthenticateA✅ Digital signatures, HMACConfigure authenticationMessage signing algorithms
§164.312(d)Person/Entity AuthenticationR✅ OAuth2, JWT, password hashingConfigure authenticationPassword hashing
§164.312(e)(1)Transmission SecurityR✅ TLS 1.2+Configure TLSTransport encryption
§164.312(e)(2)(i)Integrity ControlsA✅ Message signing (HMAC, opt-in) — an unkeyed checksum does not satisfy thisEnable signing, then verify transmission integrityMessage signing in the pipeline
§164.312(e)(2)(ii)EncryptionA✅ TLS 1.2+Enable TLSTransport encryption

Legend:

  • R = Required
  • A = Addressable (required unless alternative equivalent)
  • ✅ = Framework provides full implementation
  • ⚠️ = Framework provides tools, consumer implements policy

Implementation Checklist​

Phase 1: Prerequisites (Week 1)​

1.1 Understand HIPAA Scope​

  • Determine if you are a covered entity or business associate
  • Identify all systems that process, store, or transmit PHI
  • Classify data (PHI vs non-PHI)
  • Document system boundaries

PHI Examples:

  • Patient names, addresses, birthdates
  • Medical record numbers
  • Health plan beneficiary numbers
  • Device identifiers (e.g., pacemaker serial numbers)
  • Biometric identifiers
  • Diagnoses, treatment information

Reference: HHS PHI Definition

1.2 Install Framework Packages​

dotnet add package Excalibur.Domain  # For encryption, audit, access control
dotnet add package Excalibur.Compliance  # For GDPR erasure (right to access)

1.3 Engage HIPAA Compliance Specialist​

  • Hire HIPAA compliance consultant or legal counsel
  • Conduct Risk Assessment (required by §164.308(a)(1)(ii)(A))
  • Develop Security Policies and Procedures
  • Develop Privacy Policies and Procedures
  • Create Business Associate Agreements (BAAs)

CRITICAL: This checklist does NOT replace professional HIPAA compliance guidance. You MUST engage a qualified specialist.

Phase 2: Administrative Safeguards (§164.308) - Week 2-3​

NOTE: Administrative Safeguards are primarily organizational policies. The framework does NOT automate these. Consult with your compliance specialist.

2.1 Security Management Process (§164.308(a)(1))​

Required:

  • Risk Analysis (identify threats to PHI)
  • Risk Management (implement security measures)
  • Sanction Policy (consequences for violations)
  • Information System Activity Review (audit log review)

Framework Support:

  • IAuditLogger provides audit logs for review (§164.308(a)(1)(ii)(D))

Evidence:

  • Risk assessment documentation
  • Sanction policy
  • Audit log review procedures
  • Monthly audit log review reports

2.2 Assigned Security Responsibility (§164.308(a)(2))​

Required:

  • Designate Security Official responsible for HIPAA compliance
  • Document appointment in writing

2.3 Workforce Security (§164.308(a)(3))​

Required:

  • Authorization/Supervision procedures
  • Workforce clearance procedures
  • Termination procedures (revoke access)

Framework Support:

  • [RequirePermission] enforces authorization
  • RBAC for role-based access control

2.4 Information Access Management (§164.308(a)(4))​

Required:

  • Isolating Healthcare Clearinghouse Functions (if applicable)
  • Access Authorization (grant minimum necessary access)
  • Access Establishment and Modification

Framework Support:

  • [RequirePermission] attribute for access control
  • Role-based permission assignments

2.5 Security Awareness and Training (§164.308(a)(5))​

Required:

  • Security Reminders (periodic)
  • Protection from Malicious Software
  • Log-in Monitoring
  • Password Management

Framework Support:

  • Password hashing (Argon2id) via framework
  • Login audit events via IAuditLogger

2.6 Security Incident Procedures (§164.308(a)(6))​

Required:

  • Response and Reporting procedures

Framework Support:

  • Incident detection via audit logs and monitoring

Evidence:

  • Incident response plan
  • Incident logs
  • Breach notification procedures

2.7 Contingency Plan (§164.308(a)(7))​

Required:

  • Data Backup Plan
  • Disaster Recovery Plan
  • Emergency Mode Operation Plan

Framework Support:

  • N/A (infrastructure/business policy)

2.8 Evaluation (§164.308(a)(8))​

Required:

  • Periodic technical and non-technical evaluation (annual recommended)

Framework Support:

  • Automated control validation (SOC 2 validators can be used)

Phase 3: Physical Safeguards (§164.310) - Week 4​

NOTE: Physical Safeguards are primarily data center and facility controls. For cloud deployments, these are typically inherited from cloud provider (Azure, AWS, GCP).

3.1 Facility Access Controls (§164.310(a)(1))​

Required:

  • Contingency Operations (facility for backup operations)
  • Facility Security Plan (safeguard against unauthorized access)
  • Access Control and Validation (control physical access)
  • Maintenance Records (repairs and modifications)

Framework Support:

  • N/A (cloud provider responsibility for IaaS/PaaS)

Cloud Provider Evidence:

  • Azure: SOC 2 Type II, ISO 27001, FedRAMP certifications
  • AWS: SOC 2 Type II, ISO 27001, FedRAMP certifications
  • GCP: SOC 2 Type II, ISO 27001, FedRAMP certifications

3.2 Workstation Use (§164.310(b))​

Required:

  • Policy on proper workstation use

Framework Support:

  • N/A (organizational policy)

3.3 Workstation Security (§164.310(c))​

Required:

  • Physical safeguards for workstations accessing PHI

Framework Support:

  • N/A (endpoint security, MDM solutions)

3.4 Device and Media Controls (§164.310(d)(1))​

Required:

  • Disposal (secure disposal/reuse of PHI)
  • Media Re-use (remove PHI before reuse)
  • Accountability (track hardware/media movements)
  • Data Backup and Storage

Framework Support:

  • IErasureService for cryptographic erasure (secure disposal)
  • Backup/storage (cloud provider or consumer infrastructure)

Evidence:

  • Media disposal procedures
  • Your key-management service's record of each key deletion (the evidence that cryptographic erasure took place)
  • Erasure certificates, as an internal record of the request only — not as evidence of disposal
  • Asset tracking logs

Phase 4: Technical Safeguards (§164.312) - Week 5-7​

NOTE: This is where the framework provides the MOST value. Focus your implementation effort here.

4.1 Access Control (§164.312(a)(1)) [REQUIRED]​

Control Requirement: Implement technical policies and procedures that allow only authorized persons to access electronic PHI (ePHI).

Framework Implementation:

  • [RequirePermission] attribute for declarative authorization
  • Role-based access control (RBAC)

Consumer Checklist:

  • Apply [RequirePermission] to all PHI access operations

Code Example:

using Excalibur.A3.Authorization;

[RequirePermission("phi.read")]
public class GetPatientRecordAction : IDispatchAction
{
    public Guid PatientId { get; set; }
}

[RequirePermission("phi.write")]
public class UpdatePatientRecordAction : IDispatchAction
{
    public Guid PatientId { get; set; }
    public PatientRecord Record { get; set; }
}
  • Define role-to-permission mappings (minimum necessary access)

Role Examples:

{
  "Roles": {
    "Physician": ["phi.read", "phi.write", "prescriptions.create"],
    "Nurse": ["phi.read", "vitals.write"],
    "Receptionist": ["demographics.read", "appointments.write"],
    "BillingClerk": ["billing.read", "billing.write"]
  }
}
  • Test authorization enforcement (unauthorized access denied)

Evidence:

  • Authorization - Authorization guide
  • Permission catalog (roles and permissions)
  • Unit tests for authorization
  • Access control policy documentation

SSP Statement (BAA):

"§164.312(a)(1) Access Control is satisfied through the Excalibur framework's [RequirePermission] attribute and role-based access control. Only authorized users with appropriate roles can access ePHI. Minimum necessary access is enforced through granular permissions."

4.1.1 Unique User Identification (§164.312(a)(2)(i)) [REQUIRED]​

Consumer Checklist:

  • Assign unique user ID to each user (no shared accounts)
  • Capture user ID in all audit logs

Code Example:

// Audit log includes unique user ID
await _auditLogger.LogAsync(new AuditEvent
{
    EventId = Guid.NewGuid().ToString(),
    EventType = AuditEventType.DataAccess,
    Action = "PHI.Read",
    ActorId = currentUser.Id,
    Outcome = AuditOutcome.Success,
    Timestamp = DateTimeOffset.UtcNow,
    ResourceId = patientId.ToString(),
    ResourceType = "Patient"
}, CancellationToken.None);
  • Test audit logs include user ID

Evidence:

  • User provisioning procedures
  • Audit log samples showing unique user IDs
  • No shared account verification

SSP Statement:

"§164.312(a)(2)(i) Unique User Identification is satisfied by assigning each user a unique identifier. All audit logs capture the user ID of the individual accessing ePHI. Shared accounts are prohibited."

4.1.2 Emergency Access Procedure (§164.312(a)(2)(ii)) [REQUIRED]​

Consumer Checklist:

  • Document emergency access procedures (break-glass scenarios)
  • Create emergency access role with elevated permissions
  • Log all emergency access usage
  • Review emergency access logs weekly

Policy Example:

"Emergency Access Procedure: In medical emergencies where patient care requires immediate ePHI access and normal authentication is unavailable, the on-call physician may use the emergency access account. All emergency access is logged and reviewed by the Security Official within 24 hours."

Evidence:

  • Emergency access policy
  • Emergency access audit logs
  • Weekly review reports

SSP Statement:

"§164.312(a)(2)(ii) Emergency Access Procedure is satisfied through a documented break-glass procedure. Emergency access is logged via IAuditLogger and reviewed by the Security Official within 24 hours."

4.1.3 Automatic Logoff (§164.312(a)(2)(iii)) [ADDRESSABLE]​

Consumer Checklist:

  • Configure session timeout (15-30 minutes recommended for PHI systems)
  • Test automatic logoff after inactivity

Code Example:

// ASP.NET Core session timeout
services.AddSession(options =>
{
    options.IdleTimeout = TimeSpan.FromMinutes(15);  // HIPAA recommendation
    options.Cookie.HttpOnly = true;
    options.Cookie.IsEssential = true;
});
  • Document session timeout configuration

Evidence:

  • Session timeout configuration
  • Timeout testing results

SSP Statement:

"§164.312(a)(2)(iii) Automatic Logoff is satisfied through a 15-minute session timeout. Users are automatically logged off after 15 minutes of inactivity to prevent unauthorized access."

4.1.4 Encryption and Decryption (§164.312(a)(2)(iv)) [ADDRESSABLE]​

Consumer Checklist:

  • Enable encryption at rest for all ePHI

Code Example:

using Excalibur.Compliance;

services.AddEncryption(encryption => encryption
    .UseKeyManagement<AesGcmEncryptionProvider>("aes-gcm-primary")
    .ConfigureOptions(options => options.DefaultPurpose = "field-encryption"));

// Annotate PHI fields
public class PatientRecord
{
    public Guid Id { get; set; }

    [PersonalData]  // [PersonalData] is encrypted ONLY on a record that also carries [DataSubjectId],
    // and only on a path you wire (crypto-shredding / the encrypting event-store decorator).
    // A record with no [DataSubjectId] member is left in cleartext.
    public string FirstName { get; set; }

    [PersonalData]
    public string LastName { get; set; }

    [PersonalData]
    public string SSN { get; set; }

    [PersonalData]
    [Sensitive]  // in every released version: classification + log masking only, no encryption.
                 // On the main branch it also selects the property for encryption at rest.
    public string Diagnosis { get; set; }

    [PersonalData]
    [Sensitive]
    public string TreatmentPlan { get; set; }
}
  • Verify encryption at rest (inspect database)
  • Configure key rotation (90-day recommended)
  • Document encryption configuration

Evidence:

  • Encryption architecture - Encryption guide
  • Encryption verification tests
  • Key management procedures
  • Database inspection (encrypted values)

SSP Statement:

"§164.312(a)(2)(iv) Encryption and Decryption is satisfied through AES-256-GCM encryption at rest using the Excalibur framework. ePHI fields are annotated with [PersonalData] on records that also carry [DataSubjectId], and are encrypted once crypto-shredding is registered. Encryption keys are managed via Azure Key Vault with 90-day rotation."

4.2 Audit Controls (§164.312(b)) [REQUIRED]​

Control Requirement: Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI.

Framework Implementation:

  • IAuditLogger interface with tamper-evident hash chain
  • Structured audit logs capturing who/what/when/where
  • Immutable append-only audit trails

Consumer Checklist:

  • Configure audit logging for all PHI access

Code Example:

using Excalibur.Compliance;

public class PatientRecordService
{
    private readonly IAuditLogger _auditLogger;

    public async Task<PatientRecord> GetRecordAsync(Guid patientId, CancellationToken ct)
    {
        var record = await _repository.GetAsync(patientId, ct);

        // Audit PHI access
        await _auditLogger.LogAsync(new AuditEvent
        {
            EventId = Guid.NewGuid().ToString(),
            EventType = AuditEventType.DataAccess,
            Action = "PHI.Read",
            ActorId = _currentUser.Id,
            Outcome = AuditOutcome.Success,
            Timestamp = DateTimeOffset.UtcNow,
            ResourceId = patientId.ToString(),
            ResourceType = "Patient",
            Metadata = new Dictionary<string, string>
            {
                ["FieldsAccessed"] = "FirstName,LastName,Diagnosis"
            }
        }, ct);

        return record;
    }

    public async Task UpdateRecordAsync(PatientRecord record, CancellationToken ct)
    {
        await _repository.UpdateAsync(record, ct);

        // Audit PHI modification
        await _auditLogger.LogAsync(new AuditEvent
        {
            EventId = Guid.NewGuid().ToString(),
            EventType = AuditEventType.DataModification,
            Action = "PHI.Update",
            ActorId = _currentUser.Id,
            Outcome = AuditOutcome.Success,
            Timestamp = DateTimeOffset.UtcNow,
            ResourceId = record.Id.ToString(),
            ResourceType = "Patient",
            Metadata = new Dictionary<string, string>
            {
                ["FieldsModified"] = "Diagnosis,TreatmentPlan"
            }
        }, ct);
    }
}
  • Configure audit event types (access, create, update, delete, export, print)
  • Implement audit log retention (6 years HIPAA requirement)
  • Configure RBAC for audit log access (Security Official only)
  • Test hash chain integrity verification

Audit Events to Capture:

  • PHI access (read)
  • PHI creation
  • PHI modification
  • PHI deletion (with erasure certificate)
  • PHI export (download, print, email)
  • Authentication (login, logout, failed attempts)
  • Authorization failures (access denied)
  • Configuration changes (roles, permissions)

Evidence:

  • Audit logging - Audit logging guide
  • Audit log samples (anonymized)
  • Audit log retention policy (6 years)
  • Hash chain integrity verification tests
  • Conformance results from the arms you wrapped (AuditStoreConformanceTestKit)
Wrapped is not run

The kit is bound against real SQL Server and real PostgreSQL, not the in-memory store alone. That evidences our schema and our configuration, not your deployment — our suites run against a disposable container. Cite the arms your run executed and passed against your database, not the bindings we ship.

SSP Statement:

"§164.312(b) Audit Controls is satisfied through the Excalibur framework's IAuditLogger with tamper-evident hash chain. All ePHI access, modifications, and deletions are logged with user ID, timestamp, and action. Audit logs are retained for 6 years per HIPAA requirements."

4.3 Integrity (§164.312(c)(1)) [REQUIRED]​

Control Requirement: Implement policies and procedures to protect ePHI from improper alteration or destruction.

Framework Implementation:

  • Hash chain integrity for audit logs
  • Event versioning in event sourcing
  • Optimistic concurrency control

Consumer Checklist:

  • Verify hash chain integrity (audit logs cannot be tampered)
  • Test concurrency control (prevent lost updates)

Code Example:

// Optimistic concurrency via event sourcing
public class Patient : AggregateRoot
{
    public void UpdateDiagnosis(string newDiagnosis)
    {
        // Event versioning prevents concurrent updates
        RaiseEvent(new DiagnosisUpdatedEvent
        {
            AggregateId = this.Id,
            Version = this.Version + 1,  // Concurrency control
            NewDiagnosis = newDiagnosis,
            UpdatedAt = DateTime.UtcNow
        });
    }
}
  • Test integrity controls (detect tampering attempts)

Evidence:

  • Hash chain integrity tests
  • Concurrency control tests
  • Version conflict handling tests

SSP Statement:

"§164.312(c)(1) Integrity is satisfied through tamper-evident hash chains for audit logs and optimistic concurrency control for ePHI updates. Hash chains detect any unauthorized modifications. Versioning prevents lost updates from concurrent access."

4.3.1 Mechanism to Authenticate ePHI (§164.312(c)(2)) [ADDRESSABLE]​

Consumer Checklist:

  • Implement digital signatures or HMAC for message authentication
  • Verify message authenticity on receipt

Code Example:

The framework ships this

You do not need to hand-roll message authentication. services.AddMessageSigning(...) registers MessageSigningMiddleware, which signs outbound messages and verifies inbound ones through HmacMessageSigningService — which compares in constant time and takes its key from your key management rather than a string field. The example below is shown only to illustrate the control.

// HMAC for message authentication
public class MessageAuthenticationService
{
    private readonly string _secretKey;

    public string ComputeHMAC(string message)
    {
        using var hmac = new HMACSHA256(Encoding.UTF8.GetBytes(_secretKey));
        var hash = hmac.ComputeHash(Encoding.UTF8.GetBytes(message));
        return Convert.ToBase64String(hash);
    }

    public bool VerifyHMAC(string message, string receivedHMAC)
    {
        // Constant-time: a `==` on two Base64 strings leaks the match position by timing.
        return CryptographicOperations.FixedTimeEquals(
            Convert.FromBase64String(ComputeHMAC(message)),
            Convert.FromBase64String(receivedHMAC));
    }
}
  • Document authentication mechanism

Evidence:

  • HMAC implementation
  • Message authentication tests
  • Authentication policy

SSP Statement:

"§164.312(c)(2) Mechanism to Authenticate ePHI is satisfied through HMAC-SHA256 for message authentication. Message signing is enabled in this deployment, so ePHI transmitted between systems is signed and verified to prevent tampering."

Signing is opt-in and off by default — confirm before adopting this statement

The framework does not sign messages unless you turn signing on: it is composed only when Security:Signing:Enabled is true (or EnableSigning is set on the options overload). A deployment that has not enabled it transmits ePHI unsigned, and the statement above would be false for that deployment. Verify your own configuration before adopting the wording.

4.4 Person or Entity Authentication (§164.312(d)) [REQUIRED]​

Control Requirement: Implement procedures to verify that a person or entity seeking access to ePHI is the one claimed.

Framework Implementation:

  • Argon2id password hashing (OWASP recommended)
  • OAuth2 / OpenID Connect support
  • JWT token validation

Consumer Checklist:

  • Configure authentication mechanism (OAuth2, SAML, etc.)
  • Enforce strong password policy (12+ characters, complexity)
  • Implement multi-factor authentication (MFA) for PHI access

Code Example:

using Excalibur.Security;

// Argon2id password hashing (OWASP defaults)
services.AddPasswordHasher(options =>
{
    options.MemorySize = 65536;  // 64 MB
    options.Iterations = 4;
    options.Parallelism = 4;
});

// OAuth2 / OpenID Connect
services.AddAuthentication("Bearer")
    .AddJwtBearer(options =>
    {
        options.Authority = "https://login.microsoftonline.com/{tenant}";
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true
        };
    });
  • Test authentication (verify user identity before PHI access)
  • Test MFA enforcement
  • Document authentication procedures

Evidence:

  • Password hashing - Password management guide
  • Authentication configuration
  • MFA enforcement verification
  • Password policy documentation

SSP Statement:

"§164.312(d) Person or Entity Authentication is satisfied through OAuth2/OpenID Connect with multi-factor authentication (MFA). Passwords are hashed using Argon2id. Users must authenticate with MFA before accessing ePHI."

4.5 Transmission Security (§164.312(e)(1)) [REQUIRED]​

Control Requirement: Implement technical security measures to guard against unauthorized access to ePHI that is being transmitted over an electronic communications network.

Framework Implementation:

  • TLS 1.2+ enforcement for all HTTP traffic
  • Certificate validation
  • Encryption in transit

Consumer Checklist:

  • Configure TLS 1.2+ for all HTTP endpoints
  • Disable insecure protocols (SSL 3.0, TLS 1.0, TLS 1.1)

Code Example:

// ASP.NET Core Startup.cs
services.Configure<HttpsConnectionAdapterOptions>(options =>
{
    options.SslProtocols = SslProtocols.Tls12 | SslProtocols.Tls13;
});

// Enforce HTTPS redirection
app.UseHttpsRedirection();
app.UseHsts();
  • Verify TLS configuration (testssl.sh or nmap)
  • Document TLS configuration

Verification Command:

# Verify TLS 1.2+ enforcement
testssl.sh https://yourdomain.com

# Or using nmap
nmap --script ssl-enum-ciphers -p 443 yourdomain.com

Evidence:

SSP Statement:

"§164.312(e)(1) Transmission Security is satisfied through TLS 1.2+ enforcement for all HTTP traffic. Insecure protocols (SSL 3.0, TLS 1.0, TLS 1.1) are disabled. All ePHI transmitted over the network is encrypted."

4.5.1 Integrity Controls (§164.312(e)(2)(i)) [ADDRESSABLE]​

Consumer Checklist:

  • Implement message signing or checksums for transmitted ePHI
  • Verify integrity on receipt

Code Example:

// Message integrity via checksum
public class TransmissionIntegrityService
{
    public string ComputeChecksum(byte[] data)
    {
        using var sha256 = SHA256.Create();
        var hash = sha256.ComputeHash(data);
        return Convert.ToBase64String(hash);
    }

    public bool VerifyIntegrity(byte[] data, string expectedChecksum)
    {
        var actualChecksum = ComputeChecksum(data);
        // Constant-time comparison; and note a bare checksum is unkeyed, so it detects
        // corruption but not tampering. Prefer the keyed HMAC above for §164.312(e)(2)(i).
        return CryptographicOperations.FixedTimeEquals(
            Convert.FromBase64String(actualChecksum),
            Convert.FromBase64String(expectedChecksum));
    }
}
  • Test that the unkeyed checksum detects corruption (it cannot detect tampering — see below)
  • Enable message signing and test that a modified message is rejected — this is the arm that evidences the control

Evidence:

  • Checksum implementation
  • Integrity verification tests

SSP Statement:

"§164.312(e)(2)(i) Integrity Controls is satisfied through HMAC-SHA256 message signing, which is enabled in this deployment. Signed messages are verified on receipt, so a modification in transit is detected and rejected."

An unkeyed checksum does not satisfy this control

Do not adopt the statement above unless message signing is actually enabled in your deployment, and do not substitute a plain SHA-256 checksum for it. The two are different security properties:

mechanismdetects corruptiondetects tampering
unkeyed SHA-256 checksumyesno — an attacker who alters the message recomputes the hash
keyed HMAC-SHA256 (message signing)yesyes, while the key stays secret

§164.312(e)(2)(i) is about tampering, so only the keyed form satisfies it. Signing is opt-in and off by default — the framework composes it only when Security:Signing:Enabled is true and you have supplied an IKeyProvider. A deployment that has not done both transmits ePHI unsigned, and neither the statement above nor the checksum sample below evidences this control for it.

4.5.2 Encryption (§164.312(e)(2)(ii)) [ADDRESSABLE]​

Consumer Checklist:

  • Enable TLS 1.2+ encryption (see §164.312(e)(1) above)
  • Verify encryption is active for all PHI transmissions

Evidence:

  • TLS configuration (see §164.312(e)(1))

SSP Statement:

"§164.312(e)(2)(ii) Encryption is satisfied through TLS 1.2+ enforcement (see §164.312(e)(1))."

Privacy Rule (§164.500-534)​

NOTE: The Privacy Rule is primarily organizational policies and procedures. The framework provides some technical capabilities (e.g., access logs, erasure), but full compliance requires comprehensive privacy policies, training, and business processes.

Key Privacy Rule Requirements​

Individual Rights​

  • Right to Access (§164.524): Provide individuals access to their PHI within 30 days
    • Framework support: Access audit logs verify fulfillment
  • Right to Amend (§164.526): Allow individuals to request amendments to their PHI
    • Framework support: Audit logs track amendment requests and fulfillment
  • Right to an Accounting of Disclosures (§164.528): Provide list of PHI disclosures
    • Framework support: Audit logs provide disclosure accounting
  • Right to Request Restrictions (§164.522): Allow individuals to request restrictions on PHI use/disclosure
    • Framework support: Access control can enforce restrictions
  • Right to Request Confidential Communications (§164.522): Allow alternative communication methods
    • Framework support: N/A (business process)
  • Right to Receive Notice of Privacy Practices (§164.520): Provide privacy notice
    • Framework support: N/A (business process)

Framework Support:

  • IAuditLogger provides disclosure accounting
  • IErasureService provides right to deletion (not required by HIPAA but good practice per GDPR)

Evidence:

  • Privacy notice (HIPAA-compliant)
  • Individual rights procedures
  • Audit logs (access, amendments, disclosures)
  • Request tracking logs

Consumer Responsibilities​

Framework Provides:

  • Technical safeguards (access control, audit, encryption, authentication, transmission security)
  • Conformance test kits (Audit, Erasure, LegalHold, DataInventory; the count that evidences a control is the one your own run executed)
  • Evidence collection (audit logs, encryption verification)

Consumer Must Implement:

  • Administrative Safeguards: Risk assessment, policies, training, incident response
  • Physical Safeguards: Facility security, workstation security, device disposal
  • Privacy Policies: Notice of Privacy Practices, individual rights procedures
  • Business Associate Agreements (BAAs): Contracts with vendors processing PHI
  • Workforce Training: Annual HIPAA training for all employees
  • Breach Notification: 60-day notification to HHS and affected individuals

Compliance Verification​

Pre-Certification Testing​

Week 8: Risk Assessment

  • Conduct comprehensive Risk Assessment (required by §164.308(a)(1)(ii)(A))
  • Identify all threats to PHI (natural, human, environmental)
  • Assess current safeguards
  • Determine residual risk
  • Document risk management plan

Week 9: Policy Development

  • Develop Security Policies and Procedures (all §164.308, §164.310, §164.312 requirements)
  • Develop Privacy Policies (all §164.500-534 requirements)
  • Create Notice of Privacy Practices
  • Create Business Associate Agreement (BAA) template

Week 10: Technical Validation

  • Verify technical safeguards (see Phase 4 above)
  • Run conformance test kits (Audit, Erasure, etc.)
  • Test access controls (unauthorized access denied)
  • Test audit logging (all PHI access logged)
  • Test encryption (data at rest and in transit)
  • Test authentication (MFA enforced)
  • Test transmission security (TLS 1.2+ enforced)

Week 11: Training

  • Conduct HIPAA training for all workforce members
  • Document training completion (attendance, signatures)
  • Test workforce knowledge (quiz or assessment)

Week 12: External Audit (Optional but Recommended)

  • Engage HIPAA compliance auditor
  • Provide Risk Assessment and policies
  • Demonstrate technical safeguards
  • Remediate any findings

Evidence References​

Primary Evidence​

Framework Implementation:

Conformance Test Results:

  • AuditStoreConformanceTestKit - §164.312(b)
  • ErasureStoreConformanceTestKit - Secure disposal
  • Encryption verification tests - §164.312(a)(2)(iv), §164.312(e)(2)(ii)

No arm count is published here, deliberately. The kits carry no test attributes, so an arm is not executed until you declare an attributed wrapper for it in your derived class — any number we print is ours at some past moment and describes what a kit offers, never what your suite verified. Record the executed and passed count from your own run and attach its output; that is what evidences the control.

Audit Evidence:

  • Audit log samples (PHI access, modifications, deletions)
  • Disclosure accounting (audit logs)
  • Authentication logs (successful/failed logins)
  • Authorization failures (access denied)

Supporting Documentation​

HIPAA Regulations:

Framework Documentation:

Continuous Compliance​

Automated Monitoring​

Daily:

  • Audit log integrity verification (hash chain)
  • Encryption key rotation status
  • Authentication failures (detect brute force)
  • Authorization failures (detect unauthorized access attempts)

Weekly:

  • Emergency access log review (Security Official)
  • Failed authentication attempts review
  • Audit log completeness check

Monthly:

  • Risk assessment update (new threats, vulnerabilities)
  • Policy and procedure review
  • Workforce training completion tracking

Annually:

  • Comprehensive Risk Assessment
  • Policy and procedure updates
  • Workforce training (required annual HIPAA training)
  • External audit (recommended)

Contact​

Questions:

  • HIPAA Compliance Specialist: Legal/regulatory guidance
  • Product Manager: Privacy policy, individual rights procedures
  • Software Architect: Technical safeguards, framework capabilities
  • Project Manager: Audit coordination, evidence package

Escalation:

  • PHI breach: Follow Breach Notification Rule (60-day notification to HHS)
  • Compliance gaps: Engage HIPAA compliance specialist
  • Audit requests: Contact Project Manager for evidence package

DISCLAIMER​

This checklist provides guidance on technical safeguards implemented by the Excalibur framework. It does NOT constitute legal advice or guarantee HIPAA compliance.

HIPAA compliance requires:

  • Comprehensive Risk Assessment
  • Security and Privacy Policies
  • Workforce Training
  • Business Associate Agreements
  • Breach Notification Procedures
  • Physical Safeguards
  • Administrative Safeguards

Consult with a qualified HIPAA compliance specialist and legal counsel to ensure full compliance.

See Also​

Last Updated: 2026-09-12 Document status: every safeguard in scope is walked through below. This describes the document, not your compliance posture — the controls you may inherit are marked per row; the rest are yours to implement and evidence.