PMS user roles and permissions: a setup checklist for hotels

PMS user permissions are the individual rights a hotel grants inside its property management system, such as voiding a charge or exporting guest data. Set them by role rather than by person: give each job only the rights it needs, split the sensitive ones between two people, keep one login per person, and review the list every quarter.

At 03:40 the night auditor voids a minibar charge and then closes the business day. If one login can do both, the record shows a user, not a person, and nobody can say afterwards whether the void was a correction or a loss. This article gives you the full setup: which rights carry the real exposure, how to build roles from tasks, how to separate duties, how to handle logins and non-human accounts, and what routine keeps it all correct after the first week.

What are PMS user permissions, and why do they carry the hotel's money and guest data?#

A permission is a single right inside the hotel's property management system (PMS), the software that holds reservations, the guest bill and the business day. A role is a named bundle of permissions given to a job. Keep the two words apart from the start: the permission is what the system checks at the moment of the action, and the role is only a convenient way to hand out many permissions at once.

The system holds three things that matter: money on the guest bill, identity data used for guest notifications, and the closed business day. A permission is the only thing standing between an employee and those records. Under KVKK (Kişisel Verilerin Korunması Kanunu, the personal data protection law), the data controller must take technical and administrative measures to prevent unlawful processing of and unlawful access to personal data. Confirm your own obligations, and how they apply to anyone processing data on your behalf, with a legal adviser.

The working rule is least privilege. NIST's glossary, citing CNSSI 4009-2022, defines it as restricting the access of users, and of processes acting on their behalf, to the minimum necessary to accomplish assigned tasks (NIST CSRC, Glossary, 2022). The Authority's Personal Data Security Guide (April 2025) (opens in a new tab) advises giving employees access only to the extent their tasks, authority and responsibilities require, through a username and password, with an access authorization and control matrix built on the principle that everything is forbidden unless permitted.

A decision rule you can apply today: if you cannot name the task that needs a right, the role should not have that right. Ask your vendor for a permission list you can export, so the matrix you approve is the matrix the system actually enforces. When you evaluate systems, this belongs among the questions to ask a PMS vendor about user permissions.

Which permissions carry the real financial and privacy exposure?#

Five rights do most of the damage when they sit in the wrong role: voiding a charge, overriding a rate, granting a complimentary room, exporting guest data and reopening a closed day. Everything else can usually follow the job description.

Voiding is not deleting. A correction is made by voiding the original entry and posting a reversal, so the original stays visible; the risk is not the correction, it is the volume nobody reviews. A rate override quietly changes what the hotel earns on a room, and it is easy to hide inside a busy week because the reservation still looks normal. A complimentary room gives away revenue with no payment trail, which is why it usually needs a second name on it.

Guest data exports copy profiles, contact details and identity data out of the system and out of your control; the export right should be narrower than the view right, not wider. Reopening a closed business day changes figures that have already been reported, so it belongs to the controller or the general manager and should leave a written reason. For each of the five, decide three things in advance: who may hold it, what the record must show, and who reads that record.

How do you map tasks to roles by department?#

Write down what each department actually does in the system, then build roles that cover exactly those tasks and nothing more. The order matters: tasks first, roles second, people last.

Start with a task inventory per department: front desk, reservations, housekeeping, restaurant and bar, accounting, revenue, IT and the GM's office. One page each is enough. Group the tasks into six to ten roles; fewer and you will over-grant, many more and nobody can maintain the matrix. Name roles after the job, never after the person: "night auditor" survives a staff change, a person's name does not.

Give each role a default view and only the menus its tasks need, so a front desk agent does not land on the rate manager screen every morning. Test each role by signing in as it and attempting a task it must not do; the system must refuse, and the refusal is your evidence that the role is set correctly. Record the result as a role-by-right matrix in a spreadsheet, dated and signed by the GM and the controller. In a group, reuse the same roles across properties so that a transfer does not create a new permission set.

Why do separation of duties and reason codes belong together?#

Separation of duties stops one person from completing a risky action alone; reason codes make the exceptions that remain readable. Without the second, the first produces a log nobody can interpret.

NIST's glossary, citing NIST SP 800-192, defines separation of duty as the principle that no user should be given enough privileges to misuse the system on their own, enforced statically through conflicting roles or dynamically at the time of access, with the two-person rule as the dynamic form (NIST CSRC, Glossary, 2026). The classic conflict in a hotel is between taking money and removing it: the person who receives a payment should not also be able to void it without a second name. The second conflict is inside the night: whoever closes the business day should not be able to post and void freely in the same session, because the closing figure is what everyone later trusts.

Keep the reason-code list short and fixed, for example guest complaint, wrong room, minibar error, management compliment, then allow free text underneath. A list of thirty codes gets ignored. Use a two-person rule for complimentary rooms and for voids above a threshold you set: one person enters, another approves with their own credentials, and both names stay on the record.

In a small hotel where three people cover everything, separation may be impossible. Then keep the rights but compensate with a next-morning review by the owner or an outside accountant, and never with a shared login. For AI-assisted workflows, the same idea extends to which actions should wait for a person to confirm.

Why does one person, one login matter, even at a shared terminal?#

A shared terminal is fine; a shared account is not. The moment two people use one login, the system can no longer say who did what, and every later review rests on a guess.

The log is the product of the whole setup. If it records "reception", the void, the override and the export are all attributed to a desk rather than a person. Keep the machine shared and the account personal: individual sign-in with a short PIN or a badge reader on the same terminal, or fast user switching between shifts. Lock the screen on walk-away, and never leave a manager session open at the front desk for the next person to use.

Administrator rights belong on a separate account used only for administrative work, as the Authority's guide recommends, not on the everyday account of the person who happens to be trusted. Weigh the cost honestly: an individual sign-in costs seconds per shift, while an unexplained void costs days of reconstruction and a conversation nobody enjoys. Watch for the override habit, where a manager types a password at an agent's terminal; that is a shared credential with extra steps.

What about accounts that are not people: integrations, vendor support and AI assistants?#

Every non-human account is a login with no face behind it, so it needs a name, an owner, the narrowest rights that let it work, and its own line in the log. This is part of how the core hotel systems fit together.

Give each integration its own account: the channel connection, the accounting export, the door-lock system, the e-invoice integrator. One account per connection, documented with what it reads and what it writes. Vendor support access should be named, approved in advance, limited to a window, and switched off when the session ends; ask for a session record and keep it with the ticket.

For AI assistants, apply one principle regardless of vendor: the assistant acts with the rights of the person on whose behalf it acts, never with a super-user account, and anything sensitive is confirmed by a person. Log the requesting user alongside the assistant's own account, so an action taken through an assistant still points back to a human. Rotate or reset the credentials of any shared integration account when someone who knew them leaves, and note the change in the matrix. Review non-human accounts on the same schedule as people; they are the ones nobody remembers creating. In shared software, also check how each hotel's data stays apart.

What routine keeps permissions correct after the first setup?#

Three habits: handle joiners, movers and leavers on the day it happens, read a daily exception report, and run a quarterly access review with names and dates on it.

Joiners get an account on their start date with a role from the matrix, never a copy of a colleague's account, because a copy carries rights nobody chose. Movers are the quiet failure: adding the new role is easy, removing the old one is forgotten, and the person ends up with the union of two jobs. Leavers are closed on their last shift, not at the end of the month; the Authority's guide says the accounts of employees who leave should be deleted or closed without delay.

The daily exception report lists voids, complimentary rooms, rate overrides, data exports, reopened days, failed sign-ins and activity outside normal hours. Someone named reads it and signs it. The quarterly review exports the user list, and each department head confirms or removes every account; check dormant accounts, count the administrator accounts, and compare your list with the vendor's. Keep the dated records: under KVKK the controller must take technical and administrative measures, and a measure you cannot show is hard to defend later. Confirm your own retention and deletion duties, and any registration obligations that apply to you, with a legal adviser or accountant rather than from a blog post.

What to do next#

Export your current user list today and mark who holds the five sensitive rights: voids, rate overrides, complimentary rooms, guest data exports and reopened days. That single page tells you where the exposure sits, and it is the document the rest of this checklist is built on: roles from tasks, separation for the sensitive rights, one login per person, narrow accounts for everything that is not a person, and a review that happens on a schedule rather than after an incident.