Security Practices & Incident Response

Our approach

Security is not a page we wrote once and set aside. It is a standing part of how this website and the systems behind it are built and run, checked against every time something changes, in the same way a fare is checked against the published rate card before it goes out. This page sets out what that actually means in practice: what is protected, how, by whom, and what happens if something ever goes wrong.

Running an enquiry-led transport business, rather than an online store or a bank, means we hold a narrower set of information than a website like this one is sometimes assumed to collect, and it is worth being exact about what that actually is. A name, a mobile number, a pick-up point and a drop point, a date and a time, and, where you book through a company account, the commercial terms behind that account: a rate, a purchase order or cost-centre reference, an invoice history. That is the whole of it. This site does not run an online store and does not hold a payment card on file, because there is no payment gateway anywhere in the booking flow, a fact Section 4 below sets out in full because it is one of the more reassuring things this page can say.

None of that is a reason to treat the subject lightly. A travel plan tells a stranger where somebody will be and when, and a company account's commercial terms are exactly the kind of detail a competitor would want and a fraudster could misuse. Encryption in transit, controlled access, plain limits on what is collected in the first place, and a stated commitment on what happens if something goes wrong, sit below, and each one is a standard any operation handling personal information should meet, whatever its size.

This page is written for whoever wants to understand how we treat information generally: a customer deciding whether to book, a corporate account holder's own compliance team reviewing us as a vendor, or a researcher working out where to send a finding. It sits alongside two other pages rather than repeating them. Our Privacy Policy at /privacy-policy sets out what personal data we collect and why, and the rights you have over it. Our Responsible Disclosure policy at /legal/responsible-disclosure sets out exactly how to report a vulnerability found on this website, and what protection a good-faith researcher has for doing so; Section 10 below points to it rather than restating it.

Encryption

Every page on this website, and every form on it, including the enquiry form used to ask for a fare, is served over an encrypted connection, using TLS, the technology behind the padlock icon a browser shows next to almost every legitimate website address today. This is not something to take on trust. Look at the address bar on any page of this site: if it reads https and shows a padlock rather than a warning, the connection is encrypted, and that can be checked at any time, on any page, without asking us.

In plain terms, here is what that protects. Picture sending a name, a mobile number and a pick-up address from a phone connected to the open wifi in an airport lounge, or on a shared guest network at a wedding venue. Without encryption, anybody else on that same network could, in principle, read what was typed as it left the phone. With TLS in place, what leaves the phone is scrambled in a way that only our server can unscramble, so somebody sitting on the same network sees nothing usable, even while actively trying to look. The same protection works the other way too: a quotation or a confirmation sent back cannot be quietly altered in transit by somebody sitting between the two ends of the conversation.

It is worth being precise about what encryption in transit does not do, because a padlock icon is sometimes read as a wider promise than it actually makes. TLS protects data while it is moving between a device and our server. It says nothing about what happens to that data once it has arrived, which is a separate question governed by who can access it once it is here, and that is what the next section addresses. Treat the padlock as the answer to one specific question, whether this connection is being listened to as it happens, rather than as a guarantee covering everything that happens to the data afterwards.

Access control

Access to any system that holds customer information is limited to the people who actually need it to do their job, and it stops there. A pick-up address given for one trip is not visible to everyone in the business; it is visible to whoever is arranging that trip and to nobody arranging a different one, and that boundary is the starting point for how access is thought about generally, not an exception made for sensitive cases.

Everyone who does have access is identifiable individually. Nobody signs in to a shared account or a shared password to look at a booking or a customer record; each person who can see something is signed in as themselves, and what they looked at, and what they changed, is attributable to that one person rather than to a role several people share. This matters for two practical reasons rather than as procedure for its own sake. It gives accountability: if a record is changed or looked at, we can say who did it, which is what makes a complaint or a dispute actually resolvable rather than a matter of everyone denying it was them. And it gives containment: if one person's access is ever compromised, a lost device, a guessed password, that one person's access can be shut off without resetting a password five other people also rely on, and without wondering what else might be affected.

Our own engineering standards for this website state plainly, as a rule every change is checked against, that personal information must never appear in a log file, an error report, or a message passed to an outside service, and that any query against stored data must be scoped to what the person or system asking is actually entitled to see, denying access by default rather than granting it and trusting that nobody asks for more than they should. The code itself is checked against these rules as it is written, and a change that would break them is not the kind of change that ships.

Today, the number of people who can even reach a customer's contact details or trip history is small, because the business itself runs on a small, direct team rather than a large distributed one. As the administrative system behind this site is built, access to it will be structured on the same principle set out above: role-based, limited to what each role genuinely needs, with multi-factor sign-in required of anyone who can reach it, a shared login for nobody, and access removed the same day somebody stops working with us rather than left open out of oversight. That commitment is stated now, ahead of the system existing, because it is the standard being built to, and it is better to be held to it in writing than to have it assumed.

What we do not store

There is a shorter route to protecting a category of information than defending it well: never holding it in the first place. Data that is never collected cannot be stolen, cannot be misused, and cannot be handed over by mistake. On three fronts, and they are the three most often asked about, that is exactly the position this business is in, and it is worth stating plainly rather than leaving it to be assumed.

We do not store your payment card number in full, and we never store the card verification value, the three or four digit CVV printed on the card. We do not store the full 12-digit Aadhaar number of a customer, a driver or anyone else we work with. We do not hold a password of yours in plain, readable form, because this website does not ask you to create one.

This website does not process an online payment today. There is no payment gateway anywhere in the enquiry or booking flow: a fare is quoted, a booking is confirmed, and payment is settled directly with our office, by whichever method is agreed, rather than typed into a card form on this site. No card number, no expiry date and no CVV ever reaches a system we control, in any form, because the website never asks for one. This is, plainly, the most reassuring fact on this page rather than the most technical one: the strongest protection for a card is that it is never in a position to be at risk here. When online payment is introduced, it will be handled by a payment aggregator authorised by the Reserve Bank of India, and card details will be entered directly into that provider's own secure form and tokenised there, at the point of entry; they will not pass through, and will not be stored on, our own systems at any stage.

A masked Aadhaar number can be part of how the identity of a driver or a vehicle partner is verified before he is put on duty; what is accepted for that purpose, and why, is set out in full in our Partner Privacy Notice at /legal/partner-privacy-notice. What matters here is the boundary rather than the mechanism: a customer, a driver or anyone else is never asked for a full, unmasked Aadhaar number, and one is never held. What is accepted instead, a masked Aadhaar showing only the last four digits, an Aadhaar Offline XML, or a document issued through DigiLocker, confirms who somebody is without our ever holding the one number that, in the wrong hands, could be used to open other doors in that person's name.

This website has no customer accounts and no login, and booking a trip, sending an enquiry or asking a question has never required creating a password. There is, quite simply, no password for us to protect or to get wrong. A system with no password store cannot have that store stolen, cannot be tricked by a fake password-reset request, and cannot be broken into by somebody trying a password leaked from an unrelated website against a name here. Where a password is ever genuinely needed, for a corporate client's own portal, for instance, it is stored the only way a password should be: run through a one-way function so that even we cannot read it back, only confirm whether what was typed matches, never in a form a stolen database could hand over as a readable list.

Vulnerability management

The software this website runs on, like any software, receives fixes for newly discovered weaknesses on an ongoing basis, and keeping current with those fixes is treated as routine maintenance rather than an occasional project. The components this site depends on are kept up to date, and a fix addressing a genuine security weakness is applied promptly rather than queued behind other work.

The site is also kept from volunteering more about itself than it needs to. The technical detail of exactly what a website is built on is precisely the kind of information a would-be attacker finds useful for working out where to look, so this page describes our practices without describing our technology stack, for much the same reason a bank explains how it protects an account without publishing the layout of its own server room.

We do not currently run a named, contracted vulnerability-scanning service. What we do have, and what anybody can use, is the channel described in Section 10 below: if a genuine weakness on this site is found, by a person or by a tool, we want to hear about it, and Section 10 sets out exactly how to tell us and what happens once a report reaches us.

Backup and continuity

This page does not publish a specific recovery time or a specific data-loss window, because neither is a figure that has been measured and can honestly be stood behind yet, and a number nobody has actually tested does not belong here. What can be set out is the standard itself, and where it currently applies.

As things stand, this site does not hold a live, growing database of customer records; an enquiry submitted through it reaches our office directly rather than accumulating in a system that would need its own backup regime the way a running ledger does. That is a genuine, current limitation on what a backup commitment can mean today, and it is stated here rather than describing a safeguard for a system that does not yet exist.

As a system of record for bookings and customer history is built, it will be backed up on a regular schedule, to a location kept separate from where the working copy is normally held, so a single failure cannot take out both at once. A backup is only worth something if restoring from it has actually been tried, so the further commitment is that restoring will be tested as a matter of course, so that using it is a practiced action rather than something attempted for the first time in the middle of an actual failure, exactly when it matters most and there is least room for a surprise.

Continuity is not only a data question. The office itself is reachable at any hour, and our Emergency Protocol at /legal/emergency-protocol and our Force Majeure Policy at /legal/force-majeure set out how a disruption to an actual trip is handled. This page covers the systems and the information behind the business; those two cover the vehicle in front of you, and the two are kept separate because they fail, and recover, in different ways.

Vendor and processor diligence

Running this website depends on a small number of outside services: whoever hosts the site itself, whoever delivers an email sent from it, and WhatsApp Business, which is how a good many enquiries arrive and how we reply. Each is chosen with security and data handling in mind rather than on price or convenience alone, and each is given only the data it actually needs for its specific job, never a wider copy of what we hold.

Before any outside service is relied on to handle part of a customer's information, we look at what that provider itself commits to on security and data handling, not only at what it does for us functionally. Where a provider cannot say plainly how it protects data or how long it keeps it, that counts against using it, whatever else it offers. A fuller list of the categories of third party used, and what each one sees, is maintained at /legal/subprocessors.

WhatsApp is worth its own word because so many enquiries arrive through it. A message sent to us over WhatsApp travels under WhatsApp's own encryption and is subject to WhatsApp's own privacy terms as a platform, not ours; we see a message sent to us the same way any business using WhatsApp Business sees a message sent to it, and nothing more. Anyone who would rather not use that channel for something sensitive can reach us just as directly by phone or by email, both published on /contact.

The same principle applies to any vendor added in future: the minimum access it genuinely needs, a provider that can account for its own security practices, and a relationship that can be ended if it stops meeting the standard it is held to. A vendor is not treated as trustworthy simply because it is well known; it is treated as trustworthy once we have actually looked at what it does with what it is given.

Personnel

Anyone who can see a customer's phone number, pick-up address or trip history at Om Travels is told plainly, before being given that access, what it may be used for and what it may not: running the trip, and keeping the record that duty requires, and nothing beyond that. Treating a customer's information carefully is a condition of working with us at all, the same way handling a passenger safely is a condition of driving for us.

What is done is direct and practical: anyone with access to customer information knows who to go to if something looks wrong, a message that seems to be phishing for a customer's details, a device that has gone missing, a request for information that does not sit right, and is expected to raise it immediately rather than sit on it. Our Grievance Officer and Security Contact, named in Section 12 below, are that person.

When somebody stops working with us, whatever access they had is removed at that point, not left open on the assumption that it no longer matters because they have gone. This is the same access-control principle set out in Section 3 above, applied at the one moment it is most often forgotten.

Incident response commitment

However carefully a system is built, no honest security page can promise that nothing will ever go wrong. What it can promise is what happens next if it does, and this is that commitment.

If a security incident affecting your data occurs, we tell the people affected without undue delay, what happened, what data was involved, and what we are doing about it. Where the incident is a cyber security incident within the meaning of the Information Technology Act, 2000, we report it to the Indian Computer Emergency Response Team, CERT-In, within 6 hours of noticing it, under the CERT-In Directions No. 20(3)/2022-CERT-In dated 28 April 2022. Where it is a personal data breach, the Data Protection Board of India is the regulator with ultimate oversight of how it was handled.

'Without undue delay' is deliberately not fixed to a set number of days here, and that is worth explaining rather than leaving as legal phrasing. The useful version of that promise is that affected individuals are told as soon as there is actually enough understood to say something true and useful, rather than either staying silent while it is worked out, or sending a vague alert before what happened is understood at all. A notification that arrives fast but says nothing concrete is not meaningfully faster in any way that helps anyone protect themselves.

CERT-In, the Indian Computer Emergency Response Team, is the Government of India's nodal agency for cyber security incidents, and the Directions it issued in April 2022 require certain incidents, broadly, unauthorised access, a data breach, or a serious attack on a website or system, to be reported to it within 6 hours of coming to notice. That is a fast clock by any standard, and it exists because a cyber incident that is not reported quickly is one the wider ecosystem, other businesses, other users, cannot be warned about in time to protect themselves either. That 6-hour clock is treated as a real deadline rather than a target to aim for.

A cyber security incident and a personal data breach are related but are not the same thing, and it is worth being precise about which regulator answers to which. A cyber security incident, in the sense the CERT-In Directions use the term, covers unauthorised access to, or an attack on, a system, whether or not it actually exposes anyone's personal data, and CERT-In is the reporting body for that. A personal data breach, in the sense the Digital Personal Data Protection Act, 2023 uses the term, is specifically about personal data being compromised, and the Data Protection Board of India is the body with ultimate regulatory oversight of how a data fiduciary, which is what we are in relation to the data described on this page, has handled that. The two obligations can both apply to the same incident, and where they do, both are met.

Where a company account is held with us, our Corporate Transport Terms at /corporate/terms set out how account-level matters, including this one, are also handled through the account's own contact, in addition to, not instead of, everything on this page.

Responsible disclosure

A security researcher, or simply somebody who has noticed something on this website that looks like it should not be possible, is asked to tell us. A vulnerability reported in good faith is treated as exactly that: a favour done to us and to every other visitor to this site.

The full process, how to report, what to include, the timeline worked to once a report arrives, and the safe harbour protection a genuine researcher has, is set out on its own page rather than repeated here, at /legal/responsible-disclosure. This page states the standard held to generally; that one states exactly what to do about a specific problem already found.

Certifications

No formal security certification, such as ISO 27001 or SOC 2, is currently held.

Security here is practiced as a standing discipline rather than a one-time exercise: encryption in transit, controlled access, plain limits on what is collected, and a stated incident-response commitment, each checked against continuously rather than audited once and left alone.

Contact

For any question about our security practices, or to report a possible weakness, write to our Security Contact, Sachin Jaglan: sachin@om-travels.in · +91 99966 69190 · Grand Trunk Road, Panipat, Haryana. For a report specifically about a vulnerability, our Responsible Disclosure policy at /legal/responsible-disclosure sets out the fastest and clearest route.

Where the concern is not really about a technical weakness but about how a member of our team has handled information, that is a grievance rather than a security report, and our Grievance Officer and the full escalation ladder are published at /grievance-redressal.