Hotel website security and ownership: domain, certificate, updates and logins

Hotel website security means the hotel, not its agency, holds the domain and the DNS records that point it at a server, knows every renewal date, keeps the software updated, gives each person their own admin login with two-step sign-in, and has restored a backup once.

A hotel changes web agency, and three months later the site goes dark. The domain was registered in the agency's name and the renewal card on file was theirs. Nothing was stolen, and nobody had checked who held the account. This article walks through hotel website security from the ground up: who owns the domain, when things expire, who signs in, whether backups restore, and what changes hands when the agency changes.

Who owns the hotel's domain name and its DNS?#

The hotel should own both: the domain registered in the hotel company's name, and the DNS account that decides where that name points. The agency can do the work without holding either.

Separate the two roles. The registrant is the name on the registration record and controls the domain. The payer is whoever settles the invoice. An agency can pay every year and still not be the owner, or be the owner and pay nothing. Ownership follows the record, not the card.

DNS needs explaining in plain words. The DNS records are short entries that tell the internet which server serves the website and which service handles the hotel's email. Whoever can edit them can move the site and the mail within minutes. That is why the website and the email belong in one conversation: control of DNS is control of the hotel's mail as well.

The workable arrangement is delegated access. The hotel holds the registrar and DNS accounts, and the agency gets its own user with the rights it needs, removed in writing when the contract ends. Check it today: look up the public registration record for the domain and read the registrant line. If it names a person at the agency rather than the hotel company, that is the finding.

Be honest about the trade-off. Agencies often register on the hotel's behalf because it is faster at the start. That is workable if the account is created in the hotel's name from day one, and painful to unwind later.

For the email side of DNS, see SPF, DKIM and DMARC for hotels.

When do the domain and the SSL certificate expire, and who gets the reminder?#

Both dates belong in the hotel's own calendar with a named owner, because an expired certificate turns the site into a browser warning and an expired domain takes the name offline entirely.

Define the certificate once. An SSL certificate is a file issued for a specific name that lets the browser show the padlock and encrypt the connection. It has a start date and an end date, and nothing renews it by itself unless someone set that up.

Auto-renew fails quietly. The card on file expires, the reminder goes to a mailbox nobody reads after a staff change, or the automation breaks and no one looks at the site for a month. Record four fields for every item that expires: what it is, where the account lives, the renewal date, and the person responsible. A date without a name is a date nobody keeps.

Put two reminders in the hotel's calendar, one a month before and one a week before, sent to an address the hotel controls rather than the agency's. Check which names the certificate covers: a certificate for the main site does not automatically cover the booking subdomain, and that is the page where money changes hands.

Short-lived certificates that renew automatically move the risk rather than remove it. The question becomes whether the automation still works, so someone opens the site and looks at the padlock every week.

The hotel fills one line per row and reviews it when staff or agencies change.

Is the site software up to date, and who is allowed to update it?#

Updates should run on a schedule with one named person responsible, because out-of-date software is a known way in and the fix is usually a click that nobody scheduled.

Know what the site is made of: a core system, a theme, plug-ins or modules, and the server software underneath. Each has its own update path and its own owner. Remove what is not used: an inactive plug-in is still code sitting on the server, and nobody is watching it.

Test on a copy when the site takes bookings. Update the copy, walk the booking path, then update the live site. On a brochure site the order matters less; on a booking site it matters. Keep a short change log: date, what changed, who did it, what was checked afterwards. It turns an argument with an agency into a record.

Watch for end-of-life software. When the maker stops issuing fixes, updating is no longer possible and replacing that piece is the only real option. Do not forget the server side: the hosting panel and the database engine need updates too, and they are usually the agency's job, which means it must be written down.

Who has admin access, and how do they sign in?#

Every admin login should belong to one named person, require a second step at sign-in, and end on the day that person leaves.

Shared accounts make the log useless. With one login called admin, nobody can tell who changed a price, a page or a redirect. Two-step sign-in, in plain words: the person enters a password and then a code from a phone or a hardware key. A stolen password alone stops being enough.

Inventory every door, not just the website: hosting panel, database, DNS, booking engine, payment provider dashboard and the agency's own management panel. Handle leavers as a process: a written list of who had access, checked at every staff change and at the end of every agency contract, with the removal dated.

Store passwords in a manager the hotel owns, so access does not depend on one person's memory or one phone that might be lost. Apply least privilege: an editor does not need the right to install software, change DNS or add users.

For the wider picture, see the hotel cybersecurity checklist for owners and general managers.

Do the backups actually restore?#

A backup counts only after someone has restored it to a test address and seen the site work, so the test is part of the backup, not an extra.

Ask three questions: what is copied (files, database, images), where the copy lives (not on the same server as the site), and who can restore it without calling the agency. Set the frequency from what the hotel can afford to lose: a site with a live booking engine changes every day, a brochure site does not.

Run the restore test properly: restore to a temporary address, open the home page, follow the booking path, send a test form, then delete the test copy so it cannot be found later. Record the test: date, who ran it, what broke, how long it took. The record is what turns a claim into a fact.

Treat the agency's backup as the agency's until the hotel can request a copy and receive it in a usable form. Keep one copy the hotel can reach without anyone's help, even if it is only the files and the database export.

For more depth, read backups for hotel systems: what to copy, where to keep it and how to test it.

Booking engine and payment pages: whose domain, whose responsibility?#

The booking page is where the money is, so the hotel needs to know whose name is in the address bar, whose certificate covers it, and who is called when it breaks.

Two common shapes exist: the booking engine on a subdomain of the hotel's own name, or on the provider's domain. Each shape gives the certificate a different owner and the guest a different name to look at. Read the address bar as a guest would: a certificate is issued for a name, so a booking page on a provider's domain shows the provider's name, and some guests notice before they type a card number.

Understand where card details are entered: usually on the bank's or the payment provider's page, not the hotel's. The hotel's duty is never to ask for card details by email, chat or phone. Write the responsibility into the contract: who watches the booking page, who is called outside office hours, and what the hotel is told when the page goes down.

Test the whole path on a phone once a month, including the confirmation email, because a booking that completes but never confirms is a complaint waiting to happen. Treat an unexpected redirect as an emergency: a booking page that sends guests somewhere new is either a setting someone changed or a sign that the site has been altered. Fake booking messages are a related threat; see fake booking messages and extranet takeovers.

Changing web agencies: what belongs in the handover file?#

The handover file is a written list of every account, date and password holder, signed by both sides, and it is prepared before the contract ends, not after.

Cover every account, not just the website: registrar, DNS, hosting, certificate, site admin users, database, backup location and last restore test, booking engine, analytics, search console, payment dashboard and mail records. Order the transfer so nothing goes dark: create the hotel's own accounts first, move the data, then remove the agency's access, and note each step with a date.

Change every shared password on the day of handover, and record who holds each one afterwards. Ask for a full export: files, database, images, and the receipts for any theme or licence the hotel paid for. Check the site after handover against the same list: padlock, booking path, forms, confirmation email, and the certificate's renewal date. Keep the file alive: review it when staff change, when the agency changes, and once a year even if nothing happened.

What to do next#

Open the public registration record for your domain today and read the registrant line. If it does not name your company, that is the first fix, because the certificate, the updates, the logins, the restore test and the handover file all assume the hotel holds the accounts. Everything else on this list is maintenance; ownership is the part that cannot be recovered quickly once it is lost.