PHI Contingency Plan Addendum

Effective: March 8, 2026

1. Purpose

This addendum establishes H33's contingency plan for electronic protected health information (ePHI) as required by 45 CFR §164.308(a)(7). The HIPAA Security Rule mandates that covered entities and business associates establish policies and procedures for responding to emergencies or other occurrences that damage systems containing ePHI.

This plan addresses three required implementation specifications: a data backup plan, a disaster recovery plan, and an emergency mode operation plan. It is designed to ensure the confidentiality, integrity, and availability of ePHI throughout any disruption, leveraging H33's post-quantum cryptographic architecture to maintain security even under adverse conditions.

2. Scope

This contingency plan applies to all H33 systems that create, receive, maintain, or transmit ePHI, including:

• H33-Vault: FHE-encrypted document validation platform, including BFV encryption engines, ZKP verification pipelines, and Dilithium signature services
• Auth1: Authentication and identity management service (Elastic Beanstalk deployment at auth-api.z101.ai), including biometric template storage (FHE-encrypted)
• RDS PostgreSQL: Primary relational database (z101-postgres-prod.crshaxdghnnj.us-east-1.rds.amazonaws.com), storing customer data, audit trails, and encrypted PHI metadata
• ElastiCache Redis: In-memory cache layer (l100-redis-prod.encpey.0001.use1.cache.amazonaws.com), used for session management, rate limiting, and transient ePHI processing
• S3 Storage: Document storage buckets with versioning enabled, containing FHE-encrypted document artifacts
• CloudFront CDN: Static asset distribution (no ePHI in CDN cache by design)

3. Data Backup Plan

H33 maintains a comprehensive data backup strategy designed to protect ePHI against loss, corruption, or destruction, per 45 CFR §164.308(a)(7)(ii)(A).

3.1 RDS Automated Backups

Amazon RDS automated backups are enabled for the production PostgreSQL instance with the following configuration:

• Backup window: Daily automated snapshots during the configured maintenance window
• Retention period: 35 days (maximum supported by RDS)
• Encryption: All backups are encrypted at rest using AWS-managed encryption keys (AES-256)
• Verification: Backup completion is monitored via CloudWatch alarms; failures trigger immediate notification to the Security Officer

3.2 Point-in-Time Recovery

RDS point-in-time recovery (PITR) is enabled, providing the ability to restore the database to any second within the retention window.

3.3 S3 Bucket Versioning

All S3 buckets containing document artifacts have versioning enabled. This provides protection against accidental deletion or overwriting of FHE-encrypted documents. Lifecycle policies are configured to transition older versions to S3 Glacier after 90 days and expire after 365 days, balancing cost with compliance retention requirements.

3.4 Cross-Region Replication

Cross-region backup replication to a secondary AWS region (us-west-2) is planned for implementation. Until cross-region replication is active, the multi-AZ deployment within us-east-1 provides redundancy against single availability zone failures.

3.5 FHE-Encrypted Data in Backups

4. Disaster Recovery

H33's disaster recovery plan ensures timely restoration of ePHI systems following a disruptive event, per 45 CFR §164.308(a)(7)(ii)(B).

4.1 Recovery Objectives

4.2 Multi-AZ Deployment

The production RDS PostgreSQL instance is deployed in a Multi-AZ configuration. In the event of an availability zone failure, RDS automatically fails over to the standby replica in a different availability zone. Failover typically completes within 60–120 seconds with no data loss.

4.3 Elastic Beanstalk Auto-Scaling

H33's application tier runs on AWS Elastic Beanstalk with auto-scaling and health monitoring enabled. The environment automatically replaces unhealthy instances, scales capacity based on demand, and distributes traffic across multiple availability zones. Health checks run at 30-second intervals, and unhealthy instances are terminated and replaced within 5 minutes.

4.4 CloudFront CDN

Static assets are served via Amazon CloudFront, providing geographic distribution and edge caching for high availability. CloudFront does not cache or serve ePHI — it is used exclusively for static application assets (JavaScript, CSS, images). This ensures that application availability is maintained even during origin server disruptions.

4.5 Disaster Recovery Runbook

A detailed disaster recovery runbook is maintained in the internal wiki and includes step-by-step procedures for:

• RDS failover verification and manual promotion
• Elastic Beanstalk environment rebuild from saved configuration
• S3 data restoration from versioned objects or cross-region replicas
• ElastiCache cluster recreation and cache warming
• DNS failover and CloudFront origin switching
• Post-recovery validation and integrity checks

The runbook is reviewed and updated quarterly by the Security Officer.

5. Emergency Mode Operations

H33 maintains emergency mode operation procedures to ensure critical ePHI functions continue during and immediately after a crisis, per 45 CFR §164.308(a)(7)(ii)(C).

5.1 Read-Only Mode

During active incidents that affect system integrity, H33 can activate read-only mode for critical ePHI access. In read-only mode:

• Existing FHE-encrypted records remain accessible for authorized read operations
• New document submissions and validation requests are queued for processing after the incident is resolved
• Audit logging continues in append-only mode to maintain the integrity of the Dilithium-signed audit trail
• No write operations are permitted to ePHI-containing systems until the incident is resolved and system integrity is verified

5.2 Manual Failover Procedures

If automated failover mechanisms are unavailable or insufficient, the Security Officer may initiate manual failover procedures. These procedures are documented in the disaster recovery runbook and include manual RDS promotion, Elastic Beanstalk environment swap, and DNS record updates.

5.3 Emergency Contacts

5.4 Communication Plan

During an incident affecting ePHI systems, the following communication channels are used:

• Internal (immediate): Slack channel #security-incidents for real-time coordination among the incident response team
• Internal (formal): Email to compliance@h33.ai for documented notifications and escalations
• External (customers): Status page updates and direct email notification to affected customers, as required by BAA obligations and HIPAA breach notification rules
• External (regulatory): Notifications to HHS OCR as required by 45 CFR §§164.404–164.410, coordinated by the Security Officer with legal counsel

6. Testing

H33 conducts regular testing of contingency plan procedures to ensure their effectiveness, per 45 CFR §164.308(a)(7)(ii)(D).

6.1 Annual Disaster Recovery Test

A full disaster recovery simulation is conducted annually. The test includes:

• Simulated failure of the primary RDS instance with failover to standby
• Restoration of the database from backup to a point-in-time within the RPO
• Verification that all FHE-encrypted ePHI is intact and accessible after recovery
• Validation of Dilithium signature chains on the audit trail post-recovery
• End-to-end application testing with production-equivalent workloads
• Measurement of actual RTO against the 4-hour target

6.2 Quarterly Backup Restoration Verification

Backup restoration is verified quarterly by restoring the most recent RDS snapshot to a test environment and confirming:

• Database schema integrity and data completeness
• FHE ciphertext integrity (sample decryption of test records)
• Audit trail continuity and Dilithium signature verification
• Application connectivity and functional validation

6.3 Documentation and Review

All test results are documented in a standardized report format that includes: test date, participants, scenarios executed, pass/fail criteria, actual results, identified gaps, and remediation actions. Reports are reviewed by the Security Officer and retained for a minimum of six (6) years per HIPAA documentation requirements.

7. Cryptographic Continuity

H33's post-quantum cryptographic infrastructure requires specific continuity measures to ensure that ePHI remains accessible and verifiable through any disruption.

7.1 FHE Key Storage

BFV FHE encryption keys are stored in AWS Secrets Manager, encrypted at rest using AWS KMS. Access to Secrets Manager is restricted to authorized service roles and the Security Officer. Key material is never written to disk in plaintext outside of Secrets Manager.

7.2 Key Recovery Procedures

FHE key recovery procedures are tested semi-annually as part of the contingency plan testing cycle. The test verifies that:

• Keys can be retrieved from Secrets Manager and used to decrypt test ciphertexts
• Key rotation procedures function correctly without disrupting active encrypted records
• Backup key material (if maintained) matches the active keys

7.3 Dilithium Signing Key Backup

CRYSTALS-Dilithium (NIST FIPS 204) signing keys used for audit trail integrity are backed up using a 2-of-3 threshold split-key recovery scheme. Three key shares are distributed to separate, authorized custodians. Reconstruction of the signing key requires any two of the three shares. This ensures that:

• No single custodian can unilaterally access or reconstruct the signing key
• The signing key can be recovered even if one custodian is unavailable
• Key shares are stored in separate physical and logical locations

The split-key recovery process is tested semi-annually, concurrent with FHE key recovery testing.

8. Plan Maintenance

This contingency plan addendum is a living document. It shall be updated upon the occurrence of any of the following:

• Completion of a disaster recovery test or backup restoration verification (incorporating lessons learned)
• Any security incident or breach involving ePHI systems
• Significant changes to H33's infrastructure, including new AWS services, region migrations, or architectural changes
• Changes to H33's product offerings that affect ePHI processing (new services, deprecated services, or material feature changes)
• Changes to HIPAA regulations, HHS guidance, or OCR enforcement priorities related to contingency planning
• Organizational changes affecting the contingency plan team, contact list, or authority structure

All updates must be reviewed and approved by the Security Officer before publication. Version history is maintained in the document header and in the internal change management system.

9. Review

This contingency plan addendum shall be reviewed and reaffirmed (or updated) on an annual basis. The next scheduled review is March 2027.

The annual review shall include:

• Validation that all recovery objectives (RTO, RPO) remain appropriate for current operations
• Review of all test results from the preceding year
• Assessment of infrastructure changes and their impact on contingency procedures
• Verification that emergency contact information is current
• Confirmation that all referenced runbooks, procedures, and documentation are up to date