Security description

Document ID: O-07
Version and date: 2026-08-21.1 - 21 August 2026
Provider: FlowDule ApS, CVR 46273397
Contact: security@flowdule.com

Purpose: This description gives customers and users an understandable overview of FlowDule’s security model. It does not contain credentials, network details, known vulnerabilities, customer-specific configurations or information that could weaken security. The binding security level follows from the accepted data processing agreement, the customer annex and the version-bound TOMs annex.

1. Security level and risk profile

FlowDule is a B2B SaaS platform that may process client, health record and health data on behalf of practitioners and clinics. The private nature of the data calls for a high, risk-based and continuously controlled security level.

The security work is built on:

• confidentiality: only identified and authorised persons and systems are given the access they need;

• integrity: relevant changes, sharing, deletions and administrative actions must be capable of being checked;

• availability and resilience: critical data and functions must be recoverable under documented and tested procedures;

• data protection by design and by default: the least possible access, data, sharing, retention and third-party enablement is the starting point;

• documented effectiveness: a control is not regarded as verified merely because it has been designed or exists in code.

2. Allocation of responsibility

The customer’s responsibility does not limit FlowDule’s responsibility for its own measures. Nor does FlowDule’s security replace the customer’s duty to choose an appropriate configuration and to control its own users’ lawful access.

3. Infrastructure and environments

FlowDule’s core platform runs on Amazon Web Services. The accepted combination of supplier, service and region follows from Sub-processors and suppliers and from the customer’s instruction annex.

Development, staging and production are treated as separate environments. Production is not a test environment. Real client and health record data may not be copied into development or ordinary testing. Testing uses synthetic data or data that is otherwise lawfully approved and minimised.

Changes to data flows, access, networks, encryption, logging, retention, regions and suppliers require a risk assessment, relevant testing, the ability to roll back and updated documentation before release.

4. Identity and access

FlowDule’s security model requires:

• personal accounts rather than shared login credentials;

• role- and relationship-based access on a least-privilege basis;

• multi-factor authentication for privileged and internal production access;

• central validation and limited lifetime for access tokens;

• prompt blocking on departure, compromise or the access no longer being needed for the work;

• regular reassessment of privileged and broad access.

Support access to customer content may take place only in a specific and documented case, after the necessary approval, with a personal identity, for the shortest possible duration and with relevant logging. Emergency access must not amount to a hidden permanent administrator role.

5. Customer and data separation

FlowDule is a multi-tenant platform. Customer separation must be enforced in the relevant layers, including the user interface, the API, the application logic, the database and file access.

Access is assessed by customer affiliation, role, location and the relevant work or treatment relationship alike. A user must not be given access to a client merely because the user belongs to the same customer organisation, where the chosen customer model requires a narrower relationship.

Isolation is tested with positive and negative scenarios, including attempts to gain access across customers, locations and roles. Privileged database and support routes are covered by the same control principle.

6. Encryption and secrets

Communication with FlowDule must be protected by modern transport encryption. The approved production baseline uses encryption at rest for the relevant databases, files and sensitive fields together with controlled key management.

Credentials, tokens, encryption keys and other secrets may not be stored in source code, ordinary logs or user interfaces. Access to secrets is granted on a need-to-know basis, is recorded, and is rotated on compromise and in accordance with the approved key plan.

The specific cryptographic implementation, migration status and key access are documented in the confidential TOMs and evidence material and are disclosed only on a need-to-know basis through a secure channel.

7. Logging and control of access

Relevant actions involving client and health record data must be traceable to an identified natural user or to an unambiguous system component. Depending on the risk, this covers reading, searching, creation, modification, download, export, sharing, revocation, deletion and privileged administrative actions, among other things.

Logs must:

• contain sufficient context to investigate the action;

• avoid health record text, passwords, tokens, signed URLs and other unnecessary sensitive values;

• be protected against unauthorised modification and reading;

• have a documented retention period and automatic deletion;

• be capable of being used for relevant alerts, investigations and the customer’s lawful control.

The customer is responsible for controlling its own users’ work-related look-ups. FlowDule provides the agreed functionality and assistance. Control must be objectively justified, proportionate and access-restricted.

8. Secure development and change management

FlowDule’s development process requires risk-based code review and testing before release. Depending on the change, this includes automated functional and security tests as well as scanning of dependencies, secrets, containers and infrastructure configuration, among other things.

Findings are prioritised by likelihood, consequence, exposure surface and the data being processed. Critical matters lead to the affected release being blocked, restricted or rolled back. An accepted exception must be time-limited, have an owner and a justification, and be recorded in the deviation register.

Production changes must be capable of being linked to a requirement, the change itself, the reviewer, the test evidence and the release decision.

9. Files and malicious content

Uploads are restricted by file type, size, signature and the specific function. Files and metadata must not be capable of being used to circumvent customer separation, access control or secure file rendering.

The relevant upload function is released only with a documented risk-based solution for malware control or secure isolation/quarantine. Files must not be presented as fully malware-checked before the actual control has been implemented and tested.

10. Supplier and transfer security

Before a supplier receives personal data, FlowDule assesses at least:

• the legal role, the service, the data and the data subjects;

• the contract, the data processing agreement and 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 supplementary measures.

EU hosting is not on its own proof that no third-country transfer can take place. The current public supplier status is set out in Sub-processors and suppliers. Restricted or unreleased features may not be enabled with the personal data in question.

11. Backup, restore and continuity

FlowDule uses backup and restore mechanisms that must be tested in an isolated environment. An approved restore test must document the recovery point chosen, the actual data loss, the time measured, integrity, customer separation and the correct re-application of deletions and legal holds before the environment is opened.

FlowDule does not publish or promise particular RPO, RTO, backup or uptime targets before they have been tested and expressly agreed in an SLA or a customer annex. The customer’s local emergency procedure must be able to function without insecure private e-mails, chats, shared documents or unauthorised devices.

After a restore, FlowDule checks technical completeness. The customer checks its own critical professional data and carries out any necessary traceable subsequent recording.

12. Security incidents and personal data breaches

Any suspicion of a loss of confidentiality, integrity or availability is treated as a security incident. FlowDule records, contains, investigates and documents the incident and preserves the necessary evidence without creating unnecessary copies of sensitive content.

Where a personal data breach concerns the customer’s data, FlowDule notifies the customer without undue delay and provides the available information in phases. As controller, the customer decides on notification to the supervisory authority and on informing the data subjects. FlowDule’s procedure must not delay the customer’s ability to meet its deadline.

Suspected security issues must be reported immediately to security@flowdule.com. Ordinary support questions should be sent to support@flowdule.com.

13. Retention, deletion and legal hold

The customer’s retention profile is determined by professional group, country, data category and purpose. FlowDule does not automatically apply a health law record retention period to self-employed psychotherapists who are not covered by that particular special rule.

Deletion must cover the relevant databases, files, shares, queues, caches, export files and other active copies. Backups are phased out through documented rotation. Until they expire they are protected and may not be used for other purposes.

A legal hold is applied only where there is a specific documented obligation, dispute or lawful instruction. It is limited to the necessary persons, objects and data categories, is reassessed regularly, and is lifted traceably.

14. AI security

AI features are separately enabled use cases and not a general access to the customer’s data. Before enablement, the model, version, data, regions, retention, supplier sharing, absence of training, quality testing, human control and stop rule are documented.

AI output is a draft. A competent user must check the source, the facts, negations, figures, dates, the person and the professional context, and must actively approve the result. FlowDule’s AI may not itself make diagnostic, triage, treatment or access decisions.

Further information is available in AI information.

15. Training and confidentiality

Persons with internal or privileged access are subject to confidentiality and are instructed before access, and regularly thereafter, in phishing, credentials, health record data, support access, logging, incidents, AI and immediate reporting, among other things.

Access and training are documented. Deliberate misuse, sharing of credentials, circumvention of controls or concealment may lead to immediate closure of access and to relevant contractual or employment law consequences.

16. Documentation, audit and customers

FlowDule maintains an internal control and evidence register. Test evidence is kept access-restricted and covers only the necessary information. Open matters are recorded with an owner, a deadline, the risk and any interim control.

The customer may obtain documentation and carry out an audit under the Data Processing Agreement. Control normally begins with the accepted TOMs, the relevant test summaries, supplier documentation and any independent assurance reports. Details that could compromise security or other customers’ confidentiality are disclosed only through an appropriately 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 does not claim ISO 27001, SOC 2 or any other certification without valid evidence.

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

• Articles 25 and 32 GDPR

• The Danish Data Protection Agency’s (Datatilsynet) catalogue of security measures

• The Danish Data Protection Agency’s (Datatilsynet) guidance on logging