How we protect your data

• Defence-in-depth: every request passes through perimeter filtering, authentication, authorisation, tenant scoping, and per-resource access checks before reaching data.
• Least-privilege by default. Production access is just-in-time and logged; no standing admin sessions.
• Security review is mandatory for changes to authentication, authorisation, billing, payments, and any code path that handles PHI.

• At rest: AES-256 (AWS KMS-managed keys). Database volumes, object storage, backups, and audit logs are all encrypted.
• In transit: TLS 1.2+ on every public endpoint. HTTP Strict Transport Security enforced. Modern cipher suites only.
• Application-level encryption: secrets and payment-token material are encrypted with a separate envelope key before they touch storage.

• Role-based access control (RBAC) with hierarchical roles — PLATFORM_OWNER > SUPER_ADMIN > ORG_ADMIN > clinical roles.
• Multi-factor authentication available for every account; required for PLATFORM_OWNER and SUPER_ADMIN.
• JWT sessions with refresh rotation; revoked centrally on logout or suspected compromise.
• Patient app sessions signed with a separate key and a distinct audience — they can’t be used against staff surfaces.

• Per-tenant PostgreSQL schema. The “search_path” is set at connection acquisition time and cleared at release — one tenant’s query cannot cross into another tenant’s schema.
• Row-level access checks in every service. Tenant ID is never trusted from a request body; it is resolved from the authenticated session and validated against every resource.
• Shared “public” schema carries only cross-tenant infrastructure (user accounts, Master Patient Index, billing registry) — never clinical content.

Every view, create, update, and delete of PHI is recorded to an append-only audit log with actor, timestamp, resource, tenant, and before/after where applicable. Retention: 6 years from event. Tenants can view their own audit log through the admin console.

• Continuous point-in-time recovery on the primary database (last 14 days).
• Nightly snapshot retained for 30 days.
• Target RPO: 15 minutes. Target RTO: 4 hours.
• Restore drills quarterly; results logged internally.

• Annual third-party penetration test covering the web application, public API, mobile apps, and supporting infrastructure.
• Continuous dependency scanning (CVE monitoring with time-bound patching SLAs).
• Static application security testing (SAST) and dependency analysis in CI for every pull request.

We welcome reports from independent researchers. Report vulnerabilities to security@tryvedge.com — we acknowledge within 2 business days and will work with you on remediation and (where appropriate) public disclosure timing. Good-faith research that stays within the rules below will not trigger legal action:

• No testing against production records of real patients; use your own test accounts.
• No denial-of-service, social engineering, or physical attacks.
• Keep findings confidential until we’ve had a reasonable chance to fix them (90 days default).

Our incident-response plan runs on a 24-hour clock. On confirmation of an incident we:

• Open an internal incident channel and assign an Incident Commander.
• Notify affected tenants within 48 hours.
• For incidents meeting the CSA Critical Information Infrastructure threshold, notify 24 hours to CSA for designated CII operators.
• Publish a post-incident review after resolution, with tenant-facing detail proportional to impact.

• Ghana Data Protection Act 2012 (Act 843) — registered processor. See Privacy Policy.
• Ghana Cybersecurity Act 2020 (Act 1038) — we monitor CSA directives and will register on designation.
• SOC 2 Type I — roadmap: Q4 2026 observation window, report Q1 2027.
• PCI-DSS — card data is handled exclusively by our payment sub-processors; Vedge is a SAQ-A merchant scope only.