Personal Data Breach and Cyber Incident Response Policy
Internal procedure for detecting, containing, reporting and learning from security incidents
Effective: October 2026
Version 1.0
In plain words
If personal data is lost, leaked, stolen or exposed, the clock starts the moment anyone notices. CERT-In must hear from us within 6 hours, the Data Protection Board and affected customers without delay, and the Board must get a detailed report within 72 hours. This policy tells every person exactly what to do in the first hour, who decides what, and how we notify.
Purpose and scope
This policy sets out how T4Travelonline Private Limited responds to personal data breaches and cyber security incidents affecting www.t4travelonline.com, the T4Travel mobile app (Android and iOS), the corporate portal, our APIs, internal tools, and data held for us by processors. It meets section 8(5) and 8(6) of the DPDP Act, Rules 6 and 7 of the DPDP Rules 2025, and the CERT-In Directions of 28 April 2022 issued under section 70B of the IT Act.
What counts as an incident
- Personal data breach: any unauthorised processing, accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data that compromises its confidentiality, integrity or availability (DPDP Act, section 2(u)).
- Cyber security incident: any event listed in the CERT-In Directions, including compromise of systems, unauthorised access, data leaks, ransomware, website defacement, malicious code, attacks on servers or APIs, and identity theft or phishing affecting our customers.
- Near miss: a weakness found before it was exploited. These are logged and fixed the same way, but are not notifiable.
Examples: a booking export emailed to the wrong person; an API that returns another customer's booking; a leaked admin password; a lost laptop with customer data; a supplier telling us their system was breached; a phishing site copying our brand.
Notification deadlines
| Who | Deadline | How | Legal basis |
|---|---|---|---|
| CERT-In | Within 6 hours of noticing a reportable incident | incident@cert-in.org.in, in the CERT-In format | CERT-In Directions 2022 |
| Data Protection Board of India (initial) | Without delay | The Board's online platform | DPDP Act s.8(6); DPDP Rules, Rule 7 |
| Data Protection Board (detailed report) | Within 72 hours of becoming aware, unless the Board allows longer in writing | Facts, cause, measures taken, findings, notifications made | DPDP Rules, Rule 7 |
| Affected customers | Without delay | Email and SMS, plus in-app notice where useful | DPDP Rules, Rule 7 |
| Payment aggregator (Easebuzz), if payment data is involved | As per contract, usually within 24 hours | Their security contact | Contract; RBI PA directions |
| Corporate clients whose employees are affected | Without delay, and within any contractual deadline | Account manager and client security contact | Contract |
| Insurer (Asego), if insurance data is involved | Without delay | Their nominated contact | Contract; IRDAI expectations |
| Police / Cyber Crime cell | Where a crime is suspected | cybercrime.gov.in or local cyber cell | IT Act; Bharatiya Nagarik Suraksha Sanhita |
Roles
| Role | Who | Responsibility |
|---|---|---|
| Incident Lead | Grievance & Data Protection Officer | Declares the incident, owns the timeline, approves every external notice. |
| Technical Lead | Engineering Lead (Wooshelf delivery team for the app and portal) | Contains the threat, preserves evidence, restores service. |
| Communications | Customer Experience lead | Writes and sends customer notices, prepares support scripts. |
| Legal adviser | External legal counsel | Advises on notifications, law enforcement and liability. |
| Management | Director | Approves spending, external experts and public statements. |
| Everyone | All staff and contractors | Report anything suspicious immediately, and do not investigate or delete anything on their own. |
How to report: email security@t4travelonline.com or privacy@t4travelonline.com, and phone the Incident Lead. Reporting a mistake in good faith is never punished; hiding one is a disciplinary matter.
Severity levels
| Level | Description | Example | Response |
|---|---|---|---|
| P1 Critical | Confirmed exposure of sensitive data (passport, PAN, payment, ID documents) or of many customers; active attacker | Database dump found online; admin account taken over | War room at once; CERT-In within 6 hours; Board and users without delay |
| P2 High | Confirmed exposure of personal data of a limited number of people | Booking confirmations sent to the wrong customers | Incident Lead within 1 hour; notify as the law requires |
| P3 Medium | Suspected incident, or exposure of non-sensitive data with low risk | Unusual login attempts; misconfigured but unaccessed storage | Investigate within 4 hours; decide on notification |
| P4 Low | Near miss or policy breach with no data exposed | Password shared in a chat, then changed | Log and fix within 5 working days |
Response procedure
First hour
- 1Whoever notices it reports it straight away. Do not switch off, wipe or “clean up” affected systems.
- 2The Incident Lead opens an incident record with the time of discovery. All deadlines run from this time.
- 3The Technical Lead contains the issue: revoke leaked keys and tokens, disable compromised accounts, block malicious IPs and close the exposed endpoint.
- 4Preserve evidence: snapshot logs, take disk images where needed and record every action with a timestamp.
Within 6 hours
- 1Assess severity and decide whether the incident is reportable to CERT-In. If in doubt, report.
- 2Send the CERT-In report with what is known.
- 3Send the initial notice to the Data Protection Board if personal data is affected.
Within 72 hours
- 1Identify which people and which data are affected, and the likely consequences for them.
- 2Notify affected customers in clear language (see the template below).
- 3Submit the detailed report to the Data Protection Board.
- 4Notify partners and corporate clients as their contracts require.
Recovery and lessons learned
- 1Remove the root cause, restore from clean backups where needed, and watch closely for repeat activity.
- 2Within 14 days, hold a blameless review: what happened, why, what worked, and what changes we will make, with owners and dates.
- 3Update this policy, training and controls based on what was learned.
Customer notification template
Prevention and readiness
- System clocks synchronised to the NTP servers of NIC or NPL, so that log times hold up as evidence (CERT-In requirement).
- ICT system logs kept for 180 days within India, and processing logs for at least one year (DPDP Rules, Rule 8).
- Encryption in transit (TLS 1.2 or higher) and at rest for databases and backups; secrets kept in a vault, never in code.
- Role-based access, multi-factor authentication for all admin and cloud consoles, and access reviews every quarter.
- Contracts with every processor require them to tell us of a breach within 24 hours.
- A tabletop exercise of this procedure at least once a year, and security awareness training for all staff.
Document ref: T4T-POL-IRP-04 · Version 1.0 · Effective October 2026. Questions about this policy: privacy@t4travelonline.com