Auditing staff permissions: a quarterly checklist.

Why permissions drift, and why it matters

Access creep is one of the most predictable patterns in any software system with more than a handful of users: it is always easier to grant broad access once than to scope it precisely, and it is always easier to leave an old account active than to chase down whether it's still needed. Neither failure is usually the result of carelessness — it's the natural outcome of nobody owning the review. For a hotel PMS specifically, the stakes are concrete rather than abstract: overly broad access means a front-desk shift can quietly override a rate, a housekeeping login can see financial reports it has no reason to see, and a former employee's still-active account is a real exposure, not a theoretical one.

The fix isn't a one-time lockdown, it's a recurring habit — a quarterly review that takes an hour or two and catches drift before it compounds.

Role types in Sabee

Sabee ships with a set of role templates that map to how a hotel actually organises its team, and each should be treated as a starting point to refine rather than applied identically everywhere:

• General manager. Full visibility across the property — reservations, rates, reporting, housekeeping, and typically finance — but even a GM role benefits from being scoped to their own property in a multi-property account rather than granted blanket group access by default.
• Reception / front desk. Reservation creation and management, guest communication, check-in and check-out flow, and typically read-only visibility into rates rather than edit rights — a front-desk shift should be able to see the rate a guest is quoted without being able to change the underlying rate plan.
• Revenue / rate management. Edit rights on rate plans, calendars and channel mapping, but not necessarily full financial reporting or refund authority — revenue strategy and accounting are related but distinct responsibilities and are worth separating even at a small property.
• Housekeeping. The mobile task workflow described in our housekeeping workflow guide — room status, maintenance tickets, deep-clean schedules — with no visibility into rates, guest payment details or financial reporting at all.
• Finance / accounting. Invoice generation, credit notes and refund processing, VAT and reporting exports — covered in our VAT and invoicing guide — typically without reservation-editing rights, since finance's job is to record what happened accurately, not to change bookings.
• Chain-level / group admin. Cross-property visibility and, depending on your operating model, cross-property rate or reporting authority, as covered in our multi-property rollout guide. This role should be the most sparingly assigned of all of them — it's the one with the broadest blast radius if the account is ever compromised or misused.

The least-privilege principle, applied practically

Least privilege means granting each person the minimum access required to do their actual job, not the maximum access that might one day be convenient. In practice this means resisting three common shortcuts:

• "Just make them admin, it's easier." It is easier, right up until an admin-level account is compromised, misused, or simply makes an unintended change somewhere they never needed access to in the first place. Scoping access takes a few extra minutes during setup and pays that time back many times over.
• Copying an existing user's permissions for a new hire without checking whether that existing user's own access has drifted beyond what their role actually needs. Build new users from the role template, not from whoever happens to be sitting next to them.
• Leaving a temporary elevation in place. A staff member covering for a manager on leave, or a seasonal supervisor given rate-edit access for one busy period, needs that elevation reverted on a set date, not left indefinitely because nobody remembered to undo it.

The quarterly review checklist

Run this every quarter — calendar it as a recurring task owned by one specific person (typically the GM, or the group operations lead for a multi-property account), not left as "someone should probably do this eventually":

• List every active user against your current staff list. Any account without a matching current employee is a candidate for immediate deactivation, not a "we'll get to it" item.
• Check each user's role against their actual current job. Someone promoted from reception to revenue management six months ago and still holding only front-desk permissions is a functional problem; someone who moved to a different role but kept their old broader access is a security one.
• Look specifically for admin and finance-level access and confirm every account holding it currently needs it. These are the highest-impact roles to keep tightly scoped.
• Review any temporary elevations granted since the last review and confirm each has either been reverted already or has a clear, justified reason to still be active.
• Check group-level access in a multi-property account specifically — cross-property visibility is the easiest permission to over-grant because it feels natural to give a regional manager "everything" rather than scoping to their actual cluster of properties.
• Confirm password hygiene — no shared logins across multiple staff members, which breaks the entire point of an audit log by making it impossible to know who actually took a given action.

Offboarding: the step that gets missed most often

Offboarding should be treated as part of the exit process itself, not a follow-up task for whenever the next permissions review happens to fall. The moment a staff member's departure is confirmed — ideally on their last working day, not weeks after — their Sabee account should be deactivated, not merely have its password left unchanged. Deactivation preserves the account's history in the audit log (useful for reference later) while immediately removing access, which is different from deletion and is the correct approach for most properties.

A simple offboarding checklist worth attaching to your HR exit process: deactivate the Sabee account, confirm no shared devices (a tablet at the front desk, a shared housekeeping phone) remain logged into their personal account rather than a role-based one, and check whether they held any temporary elevated access that needs to be reassigned rather than simply removed if their responsibilities are being picked up by someone else immediately.

Reading the audit log

Every meaningful action inside Sabee — a rate change, a refund issued, a permission granted, a reservation modified — is recorded in an audit log tied to the specific user who took it, with a timestamp. The log exists for two purposes: reconstructing what happened when something needs investigating (a rate discrepancy, a disputed refund), and, just as usefully, giving your quarterly review something concrete to check rather than relying on memory of who's been doing what.

During a quarterly review, it's worth spot-checking the audit log for anything unexpected — a rate change made outside normal hours, a refund processed by an account that shouldn't have refund authority, a permission change nobody remembers requesting. None of these are necessarily a problem on their own, but the audit log is what turns "we assume everything is fine" into "we checked, and everything is fine," which is the entire point of running the review in the first place.