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.
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 you can use in your own documentation. The overview is informative: the binding level of security follows from the accepted Data Processing Agreement, the customer annex and the version-bound TOMs annex, which takes precedence in the event of any inconsistency.
The description covers identity and access, separation of data between chains, encryption, traceability, data integrity, deletion and operations.
Identity and access, tenant separation, encryption, traceability and data integrity
Sign-in goes through AWS Cognito with signed tokens. Access is governed 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.
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 reject queries beyond the chain the user is signed in to. Access is assessed by customer affiliation, role, location and the relevant working or treatment relationship.
Communication with FlowDule is protected with modern transport encryption. The approved production baseline uses encryption at rest for the relevant databases, files and sensitive fields, together with controlled key management using AWS KMS. The specific cryptographic implementation, the 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.
Relevant actions involving client and journal data must be traceable to an identified user or to an unambiguous system component. Logs are protected against unauthorised modification and reading, have a documented retention period and avoid journal text, passwords and tokens. Log coverage is under testing, and the customer is responsible for checking its own users' work-related reads.
Journal notes are versioned. A correction is made as an addition, and the original text is preserved, so the journal can be read as it looked at the time.
The customer's retention profile is set according to professional group, country, data category and purpose. Deletion must cover the relevant databases, files, shares, queues, caches, export files and other active copies, while backups are phased out through documented rotation. Retention, deletion and legal hold are under testing and are not presented as verified controls until the test has been approved. The rules for how long journal data is kept, and what happens on an erasure request, are described separately.
Journal data retention
Core production runs on AWS in EU regions: database, API, cache, secrets and KMS primarily in eu-north-1, files in eu-central-1 and eu-north-1, and sign-in in eu-central-1 as of the latest baseline. Global delivery and operational logs cannot be described as fully region pinned, and EU hosting is not on its own proof that no third country transfer can take place. Vulnerability and change management, patch and key rotation under the approved key plan, incident response, continuity and an isolated restore test with a measured result are requirements that are only presented as verified once the controls have been tested and approved.
SecurityThe agreement between you as data controller and FlowDule as data processor. The binding Article 32 measures follow from the version and hash bound TOMs annex, which is accepted with Customer Annex A. This page is only an informative summary.
Read the DPAThe list of providers processing data on FlowDule's behalf, and how changes are notified.
See sub-processorsThe accepted TOMs annex is identified by title, version and document hash in Customer Annex A. A review normally starts with the accepted TOMs, the relevant test summaries and supplier documentation, and details that could compromise security or other customers' confidentiality are disclosed only through a secure and confidential process. Write to privacy@flowdule.com with the requested control and period.