What a penetration test is, when a hotel needs one and how to read the report

A penetration test is an authorized, simulated attack on your systems by a person who tries to break in and then shows you how. For a hotel it covers the website, guest Wi-Fi, staff network and remote access. It comes after basic hygiene, needs written permission, and ends in a dated fix list.

A security firm offers you a penetration test at a price that sounds reasonable, and asks for your public IP addresses by email. Before you reply, three questions decide whether the money buys you anything: what is being tested, who has agreed to it, and what you will do with the result. This article answers all three, and ends with a way to turn the report into a dated list your team can actually work through.

What is a penetration test?#

A penetration test is a planned, permitted attempt to break into your own systems, carried out by a person who then documents how far they got and how. The deliverable is evidence and a fix list, not a score.

The tester works from a written scope: named addresses, applications and accounts, with start and end dates. Anything outside that list is not touched. A person chains small weaknesses together. An exposed admin page, a shared password and an unpatched plugin are each minor; combined, they can be a path from the internet to the reservation book.

A finding counts only when it can be reproduced. The report should give steps another technician can follow to see the same result. It is a snapshot of one moment, not a guarantee: a clean report says the tested systems resisted the tested attacks on the tested days. It is not a compliance stamp and not a substitute for patching, backups or access control. Those are the hotel's daily work.

Three activities get confused, and the confusion costs money:

A scan is automated, frequent and noisy: it matches known signatures and lists candidates. A test is manual, periodic and produces proof. An audit reads documents and interviews people to check that you do what you say you do.

Should you fix the basics before you pay for a test?#

Yes. A test on unpatched, unmanaged systems mostly rediscovers what a scan already told you, and you pay a specialist's day rate to hear it.

Testers charge for time. Every hour spent proving that an unsupported server is unsupported is an hour not spent finding the path an attacker would actually take. The basics are cheap and unglamorous: supported software with updates applied, one account per person, multi-factor authentication on anything reachable from the internet, and administrator accounts that are not shared.

Backups count only if someone has restored one and written down the date. A backup nobody has tested is a hope. People leave, so accounts and remote access for former staff and former agencies are worth checking in any small organization. Keep logging on and keep it long enough to reconstruct an incident, because a test that finds nothing still leaves you needing to answer what happened last Tuesday.

The order that works: fix the basics, run a scan, fix what the scan shows, then commission the test. The test then measures the residue, which is what you are paying to learn. Write the preparation list down before you request quotes, so that every firm prices the same scope.

What is in scope for a hotel?#

For a hotel the usual scope is four things: the public website and booking flow, the guest Wi-Fi, the staff network, and remote access into both. Everything else is either added deliberately or written out.

The website and booking flow covers public forms, the login area, the redirect to the payment page, and any upload or contact form that reaches a mailbox. For guest Wi-Fi, the real question is whether a guest, once connected, can see the staff network, the property management system or another guest's device. Guest and staff traffic belong on separate networks.

The staff network covers shared drives, back-office machines, printers, and whatever the front desk uses to reach the reservation system. Remote access covers the VPN, remote desktop, and any account a support company uses to log in from outside. These are the doors that stay open at night.

Vendor-hosted parts, such as the property management system, the channel manager or the mail service, are usually outside your scope. Ask the vendor what they test and whether they will share a summary. Decide explicitly whether people are in scope: phishing staff, or walking into an unattended back office. If it is not written down, it is not tested.

Give the tester test accounts and test data. Real guest data should not be needed to prove a weakness, and if it is, that is a finding in itself. If you are not sure who can reach your systems from outside, start with our review of vendor remote access, integrations and API keys.

Whose permission do you need before anyone tests?#

Written permission from the owner of every system in scope, which for a hotel is rarely just the hotel. Testing without it can be treated as an attack, by the vendor, by the hosting provider and by the law.

The authorization letter names the testing firm, the individual testers, the dates and hours, the addresses and applications, and the person who can stop the test. Vendor consent comes first, not after. A hosted property management system, a booking engine or a cloud host may require advance notice, may forbid certain tests, or may run its own program you must join.

Rules of engagement belong in the same document: no attacks that take a service down, no copying guest data beyond what proves the point, and a phone number to call if the tester finds someone else already inside. Confidentiality runs both ways. The firm signs an agreement, and the hotel agrees on how findings are stored and who may read them.

Personal data rules apply to the test itself. Test accounts, test bookings and a written deletion step at the end keep the exercise from creating the problem it was meant to prevent. If a vendor refuses permission, that is information. Write it down, and ask the vendor for their own test summary instead.

How do you choose a penetration testing firm?#

Choose on certification, on the named person who will do the work, and on a sample report you can actually read. The sales deck tells you nothing.

Ask what the firm is certified for and at which level. TSE certifies firms that perform penetration tests (opens in a new tab) under TS 13638/T2 at three levels, A, B and C, and issues the title Approved Penetration Testing Firm (TSE, "Sızma Testi Yapan Firmaların Belgelendirilmesi", 22 October 2026). The levels differ by staff and by management system. Level A requires at least one senior, one certified, one registered and two trainee penetration testing experts; level C requires at least one registered expert. Levels A and B also require an accredited information security management certificate (same source).

TSE audits the firm for one day and reviews at least two penetration test projects carried out under the standard (same source). Ask for the certificate's scope and expiry date, not a logo.

Ask who does the work. A senior name can appear on the proposal while a junior does the work; insist the named tester is on the team. Ask for a sample report with the client's details removed, and judge whether the findings are explained in language an owner can act on. Ask whether a retest of the fixes is included, and what it costs if it is not. A test without a retest leaves you with a list and no proof.

Time it outside peak season and outside a system migration, and name a person who is reachable while the test runs. If an insurer or a brand is asking for the test, find out what evidence they want before you brief the firm; our guide to cyber insurance for hotels covers the questions insurers tend to ask.

How do you read a penetration test report?#

Read the definition of the severity scale before you read the findings, then check that each finding has proof and a fix. The label matters less than whether the thing is reachable today.

Severity scales are the firm's own. One firm's high is another firm's medium, so read how the scale is defined and whether it accounts for exposure, meaning whether the system faces the internet or sits in a locked office. Each finding should state what it is, where it lives, how to reproduce it, the evidence, the business impact for a hotel, and the recommended fix. A finding missing the reproduction steps cannot be verified or closed.

Look at the proof. If you cannot follow the steps and see the same result, ask the tester to walk you through it. Separate what is exploitable now from what is theoretical: a medium finding on the internet-facing booking login can matter more than a high finding on an isolated back-office printer. Some findings are configuration choices you made on purpose. That is a legitimate answer, but write it down as an accepted risk with a name and a date. Ask for two layers: a short summary you can hand to an owner or an insurer, and the technical detail for whoever will do the fixing.

How do you turn findings into a dated list?#

Copy every finding into one line with an owner, an action and a date, then work the internet-facing and credential findings first. A report nobody schedules is a document, not a fix.

One line per finding: what it is, who owns it, what will be done, by when, and the current status. Keep it where the owner will see it, not in a folder. Order by exposure first: anything reachable from the internet, anything involving passwords or remote access, then the rest.

Some fixes belong to a vendor. Those lines still need an owner inside the hotel, a ticket with the vendor and a follow-up date. Accepting a risk is a decision, not a default. Record who accepted it, why, and when it will be looked at again.

Retest the fixes rather than the whole scope, and keep the retest letter with the original report. That pair is what proves the work was done. Test again on a rhythm: once a year, after a major change such as a new property management system, a new website or a rebuilt network, and after any incident. Keep the reports. An insurer or a brand may ask for evidence, and a dated report with a dated retest answers that question faster than a description of your intentions.

What to do next#

Write the scope and the permission letter before you ask any firm for a quote, because those two documents decide whether the test is useful and lawful. Then close the basics, run a scan, fix what it shows, and only then commission the test and schedule its findings into a dated list with a retest behind it. The single next step: fill in the scope worksheet above, and send the permission question to every vendor named in it.