Security and privacy at Senno GDPR by design

A clinic’s data stays the clinic’s. By design.

Senno runs the daily work between dental clinics and laboratories. It holds patient health data, so security is not a layer we added. It is how every data, key and release is built.

16,500+
automated tests before every release
1 key
per patient, AES-256-GCM
0
messages sent before a person allows it
Isolation

Each clinic is walled off inside the database

Row-level security on every table means a clinic’s rows are invisible to every other organisation, even to a faulty query.

Learn more
GDPR by design

Every patient right is a working feature

Consent, access, portability, rectification and erasure are built into the product, ready to show to a patient or a regulator.

Learn more
Erasure

Forget a patient everywhere, even in backups

Each patient has their own encryption key. Destroy it and their data is unreadable at once, in the database and in every backup.

Learn more
AI privacy

The AI reads pseudonyms, not names

Names and contacts are replaced before text reaches the model, and every suggestion waits for a person to sign it.

Learn more
Outbound guard

Nothing leaves without a person

SMS and e-mail stay held until a person opens the door for that organisation. With no decision, the door stays closed.

Learn more
Proven on every release

16,500+ automated checks before anything ships

Many of them read the code itself to catch a missing scope, a leaked secret or an unchecked route before it reaches a clinic.

Learn more

GDPR by design

Every patient right is a feature in Senno, not paperwork.

Senno processes health data for clinics and laboratories, who stay in control of their patients' data. For each right and duty in the GDPR there is a working answer in the product, ready to show to a patient or a supervisory authority.

Health data · Art. 9 Privacy by design and default · Art. 25 Security of processing · Art. 32 Accountability · Art. 5(2)
Art. 6 · 7 · 9 · in the product today

Explicit consent for health data and AI

Health data is a special category under the GDPR. Before every interaction with Senno’s AI assistant, the patient’s explicit consent is checked. Without it, the assistant does not process their data, and the patient can withdraw consent at any time.

Consent checked on every AI interaction.
Art. 15 · 20 · in the product today

Access and portability

Patients export their own data themselves, in a portable format, without filing a request or waiting for the clinic.

Self-service export in the patient area.
Art. 16 · in the product today

Rectification that keeps the history

A correction is a new, attributed version. The record becomes accurate and the trail of who changed what, and when, stays complete.

Append-only histories enforced by the database.
Art. 17 · in the product today

Erasure that reaches the backups

Destroying a patient’s personal key makes their data unreadable everywhere at once, including in backups. The erasure itself stays on record as proof.

Previewed first, irreversible by design.
Art. 5(1)(c) · 25 · in the product today

Minimisation and privacy by default

The AI reads text with names and contacts replaced by pseudonyms. Messages stay held until a person allows sending. Each team member sees only what their role needs.

Defaults are closed, never open.
Art. 32 · in the product today

Security of processing

Per-patient AES-256-GCM encryption, isolation of each organisation inside the database, encrypted off-site backups with tested restores, and more than 16,500 automated tests before every release.

Each control is guarded by an automated check.
Art. 5(2) · 30 · in the product today

Accountability you can show

A hash-chained audit record shows who did what and when, sealed by signed checkpoints. Clinics can demonstrate their processing to a supervisory authority.

Change one byte and the chain stops matching.
Art. 28 · in the product today

The clinic in control, Senno as processor

Clinics and laboratories decide; Senno processes on their behalf. Each organisation’s data is walled off from every other one inside the database itself.

Row-level security on every table.

How the API is protected

Three ways in. One set of checks for all of them.

A person in the browser, a partner integration and Senno's own AI assistant all reach the same API. Each proves who it is in its own way, and then every request passes the same capability check, the same organisation scope and the same row-level security in the database.

Who calls
How they prove it
Senno API
Data layer
A person
Browser, phone or desktop app
An integration
Script, import or partner system
The AI assistant
Acting for a signed-in person
Single sign-on
1-hour access · optional 2FA
Scoped token
Hash only · expires · revocable
Assistant tools
No names out · writes are proposals
1 · Capability check
This role may do this exact action 2 · Scope declared
One organisation, or it does not run 3 · Same transaction
Change and audit commit together 4 · Outbound guard
Nothing is sent until a person allows it
Row-level security
Only that organisation's rows
Patient keys
AES-256-GCM, one per patient
Audit chain
Hash-linked, append-only
Every caller, person, integration or assistant, ends at the same capability, scope and row-level security checks. No route skips them.

Three callers, one gate. Whatever the way in, a request ends at the same capability check, organisation scope and row-level security.

A clinic or laboratory person signs in once through single sign-on. Access lasts one hour and renews quietly; two-factor codes can be required per person.

Integrations use a scoped token created for one job. Senno keeps only its hash, it expires on its own, and it can be revoked at any moment.

The assistant acts for the signed-in person through tools that never return names or contacts. What it writes is a proposal until that person signs.

Follow one request: six checks between a click and a patient record

  1. 01
    Single sign-on
    The person signs in through Senno’s identity provider, with optional two-factor codes.
  2. 02
    Capability check
    The API checks that this role may perform this exact action.
  3. 03
    Scope declared
    The transaction states which organisation it acts for, or it does not run.
  4. 04
    Row-level security
    PostgreSQL returns only rows of that organisation, even to a buggy query.
  5. 05
    Patient key
    Sensitive fields decrypt only with that patient’s own key.
  6. 06
    Audit chain
    The action is written to the hash-linked record in the same transaction.

Tokens and credentials

Short-lived, narrow, and stored only as a hash

Every way into Senno has its own kind of credential, built for one job. Each is tied to one organisation and to named capabilities, so a credential that leaks opens one narrow door for a short time, and it can be closed at once.

Sign-in session

1 h
People in the browser and apps
Issued by single sign-on after the person proves who they are, optionally with a two-factor code. Renews quietly while the person keeps working.

Personal token

≤ 24 h
A person’s own automation
Created by a signed-in person to act as them in one organisation. Stored only as a hash, revocable at once, and it cannot create further tokens.

Integration token

scoped
Partner systems and imports
Bound to one organisation and to the capabilities the integration needs, nothing more. Every use is checked like any other request.

Assistant access

per person
Senno’s AI assistant
Acts only for the person who asked, with tools that return no names or contacts. Its writes are proposals for that person to sign.

Device token

per device
The laboratory desktop agent
One per installed device. Files it uploads belong to that device until a person links them to a case.

The life of a personal token

  1. 1Issue
    A signed-in person creates it for one organisation.
  2. 2Store
    Senno keeps only a hash. The secret is shown once.
  3. 3Use
    Each call passes capability, scope and row-level security.
  4. 4Expire
    It stops working on its own, at most 24 hours later.
  5. 5Revoke
    Revoked at any moment; the next call is refused.

Security principles in use today

Ten principles. Each one is code, not a policy document.

An automated check guards every principle below. If a change breaks one, that change does not ship.

Tenant isolation in the database

Every table enforces row-level security, forced even for the table owner. The application runs as a role without superuser rights, and every transaction declares which organisation it acts for.

Guard: a new table without forced row-level security fails the build.

One encryption key per patient

Clinical notes and identity fields are encrypted with AES-256-GCM. Each patient has their own data key, wrapped by a master key that is kept outside the backups.

Guard: every patient is created with a key.

Erasure by destroying the key

The right to be forgotten is cryptographic: destroying a patient’s key makes their data unreadable in the database and in every backup, while the audit record of the erasure stays.

Irreversible by design, previewed before it runs.

Hash-chained, append-only audit

Each audit record carries the fingerprint of the previous one, sealed by signed checkpoints. Histories cannot be edited or deleted: a correction is a new reversing record.

Database triggers refuse UPDATE and DELETE on histories.

Single sign-on and least privilege

People sign in through single sign-on with optional two-factor codes. What each person may do comes from explicit capabilities per role, never from being inside a network.

Guard: every route names the capability it needs.

Short-lived, revocable access tokens

Automation acts through personal tokens that live at most 24 hours, are stored only as a hash, can be revoked at once and can never create further tokens.

A database rule caps the lifetime at 24 hours.

AI proposes, a person signs

The assistant reads and suggests. Notes, messages and financial actions stay proposals until a person accepts them. Text reaches the model with names and contacts replaced.

Assistant tools never return a name, phone or address.

Nothing leaves without a person

SMS and e-mail stay held until a person opens the door for that organisation. With no explicit decision, the door is closed.

Closed by default: no row means no sending.

Secure development, proven on every change

More than 16,500 automated tests run on every release batch. Many read the code itself to catch a missing scope, a leaked secret or an unchecked route. New checks are proven by breaking the code on purpose.

Secrets are never in the repository, and a test enforces it.

Encrypted backups, tested restores

Databases and files are backed up daily. Copies leave the server only encrypted, and restore drills run on a schedule. The master key is never inside a backup.

Releases are verified on the live service after every deploy.

Compliance map

Built to the controls of GDPR, SOC 2 and ISO/IEC 27001

These three are different things. GDPR is the law we work under. SOC 2 is an audit report on a service's controls. ISO/IEC 27001 certifies how an organisation runs security. None of them certifies software. Pick a framework and a principle to see where each control lands.

GDPR · Built in
SOC 2 · Controls mapped · report on roadmap
ISO/IEC 27001 · Controls mapped · certification on roadmap

Tenant isolation in the database

Every table enforces row-level security, forced even for the table owner. The application runs as a role without superuser rights, and every transaction declares which organisation it acts for.

GDPRArt. 32(1)(b)
SOC 2CC6.1
ISO/IEC 27001A.8.3

Senno acts as processor for clinics and laboratories, which remain controllers of their patients’ data. Article numbers refer to Regulation (EU) 2016/679.

SOC 2 is an independent auditor’s report on a service’s controls against the Trust Services Criteria. Codes refer to the 2017 criteria. Senno has no SOC 2 report yet.

ISO/IEC 27001 certifies an organisation’s security management for a defined scope, here the Senno platform. Codes refer to Annex A of the 2022 edition. Senno is not certified yet.

Health data

Every patient has their own key. Erasure destroys it.

Clinical notes and identity fields are encrypted with AES-256-GCM using a key that belongs to one patient. That key is itself encrypted by a master key kept outside the backups. When a patient asks to be forgotten, Senno destroys their key: the data becomes unreadable everywhere at once, including old backups. The audit record of the erasure stays.

  • Search without decrypting, through a blind index
  • Patients export their own data (GDPR Art. 15 and 20)
  • Backups leave the server only encrypted, and restores are tested
Patient record · demo Key activeKey destroyed
Name
Joana M.7f3a·c91e·04bb·e2d0
Clinical note
Crown on 36, shade A2a9e1·77f0·d3c2·5b18
Phone
+351 9•• ••• •••0c4d·91aa·e7f3·2b60
Audit record
kept · erasure loggedkept · erasure logged

Demo data. In Senno the erasure is previewed first and cannot be undone.The data is still there, but no one can read it any more, in the database or in any backup.

AI with a person in charge

The AI prepares. A person decides and signs.

Senno's assistant reads and proposes. Every clinical note, message or financial action it suggests stays a proposal until a person accepts it. Names and contacts in text are replaced with pseudonyms before the model reads them, and the assistant's tools never return a name, phone or address.

Before any interaction with the assistant, Senno checks the patient's explicit consent. Voice notes and files a patient chooses to send are processed only under that consent.

What the clinic seesAna Costa (912 345 678) reports pain on tooth 36 since Monday. Asks for the first slot with Dr. Ribeiro.
What the AI model reads[PATIENT·A7] ([PHONE]) reports pain on tooth 36 since Monday. Asks for the first slot with [DOCTOR·2].
Proposal · waits for the dentist's signature

Tamper-evident audit

Nothing is deleted. Everything is versioned and chained.

Each audit record carries the fingerprint of the one before it, and signed checkpoints seal the chain. Change one byte in the past and every later record stops matching. Histories are append-only: a correction is a new record that reverses the old one.

  1. #10419f3a…e1
    Case sent to lab
    prev 4c07…b2
  2. #1042b61d…07
    Quote approved
    prev 9f3a…e1
  3. #10432e88…c4
    Note signed
    prev b61d…07
  4. #1044d09c…5a
    Access granted
    prev 2e88…c4
  5. #104571fe…93
    Checkpoint sealed
    prev d09c…5a

Where we are, plainly

The controls are built. Certification is the next step, not a claim.

Senno is not yet audited against SOC 2 or certified to ISO/IEC 27001. We publish what is done and what comes next, and partners can follow every open item in the tracker.

  1. Today
    Controls in code
    Isolation, per-patient encryption, crypto-erasure, audit chain, outbound guard and AI proposals run in production.
  2. Next
    Assurance groundwork
    Platform impact assessment, external penetration test, signed processor agreements and a public subprocessor list.
  3. Then
    SOC 2 Type I
    An independent auditor reports on how the platform’s controls are designed, at a point in time.
  4. After
    ISO/IEC 27001 and SOC 2 Type II
    Certification of the platform scope, and an audit of how controls operate over months. No dates committed.

Need the details for your own review?

We share the security pack, the subprocessor list and the open-items tracker with clinics, laboratories and partners under NDA.

Request the security pack Partner sign-in to the tracker