Policy
The retention schedule and the sub-processor list are published, not available on request
Every third party that processes customer data on our behalf is named on a page, with what it does and why.
A sub-processor list you have to email for is a list that changes without you. Ours is a page. It names every third party that processes customer data on our behalf, what each one does, and what it therefore sees. The retention schedule sits beside it on the same terms: what we store, for how long, where it lives, and who can reach it.
The reason to publish rather than furnish on request is that publication creates an obligation to keep it true. A page that is wrong is visibly wrong, and a change to the list is a change to a document with a history, which is a considerably better control than a promise to tell you.
Breach response is stated on the same principle. Where a personal data breach is likely to result in a risk to individuals we notify the supervisory authority within seventy-two hours of becoming aware, and affected people without undue delay where the risk is high. Business customers are notified within forty-eight hours under the data processing addendum.
One engineering rule belongs to this remit and is worth naming on its own: a generated storefront is a set of static files a customer downloads, so a credential written into one is a published credential. No secret is ever written into generated output. Provider credentials live in environment configuration outside the repository and are never inlined in code.
Read next
Data handling and retention, in full.
More from FlowFinds
- Newer: A model ships with its system card or it does not ship
- Older: What we do not have: no SOC 2, no ISO 27001, no penetration test
- Everything else is in the news index.
To fact-check anything above before you publish it, write to [email protected].