A hotel is the only business most people deal with that asks every customer, on arrival, for an identity document and a payment card, and then keeps both.

It keeps them for longer than the guest imagines, in more places than the hotel usually knows, and it entrusts them to a chain of people and companies the guest will never meet: the receptionist on her second day, the night auditor, the property system hosted in another country, the channel manager, the payment gateway, the company that maintains the door locks, the IT provider, the booking platform through which the reservation arrived. None of them is careless. Each of them holds a piece of something the guest handed over once, at a counter, usually in a hurry.

This standard does not ask a hotel to become a bank. It asks that somebody has decided, for each thing the guest entrusts, who holds it, who can reach it, how long it is kept and what happens when something goes wrong, and that the decision can be shown to somebody who was not in the room when it was taken. Everything in this book follows from that sentence.

There is a second thing to say about this discipline, and it belongs to the subject rather than to the standard. Information security is the discipline in this series most readily handed away. Energy goes to the chief engineer, but the owner still sees the bill. Information security goes to the IT department or to the IT provider, and it disappears from the owner’s view entirely, as if it were a technical matter with a technical answer. It is not. The decisions that most determine how safe a guest’s information is in a hotel are about licences, staffing, rotas, suppliers, what the front desk does at its busiest hour, which list is printed at night and which software is bought on price. They are taken in budget meetings and on the front desk, by people who do not think of them as security decisions, and the standard places them where they belong: with top management.

That is why this volume is the helm. The first chapter is what ownership decides: the value of the information itself, the context in which it lives, the parties who have an interest in it, the leadership that cannot be delegated, the scope that can be drawn honestly or conveniently, the relationship between the law and the standard, the policy, the risks and their owners, the statement of which controls apply and why, the objectives, the budget and the insurance, the suppliers, the staffing model, the management review, and the oldest control in the building, which is discretion. The second chapter is what management does with those decisions: access, identity documents at the counter, card numbers, connected rooms, messaging groups, suppliers who log in at night, the hotel without its systems, the purchase of software, cameras, devices that leave the building, the first hours of an incident, the network, training, monitoring and, finally, the correction of what went wrong.

Eight appendices follow the Afterword, and they are working material rather than further argument: every reference control read from a hotel, the short list of what the standard asks to be written down, the law and the standard set side by side by function, a sequence for the first year, questions for the suppliers who hold the keys, one hotel with its instruments filled in, a five-minute briefing for each department, and the thirty cases in brief.

The companion volume examines the same system from the two positions that have to be convinced it works. Everything in this book is what a property does. Whether any of it is true is a different question, asked by different people, and it is not the subject here.

Where this standard came from

Hotels were keeping secrets long before anybody wrote a standard about it. The register at the desk, the safe behind it, the concierge who knew which guests were not to be announced: the trade had controls for information before it had the word. What changed was not the duty but the medium. The register became a database reachable from anywhere, the key became a card and then a code on a telephone, and the guest’s details began to travel, through a dozen systems, to places the hotel could not see.

The standard itself began as a British code of practice in the mid-nineteen-nineties, written for organisations of every kind, and became international at the turn of the century. Its requirements, the part against which an organisation can be certified, were published as ISO/IEC 27001 in 2005 and revised in 2013 and in 2022. The most important thing that happened along the way was a change of object: from the security of systems to the security of information, in whatever form it takes. That matters more in a hotel than almost anywhere, because in a hotel the information is on a screen, on a printed list in a pantry, in a photograph on somebody’s phone, and in a conversation at the bar, and a system that protects only the first of these protects the part that is least likely to leak.

Hotels came to the standard late, and most of those that came were pushed: by a corporate client’s questionnaire, by a group’s policy, by the arrival in 2018 of the European Union’s data protection regulation, which asked organisations to demonstrate what they had previously only asserted. The regulation says what must be protected and what a guest is entitled to. The standard supplies a way of managing the protection so that it can be demonstrated. This book uses both, and keeps them apart.

Who this book is for

The owner who signs the IT contract without reading the part about who reports what, and when. The general manager who is told that security is in hand because the provider’s report is green. The front office manager whose desk collects more personal information in an afternoon than the rest of the hotel in a week. The finance director who receives the letter from the card acquirer. The human resources manager who hires sixty people in April and does not know that she is also granting access to sixty accounts. The IT provider who wants to know what a hotel should be asking of it. The data protection officer who keeps a careful record that nobody else reads. And the person, there is usually one, who runs the information security system alongside another job, in whatever hours are left.

Three facts about hotels govern everything in this book. The first is that the information is collected at the counter, at the busiest hour, often by the newest person on the desk. The moment at which a guest becomes a set of records is the moment at which the hotel has the least time, the most noise and the least experience available, and every control that depends on calm will fail there first.

The second is that the workforce changes faster than the systems. A resort may hire more than half its summer staff for the season, a city hotel loses a receptionist every few months, and each arrival and departure is, among other things, an account opened or left open. Access that is not managed at the speed of people drifts away from the people the hotel actually employs.

The third is that most of the systems that hold guests’ information are run by somebody else. The property system is hosted, the booking engine is a service, the payments pass through a gateway, the locks and the cameras are maintained under contract, and the network is looked after by a provider. A hotel’s information lives, for the most part, in other people’s buildings, and the hotel’s security is largely the security of its suppliers, chosen and contracted by the hotel.

To these the standard adds a fourth, and it is what separates this discipline from the others in the series. Its annex contains a list of reference controls, ninety-three of them, and the list is the most visible part of the standard and the most misunderstood. It is not a catalogue to be implemented. The hotel decides which controls it needs from its own risks, and then compares its choice with the list to make sure it has not omitted anything necessary, explaining in a single statement what it has included, what it has left out, and why. A good part of this book is about that sequence, because a hotel that starts from the list builds a system for somebody else’s risks.

What this book is, and what it is not

It is a practitioner’s guide to building and running an information security management system in a hotel. It is not consultancy, it does not sell a template, and it will not tell you whether your property is compliant; nobody who has not seen your systems, your contracts and your front desk at three in the afternoon can tell you that. It is also not a technical manual. There is nothing here about configuring a firewall or choosing an encryption algorithm, because those are questions for a different profession and because the failures described in this book were almost never caused by a lack of technical knowledge.

Opening

The reservations were cancelled between two and four on a Saturday morning, and the front office found out when the first guest arrived for a room that no longer existed.

The hotel is two hundred and forty rooms a few streets from Syntagma Square in Athens, one of six in a Greek hotel group, and that weekend it was sold out for a conference. By nine in the morning the front office manager had found that forty reservations for the Saturday and Sunday nights had been cancelled in the property system during the night, their rooms released and in several cases resold through the booking platforms at a fraction of the rate. The duty manager spent the day finding rooms for guests in other hotels, at the hotel’s expense, and apologising to a conference organiser who had chosen the hotel because it had never let her down.

The general manager, Nikos Papadakis, who had joined the property four months earlier, asked the IT coordinator who had done it. The property system was hosted, and its logs showed that the cancellations had been made from an internet connection outside the hotel, using the account of a night auditor who had left the hotel eleven weeks earlier after a dispute over his hours. His account had never been closed. Because the system could be reached from any browser, leaving the building had not ended his access to it.

Nikos then did what he had intended to do since he arrived and had not found time for. He asked for every account on every system in the hotel and set the list beside the payroll. The property system had two hundred and twelve active accounts for a hundred and forty employees. Thirty-eight belonged to people who had left, most of them seasonal staff from the previous two summers. Nine people in reception shared an account called reception1. Fifteen belonged to suppliers and contractors, some of whom nobody could identify. And a dozen staff who had changed jobs within the hotel still held every right they had ever been given: a former reservations agent now in sales could still override rates and issue refunds; a former night auditor now in accounts could still post adjustments to guests’ folios.

None of this was the result of a decision. Every account had been opened for a good reason, at the request of a manager who needed somebody to start work. None had been closed, because closing an account was nobody’s task. Human resources knew when people left, and did not manage the systems. IT managed the systems, and was not told when people left. Department heads knew what their staff needed, and were never asked.

The Problem

The first failure is how access was granted. Any manager could ask the IT coordinator for an account for a new starter, usually by a message on the morning the starter arrived, and the coordinator created it, usually by copying the account of somebody in the same department. Nobody approved the rights in the sense of deciding what this particular person needed. The copied account carried whatever its original holder had accumulated, and the new starter began with more access than any job description would have justified.

The second failure is that leaving was not connected to access. Human resources ran a careful process for leavers: final pay, return of uniforms and keys, a leaving interview. Nothing in it told IT. The keys to the building were recovered on the last day; the keys to the property system, which opened far more, stayed with the person who had left.

The third failure is what happened to people who moved. Hotels promote from within, and staff move between departments often, which is one of the strengths of the industry. Each move added rights, because the new job needed them, and removed none, because nobody thought of the old job’s rights when the person was starting the new one. After a few years, the staff with the most varied careers held the widest access in the building, including combinations, such as posting charges and approving refunds, that the hotel would never have granted to one person deliberately.

The fourth failure is that the hosted system was reachable from anywhere. When the property system ran on a server in the hotel, a person who had left the building could not use it. Now it could be reached from any browser in the world, which made it far more convenient for the hotel and meant that access ended only when the account did. The move to the hosted system had been decided for good reasons. Its consequence for the way accounts had to be managed had not been noticed.

The fifth failure is that access had never been reviewed by anybody who could judge it. The IT coordinator had once produced a list of accounts for the internal auditor, who had checked that a list existed. Nobody had asked the head of each department to look at the accounts in their area and say which were still needed and whether their rights made sense. IT could see the accounts. Only the departments could see whether they were right.

The sixth failure is the shared account. Reception1 had survived from a time when the front desk had fewer terminals and the property system charged by named user. Nine people used it. Any action taken through it, a rate change, a refund, a cancellation, could not be attributed to anybody, and if one of the nine had been the saboteur, the logs would have pointed to all of them.

The seventh failure is in the logs. The property system recorded every login and every action, with the time and the address it came from. Nobody looked at those records unless something went wrong, and nobody had arranged to be told of anything unusual, such as a login at three in the morning from outside the hotel by an account that had not been used for eleven weeks. The evidence of the problem had existed, in plain view, since the night auditor left.

Underneath all seven sits a single structural fact. In a hotel, people change faster than systems. Staff join, move and leave every month, and in a seasonal property by the hundred each year, while the systems they use stay the same for years. Unless the hotel manages access at the speed at which its people change, its accounts will drift further every month from the people it actually employs, and every account that belongs to nobody is a door that anybody who knows its password can use.

The Principle

Access follows the person through three events: joining, moving and leaving. At each event, a named person in the business decides what access is needed, and somebody else carries it out and records it. When a person joins, their manager asks for access by role, and the rights granted are those of the role, not those of a colleague. When they move, the rights of the old role are removed as the rights of the new one are added. When they leave, every account is closed on their last day, whatever system it is on, whoever supplies it.

The standard expresses this through a group of reference controls. It asks for rules to control access based on business and security requirements, for the full life cycle of identities to be managed, for authentication information to be managed, and for access rights to be provisioned, reviewed, modified and removed in accordance with the organisation’s rules. It asks for privileged access to be restricted and managed, and for activity to be logged. None of these requires technology the hotel does not already have. They require a process that connects human resources, department heads and whoever administers the systems.

For the management of a hotel, the principle has a practical centre. The person who knows whether access is right is the head of the department, not IT. The head of front office knows who works at the desk, who has moved to sales and who has left. So the review of access belongs to department heads, a few times a year, with a list of their people’s accounts in front of them, and the question is simple: does each of these people still work here, and does each still need what they have?

There is a second part to the principle that concerns the hotel’s own staff rather than its systems. A person who leaves on bad terms, as the Athens night auditor did, is the person most likely to misuse access that has not been closed. That is not a reason to suspect staff. It is a reason to close accounts on the last day as a matter of routine, for everybody, so that nobody’s departure depends on whether they left happily.

What the Standard Says

This subchapter rests on the reference controls on access, identity and authentication. What follows is what they oblige, in this book’s own words.

• Rules to control physical and logical access to information and associated assets must be established and implemented based on business and information security requirements.
• The full life cycle of identities must be managed.
• The allocation and management of authentication information, such as passwords, must be controlled by a management process, including advising personnel on its appropriate handling.
• Access rights must be provisioned, reviewed, modified and removed in accordance with the organisation’s topic-specific policy and rules for access control.
• The allocation and use of privileged access rights must be restricted and managed.   …