Legitimate Interests Assessment — guest standing, flags and restrictions
Version 2026-09-09. Prepared by Royal SoftWorks DOO Kragujevac for the SilverQR platform. Reviewed annually, or on any material change to the feature.
This is an internal accountability record made available to customers. It is the balancing test required by Article 6(1)(f) GDPR and referenced by Recital 47, covering the part of SilverQR that lets a venue record a judgement about a guest — ratings, flags, internal notes, the watchlist, and venue or workspace restrictions.
It exists because this is the highest-risk processing in the product and because "a hospitality blacklist" is a phrase that deserves a written answer rather than a paragraph in a policy. A venue using the feature is the controller; this assessment covers our design of it and is offered to venues as the starting point for their own.
1. What the processing is
| Element | What it holds | Who can see it |
|---|---|---|
| Rating | 1–5 stars, written by a member of venue staff about a guest | The workspace that wrote it |
| Flags | A closed list: abusive to staff, prank/fake requests, no-show, spam, other | The workspace that wrote it |
| Note | Free text, written by staff for other staff | The workspace that wrote it |
| Watchlist | A derived view, not stored data — the guests already flagged, restricted, banned or rated below 3 | The workspace |
| Venue / workspace restriction | A block on sending service requests, orders, bookings or messages, with an internal reason | The workspace that imposed it |
| Platform restriction | The same, applied by us across all venues | Us, and the effect is visible to venues as "restricted" |
| Aggregate platform rating | An anonymous average and count across all workspaces | Every workspace, without attribution |
A guest never sees any of it. There is no route in the product by which a guest can read a venue's opinion of them, and that is deliberate: an internal note that staff know will be read by the subject is a note that stops being honest, and a guest reading "flagged: abusive" from a venue they disagree with is a dispute the software cannot adjudicate.
2. Purpose test — is there a legitimate interest?
Yes, and it is specific rather than general. The venue's interests are:
- Protecting staff. Hospitality staff are assaulted, threatened and abused, and a venue that cannot record "this person did that here" cannot protect the people who work the next shift.
- Preventing repeat abuse of the request channel. The service bell, the order basket and the booking form can all be used to waste a venue's evening. Prank orders sent to a kitchen are a real cost in food and labour.
- Enforcing house rules the venue is entitled to have. A no-show at a table held for two hours is money; a person barred for cause returning on a new phone defeats the bar.
Third-party and wider interests also weigh in: other guests benefit from a venue that can exclude someone who has been abusive, and staff have their own Article 8 Charter interests in a safe workplace.
What it is not for. It is not marketing segmentation, it is not a credit or solvency signal, it is not scoring, and it is not sold. §3 of the Privacy Policy records those as things the platform is built without.
3. Necessity test — is it needed, and is there a gentler way?
Necessary, yes. The alternative to a record is memory: whoever was on shift. That fails across shifts, across staff turnover and across venues in one group, and it fails in exactly the case that matters — the person nobody on tonight has met.
Gentler alternatives considered and adopted where possible:
- Not recording anything and blocking by device only. Rejected: a device is replaced in a day, and a device-only block also catches the next person to use that phone.
- Recording only restrictions, not ratings or notes. Rejected as worse for the guest: without a note, a restriction has no stated reason, cannot be reviewed and cannot be lifted on the merits. A reason makes the decision auditable.
- Making the record visible platform-wide. Rejected, and this is the single most important design decision here. One venue's judgement is not evidence for another's. Ratings, flags and notes are private to the workspace that wrote them, and the only cross-workspace signal is an anonymous average with no authorship and no text.
- Free-text everywhere. Reduced: the flags are a closed list, so the common cases are structured rather than prose, and the free-text note is optional.
- Automatic restriction. Rejected. No rating, flag or count causes a restriction by itself. A person imposes every one — see §6.
4. Balancing test — does it override the guest's interests?
The intrusion is real and is mitigated at each point:
| Risk to the guest | Mitigation in the product |
|---|---|
| Being judged by someone they never met | The record is private to the workspace, and every rating carries its author for internal accountability |
| A judgement following them across unrelated businesses | Ratings, flags and notes never cross a workspace boundary. Only an anonymous, unattributed average does |
| Being unable to buy a service at all | A restriction blocks requests, not the menu. A restricted guest can still read the page, and can still be served by talking to staff — this is a block on a channel, not on entry |
| Being wrongly identified | An email address alone never merges profiles; only a device signal or a proven signed-in account does. Enforcement matches by address deliberately (a barred guest on a new phone), and the cost of that error is a conversation with staff |
| Never knowing it happened | The Privacy Policy states the feature plainly, in the section a guest reads, rather than describing it as "quality assurance" |
| It lasting forever | Retention is bounded — see §5 |
| Automated consequences | None. Article 22 does not bite because no decision here is automated: see §6 |
Reasonable expectations. A guest ringing for a waiter from a venue's own page, or holding a table, would expect the venue to remember a serious incident. They would not expect that memory to be shared with unrelated businesses or to be attached to a marketing profile, and neither happens.
Conclusion. For the workspace-private record, the interest is not overridden. The design that makes that true is the workspace boundary; a version of this feature with a shared blacklist would reach the opposite conclusion, and is the reason the boundary is enforced in the database (row-level security) rather than only in the application.
5. Retention
| Record | Kept |
|---|---|
| Ratings, flags, notes | Until the workspace removes them, or the guest profile is erased |
| Active restriction | While active |
| Lifted restriction | Kept as history, so a venue can see a decision was reviewed |
| Guest profile with no activity | Deleted after 365 days, together with every rating and flag on it, unless an active restriction is attached |
| Visits | 90 days |
| Requests and orders | 30 days after being closed |
The 365-day sweep is automated and is the effective ceiling on a judgement about a guest who does not come back. A restriction survives it deliberately: a bar that expires because the barred person stayed away is not a bar.
6. No automated decision-making
Article 22 is not engaged. Nothing in this feature produces a decision by automated means:
- A rating is written by a person.
- A flag is ticked by a person.
- A restriction is imposed by a named member of staff, with a reason, and is recorded in the audit log with their identity.
- The watchlist surfaces guests who already carry a human-made mark. It creates nothing and decides nothing.
- The platform-wide restriction is imposed by our own staff, by hand, in the operator console, and is logged.
There is no score, no model, and no threshold that acts on its own.
7. Rights, and how they are answered
A guest may ask for access to, correction of, or erasure of what is held about
them. Because the venue is the controller for guest data, we refer substantive
requests to the venue and support it in answering them; our own tooling at
/legal/data-request lets a guest reach the record directly, and erasing a guest
profile removes the ratings, flags and notes on it.
The one thing erasure does not automatically remove is an active restriction. A venue's ability to enforce a decision it made for cause is the legitimate interest this whole assessment is about, and a right to erasure that deletes the bar is a right to erase the bar. Where a guest objects to a restriction under Article 21, the venue must consider the objection on its merits and record the outcome — and we will tell a venue so when it asks us.
8. What would change this assessment
Any of the following requires this document to be redone before the change ships:
- Making any workspace's ratings, flags or notes readable by another workspace.
- Deriving a restriction, a score or a ranking automatically from ratings.
- Retaining a rating, flag or note beyond the dormancy sweep.
- Attaching the record to anything used for marketing.
- Disclosing the SilverQR account identifier to a workspace, which would make a guest correlatable between venues by a third party.
9. References
- Regulation (EU) 2016/679, Articles 5, 6(1)(f), 13, 21, 22; Recitals 39, 47.
- Article 29 Working Party, Opinion 06/2014 on the notion of legitimate interests, WP217.
- EDPB Guidelines 1/2024 on processing of personal data based on Article 6(1)(f).
Questions about this document: [email protected].