DentalX Back to home

Schedule 2: Technical and organisational measures

MDPA-S2 · Draft of October 6, 2026 · revision 1 · version 1.0

Part of Master Data Processing Agreement

Final draft for counsel's review. It is not in effect, and no clinic has accepted it. Items still to be confirmed are highlighted in the text.

Which language controls depends on the clinic's country: English, Español, Português, Français.

Read in: English · Español · Português · Français

SHA-256 of this text: 2baf20e09879b1cbb4fff8d0e095675c2604770eb15f1051fbb905488bdd45bb

Schedule 2 — Technical and organisational measures

These are the measures in force at the Effective Date. They are described as the Service is built, not as it may become.

A. Encryption

  1. In transit. All traffic between browsers and the Service, and between the Service and its Sub-processors, is encrypted with TLS.
  2. At rest (provider). Google encrypts all data that DentalX stores on Google Cloud at rest.
  3. Field encryption (DentalX).
    • Before they are stored, DentalX encrypts the following with AES-256-GCM:
      • the patient record's name, date of birth, telephone, address, emergency contact, medical history and insurance details; and
      • consent forms and prescriptions written from [[TO CONFIRM: date phase B′ went live — 2026-10-06]].
    • Consent forms and prescriptions written before that date are being sealed by a migration [[TO CONFIRM: completion date of the sealing sweep (phase C)]].
    • The patient's email address is not field-encrypted.
    • A patient's name is copied without field encryption onto the records that need it: appointments, invoices, treatments, recalls, consent forms and prescriptions. Appointments also carry the patient's telephone and email, and WhatsApp conversations the patient's telephone. Those copies, and records such as treatment notes, images, documents and messages, are protected by the provider encryption in item 2 and by the controls below.
  4. Key custody. The field-encryption key is held in Google Secret Manager in VstreamX's own Google Cloud project, with access restricted to the service identity that encrypts and decrypts and to VstreamX's project administrators. An off-platform sealed copy is kept for recovery [[TO CONFIRM: owner's confirmation of the off-platform key copy]]. Because the key is held within Google Cloud, the field encryption protects against exposure of the stored data and against access by persons who lack access to the key. It is not relied on as a supplementary measure against access compelled from Google itself. [[TO CONFIRM: whether VstreamX will move key custody to Cloud EKM/HSM under external control, which would change this statement]]

B. Access control and isolation

  1. Each clinic's data is isolated by database and storage security rules that deny access by default and allow a User to reach only the data of the clinic they belong to.
  2. Within a clinic, each User sees and does only what their role (owner, manager, dentist, receptionist) allows. Clinical AI features are available only to owners, managers and dentists.
  3. Each person has their own login; shared logins are prohibited by the Terms.
  4. Multi-factor authentication:
    • DentalX asks for a second factor at sign-in from every User who has set one up.
    • A clinic owner can make a second factor mandatory for the clinic's owners and managers.
    • VstreamX's own staff must use a second factor to open DentalX's administrative console.
  5. Session control. A User is signed out after eight hours without activity, including when the browser was closed in the meantime.
  6. Links. Links sent to patients expire, and a consent-signing link works once.
  7. VstreamX personnel.
    • DentalX's administrative console does not show patient records to support staff.
    • Access to the Google Cloud project is limited to named administrators, using individual accounts with multi-factor authentication. [[TO CONFIRM: that every Google Cloud project administrator account enforces 2-step verification]]

C. Logging and monitoring

  1. Audit trail. DentalX records the opening of a patient's chart, exports and deletions, and changes to patient and treatment records, with the User and the time. It is kept for seven years while the Clinic's account is active, and after the end as clause 14.5(c) provides. It does not record every read, such as the opening of a stored file. [[TO CONFIRM: roadmap date for read-access logging of every patient-data view, including file opens, list views and exports that show a patient's identity; Manitoba, Nova Scotia, Sweden, Norway, Italy and the Netherlands do not open to new Clinics until it is live]]
  2. The audit trail records no IP address.
  3. Server logs are kept for 30 days, and error reports and performance measurements for 90 days.

D. Availability and resilience

  1. The database is backed up daily. Seven days of backups and seven days of point-in-time recovery are kept, in the same Google Cloud project.
  2. Files are stored with version history, as clause 14.5(b) describes.

E. Data minimisation in the browser

  1. DentalX uses no advertising, analytics or session-replay tools.
  2. To load quickly, the app keeps a working copy of the clinic's records in the browser. The patient record's encrypted fields stay encrypted in it. Signing out from the menu erases the working copy.

F. Secure development and operations

  1. Dependencies are audited for known critical vulnerabilities before each production deployment. A deployment that fails this check does not proceed.
  2. Production deployments are made only through VstreamX's controlled deployment process.
  3. A Content-Security-Policy restricts the third-party hosts a DentalX page may load or call to those disclosed on the sub-processors page.

G. Organisation

  1. Personnel with access to Clinic Data are bound by the confidentiality and secrecy undertaking in clause 5.3, receive privacy and security training on joining and every year, and lose access when their role ends. [[TO CONFIRM: that written confidentiality undertakings and annual training are in place for every person with production access]]
  2. VstreamX maintains an incident-response procedure that implements clause 9, including the 24-hour initial notice and the breach register.
  3. VstreamX's accountable individual for privacy is named in clause 24.1.
  4. Independent certification. VstreamX does not hold an independent security certification of its own at the Effective Date. Its hosting Sub-processor, Google Cloud, holds the certifications listed on its compliance pages (including ISO/IEC 27001, 27017 and 27018 and SOC 2). [[TO CONFIRM: that VstreamX holds no ISO 27001 / SOC 2 / NEN 7510 certification today]]