Security & Compliance Posture

Data in transit — TLS

All Veridoc traffic is served over HTTPS. TLS 1.2 is the minimum protocol version accepted at the edge; TLS 1.3 is negotiated where client-capable. Render terminates TLS upstream of our application servers, with HTTP Strict Transport Security (HSTS) enabled — browsers will refuse to load any page over a downgraded plaintext connection.

• TLS 1.2 or higher required; TLS 1.3 preferred
• HSTS preloaded at the edge to prevent downgrade attacks
• TLS terminated at Render's edge before reaching the application server
• No PHI traverses plaintext channels anywhere in our stack

Data at rest — Encryption

Patient identifiers and consent records live in a managed Postgres cluster (Neon). Cluster-level AES-256 encryption at rest is enabled on the storage tier; backups and snapshots inherit the same posture. Uploaded clinical documents — pre-op imaging, lab reports, intake forms — are stored in Cloudflare R2 with server-side encryption (SSE) enabled by default on every bucket.

Provider PINs — the credential our partner agencies and hospitals use to access the admin dashboard — are never stored as plaintext. They are PBKDF2-hashed at hashing time (sha512, 100,000 iterations), and the resulting hash + salt are the only values persisted in the providers table.

• Postgres (Neon) at-rest AES-256 encryption
• Cloudflare R2 SSE on every document bucket
• Provider PINs PBKDF2-hashed (sha512, 100k iterations)
• Backups and snapshots inherit at-rest encryption posture

Role-based access control

Access is scoped by role. A patient sees only their own consent record. A treating clinician sees the records of the patients on their active case load. A hospital admin sees the records their hospital has issued. A counterparty (insurer, regulator, home physician) sees only what the public verifier link exposes — and only when a hospital staff member has explicitly shared it.

Per-site scoping for multi-site hospital networks is enforced via the case_participants table, which records who has access to which case (and therefore which clinical record). A Network-tier customer with five sites cannot see records issued by a site they do not administer.

The surfaces a verifier sees — without needing Veridoc access or training — are /verify/<recordId> (the public audit view) and /staff/<slug>/verify (staff-scoped inline verification). Both pages render the same cryptographic proof a regulator would see, scoped to the record the holder is asking about.

• Patient / treating clinician / hospital admin / counterparty scopes
• Per-site RBAC backed by the case_participants table
• Verifier surfaces are public-per-design and audit-logged on every load

Audit-log retention

Every PHI access is recorded in the audit_log table, with user_id, user_type, action, resource_type, resource_id, ip_address, user_agent, metadata, and created_at. Explicit audit entries are written for consent reads (GET /api/consents and GET /api/consents/:id), notarization events, void / append actions, role transitions, and verifier-page loads.

Retention windows:

• HIPAA baseline: at least 6 years from creation or last effective date
• California: 25 years for records involving minors
• Other state-specific extensions applied where required by law
• Audit logs themselves are append-only — they cannot be edited retroactively

Deletion on request — GDPR Art. 17 / PDPA right to erasure

Veridoc's notarized consent records are insert-only by design. Once a consent is signed it cannot be edited or deleted — that immutability is the point. What we can do today, in line with GDPR Article 17 and the right-to-erasure provisions of the PDPA frameworks we operate under, is the following:

• Issue a signed revocation event appended to the chain referencing the original record
• Soft-delete patient-identifying fields (name, contact details, MRN mapping) on request, leaving the notarized payload intact as evidence
• Honor both the explicit-consent revocation path and the regulator-filed erasure request path

The notarized row itself is append-only — that is an architectural commitment to your auditors, not a deletion that can be reversed. To request erasure or revocation, contact privacy@veridoc.health or carlos@veridoc.health. We acknowledge erasure requests within two business days and complete them within 30 days.

Hosting region

Application hosting is provided by Render. The Postgres cluster is provisioned through Neon, which offers a regional residency option selected at signup. Pilot and Network tiers default to Singapore (ap-southeast-1) — closest to our most common Southeast Asia and Gulf customer footprint. Enterprise tier customers can select from Singapore, US-East (Virginia), and additional regions on request, to align with their Business Associate Agreement and data-residency commitments.

Document blob storage lives in Cloudflare R2, which is replicated across the region selected at bucket creation time. We do not move customer data between regions without a written change-control request from the customer's security officer.

Privacy frameworks — PDPA + GDPR Article 9

Patient data flowing through Veridoc is governed by the privacy framework of the patient's jurisdiction. For our Southeast Asia + Gulf destinations — Thailand, Singapore, Malaysia, and the partner hospitals we onboard in the Gulf — the controlling statute is the local PDPA:

• Thailand — Personal Data Protection Act, B.E. 2562 (2019)
• Singapore — Personal Data Protection Act 2012
• Malaysia — Personal Data Protection Act 2010
• Gulf partner hospitals — UAE Federal Personal Data Protection Law (Law No. 45 of 2021) and equivalent national statutes

For EU patients, health data is classified as a special category of personal data under GDPR Article 9. Our lawful bases for processing Article 9 health data are: explicit consent (Art. 9(2)(a)) captured at the moment the patient signs the consent form, and preventive medicine / occupational medicine (Art. 9(2)(h)) where the patient is under the care of a treating clinician and the data is processed for the delivery of care.

For deeper coverage of the regulatory framing — including HHS / HIPAA Technical Safeguards, FDA 21 CFR Part 11 e-signature requirements, and the EU/UK cross-border mechanics — see our HIPAA consent checklist at /resources/hipaa-consent-checklist and the patient-data portability rights guide at /resources/patient-data-portability-rights.