Flowtly – Technical and Organisational Measures

1. Introduction and scope

This document describes the technical and organisational measures ("TOMs") that Flowtly Prosta Spółka Akcyjna (KRS 0001188143), with its registered office in Warsaw, ul. Młynarska 8/12, Poland, implements to ensure a level of security of personal data processing appropriate to the risk, in accordance with Article 32 GDPR. This document forms Annex 1 to Flowtly's Data Processing Agreement and applies to the processing of personal data on the Flowtly Platform.

This document describes the state of the Platform's security as recorded on the publication date of the relevant version, based on the Platform's infrastructure configuration. Flowtly does not claim ISO/IEC 27001 certification or a SOC 2 attestation — this document describes only measures that are actually implemented, not planned or aspirational ones, and is not the output of an independent security audit. The Polish-language version of this document is the binding version; this English translation is provided for convenience.

2. Infrastructure and hosting security

The Platform is hosted on Google Cloud Platform (GCP) infrastructure, in the europe-west1 region (Belgium, European Union). The application database (Cloud SQL) is maintained separately for each Organisation, which provides logical separation of each Organisation's data at the database level (see Section 5).

The database instance runs in a single-zone configuration, with no active standby replica in another availability zone — a deliberately accepted trade-off on infrastructure cost. In practice, this means a zone outage affects the Platform's availability, while — thanks to the measures described in Section 6 — it should not result in data loss beyond what is described there.

3. Data encryption

Connections to the Platform and communication between its components are secured with TLS. Application access to the database requires authentication with a trusted client certificate (enforced trusted-client-certificate mode). Data at rest stored in Google Cloud services is encrypted using that infrastructure provider's default encryption mechanisms.

4. Access control and identity management

Access to the Platform's infrastructure is restricted to authorised Flowtly personnel — and, to the extent necessary to provide technical support, authorised infrastructure-provider personnel — on a least-privilege basis. Database access uses cloud identity-based authentication (IAM database authentication). Application credentials and secrets are stored in a dedicated secret manager, not in source code or configuration files. Deployment pipelines (CI/CD) authenticate to the cloud infrastructure using Workload Identity Federation, without long-lived access keys stored outside the identity provider.

Database service account passwords are subject to an enforced password policy: a minimum length of 14 characters, enforced complexity, and a ban on reusing any of the last 5 passwords.

5. Separation of Organisations' data (multi-tenancy)

Each Organisation's data on the Platform is stored in a separate database dedicated to that Organisation, not in a shared database used by other Organisations. Application access to a given database is scoped to that Organisation.

6. Backups and disaster recovery

The Platform's database is automatically protected by a daily backup, configured to start its execution window at 03:00 UTC, and by a point-in-time recovery mechanism based on transaction logging. The 30 most recent successful backups are retained — in practice this can amount to less than 30 days of coverage if any scheduled backup fails.

The level of protection these measures provide in practice: an accidental deletion or a bad migration can, in the typical case, be reversed to within a few minutes' accuracy using point-in-time recovery. In the extreme scenario of losing the entire database instance, recovery is from the most recent successful daily backup, which in the typical case means a possible data loss of up to 24 hours; these are descriptions of how the mechanism typically behaves given its configuration, not maximum-loss guarantees verified in practice. The time needed to fully restore service after losing an instance (RTO) has not yet been measured in a real recovery drill — Flowtly therefore does not currently state a numeric commitment for this, and will not until it has been verified in practice.

7. Security incident management

Flowtly monitors the Platform's infrastructure and has a security incident response procedure. If a personal data breach is identified, Flowtly notifies the Controller without undue delay, in accordance with the timing and process set out in the Data Processing Agreement — in any case no later than 48 hours after the breach is identified.

8. Vendor and Sub-processor management

Flowtly engages Sub-processors that process Organisations' personal data only on the terms described in the Data Processing Agreement, including at least 30 days' advance notice for new Sub-processors and a Controller objection mechanism. The current list of Sub-processors — including the infrastructure provider (Google Cloud), payment processing (Stripe), bank data integration (Kontomatik), error monitoring (Sentry), processing of document content for AI-based features (Anthropic), and sending transactional email (Postmark) — is published in the Data Processing Agreement.

9. No-downgrade commitment and versioning

Flowtly commits not to lower the overall level of security of processing described in this document during the term of the agreement for access to the Platform; replacing a given measure with another that provides an equivalent or higher level of protection is not a downgrade. Every change to this document — including any such replacement — is recorded as a new, dated version in the revision history available on this page, so the security posture in force at any given time can always be established from that history.

This document is the version published on 23 September 2026.