CERT-In 6-Hour Incident Reporting: What Payment Businesses and Merchants Must Do (2026)
When a payment business in India detects a cyber incident, the first regulatory deadline is not days away. It is six hours. CERT-In’s cyber security directions of April 2022 require almost every organisation operating in India to report specified incidents within six hours of noticing them, and payment companies often face a second six-hour clock from RBI on top.
This guide explains who the directions apply to, which incidents count, how the clock interacts with RBI, DPDP and card network rules, and what to set up now so the first hours go on containment, not on finding the right email address.
Quick answer: Under directions issued on 28 April 2022 under section 70B(6) of the IT Act, service providers, intermediaries, data centres, body corporates and government organisations must report listed cyber incidents to CERT-In within six hours of noticing them. Listed incidents include data breaches, data leaks, unauthorised access and attacks affecting digital payment systems. Organisations must also sync clocks to NIC or NPL time sources, keep logs of all ICT systems for a rolling 180 days and name a point of contact. Payment aggregators also report to RBI within six hours, and DPDP breach intimation applies from May 2027.
Who must follow the CERT-In directions?
The directions apply to service providers, intermediaries, data centres, body corporates and government organisations. CERT-In’s FAQs say body corporate follows the IT Act definition, which covers companies and also firms, sole proprietorships and other associations engaged in commercial or professional activity.
For payments, that means:
- Payment aggregators, payment gateways and other payment system operators.
- Banks and NBFCs, alongside their own RBI obligations.
- Online merchants of any size, and vendors that host or process payment data.
The FAQs also say that entities without a physical presence in India that offer services to users in India must designate a point of contact. The duty to report cannot be passed to a vendor by contract. Any entity that notices a reportable incident must report it, even if a service provider is also reporting.
Non-compliance can lead to action under section 70B(7) of the IT Act, which allows imprisonment of up to one year, a fine of up to Rs 1 lakh, or both. CERT-In’s FAQs say it will use this power mainly where non-compliance is deliberate.
What do the directions require?
The directions have six parts. Four apply to every organisation; two apply to specific sectors.
| Direction | Requirement | Practical meaning for payment teams |
|---|---|---|
| Time synchronisation | Connect to NTP servers of NIC or NPL, or sources traceable to them | Point internal NTP to samay1.nic.in, samay2.nic.in or time.nplindia.org, or a source that does not deviate from them |
| Incident reporting | Report Annexure I incidents within 6 hours of noticing or being told | Needs a named owner, a ready form and an out-of-hours process |
| Point of contact | Designate a POC and send details to CERT-In in the Annexure II format | Keep the registration current when people leave |
| Logs | Enable logs of all ICT systems and keep them for a rolling 180 days within Indian jurisdiction | Includes firewall, application, database, VPN and cloud logs |
| Data centre, VPS, cloud and VPN providers | Keep validated subscriber records for 5 years | Applies to your hosting provider, not to most merchants |
| Virtual asset providers | Keep KYC and transaction records for 5 years | Not relevant unless you deal in virtual assets |
CERT-In’s FAQs allow logs to be stored abroad if they can be produced to CERT-In within a reasonable time. Payment data is stricter: RBI’s 2018 storage circular requires payment system data to be stored only in India. Most payment teams should simply keep logs in India.
Which incidents count for a payment business?
Annexure I lists 20 incident types. The ones that matter most for payments are:
- Data breach and data leak.
- Unauthorised access to IT systems or data.
- Attacks or incidents affecting digital payment systems.
- Attacks on applications such as e-commerce.
- Attacks on database, mail and DNS servers and network devices, and malicious code including ransomware.
- Defacement or intrusion into a website, including injected malicious code. A skimming script on a checkout page falls here.
- Identity theft, spoofing and phishing attacks.
- Denial of service and distributed denial of service attacks.
- Compromise of critical systems or information.
- Malicious or fake mobile apps, and attacks affecting cloud systems.
The FAQs say six-hour reporting is aimed at severe incidents such as intrusions, ransomware, denial of service and data breaches. If unsure, report: a minor report carries less risk than a missed deadline.
Can you report before you know the full picture?
Yes. CERT-In’s FAQs say that if all the details in the reporting form are not available within six hours, you should report what you have and send the rest within a reasonable time. The clock starts when the incident is noticed or brought to your notice, not when the investigation concludes.
Reports go to incident@cert-in.org.in, or by phone on 1800-11-4949 or fax on 1800-11-6969. The reporting formats are published on cert-in.org.in. The FAQs also say the statutory duty overrides contractual confidentiality clauses, so an NDA with a client or vendor is not a reason to delay.
How does CERT-In reporting fit with RBI, DPDP and card network rules?
A single payment data incident can start four or more clocks. They run in parallel, and meeting one does not satisfy another.
| Regime | Who it applies to | Trigger | Deadline | Report to |
|---|---|---|---|---|
| CERT-In directions, 2022 | Almost every organisation in India | Annexure I incidents | 6 hours from noticing | CERT-In (email, phone, fax) |
| RBI cyber resilience directions for non-bank PSOs, 2024 | Payment aggregators and other non-bank payment system operators | Unusual incidents: cyber attacks, critical system outages, internal fraud, settlement delays | 6 hours from detection, in RBI’s incident reporting format | RBI, plus CERT-In |
| RBI payment aggregator directions, 2025 | Payment aggregators | Security incidents and card data breaches; monthly incident report with root cause analysis | Stipulated timeframe and monthly | RBI |
| RBI cybersecurity directions for commercial banks, 2026 | Commercial banks | Cyber incidents | 6 hours from detection | RBI DAKSH platform, plus CERT-In |
| DPDP Rules, 2025 (Rule 7) | Data fiduciaries | Any personal data breach | Users and Board without delay; detailed report to Board within 72 hours | Affected users and the Data Protection Board |
| Card network rules and PCI DSS | Merchants and service providers handling card data | Suspected or confirmed account data compromise | Immediately to acquirer; Visa expects initial findings within 3 business days | Acquirer or PA, and the card network |
A few points need care.
The RBI clock is separate. Payment aggregators have been subject to the July 2024 cyber resilience directions since 1 April 2025, as RBI classes them as large non-bank payment system operators. Their six-hour report goes to RBI in its own format, and it covers events CERT-In does not, such as settlement delays and internal fraud. OurRBI payment aggregator guidelines checklistcovers the other recurring reports.
DPDP is not yet in force for breach reporting. The DPDP Rules were notified on 13 November 2025, but Rule 7 on breach intimation applies from about 13 May 2027. From then, a data fiduciary must tell each affected user and the Data Protection Board without delay, and send the Board a detailed report within 72 hours. There is no size or harm threshold. The DPDP Act allows penalties of up to Rs 200 crore for failing to notify a breach. See ourDPDP Act guide for payment data.
Merchants report through their payment provider. PCI DSS requirement 12.10.1 requires an incident response plan that includes notifying payment brands and acquirers. For most Indian merchants, the acquirer relationship runs through their payment aggregator, so the contract with the PA usually sets a notification window. Check it, because it may be shorter than you expect.
Contracts add more clocks: enterprise customers and cyber insurers often require prompt notice. Our guide tobreach notification strategy and deadlinescovers how to sequence these messages.
What should happen in the first six hours?
The first six hours decide whether you meet the CERT-In deadline with a useful report. This playbook assumes you already have an incident response plan; our guide to thefirst 24 hours after a payment data breachcovers containment and forensics in more depth.
Hour 0: detection and clock start
- Record the exact time the incident was noticed, in UTC with time zone, and who noticed it. This is the start of the CERT-In clock and, for PAs, the RBI clock.
- Open an incident ticket and a private channel. Log every decision with a timestamp.
Hours 0 to 2: triage
- Decide whether the event falls within Annexure I. If in doubt, treat it as reportable.
- Identify what is affected: card data, UPI or bank credentials, personal data, payment systems, settlement flows.
- Notify the incident lead, legal or compliance, and the CERT-In point of contact.
Hours 1 to 4: contain and preserve
- Isolate affected systems from the network rather than shutting them down. Visa’s guidance for compromised entities warns against turning off or rebooting compromised systems, because it destroys volatile evidence.
- Do not log in to compromised systems with administrative credentials or wipe and rebuild before evidence is captured.
- Snapshot cloud instances, export logs and preserve web server, application, database and firewall records.
Hours 3 to 6: report
- Submit the CERT-In report with what you know: incident type, time noticed, systems affected, indicators of compromise and actions taken.
- If you are a PA or other non-bank PSO, send the RBI report in its format within the same window.
- If card data may be involved, notify your acquirer or payment aggregator immediately.
After six hours
- Send updates to CERT-In and RBI as details become clear.
- Assess DPDP obligations and user notification (mandatory from May 2027, good practice now).
- Engage a forensic investigator if the card networks require one.
| Who | Reports what | To whom |
|---|---|---|
| Merchant | CERT-In report; card data compromise notice; contractual notices | CERT-In; acquirer or PA; enterprise customers |
| Payment aggregator | CERT-In report; RBI incident report; merchant notices | CERT-In; RBI; affected merchants |
| Service provider (cloud, SaaS, processor) | CERT-In report; customer notices under contract | CERT-In; its merchant and PA customers |
| Every data fiduciary (from May 2027) | Breach intimation and 72-hour report | Affected users; Data Protection Board |
What should you set up before an incident?
Most missed deadlines come from preparation gaps, not slow responders. Use this checklist.
Logging and retention
- Enable logs on all ICT systems: firewalls, WAF, load balancers, web and application servers, databases, identity providers, VPN, cloud control planes and admin dashboards. Record both successful and failed events.
- Keep at least 180 days of logs, stored in India, in a form you can search and export quickly. PCI DSS requirement 10 asks for 12 months with the last three immediately available, and the DPDP Rules require one year of logs for personal data processing from May 2027. Most payment teams set 12 months as the floor. Our guide toPCI DSS requirement 10covers what to capture.
Time synchronisation
- Point internal NTP servers to NIC or NPL, or to a cloud time service that does not deviate from them.
- Record the time zone with every log entry. Systems can run on UTC.
Contacts and registration
- Designate a CERT-In point of contact and a deputy, and submit their details in the Annexure II format. Update CERT-In when either changes.
- Keep a current contact sheet for RBI, your acquirer or PA, card networks, your forensic firm, legal counsel and your insurer.
Templates and rehearsal
- Prepare a CERT-In report template with fields pre-filled for your organisation.
- Prepare the RBI incident reporting template if you are a PA.
- Draft holding statements for merchants and customers.
- Rehearse with atabletop exercisethat includes a 2 am detection.
Vendor contracts
- Require vendors to notify you well within six hours of an incident affecting your data. Reviewthird-party service provider riskfor the PCI DSS side.
Frequently asked questions
1. Does the 6-hour CERT-In rule apply to small merchants?
Yes. The directions apply to body corporates, which CERT-In’s FAQs define to include companies, firms and sole proprietorships engaged in commercial or professional activity. There is no size exemption for incident reporting.
2. When does the 6-hour clock start?
It starts when you notice the incident or when someone brings it to your notice, not when the investigation is complete.
3. What if we do not have all the details within 6 hours?
Report what you know. CERT-In’s FAQs allow organisations to send the remaining details within a reasonable time after the initial report.
4. Do logs have to be stored in India?
The directions say logs must be kept for 180 days within Indian jurisdiction. CERT-In’s FAQs allow storage abroad if logs can be produced to CERT-In within a reasonable time, but RBI’s data storage rules require payment system data to stay in India.
5. Does reporting to RBI satisfy CERT-In?
No. They are separate obligations with separate formats. Payment aggregators and banks must report to both within six hours.
6. When does DPDP breach notification start?
Rule 7 of the DPDP Rules, 2025 applies from about 13 May 2027. From then, affected users and the Data Protection Board must be told without delay, with a detailed report to the Board within 72 hours.
7. What is the penalty for not reporting?
Section 70B(7) of the IT Act allows imprisonment of up to one year, a fine of up to Rs 1 lakh, or both. Separate penalties apply under RBI rules and, from May 2027, the DPDP Act.