How Roosty Handles Data Privacy and Security

Why scheduling data is sensitive data

It is easy to file scheduling software under harmless operations tooling. Look closer at what a roster system necessarily contains: who works where and when, contract hours that imply income, absence records that can imply health, availability patterns that reveal private life. Under the GDPR most of this is plainly personal data, and some of it deserves extra care.

So the honest starting point for any scheduling platform is an admission: we hold data that matters, about people who never chose the software their employer picked. Everything else in this article follows from taking that seriously.

Principle one: store the minimum, refuse the rest

The cheapest data breach is the one that cannot happen because the data was never collected. Roosty stores what scheduling needs and deliberately refuses what it does not:

What we store

• Identity basics: name, contact details, role and skills per station.
• Contract facts: hours, applicable surcharges, start and end dates.
• Scheduling data: availability, shifts, swaps, absence markers relevant to planning.
• Venue patterns: demand history and staffing baselines, as described in the venue intelligence article.

What we refuse

• Medical detail. An absence is stored as unavailable, never as a diagnosis. The reason field is deliberately absent.
• Location tracking. No GPS, no geofencing, no clock-in surveillance. Presence is a shift status, not a coordinate.
• Behavioural profiling. We model shifts and stations, not personalities. The fairness system in Building Fair Schedules counts shifts; it does not score people.
• Itemised sales data. POS integrations pull hourly aggregates for forecasting, never transactions or customer records, as detailed in the integration guide.

Principle two: your venue is an island, on purpose

Earlier we wrote about how Roosty remembers your venue. The complement matters just as much: it remembers only your venue, to you. Every workspace is logically isolated. Learned demand patterns, fairness histories and staffing baselines are scoped to the venue that generated them and never leak into another customer's drafts, however statistically tempting cross-venue learning might be.

Access follows the same boundary inward. Staff see their own shifts, availability and hours. Shift leads see their team's week. Managers see the venue. Nobody sees another venue, and Roosty's own engineers access production data only through logged, reviewed procedures for support cases.

Trust in a scheduling system is built the same way as trust in a manager: by being predictable about what you will not do with what you know.

Principle three: security as plumbing, not as a page

The security measures themselves are unexciting by design, which is rather the point:

• Encryption in transit and at rest, with keys managed separately from data.
• EU-based hosting, with data residency documented in the data processing agreement every customer signs.
• Role-based access control on every internal system, least privilege by default.
• Independent penetration testing on a recurring schedule, with findings tracked to closure.
• Versioned backups with tested restore procedures, because a backup that has never been restored is a hope, not a plan.
• Audit logs on schedule changes: who published, who edited, who approved a swap, which also quietly resolves most he-said-she-said disputes.

GDPR in practice, not in a banner

For venues operating in the EU, the division of responsibility is standard and explicit: the venue is the data controller, Roosty is the processor, and a data processing agreement governs the relationship. What matters day to day:

• Access and portability: staff data and venue data export in machine-readable formats, self-service.
• Correction and deletion: tooling exists to fulfil requests within statutory timelines, including deletion that actually deletes, subject only to legal retention duties around worked hours.
• Retention: data tied to payroll obligations is retained as law requires; everything else follows a documented schedule instead of accumulating forever.
• Sub-processors: listed, documented, and changes announced in advance.

None of this is remarkable, and that is deliberate. Privacy compliance should read like plumbing specifications: complete, boring and verifiable.

Threats we actually plan for

Security pages love abstract reassurance. More useful is naming the realistic threat scenarios for venue scheduling data and what specifically counters each:

• The shared tablet behind the bar. Venue reality: devices are communal. Counter: per-person logins with role-scoped views, short sessions on shared devices, and nothing sensitive reachable from the shift-view a bartender needs.
• The departed manager. People leave, sometimes badly. Counter: single-action offboarding that revokes access everywhere at once, and audit logs that make any pre-departure exports visible.
• The phishing attempt. Counter: authentication hardening, no credentials in email flows, and support procedures that never ask for passwords, so any message that does is self-evidently fake.
• The over-curious integration. Third-party connections that request more than they need. Counter: scoped tokens per integration and a data-minimal design on our side of every bridge, as described in the integration guide.
• Us. The processor itself is part of the threat model. Counter: logged and reviewed production access, separation of duties, and external penetration tests that treat Roosty's own staff as a potential vector, because a security story that exempts the vendor is marketing.

Advice for venue owners, beyond the vendor

Most real-world scheduling data leaks have nothing to do with software vulnerabilities. They happen in the workflow around the tool, and they are cheap to prevent:

• Stop the screenshot culture. A roster photographed into a group chat has left every protection the system provides. Native shift views for staff remove the reason screenshots exist.
• Match access to roles, then re-check quarterly. The shift lead who became a manager needs more access; the one who stepped back needs less. Access drift is the most common finding in venue audits.
• Retire the shadow copies. The old Excel files with three years of schedules and phone numbers, sitting in a shared drive, are your largest unmanaged data store. Archive what payroll law requires; delete the rest.
• Practice the exit. Once a year, walk through what happens when a manager leaves: which accounts, which devices, which shared logins. Fifteen minutes of rehearsal beats an anxious afternoon of guessing.

A note on AI and employee data

Because Roosty's scheduling intelligence learns from venue history, it is fair to ask sharper questions about the AI layer specifically, and they deserve unhedged answers.

What does the AI actually train on? Shift-level operational data: coverage outcomes, demand curves, accepted and rejected suggestions. It does not train on free-text fields, absence reasons or anything an employee might reasonably consider personal expression.

Can a schedule suggestion leak someone's private constraints? This is subtler than it sounds: a system that visibly never schedules someone on Sunday mornings reveals a pattern to colleagues. We mitigate it by design, suggestions never expose stated availability reasons, and the roster shows outcomes, not the constraints behind them. What colleagues can infer from outcomes alone is the same as with any human-made schedule.

Is there automated decision-making in the legal sense? No. Every schedule is reviewed and published by a human manager, and the system is built to make that review real rather than ceremonial: suggestions carry reasoning, and the publish step is deliberate. The GDPR's protections around solely automated decisions are therefore never in play, by architecture rather than by disclaimer.

What happens to learned patterns when someone leaves? Individual-linked history follows the deletion and retention schedule like all personal data. Aggregate venue patterns, Fridays run hot, terrace needs three in summer, contain no personal data and remain, which is exactly the split you would want: the venue keeps its knowledge, the person keeps their privacy.

When something goes wrong anyway

No honest security story ends with "nothing will ever happen". The mature version ends with an incident plan, and ours is written down: containment first, assessment with named owners, notification to affected venues within the GDPR's 72-hour window with plain-language descriptions of what data was involved, and a post-incident report that states causes and fixes rather than reassurances. Venues can request the current incident-response summary alongside the data processing agreement. The measure of a processor is not whether it can promise perfection; it is whether its worst day is organised, transparent and survivable for its customers.

Finally, the plan is rehearsed, not just written. Twice a year we run a tabletop exercise against a plausible scenario, a leaked credential, a misbehaving sub-processor, and time ourselves against the commitments above. The exercises routinely find small gaps, which is their purpose: the worst moment to discover that a phone tree is outdated is the night you need it. Venues are welcome to ask what the last exercise changed; the answer is usually pleasingly mundane.

What to ask any scheduling vendor

Whether or not you choose Roosty, these five questions separate real answers from reassurance theatre:

• Exactly which personal data fields do you store, and which do you refuse?
• Is my venue's data used to improve results for other customers?
• Where is the data hosted, and under which jurisdiction?
• How does a deletion request actually propagate, including backups?
• Show me the audit log for a schedule change. Who can see it?

Any vendor worth your roster answers these in writing without flinching. Ours are above, the product they protect is in the feature overview, and pricing includes the data processing agreement at every tier. More on how we build on the blog.

Frequently asked questions