Security

Most security pages are a list of logos. This one is a list of decisions, because a certificate we have not earned would tell you nothing true and a control we actually operate might. Read the last section first if you are evaluating us formally: it says what we do not have.

Where the data lives

FlowFinds runs on infrastructure we operate ourselves, in the European Union, behind a network provider that terminates TLS and absorbs hostile traffic before it reaches the origin. Customer data is stored in per-purpose databases on that infrastructure rather than spread across managed third-party stores, which keeps the number of parties holding a copy small enough to name — and we do name them.

All traffic to our surfaces is served over HTTPS. Credentials for payment and email providers live in environment configuration outside the repository, are never inlined in code, and are never written into a generated storefront. That last rule matters more than it sounds: a generated store is a set of static files a customer downloads, so a secret placed in one is a published secret.

Authentication and access

• No passwords to leak. Sign-in is by single-use link sent to the address on the account. There is no password database to breach and no credential to reuse across sites. The consequence, stated plainly: whoever controls the mailbox controls the account, so protect the mailbox.
• Sessions are bound to accounts server-side. A session cookie is an opaque identifier; what it is allowed to reach is decided by the server, not by anything the browser sends.
• API keys are scoped and revocable, and a call made with a key is treated as made by the account that holds it.
• Administrative access is least-privilege and limited to the small number of people who operate the service. Administrative action is logged.

Tenant isolation

Every query that returns work — products, claims, offers, stores, orders, ledgers — is scoped to the account that owns it at the point the data is read, not filtered afterwards in the interface. Product claims are enforced in the same layer: a claimed product is out of reach of other accounts because the store of record says so, not because a screen hides it. This is the control we test hardest, because it is the one whose failure would be worst.

Payments

We never receive a card number. Card details are entered on the payment provider’s own hosted page; what returns to us is a transaction reference and a status. Every message exchanged with the provider is signed, and every response signature is verified before the response is believed.

Money is credited on a confirmation we read back from the provider — through its signed server-to-server notification and through our own query against it — and never because a browser arrived at a success URL. A returning browser is a claim made by the customer’s own machine and can be typed by hand. The mechanics are in clause 4 of the billing and refund terms.

How the software is built

Changes pass deterministic gates before they ship: type checking, an automated test suite covering authorisation and the money paths in particular, and a build that must succeed. Dependencies are kept deliberately few — the payment client and the backend are written against the standard library rather than an SDK, which removes a supply-chain surface rather than managing one. Our development cycle is described at how we build.

Agent authority as a security control

The strongest limit on what an agent can do wrong is what it is permitted to do at all. The organic campaign tool holds no account on any platform and publishes nothing; the agent does not move money; irreversible actions require a person. That is a security decision as much as a product one, and the reasoning is at safety approach.

Vulnerability reporting

Send findings to [email protected]. We acknowledge within two working days and will not pursue good-faith research conducted within the scope set out in the responsible disclosure policy.

Incidents

Where a personal data breach is likely to result in a risk to individuals, we notify the supervisory authority within 72 hours of becoming aware of it, and affected people without undue delay where the risk is high. Business customers are notified within 48 hours under clause 8 of the data processing addendum. Service incidents are handled as described at availability commitment.

What we do not have

FlowFinds holds no SOC 2 report, no ISO 27001 certificate and no PCI DSS attestation. We have not commissioned an independent penetration test. Nobody has audited the statements on this page; they are our own description of our own system. We are a young company and these are the honest consequences of that.

What follows from it: PCI scope is handled by keeping card data entirely outside our systems rather than by certifying our handling of it. Where a formal report is a requirement for you, tell us at [email protected] — knowing which customers need one is how it gets prioritised. When we obtain a report, it will be named on this page with its date and scope, and offered under clause 10 of the data processing addendum. Until then, this page is what we can support.

For the controls inside the product rather than around it, see product security. For what is stored and for how long, see data handling and retention.