CERT-In Guidelines For Charge Point Operators
💡 CERT-In Guidelines For CPOs: Key Highlights
- 6 hours: any of the listed cyber incidents must be reported to CERT-In within six hours of noticing it, or of being told about it. A partial first report is accepted.
- 180 days: logs of all ICT systems must be kept securely on a rolling 180-day basis within Indian jurisdiction, and handed over with an incident report or on request.
- 20 incident types: the Directions list 20 categories. On a charging network the live ones are account takeover, attacks on IoT devices, data breaches and leaks, payment attacks and fake apps.
- Not transferable: CERT-In’s FAQs say whoever notices an incident must report it. The duty cannot be contracted away to a software vendor.
- No size threshold: the Directions cover any body corporate, including a sole proprietorship, and foreign firms serving users in India.
For a charging network, the CERT-In guidelines that matter most are the Directions of 28 April 2022, issued under Section 70B(6) of the Information Technology Act. They impose four duties: report specified cyber incidents within six hours, keep 180 days of logs, synchronise system clocks to a standard time source, and name a point of contact for CERT-In. This guide is for Indian charge point operators (CPOs) and eMobility service providers (eMSPs). It is also for the CTO or compliance owner at a fuel retailer or enterprise that runs its own chargers.
One point up front: these duties fall on the operator, whoever wrote the software. Running on a white-label or SaaS platform changes who generates the logs. It does not change who answers to CERT-In. Below, each duty is mapped onto the four places a charging business creates logs. Then come the incidents a CPO could realistically face, how responsibility splits with a vendor, and how this sits beside the EU’s NIS2 for operators in both markets.
Not legal advice. This article summarises the CERT-In Directions, CERT-In’s May 2022 FAQs and its July 2025 audit guidelines as published. Confirm how they apply to your entity with counsel.
CERT-In Guidelines Mapped Onto A Charging Stack
The Directions apply to “service providers, intermediaries, data centres, body corporate and Government organisations”. The IT Act defines a body corporate as any company, firm or sole proprietorship engaged in commercial activity, so there is no turnover or charger-count threshold. CERT-In’s FAQs add that the Directions apply to any entity in the matter of cyber incidents. Providers serving users in India must name a point of contact even without an office here. The Directions took effect 60 days after issue, on 28 June 2022.
Six-hour incident reporting
Listed incidents go to CERT-In within six hours of noticing them or being made aware of them. You can report by email to incident@cert-in.org.in, by phone or by fax, using the CERT-In incident reporting form. The clock does not wait for a full picture. FAQ 30 lets you report what you know and add details later “within reasonable time”. In practice, you need a runbook that lets someone decide “this is reportable” at 2 a.m. on a Sunday, with the form already filled in with your entity details.
180 days of logs, within Indian jurisdiction
Direction (iv) requires logs of all ICT systems to be enabled and kept securely on a rolling 180-day basis within Indian jurisdiction. They must be produced with an incident report or whenever CERT-In asks. FAQ 37 names firewall, intrusion prevention, SIEM, web, database, application, SSH and VPN logs among others. It also says both successful and failed events should be recorded. On a charging network, that means four log streams:
| Log stream | What to keep | Where it usually lives |
|---|---|---|
| OCPP message log (charger to platform) | Charger connections and disconnections with identity and IP, boot and authorisation messages, transactions, status changes, configuration and firmware commands, security events | The charging platform (CSMS) |
| Platform and admin console | Logins (successful and failed), role and permission changes, tariff edits, remote start and stop, firmware pushes, data exports | The CSMS, often in the vendor’s cloud |
| Driver app and APIs | Authentication, API gateway and firewall logs, OCPI calls from roaming partners, rate-limit hits | App backend, API gateway, roaming hub |
| Payments | Gateway callbacks, refunds, wallet adjustments, changes to payout accounts | Payment gateway and the billing module |
The four places a charging business generates logs that fall under Direction (iv).
Plan for the volume. A charger that sends an OCPP heartbeat every five minutes produces 288 messages a day. Across 500 chargers, that is about 25.9 million heartbeats over 180 days, before a single session, status change or meter value is logged. (Our arithmetic: 288 × 500 × 180. The heartbeat interval is configurable.)
What does “within Indian jurisdiction” mean when part of the stack runs abroad, such as a platform in an EU cloud region or a roaming hub outside India? The Direction’s wording is plain, but CERT-In’s own FAQs pull two ways. FAQ 35 says logs “may be stored outside India also” as long as they can be produced to CERT-In in reasonable time. FAQ 36 says any service provider offering services to users in India “needs to enable and maintain logs” in Indian jurisdiction. The conservative reading, and the easiest to defend, is to keep a complete copy of all four streams in an Indian region that can be exported within hours. If you cannot, document where each stream lives and how fast you can produce it, and get counsel’s view.
Clock synchronisation
Every ICT system must sync to the NTP servers of the National Informatics Centre (samay1.nic.in, samay2.nic.in) or the National Physical Laboratory (time.nplindia.org), or to a source that does not deviate from them. Under FAQs 40 and 42, cloud-native time services are acceptable and clocks need not run on IST, but the time zone must be recorded with every timestamp. Chargers are part of this. In OCPP, the central system returns its current time in its BootNotification and Heartbeat responses, and chargers use it to set their clocks. A platform with a drifting clock passes that error on to every charger’s session and meter timestamps. That is exactly what makes an incident timeline impossible to rebuild.
A named point of contact
Send CERT-In a point of contact in the Annexure II format (name, designation, organisation, address, email and phones) to info@cert-in.org.in, and keep it current. All CERT-In directions go to that person. When CERT-In orders information, it can set the format, up to near real-time, and the deadline. Missing either counts as non-compliance.
Which Incidents A Charge Point Operator Would Actually Report
Annexure I of the CERT-In Directions of 28 April 2022 lists 20 incident types, from targeted scanning to attacks on AI systems. FAQ 30 says the six-hour window applies in particular to four kinds of incident: severe incidents on public information infrastructure, data breaches or leaks, large-scale or frequent intrusions, and incidents affecting human safety. These are the categories a charging network is most likely to meet:
| Annexure I category | What it looks like on a charging network |
|---|---|
| (iii) Unauthorised access to IT systems or data | An operator or site-host console account is taken over, and tariffs or payout bank details are changed |
| (xiii) Attacks on IoT devices | A forged charger identity connects to the OCPP endpoint and fakes sessions, or chargers receive unauthorised remote commands or firmware |
| (xi, xii) Data breach and data leak | Driver names, phone numbers and vehicle registrations are exposed through an unprotected API or storage bucket |
| (xiv) Attacks affecting digital payments | Tampered payment callbacks mark unpaid sessions as paid, or wallet balances are credited fraudulently |
| (xvi) Fake mobile apps | A cloned copy of your charging app in an app store harvests driver logins or card details |
| (viii) DoS and DDoS attacks | The OCPP endpoint or driver app is flooded, and chargers drop offline across the network |
| (ix) Attacks on operational technology | A compromise reaches charger power control or site load management, where FAQ 30’s human-safety test may apply |
Annexure I incident types most relevant to a charging network, with a charging example for each.
Two points often catch operators out. A standalone vulnerability that is found and fixed with no incident does not have to be reported (FAQ 15). But an incident affecting your data on someone else’s systems does count (FAQ 31). A breach at your platform vendor is your incident too. The charger and OT side is covered in our guide to IEC 62443 for EV charging. The API controls that prevent the data-leak row are in secure EV charging API practices.
Who Reports When The Platform Is White-Label Or SaaS
Most Indian CPOs do not run their own backend. They operate a branded network on a white-label charging platform hosted with a cloud provider, with a payment gateway and often a roaming hub in the path. Each of those parties generates some of the logs, and any of them may be the first to see an incident.
CERT-In’s answer on responsibility is blunt. FAQ 13 asks whether a consumer-facing business and its outsourcing partner can agree in a contract who reports. The answer is that any entity that notices the incident shall report it, and the obligation “is neither transferrable nor indemnified or dispense with”. FAQ 22 adds that the duty overrides any confidentiality clause. So a contract cannot hand your duty to the vendor. What it can do is make sure you find out in time to meet it. Check three clauses:
- Notification inside your window. The vendor tells you about any incident touching your tenant, drivers or chargers within a fixed number of hours, well inside six, with a named contact on each side. “Without undue delay” leaves you guessing at hour five.
- Logs you can produce. The contract states which of the four log streams the vendor keeps for you, for at least 180 days, in which country, on a compliant time source, and how fast you can export them when CERT-In asks.
- Cooperation on CERT-In orders. If CERT-In directs you to provide information or act, the vendor supports you in the format and timeframe ordered. The vendor also tells you when it reports an incident of its own that involves your data.
Payment logs are the stream most often split between the gateway and the payment and billing software, so name both in the contract. The rest stays with the operator: its point of contact, its runbook and its decision to report. The OCPP-compliant charging software you choose decides how much of the evidence is already in one place when that decision has to be made.
When you evaluate any platform, YoCharge included, ask for written answers on those three clauses. YoCharge’s charging management platform runs on AWS, Google Cloud and Azure across 6+ data centres, so where an Indian network’s logs are hosted is something to settle at contract stage, not after an incident.
CERT-In, NIS2 And Annual Audits For Multi-Country Operators
If the same network also serves EU customers, NIS2 applies there too, and our guide to NIS2 and EV charging covers it in full. In short, NIS2 brings recharging point operators into scope by size and runs a staged clock of 24 hours, 72 hours and one month, reporting to each Member State’s CSIRT. The CERT-In Directions apply to any body corporate regardless of size and want the first report within six hours. Build one runbook to the six-hour clock and you meet both regimes’ first deadlines.
Annual audits
CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines (version 1.0, 25 July 2025) say organisations being audited are expected to have a comprehensive audit of their ICT systems at least once a year. The scope list names IoT and OT assessments, log management audits and vendor risk audits, which match the four log streams and three clauses above. What a good audit or VAPT report should contain, and when to insist on a CERT-In-empanelled auditor, is covered in our guide to VAPT, ISO 27001 and SOC 2 evidence.
On penalties, Section 70B(7) of the IT Act provides for imprisonment of up to one year, a fine of up to ₹1 lakh, or both, for failing to comply with a direction. CERT-In’s FAQ 23 says the power will be used when non-compliance is deliberate. For most operators the larger exposure is commercial: an incident handled late, in full view of site hosts and roaming partners.
Frequently Asked Questions
Sources: CERT-In Directions under Section 70B(6) of the IT Act (28 April 2022) | CERT-In FAQs on the Cyber Security Directions (May 2022) | CERT-In Comprehensive Cyber Security Audit Policy Guidelines v1.0 (25 July 2025) | CERT-In incident reporting form
Bring the three contract questions from this guide. We will show you how the YoCharge platform handles chargers, sessions, operator accounts and payments, and answer on log retention and hosting for your network.
Talk to Sales