Security architecture
Independent hotels hand us operational data — reservations, guest contact details, room statuses, invoices. This page describes, without marketing gloss, how that data is hosted, encrypted, accessed, backed up and audited.
Where the data lives
Production workloads run in ISO 27001-certified data centres in London or Frankfurt, selected at activation to match your own guest-data commitments; nothing is mirrored across regions unless you ask for it. Guest-facing modules process strictly as a processor under written terms with the UK GDPR and the Data Protection Act 2018, with retention periods fixed per module — reservation-linked records follow statutory hospitality accounting horizons, housekeeping photos expire on schedule, message logs clear after their carrier billing cycle.
In transit, every endpoint enforces TLS 1.2 or newer with modern cipher suites only; TLS 1.0 and 1.1 were retired from our gateways long before it became fashionable to say so. At rest, all volumes, database stores and object storage are encrypted with AES-256, keys managed by our cloud provider's KMS with rotation policies applied. Backups inherit the same encryption without exception.
Access control
Short-lived scoped tokens
Module connections use narrowly scoped API credentials with enforced lifetimes; long-lived static secrets are not issued to our own services for routine work.
Two-factor internally
Every member of the small Manchester team authenticates to production surfaces through mandatory two-factor challenge — hardware keys preferred, authenticator apps accepted.
Least privilege by default
Engineers hold only the environment role their current duty requires, reviewed quarterly against an access register signed off by both directors.
Customer-side access follows the same philosophy: staff accounts bind to role templates per property, sessions expire rather than persisting forever on shared front-desk machines, and the twelve-month administrative log records who changed what, when, and from where — exportable for your own internal reviews.
Backups and recovery
Databases replicate continuously with a defined recovery point objective of fifteen minutes; full snapshots span daily and weekly generations stored separately from primary infrastructure. Our stated recovery time objective is two hours for total-loss scenarios, and we prove it: failover drills run quarterly against a restored copy, with timings recorded in the change log rather than asserted from memory.
Restore testing covers more than databases — configuration, encryption contexts and webhook signing secrets are part of the drill, because an integration that cannot re-authenticate after a restore is functionally down even when the data survived.
Change discipline
Dependency sweeps run quarterly: the module supply chain is scanned for known vulnerabilities, results triaged within five working days, and patched releases pushed to customers automatically inside regular update windows with rollback available. Emergency security patches carry their own accelerated lane, announced afterwards like any other release.
All code changes reach production through peer-reviewed pull requests built in isolated pipelines. Nobody — including directors — deploys from a laptop.
Monitoring and the things we refuse to do
Production surfaces log errors, latency and authentication anomalies continuously, with alerting routed to the on-call engineer during UK business hours and a slower pager outside them. Uptime, sync-latency and queue-health dashboards are shared with customers rather than kept internal, because an integration you cannot observe is one you cannot trust.
Equally useful is what we will never do. We do not sell or share guest data with advertisers; there is no cross-site tracking anywhere in our products. We do not read reservation content beyond the fields a module's documented function requires, and support access into customer spaces is itself logged, time-boxed and visible in your dashboard after each session. We do not bury renewal or deletion choices in dark patterns: export your data as structured files at any point, or instruct deletion and receive written confirmation within thirty days.
Reporting a vulnerability
Suspected weaknesses go to security@pmssolution.com, acknowledged within one business day and triaged under coordinated disclosure: we agree a timeline with you, keep you informed at each milestone, and credit reporters who wish to be named once a fix ships. Please describe reproduction steps and affected endpoints; that alone typically halves diagnosis time. We do not pursue good-faith researchers whose exploration stays within normal account boundaries.
Sub-processors are listed openly so your own privacy documentation stays accurate. Current categories: UK/EU cloud hosting and storage, transactional messaging carriers for SMS delivery, and payment-links processing handled by our card provider under PCI DSS scope they own end to end. Any addition lands on the privacy page with thirty days' notice and a right to object before it takes effect for your property.
Oversight you can verify
PMS Solution Ltd is registered with the Information Commissioner’s Office (ICO), registration ZA741350, and operates as controller for its own business records while processing hotel and guest data strictly under processor obligations. You can check registration ZA741350 in the ICO's public register at any time.
A written data processing agreement, sub-processor list, retention schedule and this architecture summary are available on request — the documents we hand customers are the same ones our own team works from, updated together rather than drifting apart. Questions beyond this page reach an engineer directly: support@pmssolution.com.
Security questions before checkout?
Send your questionnaire or join a short call — direct answers from the people operating the systems.