Hotel Cloud Software Security & Compliance Checklist

Written by: Kelly Campbell, Vice President of Marketing, Stayntouch

Key Takeaways

• Security compliance for cloud hotel software is proven by verifiable documents such as the PCI DSS Attestation of Compliance, SOC 2 Type II report, ISO certificates, and a GDPR Data Processing Agreement, rather than by vendor badges or claims.
• Each compliance framework covers a defined scope, so buyers must read the scope sections, observation periods, and exceptions to confirm the documents apply to their PMS environment.
• Security follows a shared-responsibility model in which vendors own infrastructure and platform controls, while hotels remain responsible for user permissions, MFA enforcement, staff training, and vetting third-party integrations.
• Key technical and contractual controls to verify include encryption standards, role-based access, breach-notification timelines, data-residency options, and structured export or deletion terms at contract end.
• Stayntouch publishes checkable credentials, scopes integration access with OAuth, and maintains product compliance across 60+ countries to support this verification workflow.

Talk With Stayntouch About Your Security Requirements

Core Requirements for Security Compliance in Cloud Computing

For a hotel, cloud security compliance relies on a stack of frameworks, each covering a different risk surface. The four that matter most in a PMS evaluation are:

• Payment Card Industry Data Security Standard (PCI DSS): Proves how a vendor handles cardholder data, including tokenization, encryption, and the controls around payment processing. For deeper coverage of payment security mechanics, see Stayntouch’s existing payment security resources.
• SOC 2: An independent audit of a vendor’s security controls for availability, confidentiality, and processing integrity, conducted by a certified public accountant. A Type II report covers operating effectiveness over a defined period, while a Type I is a point-in-time snapshot.
• ISO 27001 / 27018: International standards for information security management (27001) and for protecting personal data in cloud environments (27018). Certification requires an accredited third-party audit and annual surveillance.
• General Data Protection Regulation (GDPR): European law governing how personal data about EU residents is collected, stored, processed, and deleted, regardless of where the hotel or vendor is located.

None of these frameworks certifies a vendor’s entire product. Each covers a defined scope, and reading that scope is the buyer’s responsibility.

Request the Compliance Documentation Pack

Documents to Request From a Hotel Software Vendor

Hotel PMS security compliance is demonstrated by documents, not by a logo on a vendor’s website. The following checklist names the artifact to request, what it proves, and what it does not.

1. PCI DSS — Attestation of Compliance (AOC): Request the AOC and read its scope section carefully. The AOC records which systems, transaction flows, and locations were actually assessed, and an AOC stating “e-commerce only” is invalid for card-present transactions at the front desk. The AOC is the external-facing artifact. The underlying Report on Compliance (ROC), produced by a Qualified Security Assessor (QSA), is the detailed evidentiary record. PCI DSS does not issue certificates, so a vendor claiming to be “PCI DSS certified” should mean they hold a current, signed AOC. Check the assessment date, because an AOC is commonly treated as valid for one year from the date of assessment completion, with annual renewal expected. For PCI DSS compliant hotel software, also confirm the vendor’s level. Level 1 is the most stringent tier, applied to the highest transaction volumes.
2. SOC 2 — Type II Report: Request the Type II report and check its observation period. A SOC 2 Type II report assesses both the design and operating effectiveness of controls over a period of time, typically 6–12 months, to determine whether controls functioned as intended throughout that window. A SOC 2 Type I report, by contrast, is a point-in-time snapshot of control design. Enterprise security teams and procurement departments almost universally require a SOC 2 Type II report; Type I reports are viewed as a declaration of intent rather than proof of consistent security operations. When evaluating a SOC 2 Type II hotel software vendor, also read the exceptions section. If a control failed on more than a de minimis number of occasions, the auditor notes it, and multiple exceptions in a critical area can result in a qualified opinion that significantly reduces the report’s value.
3. ISO 27001 / 27018 — Certificate and Scope Statement: Request the certificate and its scope statement. ISO 27001 covers information security management, and ISO 27018 extends that to personal data in cloud environments. Confirm the scope matches the systems and services you are purchasing. A certificate scoped to a vendor’s internal HR systems does not cover its PMS platform.
4. GDPR — Data Processing Agreement (DPA) and Subprocessor List: Request the DPA and the current subprocessor list. GDPR Article 28(3) requires a DPA to fix the processing parameters, including the subject matter and duration of processing, its nature and purpose, the type of personal data involved, and the categories of data subjects. The DPA must also address how subprocessors are managed. EDPB Opinion 22/2024, adopted 7 October 2024, requires controllers to identify every actor in the processing chain, including sub-subprocessors. For each actor, the controller needs identity and contact details, a description of processing, locations, transfer safeguards, and security guarantees, all kept up to date. A first-tier-only list, or one updated quarterly, no longer meets the bar.
5. Also Request These Contract Terms:
   • Breach notification terms, including how quickly the vendor will notify you of a confirmed or suspected incident. Vendors often default to a 72-hour breach notification window; a 24-hour contractual window gives you time to assess before your own regulatory clock starts.
   • Data residency options, including where guest data is stored and whether you can specify a region.
   • Retention and deletion policy, including how long data is held and what the deletion process looks like.
   • Exit and termination terms. Under GDPR Article 28(3)(g), when the PMS service ends the processor must delete or return personal data at the controller’s choice; a provider that only offers to destroy data without allowing prior export does not comply.

Shared Responsibility Model for Hotel Cloud Software

Cloud hotel software does not make a hotel fully compliant by itself. Security responsibilities are split between the vendor and the hotel operator, and the table below maps who owns each control area so you can see exactly where your obligations begin.

Moving a hotel PMS to the cloud changes where cybersecurity responsibilities sit but does not remove them: hotels still need to manage user accounts, access rights, devices and integrations, and must understand which security responsibilities belong to the technology provider and which remain with the hotel. The hotel owns its own access policy and staff behavior. A vendor’s SOC 2 Type II report does not cover a front desk agent who shares a login.

NIST SP 1800-27 and Hotel Property Management Systems

NIST SP 1800-27 (Securing Property Management Systems), published by the National Cybersecurity Center of Excellence, is the only federal guidance document written specifically for hotel PMS environments. It identifies the PMS as an operational hub connected to payment systems, physical access controls, point-of-sale, and ancillary hotel technology, and frames security as extending across that entire connected stack, not just the reservation database. NIST SP 1800-27 recommends hotel PMS security controls including role-based access, stronger authentication, monitoring, and protection of sensitive information. It provides a verifiable, hotel-specific framework that belongs in every PMS security evaluation, and every vendor should be able to explain how their controls map to it.

Discuss How Your PMS Maps to NIST SP 1800-27

Technical Controls to Verify

The right documents set the baseline, and targeted technical questions confirm how the PMS behaves in practice. The answers below are specific and checkable.

• Encryption in transit and at rest: Confirm that data is encrypted using TLS in transit and AES-256 at rest. PCI DSS Requirement 4 mandates strong cryptography for transmitting cardholder data, specifically requiring TLS 1.2 or higher.
• Role-Based Access Control (RBAC): Confirm that you can restrict each staff role to only the data it needs. A housekeeping account, for example, should not be able to view payment records.
• Multi-Factor Authentication (MFA): Confirm that MFA is enforced for all PMS logins, not just administrator accounts. PCI DSS 4.0 requires MFA for all access to the cardholder data environment, not just administrative accounts.
• Single Sign-On (SSO): Confirm that the vendor supports SSO for multi-property groups that manage access across many properties from one identity provider.
• Audit trails: Confirm that the system logs who accessed which guest record, when, and from where. Audit logs matter for chargeback disputes, because a signed record of the transaction and the guest’s agreement to terms often determines whether you win or lose by default. They also matter for internal investigations when a staff account is compromised.

Data Residency, Retention, Deletion, and Exit

The technical controls above protect data while the contract is active. What happens to that data at the end of the relationship is a separate negotiation, and PMS contracts are often weakest here. Write these terms into the contract before you sign.

• Data residency: Specify which region guest data must be stored in. For EU properties, confirm the vendor’s AWS or cloud region and the transfer mechanism for any data leaving the EEA, such as an adequacy decision, Standard Contractual Clauses, or EU-US Data Privacy Framework certification.
• Breach notification: Define the window contractually. GDPR requires the processor to notify the controller without undue delay. Negotiate 24 hours to give yourself time before your own 72-hour regulatory clock starts.
• Retention and deletion: Booking and stay data kept for the duration of the commercial relationship plus five years for disputes or accounting obligations is a reasonable baseline. Confirm the vendor can execute deletion on a defined schedule, not just on request.
• Exit terms: Require a full, structured export of guest profiles, booking history, billing records, and loyalty data in a usable format such as CSV, JSON, or a structured database before termination. A vendor that can only destroy data on exit does not meet the standard of a serious data processor under GDPR Article 28.
• Data ownership: Confirm in writing that guest data belongs to the hotel, not the vendor, and that the vendor cannot use it for its own analytics, benchmarking, or marketing purposes.

Third-Party Integrations as an Attack Surface

The percentage of breaches involving third parties doubled to 30% in the Verizon 2025 Data Breach Investigations Report. Every system connected to your PMS, including point-of-sale (POS), the booking engine, payment processors, door locks, online travel agencies (OTAs), and APIs, expands the attack surface. The key decision is how access is scoped for each integration. A door lock application should be able to see a room number and checkout date and should be blocked from payment details and home addresses. Scoped integration access limits the blast radius if one connected application is compromised. OAuth is the mechanism, because it grants limited, revocable access without sharing master credentials. Ask every vendor how integration access is scoped and whether it can be revoked instantly.

Why Stayntouch Supports Cloud Hotel Software Security Compliance

Stayntouch publishes checkable credentials and supports the verification workflow described in this guide. The facts below are specific and verifiable.

• PCI DSS Level 1 for Stayntouch Pay, the most stringent tier of the card industry’s security standard, covering processing, acquiring, and settlement. Tokenization replaces real card numbers with meaningless substitutes, and point-to-point (P2P) encryption scrambles card data from entry to processor.
• SOC 2 Type 1, with a current Type I report in place. As noted in the document checklist above, a Type II report that covers an observation period provides stronger evidence than a Type I point-in-time assessment, so buyers should weigh this distinction when comparing vendors.
• GDPR compliant, with appropriate processing agreements and subprocessor management.
• ISO 27001 / 27018 certified, covering information security management and personal data protection in cloud environments.
• AWS Private VPC, which provides an isolated, private section of cloud infrastructure dedicated to Stayntouch rather than shared with other tenants.
• Security program that includes quarterly system-wide patching, daily perimeter and application vulnerability scanning, quarterly Approved Scanning Vendor (ASV) scans, and annual penetration testing.
• Product compliance maintained in 60+ countries across 6 regions, including North America, the Caribbean, Central and South America, Europe, Middle East and Africa, and Asia Pacific. Jurisdictional diligence is completed in advance on the customer’s behalf, so hotels can enter new markets with a clear compliance baseline.
• Integration access scoped with OAuth, so each connected application sees only the data it needs. For example, a door lock integration can see a room number and checkout date while remaining blocked from payment details or address data.
• Support that operates 24/7/365 with no service tiers, a guaranteed response under one hour, and hospitality specialists rather than a chatbot.
• 100% system uptime as a sustained performance record, rather than a contractual guarantee.

Stayntouch connects to 1,400+ integrations at no extra cost from Stayntouch, although users must pay each third-party platform its own platform fee. Integration access is scoped, so expanding the tech stack does not expand the attack surface unnecessarily.

Review Stayntouch Security and Compliance With an Expert

Frequently Asked Questions

What Is the Difference Between SOC 2 Type I and Type II?

A SOC 2 Type I report is a point-in-time snapshot of control design. A SOC 2 Type II report tests whether controls actually operated effectively over a defined observation period, typically 6 to 12 months. As noted in the document checklist above, Type II is the stronger artifact because it demonstrates consistent operation over time, and enterprise procurement teams generally require it.

What Does a PCI DSS Attestation of Compliance Actually Cover?

The AOC records the scope of the PCI DSS assessment, including which systems, transaction flows, and locations were actually reviewed. It does not cover systems or services outside that scope. A vendor whose AOC covers only e-commerce transactions is not validated for card-present transactions at the front desk. An AOC is commonly treated as valid for one year from the date of assessment completion, with annual renewal expected. It is produced alongside either a Self-Assessment Questionnaire (SAQ), completed by the organization itself, or a Report on Compliance (ROC), completed by a Qualified Security Assessor. The AOC is the signed summary of whichever document was produced.

What Should a GDPR Data Processing Agreement Include?

A compliant DPA must cover the subject matter, duration, nature, and purpose of processing, along with the types of personal data and categories of data subjects. It must also spell out the processor’s eight obligations under GDPR Article 28(3), including processing only on documented instructions, implementing Article 32 security measures, and assisting with data subject rights requests. Subprocessor management, breach notification timelines, data return or deletion at contract end, and international data transfer mechanisms for data leaving the EEA all belong in the agreement as well. A DPA that is vague on any of these points, particularly subprocessors, breach notification, and exit terms, is not a compliant document.

Who Is Responsible for Security Under the Shared Responsibility Model?

Under the shared responsibility model, the cloud PMS vendor is responsible for the physical infrastructure (datacenters, physical network, physical hosts, hypervisor), platform-level compliance certifications, and platform services including operating systems, runtime environments, and middleware, as well as patching and fixing flaws within that infrastructure. The hotel operator is responsible for user permissions, MFA enrollment, staff security training, internal access policies, and vetting any third-party integrations the hotel adds to the stack. A vendor’s SOC 2 or PCI DSS certification does not cover a hotel’s own staff behavior, shared logins, or unreviewed integrations. Both sides own distinct parts of the security posture, and a gap on either side creates exposure.

What Is NIST SP 1800-27 and Why Does It Matter for Hotels?

NIST SP 1800-27, published by the National Cybersecurity Center of Excellence, is the only federal guidance document written specifically for hotel PMS environments. It identifies the PMS as an operational hub connected to payment systems, physical access controls, and ancillary hotel technology, and recommends controls including role-based access, stronger authentication, network segmentation, monitoring, and protection of sensitive information across the entire connected stack. It does not certify any product or vendor, but it provides a hotel-specific, verifiable framework that buyers can use to structure security questions during a PMS evaluation, and vendors should be able to speak to it directly.

What Happens to Guest Data When a Hotel Leaves a PMS Vendor?

This outcome depends entirely on what the contract says, which is why exit terms must be negotiated before signing. A compliant vendor under GDPR Article 28 must delete or return all personal data at the controller’s choice when the service ends. Request a full, structured export of guest profiles, booking history, billing records, and loyalty data in a usable format before termination. Confirm that the vendor will delete all copies after export, except where retention is required by law, and that they will provide written confirmation of deletion within a defined timeframe. A vendor that can only destroy data on exit, with no export option, does not meet the standard.

Conclusion: Compliance Is a Verifiable Workflow

Compliance is a set of documents you can demand, read, and use to hold a vendor accountable. The frameworks, including PCI DSS, SOC 2, ISO 27001, and GDPR, define the standards. The AOC, the Type II report, the certificate, the DPA, and the subprocessor list provide the evidence. Send the checklist in this guide to three vendors this week, then compare the documents side by side. Because each framework covers a defined scope, the comparison only works if you check the scope sections, observation periods, breach notification terms, and exit clauses against your own requirements. Align internally on those requirements before you sign so your team knows what is non-negotiable. Stayntouch publishes checkable credentials, scopes integration access with OAuth, and maintains product compliance across 60+ countries to support this verification workflow, so your next step is a focused conversation with their team.

See How a Best-in-Class PMS Makes Every Stay More Profitable and Book a Demo