Privacy
Privacy policy
A guest may ask to be forgotten. A tax authority requires the invoice kept for years. Both are true at once, and the resolution is the whole design: erasure destroys the person, not the transaction.
Who is responsible for what
There are two different sets of personal data here and they answer to two different people. Getting this wrong is how a guest's erasure request ends up on the wrong desk, so it is stated first and everything below follows from it.
A guest's data
The venue is the Data Fiduciary. ROSFlow is the Processor.
The restaurant or hotel decides why a guest's number is collected; we process on its instruction. That division is load-bearing: an erasure request goes to the venue and the venue performs it, which is why erasing a guest is a venue capability on the venue's own screen and not something platform support can do. Support cannot erase somebody's guest, and should not be able to.
An account holder's data
ROSFlow is the Data Fiduciary.
Opening an account gives us a name, an email address and a venue, for our own purposes — signing you in, billing you, and answering you. Nobody instructs us to hold that; we decided to. So for this set, the obligations below are ours and not a venue's.
If you have a ROSFlow account
Opening an account collects the venue's name, what kind of venue it is, the city it is in, your own name and email address, a password, and the plan you picked. The password is stored as an Argon2id hash and is not recoverable by anybody, us included — a forgotten one is replaced, never retrieved.
After that, signing in writes a session record so that you can see where your account is signed in and end any of those sessions yourself. Privileged and financial actions write a row to your venue's own audit trail naming who did what. Both exist so that an account can be defended, not so that anybody can be watched.
There is no advertising, no profiling and no sale of anything to anybody. Nothing on this site loads a third-party analytics or advertising script — see Cookies, which says what is actually stored and how you can check.
If you are a guest of a venue
What a venue holds about a guest, and the reason each field exists. The question a data-protection law actually asks is not what you store; it is what you store that you cannot justify.
A number given so a table can be called is not a marketing list. Nothing in this product exports guest contact details in bulk. There is no such screen and no such interface, and that absence is a decision rather than an oversight.
Every rights request below is made to the venue, and performed by the venue's own staff. Ask them, not us.
Destroys the identifiers and the free text; keeps every bill.
The guest record is editable on the venue's guest book.
One JSON document, gated the same way erasure is: owner, PIN, a stated request.
Append-only and per purpose. A withdrawal is a row, never a deletion.
For guest data the venue is the Fiduciary and holds the channel. For an account holder's own data, see below.
The product stores the notice text against the consent. Putting one on a screen is the venue's decision and the venue's wording.
How long anything is kept
A nightly job enforces the rows it is allowed to enforce. It runs report-only unless it is explicitly told to act, because a retention job is the one job where doing more than was agreed is the dangerous direction — and it will not touch an order, a bill, a payment or the audit trail at all. A script that can reach an eight-year statutory record is a script that can be run by mistake.
Why table events are swept at four years and not twelve months
The policy says twelve months live and then three years in cold storage. There is no cold storage. There is one database. Purging at the twelve-month boundary would therefore not move that telemetry anywhere — it would destroy it three years before the policy allows. So the sweep works to the outer boundary and prints how many rows are past twelve months, which is the size of the archive tier that does not exist. When one is built, twelve months becomes a move and the four-year figure becomes wrong; a test fails if either boundary is changed without the reasoning changing with it.
Erasure, exactly as implemented
Gated on a manager's capability, PIN-confirmed, with a reason required — and idempotent, so a record already erased is refused rather than erased twice.
What it destroys
- — The name, replaced with "Erased guest".
- — The telephone number, encrypted and hashed copies both.
- — The email address.
- — The name and number copied onto every reservation.
- — The free text people actually type it into — order notes, item notes, feedback comments, stay notes, table notes.
What it keeps
- + Every bill, every payment, every line.
- + The row itself, as "Erased guest", so the takings still add up.
- + An audit entry naming the operator, the reason and the record — erasure is itself an event somebody may have to account for.
The searchable index goes with the number, and that matters as much as the number does. A guest's telephone is stored twice: encrypted so staff can read it, and as a one-way hash so a returning guest can be recognised without the number being held readably. Clearing the encrypted copy and leaving the index would leave a searchable fingerprint of the person who asked to be forgotten. Both go.
The free text is the half most implementations miss. A captain writing "call Anjali on 98200 12345 when the cake is ready" into an order note has put a telephone number somewhere erasure was never looking. A test fails if a new free-text column appears in neither the redact list nor the keep list, so the next one cannot be forgotten quietly.
A queued message to an erased guest is suppressed rather than sent after the record explaining why it was being sent has been cleared.
Consent is a ledger
A single opt-in flag says yes or no and nothing else. Not when, not what the person was shown, not who ticked it — and not whether it was ever withdrawn, because when a flag flips back to zero the earlier consent is not withdrawn, it is erased. A venue honouring a withdrawal that way destroys the only evidence it ever had permission.
So consent is an append-only record instead. Granting writes a row; withdrawing writes another saying so. Each row carries the purpose it was given for, whether the guest gave it or a member of staff recorded it on their behalf, the exact words that were shown at that moment, and who, where and when. The current answer is the newest row. "Could we, in March?" is the newest row before March — and that is the question that actually gets asked, after somebody complains.
The back-fill is honest about itself
Guests who already carried an opt-in flag agreed to something at some point and there is no record of when. They were migrated as granted, sourced "import", with the notice text saying exactly that: the venue holds a claim of consent it cannot evidence. Writing them as though the guest had ticked it would be inventing evidence, which is the one thing a consent record must never do.
How it is protected
Every guest identifier is encrypted at rest with AES-256-GCM under a key held by the deployment. The venue's staff see them on screen; a copy of the database without the key does not. Passwords and terminal PINs are Argon2id hashes, which are not encryption and cannot be reversed at all. Card numbers are never stored — the last four digits and an authorisation reference are all this application ever receives.
The Security page sets out the rest — who can reach what, the tamper-evident audit trail, and the limits that are still open.
Cookies and what your browser stores
Short list, and you can verify all of it from your own developer tools.
There is no consent banner on this site because there is nothing to consent to. A banner asking permission to set a sign-in cookie would be theatre.
What is not built
Stated plainly, because a retention policy nothing enforces is a wish. These are the three things the internal version of this document lists as absent, and they are absent here too.
No archive tier
Cold storage has no implementation; there is one database. This is why the telemetry row above reads four years instead of twelve months. It is a piece of infrastructure rather than a query, which is why the other items on this list could be built and this one could not.
No grievance channel in the product
For a guest's data the venue holds it, which is correct. For an account holder's own data it is ROSFlow's to hold, and see below.
Nothing shows a consent notice to a guest
The product stores the words a guest was shown against the consent they gave. Putting a notice on a screen is the venue's decision and the venue's wording, and no screen does it today.
Complaints
A complaint about what a venue holds goes to the venue: it decided to collect it and it is the only party who can act. A complaint about what ROSFlow holds — your account, your email address, your billing — comes to the officer named here.
If a breach affects data held on a venue's behalf, the venue is told within 24 hours and the regulator within 72, which is the commitment the internal incident procedure makes and the one this page repeats.
Reaching us at all is Contact, which is honest about which channels exist.