TOMs annex to the Data Processing Agreement

This annex describes the technical and organisational measures that FlowDule ApS applies when FlowDule processes personal data on the customer’s behalf, cf. Articles 28 and 32 GDPR. The annex forms part of the Data Processing Agreement.

The annex is versioned. The version the customer has accepted together with the Data Processing Agreement is identified by its version and date. Changes are published as a new version, and material changes require new acceptance under the Data Processing Agreement.

The customer’s documented instruction is the chain’s own settings in the platform (enabled modules and the AI features in them, retention rules and country profile) together with the accepted Data Processing Agreement. The measures below apply to all chains; which features and suppliers are in use for an individual chain depends on the chain’s settings.

• Users log in with personal accounts via AWS Cognito.
• Multi-factor authentication (MFA) is required for FlowDule’s own platform users. The chain’s users can switch on MFA for their own account.
• Access is granted by role. A user sees only the data that the user’s role in the chain and at the location gives access to.

The platform is shared by several customers. Each chain’s data is kept separate in the application, and the database enforces row-level security, so that a query can see only rows for the chain it is run for.

On every call, the server determines which chain and which roles the logged-in user has access to. IDs in the content of the request are not used to grant access.

• Traffic between users and the platform is encrypted with TLS via Cloudflare.
• Health record data is encrypted at field level with AES-256-GCM under keys protected by AWS KMS.
• Searches in selected encrypted fields use HMAC-based blind indexes, so that the plain text is not stored in searchable form.

• Health record lookups are recorded in an access log.
• Automatic alerts are raised on errors, on failed writes to the audit log, on mass health record lookups and when a new platform owner is created.
• Alerts are collected in a digest email, and critical alerts are escalated by SMS.

Production runs on Kinsta (Sevalla) in Google Cloud data centres. This covers the API, the database and the booking sites; the database is located in the Google Cloud region europe-west3 (Frankfurt). The web app is a Sevalla static site.

Cloudflare provides the edge and TLS in front of all Sevalla apps, object storage (Cloudflare R2) for media (images, dictation audio and exports) and for the database backups, and the Turnstile bot check on the step where a booking or event registration is submitted, on the contact form and on the webshop’s back-in-stock notification form.

From AWS in the EU, Cognito (login), SES (email), Amazon Bedrock (AI), Amazon Transcribe (dictation), Amazon Textract (text recognition) and AWS KMS (keys for field encryption) are used. Amazon Translate is used only for support tickets and platform announcements.

SMS messages are sent via GatewayAPI (ONLINECITY.IO), whose platform keeps message data in the EU (Google, Belgium). Payments are handled by Stripe; client payments are made directly on the chain’s own Stripe account. Address lookup for business, location and event addresses behind login uses Postcode.eu. Push notifications are switched off in production, and no push messages are sent.

Video is provided by LiveKit (LiveKit Incorporated, USA) for chains that switch the video module on. LiveKit Cloud routes each session to the nearest server, so the processing is not bound to the EU. 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, and otherwise the EU standard contractual clauses. No recording, egress, agents or inference is used. The data processed is the session ID, a pseudonymous participant ID, the display name and audio, video and any chat in transit.

The full list with legal entities, purposes, data categories, processing locations and transfer bases is set out in Sub-processors and suppliers.

The database is backed up daily to Cloudflare R2 with 30-day rotation. As part of the recovery procedure, restoration must be tested in an isolated environment, and registered deletions and legal holds must be re-applied before a restored environment is opened.

Retention and deletion follow the chain’s retention rules and country profile and the Data Processing Agreement. Backups are deleted through the ongoing 30-day rotation, and registered deletions are also respected on restoration, cf. section 7. On termination of the agreement, data is returned, exported and deleted in accordance with the Data Processing Agreement.

• The AI features in the health record are available to chains that have switched the journal module on, and to the chain’s users according to their role; there is no separate activation step for each individual AI feature. FlowDule switches AI off for a chain on request, with the exceptions set out in the AI information.
• Text-based AI, including translation of health records, catalogues and texts, runs on Amazon Bedrock with Anthropic Claude via the EU inference profile, so that requests are processed in EU regions. Dictation is transcribed with Amazon Transcribe, and text recognition uses Amazon Textract.
• Formatted text and text from an image only enter a health record when the user saves the note. Dictated text is inserted into the writing tool, and the text of the note only changes when the user saves; if the dictation is made to a note that has already been created, the raw transcript is stored with the note as soon as it is ready. Summaries, keywords and next steps are written on the note when the user has asked for them; the user must read them and can correct or remove them. Some results are not approved individually: the automatic note feedback, the machine translation of shared content for the client and the translation of support tickets and platform messages.
• The customer’s data is not used to train AI models.

Security incidents are recorded, contained and investigated. FlowDule notifies the customer without undue delay after becoming aware of a personal data breach affecting the customer’s personal data, and assists the customer with the information the customer needs for its own assessment and any notification. A suspected security incident is reported to security@flowdule.com.

FlowDule’s internal policies lay down, among other things:

• named roles and management approval;
• confidentiality and need-based access;
• change management, code review and security testing;
• incident reporting and customer assistance;
• supplier control and documented instructions;
• training in security, privacy and AI;
• risk-based control and documentation.

FlowDule is not ISO 27001 or SOC 2 certified.

• Minor clients may be registered where the customer’s minors setting is enabled and an adult contact person with an email address or phone number is registered on the client. Messages, receipts and payment links are sent to the contact person, not to the minor.
• The contact person is given no access to the solution.
• If the customer uses the journal module for health records, only clients aged 18 or over may be registered. The customer’s minors setting states this, and it is not a technical block.
• Guardian and power of attorney models remain outside the product covered by the agreement and must not be used; no one logs in on another person’s behalf.
• Research, anonymous data sets derived from health records and autonomous AI features remain outside the product covered by the agreement, or switched off. The AI features that are in use are set out in section 9 and in the AI information.

• Articles 25 and 32 GDPR
• The Danish Data Protection Agency’s (Datatilsynet) catalogue of security measures