Trust & Security

Security policy

Our security practices cover authentication, access, and incident response:

• Authentication: Passwords hashed with bcrypt; HttpOnly cookies; CSRF protection; optional security alert webhooks for 401/403 events.
• Access control: Role-based access (Admin, Biller, Staff, Client, Auditor) with principle of least privilege; protected routes are required to validate authentication, role, and tenant scope.
• Input validation: Zod schemas validate API input; no sensitive tokens in localStorage.
• Incident detection: PHI access log review, failed login monitoring, and suspicious activity views for admins and auditors.
• Secrets management: Protected release approval requires production secrets to come from a DentriRev-only secret manager and rejects plaintext stored credentials.

Data encryption

Your data is protected with industry-standard encryption:

• In transit: Production release approval requires a pinned HTTPS origin and verifies the deployed security posture.
• At rest (database): The exact database provider, encryption controls, and BAA coverage must be confirmed in protected launch evidence.
• At rest (files): Production release requires private storage, live put/get/delete verification, malware scanning, provider encryption confirmation, and applicable BAA coverage.
• Stored credentials: Production third-party passwords, security answers, and credential notes require AES-256-GCM application encryption. Release approval rejects a missing key, plaintext, or unreadable ciphertext.
• Backups: Repository workflows support encrypted database and private-file backups, but a protected successful backup and disposable restore drill—not repository code—is the launch evidence.

Audit logs

Sensitive actions and PHI access are logged for compliance:

• Admin activity log: User changes, office updates, assignments, approvals, refunds, and administrative actions.
• PHI access log: Who viewed, exported, or downloaded protected health information — including resource type, action, IP address, and user agent.
• Credential access log: Access to decrypted insurance/portal credentials is logged.
• Entity audit (AuditLog): Traceability for claims, procedures, attachments, and payments — who changed what and when.

The application does not routinely purge these log tables. Admin activity and PHI-access exports are available; credential-access records require a governed database export until a dedicated UI export is added. The final retention period, legal holds, archive destination, and access procedure must be approved for the exact production deployment.

Backup system

DentriRev includes backup and restore tooling. Launch requires deployment-specific proof that the configured jobs and alerts work:

• Database: Configure managed recovery and an encrypted, DentriRev-only offsite backup target; retain a successful protected run for the release candidate.
• File storage: Configure a distinct encrypted backup target and prove byte-for-byte restore into a disposable store.
• Retention: Approve and configure the backup and audit-retention periods before production data is accepted.
• Verification: Protected release approval requires current restore-drill evidence; recurring drill ownership remains an operational responsibility after launch.

Disaster recovery plan

The repository contains a documented recovery plan and fail-closed release gates. The actual objectives and readiness are established by observed protected drills for the selected production providers:

• Recovery objectives: RTO and RPO are not publicly guaranteed by repository code. Record observed recovery time and recovery point during each deployment-specific drill, then approve contractual targets with operations and counsel.
• Scenarios covered: Server compromise, database corruption, ransomware, and destructive attacks.
• Incident response: Defined roles (Incident Lead, Tech Lead, Communications), escalation procedures, and containment steps.
• Restore procedures: The runbooks cover database, offsite logical backup, private-file restore, and application rollback for providers that are explicitly configured.
• Secrets recovery: Launch requires a named, access-controlled encrypted source of truth for production secrets.
• Drills: A protected drill is required before approval. Future cadence and ownership must be recorded in the on-call and incident program.

Security safeguards

• TLS/HTTPS: All traffic encrypted in transit (TLS 1.2+).
• Session timeout: Automatic logoff after 15 minutes of inactivity, with a warning modal before expiry.
• Rate limiting: Login attempts limited (5 failures per 15 minutes); brute-force protection.
• Password policy: HIPAA-aligned: minimum 8 characters with uppercase, lowercase, number, and special character.
• Security headers: HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy.

Business Associate Agreements

For BAA, privacy, or security inquiries, use the public contact form and select the matching topic. Delivery must be verified for the production recipient before launch.