Security

1. Overview

Security at Flowzart is a product property, not a department. The Service is built to give non-engineers the leverage of a software engineer, and that leverage only works if the platform underneath it is trustworthy. This page describes the technical, organisational, and contractual safeguards we apply to keep your workflows, your secrets, and your energy-consumption records safe.

The commitments here are organised by capability area. They are written at a level of detail intended to be useful to security and procurement reviewers without overspecifying operational details that would themselves be sensitive. If your review needs more depth, our trust contact can share controlled documentation under NDA.

2. Compliance & certifications

Flowzart is in early-stage development and pre-revenue. We have not yet pursued formal third-party security certifications such as SOC 2 (Type II), ISO/IEC 27001:2022, or the EU-U.S. Data Privacy Framework. As the company grows and resources permit, we plan to pursue recognised certifications appropriate to our scale and customer needs, and we will publish them here when they are in place.

Independently of formal certifications, Flowzart's processing is aligned with the EU GDPR and UK GDPR; data subject rights, lawful bases, and international-transfer mechanisms are described in our Privacy Policy and DPA. The technical and organisational measures we apply are described in the remainder of this Security Policy.

3. Hosting infrastructure

Customer data is processed on Flowzart-operated infrastructure located in the United Kingdom, Bulgaria, and Germany. Production workloads run in isolated network environments with no public ingress except through our hardened edge.

Bespoke deployment arrangements may be available on Enterprise plans; contact us for details.

4. Encryption

In transit. All traffic between you and the Service, between the Service and our sub-processors, and between internal services is encrypted using TLS 1.2 or higher with modern cipher suites. HSTS is enforced on customer-facing endpoints.

At rest. At-rest encryption of stored customer data is on Flowzart's security roadmap and is not yet enabled in production. Until it is, data at rest is protected by access controls and network segmentation on Flowzart-operated infrastructure. We will update this Security Policy when at-rest encryption is enabled.

Application secrets and infrastructure credentials. Flowzart's own application secrets (such as third-party API keys used by the Service) and database credentials are stored in a dedicated secrets-management system, encrypted at rest within that system. Database access uses dynamic, short-lived credentials with daily rotation. This is distinct from the at-rest protections that apply to customer data described above.

5. Access control

Access to production systems and customer data is granted on a least-privilege, need-to-know basis. We:

• maintain documented role-based access policies for every production system;
• require approval workflows for granting elevated privileges;
• review production access on a periodic basis and revoke unused access promptly;
• require multi-factor authentication for all internal systems that touch customer data;
• log all access to production systems for audit purposes; and
• revoke any access promptly on departure.

6. Authentication

For end users, the Service supports password-based authentication (with passwords stored only as salted hashes using a memory-hard algorithm), social sign-in via OAuth, and SAML-based single sign-on (SSO) on Enterprise plans. Two-factor authentication (2FA) using TOTP or WebAuthn is available to all users and strongly recommended.

Sessions are bound to a server-side session record so they can be revoked from your account settings at any time. We enforce idle and absolute session timeouts.

7. Network security

• Edge protection. A web application firewall (WAF) and DDoS-mitigation service sit in front of customer-facing endpoints to filter malicious traffic and absorb volumetric attacks.
• Network isolation. Production workloads run in private subnets with no direct public addressing. Egress is controlled and audited.
• Internal connectivity. All internal service-to-service communication is authenticated and encrypted; mutual TLS is used where appropriate.
• Administrative access. Access to administrative tooling is gated behind company-managed identity, MFA, and a hardened device posture.

8. Application security

• Secure SDLC. Every code change is reviewed before reaching production (today by the founder; peer code review will be required once a second engineer joins). All changes pass automated tests and CI gating before deploy.
• Static analysis. Static application security testing (SAST) and software-composition analysis (SCA) run on each build to catch known-vulnerable dependencies and common code-level issues.
• Penetration testing. Flowzart plans to commission independent third-party penetration testing as the company grows and can dedicate resources to it. Findings will be tracked and remediated in priority order, and we will share executive summaries under NDA when third-party reports become available.
• Vulnerability management. Dependencies and infrastructure are continuously monitored for vulnerabilities; we apply triage and patching priorities by severity (critical, high, medium, low).
• Hardened build and deploy. Production deployments are built from signed, version-pinned artefacts; no manual deploys from developer machines.

9. Logging & monitoring

Application and infrastructure logs are centralised, time-synchronised, and retained for an operationally-meaningful window: typically at least 12 months for security and audit logs. Logs feed into anomaly detection and alerting that triggers paging when thresholds are crossed.

Customer-visible audit logs (who did what, when, in your account) are available in your workspace settings; on Enterprise plans these can also be streamed to your own SIEM.

10. Incident response

Flowzart maintains a documented incident-response plan covering detection, triage, containment, eradication, recovery, and post-incident review. Customer-impacting incidents are handled by the on-call responder.

Where an incident involves unauthorised access to, or accidental loss, alteration, or disclosure of, your personal data, we will notify you in line with the timelines and content requirements set out in our DPA, and in any event without undue delay after we become aware of it.

Status and ongoing-incident communications are published on status.flowzart.com and via direct email to affected customers.

11. Business continuity & disaster recovery

Production data is backed up on a continuous or daily basis (depending on the data type) to a separate region. Restore procedures are exercised as part of our development cycle.

Recovery objectives. Flowzart is in active, aggressive development and does not yet publish formal recovery-time or recovery-point objectives. Commitments will be published when the platform reaches a stability tier that supports them.

12. Personnel security

Flowzart is currently operated by a single founder; the personnel-security commitments below describe the program we apply today and the program we plan to maintain as the team grows.

• Background checks. Where permitted by law, employees and contractors with access to production systems undergo background screening before they start.
• Confidentiality. Staff and contractors are bound by written confidentiality obligations and an acceptable-use policy that survives the end of their engagement.
• Training. Staff complete security and privacy training on onboarding and at least annually thereafter, including phishing-awareness exercises.
• Endpoint security. Devices used for production access have full-disk encryption, automatic patching, and screen lock. Endpoint detection and response (EDR) tooling and company-managed device policies will be enforced as the team grows.
• Offboarding. Access is revoked on the same business day a person leaves, and a checklist confirms credential and device return.

13. Sub-processor security

We use sub-processors for cloud hosting, payment processing, transactional email, customer support, error monitoring, and analytics. Each is subject to a written agreement with security and data-protection terms at least as protective as those we owe you. We assess the security posture of new sub-processors before engagement, and revisit those assessments as material changes warrant or as our review capacity grows. The current list and the change-notification mechanism are in our DPA.

14. Billing data protection

Flowzart's billing relies on two artefacts that we treat as customer data and protect accordingly:

• The energy-consumption ledger: the per-run record of watt-hours consumed by your workflows. The ledger is replicated and accessible only to the metering pipeline and your account view.
• PAYG Bundle and Subscription records: purchase dates, balances, expiry dates, and cycle-by-cycle allowance/consumption. These are retained for as long as required to operate your account, support disputes, and meet tax-and-accounting obligations (see our Privacy Policy).

We never store full payment-card numbers; payment instruments are tokenised by our payment processor, which is itself certified to PCI-DSS Level 1.

15. Customer-facing controls

The Service gives you a number of security controls to apply to your own workspace:

• two-factor authentication (TOTP / WebAuthn) and SAML SSO on Enterprise plans;
• role-based access control inside a workspace, with separate roles for view, edit, and admin;
• a workspace-level audit log of user, workflow, and credential events;
• session listing and remote sign-out;
• API tokens that you can scope, rotate, and revoke at any time;
• IP allowlisting on Enterprise plans, so the Service can be configured only to accept access from IP ranges you specify; and
• workflow-level credential storage isolated by your account.

16. Reporting a vulnerability

We welcome reports of suspected vulnerabilities in the Service. If you have found one, please write to [email protected] with:

• a description of the vulnerability and its impact;
• steps to reproduce, with as much detail as possible;
• any proof-of-concept code, screenshots, or logs (in line with the rules below); and
• your preferred contact and acknowledgement details.

Please do not exploit a vulnerability beyond what is necessary to confirm it, access data that does not belong to you, perform denial-of-service testing, or share details publicly before we have had a reasonable chance to investigate. In return, we commit to acknowledging your report within a reasonable time, keeping you updated on remediation, and treating reports submitted in good faith as authorised.

A formal coordinated-disclosure policy is in development; we will publish it on this page when ready.

Effective: 2026-05-06 · v1.0