Trust CenterMeasures
Technical and organisational measures
A summary of the measures that protect data in FlowDule: who can get in, how data is kept separate and encrypted, what is logged, and how data is deleted.
Security built into the platform
Article 32 of the General Data Protection Regulation requires both the data controller and the data processor to take appropriate technical and organisational measures. This page gives an overview of FlowDule's security model in language that can be used in your own documentation. The overview is informative: the binding level of security is set out in the accepted data processing agreement and the version-bound TOMs annex, which take precedence in the event of any discrepancy.
The description covers identity and access, separation of data between chains, encryption, traceability, data integrity, deletion and operations.
Read the TOMs annexMeasures
The measures cover five areas
Identity and access, customer separation, encryption, traceability and data integrity.
- Identity and access
Login and access control
Login takes place via AWS Cognito with signed tokens. Access is controlled by the user's role and by which chain and which location the user belongs to. If a user does not have access, the request is refused without revealing whether the data exists at all.
- Customer separation
Each chain's data is kept separate
Data belongs to one chain at a time. Customer separation is enforced in the relevant layers: user interface, API, application logic, database and file access, where the database's row-level security is configured to refuse queries beyond the chain the user is logged in to. Access is assessed on the basis of customer affiliation, role, location and the relevant working or treatment relationship.
- Encryption
Encryption in transit and in the journal
Communication with FlowDule is protected with modern transport encryption. Production uses encryption at rest for relevant databases, files and sensitive fields, and journal data is field-encrypted with AES-256 and chain-specific keys in AWS KMS. Further details of the cryptographic implementation and key access are provided as needed via a secure channel.
- Traceability
Actions must be traceable to a user
Relevant actions involving client and journal data must be traceable to an identified user or an unambiguous system component. Logs are protected against unauthorised modification and reading, have a documented retention period and avoid journal text, passwords and tokens. The access log shows who has viewed or changed a journal, and the customer is responsible for checking its own users' work-related look-ups.
- Data integrity
The original remains
Journal notes are versioned. A correction is made as an addendum, and the original text is kept, so the journal can be read as it looked at the time.
Customer separation
Separation in every layer
Customer separation is enforced in the user interface, API, application logic, database and file access. If a user does not have access, the request is refused without revealing whether the data exists at all.
- User interfaceCheckedRefuses
- APICheckedRefuses
- Application logicCheckedRefuses
- Database with row-level securityCheckedRefuses
- File accessCheckedRefuses
Answer according to role, location and relationshipThe answer does not reveal whether data exists
Deletion
Deletion follows a documented retention profile
The customer's retention profile is set according to profession, country, data category and purpose. Deletion must cover relevant databases, files, shares, queues, caches, export files and other active copies, while backups are phased out through documented rotation. The rules for how long journal data is kept, and what happens on an erasure request, are described separately.
See journal data retentionOperations
Operations, backup and ongoing control
Production runs at Kinsta (Sevalla) in Google Cloud's data centres: API, database, booking pages and web app. Cloudflare provides the edge and TLS in front of all Sevalla apps and stores media and database backups in Cloudflare R2. Login (AWS Cognito), email (Amazon SES), the AI services and the keys for field encryption of journal data (AWS KMS) are hosted at AWS. Suppliers and transfer mechanisms are set out in the list of sub-processors.
The database is backed up daily with 30-day rotation, and as part of the restore procedure, restoration must be tested in an isolated environment where recorded deletions and legal holds are reapplied before the environment is opened.
Automatic alerts respond to errors, failed writes to the audit log, bulk look-ups in journals and new platform owners. Vulnerability and change management, patching, key rotation and incident preparedness are standing requirements for operations.
See securityThe contractual basis for the measures
- Data Processing AgreementThe agreement between you as data controller and FlowDule as data processor. The binding Article 32 measures are set out in the version- and hash-bound TOMs annex, which is accepted together with the data processing agreement. This page is only an informative summary.
- Sub-processorsThe list of suppliers that process data on FlowDule's behalf, and how changes are notified.
- TOMs annexThe binding technical and organisational measures
Documentation
Need a detailed description for your audit?
The accepted TOMs annex is recorded with title, version and document hash together with your acceptance. An audit normally starts with the accepted TOMs and supplier documentation, and details that could compromise security or other customers' confidentiality are only provided through a secure and confidential process. Write to privacy@flowdule.com with the control and period you want to review.