Security and Responsible Disclosure

Summary

This summary is here to help you. It does not replace the full text below.

• Data is encrypted in transit and at rest. Passwords are hashed and never stored in readable form.
• Each hotel's data is kept separate from every other hotel's by the database itself, not only by application code.
• Card details are entered on our payment providers' own pages. Stayantra never sees or stores full card numbers.
• We do not currently hold security certifications such as ISO 27001 or SOC 2, and we do not claim to.
• Hotels are responsible for who they let into their account: use strong passwords, do not share logins, and remove staff who leave.
• If a breach affects your data, we will tell you and the relevant regulators as the law requires.
• Found a vulnerability? Email info@stayantra.com. We acknowledge within 3 business days and will not take legal action against good-faith research that follows the rules in section 6.

1. Our approach

Security is part of how Stayantra is built, not a separate layer on top. This page describes the main measures we take, what we expect from hotels using Stayantra, how we respond to incidents, and how security researchers can report problems to us.

We describe our measures honestly and in general terms. We do not publish details that would help an attacker.

2. How we protect data

Encryption

• All connections to Stayantra websites, apps and interfaces use TLS encryption in transit.
• Data is encrypted at rest by our hosting and database providers.
• Credentials that hotels give us to connect other services, such as social media or channel manager access, are additionally encrypted with AES-256-GCM before they are stored.

Passwords, sessions and keys

• Passwords are hashed with bcrypt. We cannot see your password.
• Session refresh tokens and API keys are stored only as hashes, rotate on use, and are checked for reuse.
• Sign-in endpoints are rate-limited to slow down password-guessing attacks.

Separating hotels from each other

• Every hotel's data sits in the same database but is isolated by database-level row security. Each request can only read and write the data of the hotel it belongs to, even if application code contains a mistake.
• Public interfaces, such as the hotel booking widget and the interfaces used by outside AI assistants, are limited to what a guest could do, such as searching and booking. They cannot reach hotel staff tools. A hotel's own AI assistant connection always needs a person at the hotel to approve any change.

Access and accountability

• Our staff get access on a least-privilege basis: only what their role needs.
• Stayantra administrators must use two-factor authentication.
• Every action taken by AI, and key actions taken by people, are written to an audit record that cannot be edited or deleted.
• Error monitoring removes personal data before error reports leave our systems.

Payments

Card payments are entered directly on the payment provider's own page or secure form (Stripe for cards; eSewa, Khalti and Fonepay for wallets and bank payments). Stayantra never sees, receives or stores full card numbers. Card security under the Payment Card Industry Data Security Standard (PCI DSS) is handled by those providers, which are responsible for it.

Certifications

Stayantra does not currently hold ISO 27001, SOC 2, PCI DSS or other security certifications. Our main hosting and infrastructure providers hold their own certifications for the services they run. Our list of sub-processors names them.

3. What hotels are responsible for

Each hotel controls who can use its Stayantra account. Security is shared: we secure the platform, and the hotel secures its own access. Hotels must:

• use strong, unique passwords and keep them secret;
• give every person their own account, and never share a login between staff members;
• give each person the lowest role they need to do their job;
• remove or deactivate staff promptly when they leave or no longer need access;
• keep devices secure, with screen locks and up-to-date software, especially shared front-desk devices and phones running the Stayantra Connect app;
• protect connected accounts, such as the hotel's Facebook, Instagram, WhatsApp Business and payment accounts, with their own strong passwords and two-factor authentication;
• tell us straight away at info@stayantra.com if they suspect their account has been accessed without permission.

The hotel is responsible for actions taken through its account by people it has given access to. More detail is in the Hotel Subscription and Partner Agreement, the Data Processing Addendum and the Acceptable Use Policy.

4. Incident response and breach notification

We have a process for detecting, containing, investigating and recovering from security incidents. When we become aware of an incident that affects personal data:

• Hotels. Where we act as a hotel's processor, we notify the affected hotel without undue delay and in any case within 48 hours of becoming aware, with the information the hotel needs to meet its own legal duties. This commitment is in our Data Processing Addendum.
• Regulators. Where we are the controller and the law requires it, we notify the relevant data protection authority — within 72 hours of becoming aware under UK and EU law — and other authorities as the laws of Nepal, India and other countries require.
• You. If a breach is likely to result in a high risk to your rights and freedoms, we tell you directly, in plain language, without undue delay. We explain what happened, what data was involved, what we have done, and what you can do to protect yourself.

After every significant incident we review what happened and improve our controls.

5. How to protect your own account

• Use a strong password that you do not use anywhere else, or sign in with Google or Apple.
• Never share your password or sign-in links. Stayantra staff will never ask for your password.
• Be careful with messages that claim to come from Stayantra or a hotel and ask for payment or passwords. If in doubt, open the app or website directly rather than using a link.
• Tell us at info@stayantra.com if you think someone has accessed your account.

6. Responsible disclosure policy

We welcome reports from security researchers and anyone who finds a weakness in Stayantra. This policy tells you how to report it and what we promise in return.

In scope

• stayantra.com and all its subdomains, including the marketplace, the hotel dashboard, the documentation site and hotel websites hosted by Stayantra;
• the Stayantra Go, Stayantra Connect and other Stayantra mobile apps;
• our APIs, including the public booking, AI assistant (MCP, A2A and UCP) and webhook interfaces.

Out of scope

• denial-of-service attacks, load testing, or anything that degrades the service for others;
• social engineering, phishing or pretexting of our staff, hotels or guests;
• physical attacks on offices, hotels or equipment;
• spam, or sending automated messages through our forms or chat;
• vulnerabilities in third-party services we use, such as payment providers, hosting providers, AI model providers or social networks — please report those to the provider;
• reports from automated scanners with no demonstrated impact, missing best-practice headers with no exploit, and self-XSS.

Rules for testing

• Use only accounts and hotels you created yourself, or test data. Do not access, change, download or delete data that belongs to anyone else. If you reach someone else's data by accident, stop, do not keep it, and tell us.
• Do not use AI features to generate real bookings, payments, messages or social posts that affect real hotels or guests.
• Make only as many requests as you need to show the problem.
• Do not ask for payment or other benefit in return for not disclosing a problem.

How to report

Email info@stayantra.com with:

• a description of the problem and the impact you believe it has;
• the URL, app screen or API endpoint involved;
• step-by-step instructions or a proof of concept that lets us reproduce it;
• whether any data that is not yours was accessed;
• how you would like to be credited, if at all.

If you have found a way for one hotel or user to see another's data, say so in the subject line. We treat that as the most serious kind of problem.

What we promise

• We acknowledge your report within 3 business days.
• We keep you informed while we investigate and fix the problem.
• We tell you when it is fixed.

Safe harbour

If you act in good faith and follow this policy, we will treat your research as authorised. We will not take legal action against you or report you to law enforcement for it, and if someone else does, we will make it clear that your research was authorised by us. This does not cover actions that break the rules above or that harm our users.

Disclosure

Please do not share details of a vulnerability publicly or with anyone else until we have fixed it, or until 90 days after your report, whichever comes first. If we need more time for a complex fix, we will explain why and agree a date with you.

Recognition

We do not currently run a paid bug bounty. With your permission, we will thank you publicly by name or handle once the issue is fixed.

7. Changes to this page

We update this page when our security measures or this policy change. The date at the top shows the current version.