Security

Effective Date: August 2, 2025 | Last Updated: August 2, 2025

DocVerb separates patient identity from clinical documentation. Our server architecture is designed to exclude direct patient identifiers such as names, phone numbers, email addresses, dates of birth, government IDs, locations, and other demographic attributes from clinical processing, storage, and indexing. Clinical conversations are processed exclusively to extract relevant medical information for generating SOAP notes and prescriptions, without creating patient identity profiles.

Only SOAP notes, prescriptions, and a doctor-specific anonymous UID are securely stored. This UID maintains continuity of care exclusively within the same doctor–patient relationship without creating a universal patient identity.

1. Introduction and Scope

This page describes the technical and organisational security measures DocVerb implements to protect clinical documentation and account data. DocVerb is designed with data minimisation principles. We do not build centralized patient identity databases. We process audio transiently to generate documentation, then delete the source.

No certification claims: DocVerb does not hold SOC 2, ISO 27001, HIPAA, or any other formal security certifications as of the effective date. This page describes our implemented controls and architectural decisions honestly. We are building toward formal attestations over time.

Clinical documentation is protected using encryption at multiple layers. The treating healthcare provider remains responsible for clinical decisions. DocVerb assists with documentation and workflow.

2. Encryption

2.1 Encryption in Transit

  • TLS 1.3 for all external traffic (API, web app, webhooks, QR follow-up links)
  • TLS 1.2 minimum for legacy client compatibility (actively deprecated)
  • Certificate pinning on mobile SDKs where applicable
  • All internal service-to-service communication uses mutual TLS (mTLS) within the VPC

2.2 Encryption at Rest

  • AES-256-GCM for all persistent data stores (databases, object storage, backups)
  • Envelope encryption: Data Encryption Keys (DEKs) wrapped by Key Encryption Keys (KEKs) managed via cloud KMS (AWS KMS / GCP Cloud KMS)
  • Key rotation: KEKs rotated annually; DEKs rotated per-object on write
  • Customer-managed key (CMK) option for enterprise plans (BYOK)
  • Per-record encryption: Each SOAP/prescription record encrypted with key derived from Doctor ID + Patient ID — inaccessible without both
  • UID-unlinkable ciphertext: Encrypted records contain no metadata linking to UID or human identity

2.3 Key Management

  • Keys never leave cloud KMS; no plaintext key material in application memory
  • Separate key hierarchies per environment (prod, staging, dev)
  • Key access logged and alerted; break-glass procedures documented

3. Authentication

3.1 Session Management

  • JWT access tokens (RS256, 15-minute expiry) for API authentication
  • Refresh tokens (opaque, 30-day expiry, rotation on use, revocation on logout/password change)
  • Tokens bound to device fingerprint and IP subnet (configurable)
  • Concurrent session limits per role; admin can revoke all user sessions
  • Dual-ID token binding: Clinician tokens cryptographically bound to Doctor ID; patient-context operations require matching Patient ID claim

3.2 Multi-Factor Authentication (MFA)

  • TOTP (RFC 6238) with QR code enrollment; backup codes provided
  • WebAuthn/FIDO2 support for hardware security keys (YubiKey, platform authenticators)
  • MFA required for admin roles; optional but encouraged for clinicians
  • Step-up authentication for sensitive actions (export, user management, billing)

3.3 Password Security

  • Argon2id hashing (memory-hard, configurable parameters)
  • Minimum 12 characters; breached password check via HaveIBeenPwned API (k-anonymity)
  • Rate-limited login attempts with exponential backoff and CAPTCHA

3.4 UID-Based Access Control

  • Doctor ID + Patient ID required: Every data access request must present both identifiers — missing either returns 403
  • UID + timestamp validation: Record-level operations require UID and encounter timestamp — prevents replay and enumeration
  • No UID-to-identity resolution: Authentication service cannot map UID to human identity — no such mapping exists
  • Anonymous-by-default: All backend operations treat UIDs as opaque tokens; identity resolution only possible via external clinician-patient communication

4. Authorization and Access Control

4.1 Role-Based Access Control (RBAC)

  • Roles: Owner, Admin, Clinician, Staff, Billing, Read-only
  • Permissions scoped to practice/workspace; no cross-practice access
  • Custom roles for enterprise (fine-grained: create/read/update/delete per resource type)

4.2 Principle of Least Privilege

  • Service accounts use minimal IAM policies; no wildcard permissions
  • Just-in-time (JIT) access for engineering on-call (max 4 hours, logged, requires approval)
  • Production database access via bastion with MFA and session recording

4.3 UID Architecture: Anonymous Per-User Isolated Workspaces

  • Each doctor/practice gets a cryptographically isolated workspace (UID namespace)
  • No cross-patient linking: We do not store patient identifiers that could link consultations across providers
  • Data segregation enforced at application layer and database row-level security (RLS)
  • Export/deletion operations scoped to workspace only
  • Only SOAP notes and prescriptions stored — no patient identifying information (name, phone, Aadhaar, ABHA, DOB, address) ever persisted
  • First-process display only: Patient name/details shown on clinician screen once during encounter for verification, then never uploaded or stored
  • UID is not linked to human identification: The UID is anonymous in our server — no mapping to real-world identity exists in DocVerb systems
  • Identification only possible via external sharing: A UID can only be linked to a human if the UID itself is shared from outside our system (e.g., clinician tells patient their UID)
  • Dual-ID access control: Data accessible only when Doctor ID + Patient ID match — without both, data is cryptographically inaccessible
  • Four-factor identification: The only way to identify a specific record is Doctor ID + Patient ID + UID + timestamp — all four required simultaneously

5. QR Follow-Up Workflow Security

Patients receive follow-up instructions via signed URLs—no patient authentication required.

  • Signed URLs (HMAC-SHA256, 7-day expiry by default, configurable 1–30 days)
  • Ephemeral tokens: One-time use for sensitive actions (confirmation, form submission)
  • No patient accounts: No patient PII stored; no login, no passwords, no sessions
  • Content-Security-Policy and Referrer-Policy: no-referrer on follow-up pages
  • Rate limiting per IP and per signed URL to prevent enumeration
  • Audit log entry on every access (IP, user-agent, token ID, action)

6. Data Isolation and Segregation

  • Logical isolation: Row-level security policies enforce workspace boundaries at database level
  • Network isolation: Each workspace's data accessible only via authenticated, authorized API calls
  • No multi-tenancy in AI inference: Requests routed per-workspace; no shared context windows
  • Backup isolation: Encrypted backups per workspace; point-in-time recovery scoped to workspace
  • Zero-PII storage: Only clinical content (SOAP, prescriptions) persisted — zero patient demographic data
  • Transient display only: Identifying details rendered once client-side during encounter; never transmitted to or stored by backend
  • Anonymous UID namespace: UIDs contain no derivable link to human identity; server treats all UIDs as opaque anonymous tokens
  • Dual-key data access: Each record encrypted such that decryption requires both Doctor ID and Patient ID — missing either renders data unrecoverable
  • Four-factor record resolution: Exact record retrieval requires Doctor ID + Patient ID + UID + timestamp — prevents enumeration and cross-reference attacks

7. Network Security

7.1 VPC Architecture

  • Multi-AZ VPC with private subnets for all compute and data tiers
  • Public subnets only for NAT Gateway, ALB, and WAF
  • No direct internet access for application servers, databases, or inference workers
  • VPC Flow Logs enabled; anomalous traffic alerted

7.2 Web Application Firewall (WAF)

  • Managed rule sets (OWASP Top 10, known CVEs, IP reputation)
  • Custom rules for API abuse patterns (token stuffing, enumeration, scraping)
  • Rate limiting: 100 req/min per IP on auth endpoints; 1000 req/min on API
  • Geo-blocking for high-risk regions (configurable)

7.3 Network Segmentation

  • Security groups: default deny; explicit allow per service
  • Database accessible only from application subnets on specific ports
  • Inference workers in dedicated subnet; no outbound internet
  • PrivateLink / VPC Endpoints for cloud services (S3, KMS, Secrets Manager)

8. Monitoring, Logging, and Anomaly Detection

8.1 Audit Logging

  • Immutable audit logs (append-only, cloud object storage with Object Lock / WORM)
  • Events: authentication, authorization changes, data access, export, deletion, admin actions, AI generation
  • Each entry: timestamp, actor (user/service), action, resource, result, IP, user-agent, correlation ID
  • Retention: 2 years minimum; 7 years for export/deletion events
  • UID-anonymous logging: Audit entries reference opaque UIDs only — no patient names, demographics, or identity linkage
  • Dual-ID access logged: Every data access records Doctor ID + Patient ID pair — enables detection of unauthorized cross-patient access attempts

8.2 Security Monitoring

  • SIEM integration (cloud-native: CloudTrail/CloudWatch, GuardDuty, Security Hub or equivalent)
  • Real-time alerts for: failed MFA, privilege escalation, anomalous data access, geo-impossible login, token replay
  • Behavioral baselines per user/workspace; deviation triggers investigation
  • Monthly access review for privileged roles
  • Cross-patient access detection: Alerts on Doctor ID accessing multiple Patient IDs without matching UID/timestamp — indicates enumeration attempt
  • UID correlation monitoring: Detection of external UID sharing patterns (repeated UID+timestamp from different IPs/devices)

8.3 Vulnerability Management

  • Automated dependency scanning (SAST/SCA) on every PR; blocking on critical/high
  • Container image scanning in registry; no critical vulns in production images
  • Quarterly external penetration testing; annual red-team exercise
  • Bug bounty program (managed platform) for continuous coverage
  • SLA for remediation: Critical 24h, High 72h, Medium 14d, Low 30d

9. Incident Response

  • Documented IR Plan with roles, runbooks, communication templates, and escalation matrix
  • 72-hour notification to affected practices (Data Controllers) per DPDP Act Section 8(6) and GDPR Article 33
  • Notification includes: nature of breach, categories of data affected, likely consequences, measures taken, contact for further info
  • Post-incident: root cause analysis within 14 days; corrective actions tracked to closure
  • Annual tabletop exercise; quarterly runbook review
  • Cyber insurance covering incident response, notification, and regulatory defense costs

10. Vendor and Subprocessor Management

  • Data Processing Agreements (DPAs) with all subprocessors before onboarding
  • Subprocessor categories: Cloud infrastructure (AWS/GCP India regions), AI inference (GPU providers, India-hosted), Payments (Razorpay/Stripe), Email (SendGrid), Monitoring (Sentry/Datadog - anonymized)
  • Due diligence: Security questionnaire, SOC 2 review (where available), penetration test reports, insurance verification
  • Annual re-assessment; automatic offboarding trigger for material security regression
  • Subprocessor list and DPA status available on request: docverb.no.reply@gmail.com
  • No subprocessors added without 30-day advance notice to practices (opt-out right per DPDP)
  • Zero-PII subprocessor exposure: Subprocessors receive only encrypted SOAP/prescription content — no patient identifiers, names, or demographics ever transmitted
  • UID-opaque processing: AI inference and monitoring vendors see only opaque UIDs — cannot correlate to human identity
  • No identity resolution capability: No vendor has Doctor ID + Patient ID + UID + timestamp combination — four-factor identification impossible outside DocVerb

11. Secure Development Lifecycle (SDLC)

  • Threat modeling for new features (STRIDE); documented in architecture decision records (ADRs)
  • Code review mandatory: 2 approvals required; security-focused review for auth, crypto, data handling
  • Static analysis (SAST) and Software Composition Analysis (SCA) in CI pipeline
  • Secrets detection: Pre-commit hooks + pipeline scanning; no secrets in repo history
  • Environment parity: Staging mirrors prod (data masked); no production data in dev
  • Deployment: Blue/green with automated canary analysis; rollback on error rate or latency regression
  • Infrastructure as Code: Terraform; policy-as-code (OPA) for security guardrails

12. Physical and Environmental Security

  • Cloud provider physical security (AWS/GCP data centers): SOC 2, ISO 27001, PCI DSS certified facilities
  • No DocVerb-owned hardware; all compute in cloud provider facilities
  • Employee equipment: Full-disk encryption (FileVault/BitLocker), MDM enrollment, remote wipe, auto-lock

13. Personnel Security

  • Background checks for all employees and contractors (per local law)
  • Annual security awareness training (phishing simulation, secure coding, incident reporting)
  • Confidentiality and IP agreements; role-based data access; offboarding revokes access within 4 hours
  • No single person can deploy to production without peer review

14. What We Are Building Toward

We are transparent about our roadmap for formal assurance:

  • SOC 2 Type II: Targeting audit readiness by Q2 2026; report anticipated H2 2026
  • ISO 27001: ISMS implementation aligned; certification target 2027
  • HIPAA attestation: BAA available for US-covered entities on enterprise plans; technical controls mapped to HIPAA Security Rule
  • ABDM integration: Active development for ABHA-linked workflows; compliance page at ABDM Status
  • Penetration test publication: Annual summary report (redacted) for customers
  • Customer security questionnaires: Standardized CAIQ/CAIQ-Lite responses maintained and current

15. Related Policies

16. Contact

Security questions, vulnerability reports, or requests for subprocessor details:

docverb.no.reply@gmail.com (Subject: Security)

We commit to acknowledging security reports within 48 hours. For vulnerability disclosure, we follow coordinated disclosure principles.