1. In short
#FlowDule is a B2B SaaS platform where practitioners and clinics work with client, health record and health data. The data is private, and the security level has been set accordingly. Here you and your adviser can see what we do, and what you are responsible for yourselves.
The description is an overview. It does not contain credentials, network details, known vulnerabilities or customer-specific configurations. The binding security level is set out in the data processing agreement you have accepted and in the version-bound TOMs annex.
The security work rests on four things:
- confidentiality: only identified and authorised persons and systems are given the access the task requires;
- integrity: changes, sharing, deletions and administrative actions can be traced afterwards;
- availability and resilience: critical data and functions can be recovered;
- data protection by design and by default: the least possible access, the least possible data, the least possible sharing and retention and the fewest possible third parties is the starting point.
We test and assess the measures regularly.
2. Allocation of responsibility
#| Party | Primary security responsibility |
|---|---|
| FlowDule | Platform, code, cloud environment, secure configuration, internal access, suppliers, support, backup/restore, incident handling and assistance to the customer. |
| The customer | Lawful purpose, user and treatment relationships, correct professional profile, local devices and networks, user administration, sharing, retention, control of look-ups and local emergency procedures. |
| The user | Personal account, protection of login and devices, data minimisation, correct use, checking of AI output and prompt reporting of suspicions. |
| The sub-processor | The agreed security and data protection obligations for the specific service and configuration. FlowDule carries out risk-based control. |
Your responsibility does not limit our responsibility for our own measures. And our security does not remove your duty to choose an appropriate configuration and to keep track of whether your own users have lawful access.
3. Infrastructure and environments
#FlowDule’s production runs on Kinsta (Sevalla) in Google Cloud data centres: the API, the database, the web app and the booking sites; the database is located in Frankfurt. Cloudflare provides the edge and TLS in front of the platform and object storage (Cloudflare R2) for media and database backups. AWS (EU) is used for login, e-mail, AI services and key management. The current overview of suppliers, services and regions is set out in Sub-processors and suppliers.
Development, staging and production are separate environments. We do not use production for testing, and we do not copy real client and health record data into development or ordinary testing. There we use fictitious data, or data that is otherwise lawfully approved and minimised for the purpose.
4. Identity and access
#Users sign in with personal accounts via AWS Cognito, not with shared login credentials. Access follows the role and the relationship on a least-privilege basis, so that a user sees only what the role in the chain and at the location gives access to.
FlowDule’s own platform users sign in with multi-factor authentication. Your own users can switch it on for their own account. Access tokens are validated centrally and have a limited lifetime.
We close an access when a person leaves, when an account has been compromised, or when the business need falls away, and we review the broad and privileged accesses at regular intervals.
Our support opens your content only in a specific case, after the necessary approval, with a personal login, for the shortest possible time and with logging. There is no hidden permanent administrator role.
5. Customer and data separation
#FlowDule is a multi-tenant platform: several customers share the same platform. Customer separation is enforced in the relevant layers, in the app, in the api, in the application logic, in the database and in file access. In the database this is done with row-level security. The separation is also tested with attempts to gain access across customers, locations and roles.
Access is determined by chain affiliation, role, location and the specific work or treatment relationship. A user is not given access to a client merely because the user belongs to the same customer, where the chosen customer model is built on a narrower relationship. The same principle applies to privileged database and support routes.
6. Encryption and secrets
#Traffic between you and the platform is encrypted with TLS. Sensitive health record fields are additionally encrypted at field level with keys managed in AWS KMS.
Credentials, tokens, encryption keys and other secrets are not held in source code, in ordinary logs or on screen. Access to them is granted on a need-to-know basis, is recorded and is rotated on compromise and in accordance with the key plan.
We provide details of the encryption and of access to keys only on a need-to-know basis and through a secure channel.
7. Logging and follow-up on access
#Actions involving client and health record data can be traced to a named user or to an unambiguous system component. Depending on the risk, this covers reading, searching, creation, modification, download, export, sharing, revocation, deletion and administrative actions with elevated privileges, among other things.
Logs contain the context needed to investigate an action, but not health record text, passwords or tokens. They are protected against modification and unauthorised reading, are kept for a fixed period and are then deleted automatically. Follow-up on logs is objectively justified, limited to a purpose and access-restricted.
Look-ups in health records are logged. We have automatic alerts for errors, for failed writes to the audit log, for mass look-ups in health records and when a new platform owner is created. The alerts are collected in an e-mail, and the critical ones are also escalated by text message.
You follow up yourselves on whether your own users’ look-ups are work-related. We provide the functionality and the agreed assistance.
8. Development and changes
#Changes go through automated tests and code review before they are released. The api’s dependencies are monitored automatically with Dependabot, which flags new versions and proposes updates. If we find a critical matter, we block, restrict or roll back the change. Changes to data flows, access, networks, encryption, logging, retention, regions and suppliers are assessed for risk first, and they can be rolled back.
9. Files and malicious content
#We restrict uploads by file type, size, file signature and the function the file belongs to. Neither the file nor its metadata provides a way around customer separation, the access rules or the secure file rendering.
Uploaded files are not virus-scanned.
10. Suppliers and transfers
#Before a supplier receives personal data, we look at:
- the supplier’s legal role, the service, the data it processes and the data subjects;
- the contractual basis, including the data processing agreement and the relevant security guarantees;
- the countries of processing, remote support and the sub-supplier chain;
- access, encryption, logs, retention, deletion, incidents and exit;
- any transfer basis and the supplementary measures.
We enter into a data processing agreement with the necessary security guarantees.
Hosting in the EU does not in itself rule out transfers to third countries, for example through remote support or a supplier outside the EU. The video module uses LiveKit (USA); sessions are not bound to the EU, and the transfer takes place under LiveKit’s data processing addendum, which forms part of LiveKit’s terms: the EU-US Data Privacy Framework where LiveKit is certified, otherwise the EU standard contractual clauses. The current supplier overview is set out in Sub-processors and suppliers.
11. Backup, restore and continuity
#The database is backed up daily to Cloudflare R2 with 30 days’ rotation. As part of the recovery procedure, restore must be tested in an isolated environment, and registered deletions and legal holds must be reapplied before the environment is opened.
FlowDule does not promise particular RPO, RTO, backup or uptime targets unless they are expressly agreed in an SLA. Your local emergency procedure must be able to function without insecure private e-mails, chats, shared documents or unauthorised devices.
After a restore, we review that the data is technically complete. You review your own critical professional data and record afterwards what is missing, so that it can be traced.
12. Security incidents and personal data breaches
#We treat any suspicion of a loss of confidentiality, integrity or availability as a security incident. We record, contain and investigate it and preserve the necessary material without making unnecessary copies of sensitive content.
Where a personal data breach concerns your data, we notify you without undue delay and give you the information we have, as we have it. As controller, you decide whether the breach is to be notified to the supervisory authority and whether the data subjects are to be informed. Our own procedure does not delay your deadline.
If you suspect a security incident, write immediately to security@flowdule.com. Ordinary support questions should be sent to support@flowdule.com.
13. Retention, deletion and legal hold
#Your retention profile follows professional group, country, data category and purpose. We do not automatically apply a health law record retention period to self-employed psychotherapists who are not covered by that special rule.
A deletion covers the relevant databases, files, shares, queues, caches, export files and other active copies. Backups are phased out through the ongoing rotation. Until they expire they are protected and are not used for anything else.
We apply a legal hold only where there is a specific obligation, a dispute or a lawful instruction. It is limited to the necessary persons, objects and data categories, is assessed at regular intervals and is lifted traceably.
14. AI security
#The AI features in the health record are part of the journal module and not a general access to your data. They are available to the chain’s users according to their role; there is no separate activation step for each individual AI feature. The model, data, regions, retention and suppliers are set out in the AI information, your data is not used to train AI models, and we can immediately switch a feature or model off in the event of serious or repeated errors.
AI output that is to be used in the health record or towards a client is a draft. A competent user must review the source, the facts, negations, figures, dates, the person and the professional context before the result is saved or shared. Some results are not approved individually, including the automatic note feedback and the machine translation of shared content for the client. FlowDule’s AI does not itself make diagnostic, triage, treatment or access decisions.
Further information is available in AI information.
15. Training and confidentiality
#Everyone with internal or privileged access is subject to a duty of confidentiality. They are instructed before they are given access, and regularly thereafter, in phishing, credentials, health record data, support access, logging, incidents, AI and immediate reporting, among other things.
We record who has access and when they were instructed. Deliberate misuse, sharing of credentials, circumvention of security rules or concealment closes the access immediately and may have employment or contractual consequences.
16. Documentation, audit and customers
#You can obtain documentation and carry out an audit under the Data Processing Agreement. The starting point is the TOMs annex you have accepted, the results of our own testing, the suppliers’ own documentation and any independent assurance reports. Information that could weaken security or other customers’ confidentiality is passed on only through a secure and confidential process.
17. Limitation of public promises
#This description is not an SLA and does not in itself guarantee any particular uptime, recovery time, data loss limit or certification. FlowDule is not ISO 27001 or SOC 2 certified.
If this text differs from the accepted, version-bound TOMs annex, the TOMs annex prevails for the customer in question. A later improvement does not tacitly change the customer’s agreed instructions or security level.
18. Legal sources
#The Trust Center explains security and GDPR in plain language: Go to the Trust Center. Every document in force has a date and a version: See all documents.