BAA policy, audit scope & recovery plan

Do you sign a BAA?

Encryption & backup evidence register

Evidence status is not a certification. We have not received a verified written statement covering encryption at rest for this project's database and uploaded files.

Encryption in transitHTTPS in use

The public service uses HTTPS. This does not establish encryption at rest, internal connection coverage, algorithms, or key management.

Database encryption at restWritten evidence pending

No covering project-specific provider statement has been verified. Algorithm, key ownership, rotation, and backup encryption remain unconfirmed.

Uploaded-file encryption at restWritten evidence pending

A separate statement covering private document storage and any recovery copies is needed. Private access controls are not encryption evidence.

Database backupsProvider-documented capability

One automatic database snapshot daily, retained for up to roughly 14 days; schema and data only. This project's snapshot inventory has not been verified. No point-in-time recovery.

Uploaded-file recoveryProposed procedure; not operationally verified

Daily snapshots and database exports exclude storage files. No scheduled file backup or successful file restore test is established.

What written encryption evidence must cover

Provider identity, issue date and service scope; database records, uploaded files and backup copies; algorithms; key ownership and rotation; exclusions; and applicability to this deployment. We will not publish an AES specification or customer-managed-key claim without supporting evidence.

Sources reviewed

• Lovable Cloud documentation — reviewed; no covering at-rest statement established.
• Database backup documentation — documents daily database-only snapshots, not our backup inventory.
• Storage documentation — not proof of scheduled file backups or successful recovery.

What is—and isn't—logged

Updates and history writes are separate operations; a successful update does not guarantee a log entry. Some cleanup can remove history. Email alerts do not replace audit records. This is an audit-scope disclosure, not a completed independent security audit.

Proposed file recovery plan

Documented proposal only—not an active backup service or a tested recovery guarantee.

Database snapshots and exports do not contain uploaded files. The plan below requires an approved owner, a secure copy destination, a complete manifest and an isolated restore test before it can be described as operational.

1. 1. Assign responsibility and approve the plan

   Before activation, designate an operations owner and backup custodian. Agree on scope, access restrictions, retention, and recovery targets in writing. This proposal sets no contractual recovery time or maximum data-loss guarantee.

2. 2. Preserve database and document copies separately

   Proposed cadence: download uploaded files daily and before destructive changes, and export the database before a recovery exercise. An authorized project owner downloads files through Lovable Cloud's Storage view; database exports use its Database management view. These steps are manual and are not scheduled or active today. Store copies in an approved restricted-access location; verify encryption and access controls before using it.

3. 3. Build a restricted recovery manifest

   For every saved file, record its agency, clinician and credential association, original storage path, copy time, size, and checksum. Keep the manifest private because filenames and associations can be sensitive. Reconcile its entries against credential records and confirm every expected file is readable; missing originals cannot be reconstructed from a database snapshot.

4. 4. Test without rolling back production

   Use an approved isolated destination for a database export and separate document copies. A daily snapshot restores the same project in place, not an isolated clone. Reconfigure sign-in settings and secrets at the test destination; prevent test reminders, notifications and outbound integrations from sending real data. Restore files with the correct paths and private access permissions.

5. 5. Verify recovery and agency isolation

   Confirm sign-in, clinician records, credential-to-file associations, file checksums, authorized file viewing, and denied cross-agency access. Check clinician and client portal restrictions. Record the test date, operator, scope, failures, elapsed time and evidence; a restored database alone is not proof that files recovered.

6. 6. Approve any live restore separately

   Export the current database and download current storage files first. A live daily-snapshot restore permanently loses later database changes, reverts the schema, and makes the database unavailable for a few minutes. Validate the app against the restored schema, reconcile newer files and records, and obtain explicit authorization before restarting notifications or integrations.

7. 7. Retest and maintain the procedure

   Proposed test cadence: quarterly and after material storage or schema changes, subject to approval and implementation. Track missing copies and failed checks. No recovery exercise has been completed under this plan; test results will only be published after verification.

Open evidence: current snapshot timestamp, file-copy inventory, approved retention and destination, signed-off responsibilities, and a dated database-and-file restore report. None is represented here as completed.