How this handles your data

This is Birdy Shop order support, built by Noorflows. This page says where data lives, who can reach it, what is kept, and — the part most pages leave out — which independent security reviews we have not had.

We hold no SOC 2 report, no ISO 27001 assessment, and no third-party security assessment of any kind. Nobody outside Noorflows has assessed these claims. If your procurement process requires one, we do not meet it today, and we would rather you learned that here than three weeks into an evaluation.

Where the data lives

The demo you are looking at holds invented records only.: Every company, person and record in it was made up for the purpose. No real record has ever been copied into it, for any reason, including our own testing.
A live system for a company holds that company's data and nothing else.: Not one database with a column saying which customer a row belongs to — a separate store, separately deployed. A shared database with a filter is one mistaken query away from showing one customer another customer's records, and that mistake cannot be undone by apologising.
The demo and the live system are kept separate from each other too.: A build running for a company holds its own store, and this demo holds another. They never touch, and nothing has ever crossed between them in either direction.

Who can reach it

One set of credentials per build.: No key exists that can read across two customers. That is a property of how they are deployed, not a rule someone remembers to follow.
No personal data in shared logging.: A shared log is a shared database by another name. Logs carry references — an order number, a record id — never names, addresses or contact details.
Uploads are processed in memory and discarded.: Where a build accepts a file, it is read, used, and not written to disk. Nothing is kept to "improve the service".

What we do not do

We do not	Because
Train any model on your data	Your records are yours. Nothing you send is used to improve anything we sell to anyone else.
Send your data to a model provider unless the build needs one	Where a build uses a language model it is named on that build's page, and it only ever rephrases facts the code has already established.
Keep data after an engagement ends	The customer's data is deleted. Our own record of what we did — what was checked, when, and what it said — is kept for twelve months, because a report nobody can stand behind in a year is not evidence.
Move money, send messages, or take an irreversible action on our own	Every one of those ends at a person choosing it. This is the same rule in every build.

What is written down

A build running for a company keeps a record of what was checked, what the check said, and who decided what — with the version of the rules that applied at the time, so an old entry stays readable after the rules change. Entries cannot be edited or deleted. A record that can be tidied is one nobody can rely on, and the day it matters is the day somebody would most want to tidy it.

That record holds references, never personal details.

This demo keeps nothing. What appears in the queue beside the conversation lives in the page in front of you, and it is gone the moment you reload it.

What we would need before handling real records

A signed data agreement, before any access is given — not after. Where the data concerns people in the UK or the EU, that agreement has a cross-border section a lawyer has to complete, and it is the customer who is exposed without it, which is why their lawyer is the one who stops the deal. We do not accept access to a live system before it is signed.

Back to the demo · Plain text version of the demo page · Noorflows

Written 8 August 2026, revised 9 August 2026. If anything on this page stops being true, it is a defect and we would like to be told.