AI and ML Incidents Are Already Reportable to CERT-In

Annexure I to the CERT-In Directions of 28 April 2022 lists twenty mandatorily reportable incident types. Item (xx) is attacks or malicious or suspicious activities affecting systems, servers, software or applications related to Artificial Intelligence and Machine Learning. That puts an AI incident inside the six-hour reporting regime already — no new law, no consultation, no commencement date to wait for.

CERT-In has not published item-by-item interpretive guidance for (xx). So this page keeps two things visibly apart: the text of the instrument, quoted, and our reading of how it applies to a real AI estate, labelled as a reading every time it appears. Where the two differ — and they do, because CERT-In’s explanatory note is narrower than the clause — the difference is set out rather than smoothed over.

Yes. An attack on an AI or machine learning system is a mandatorily reportable cyber security incident in India, and it has been since the CERT-In Directions of 28 April 2022 took effect. Annexure I to those Directions lists twenty types of incident that must be reported, and item (xx) is “Attacks or malicious/suspicious activities affecting systems/servers/software/ applications related to Artificial Intelligence and Machine Learning”. Direction (ii) requires every Annexure I type to be reported to CERT-In within six hours of noticing the incident or being brought to notice about it. No dedicated AI statute is required for that obligation to exist, and none is pending as a precondition for it. The instrument is the Directions issued under sub-section (6) of section 70B of the Information Technology Act, 2000, and the class was written into it on the day it was issued.

The practical consequence is a timing problem rather than a legal one. AI incidents are unusually hard to characterise quickly: a model behaving strangely is produced equally well by a prompt injection, a poisoned retrieval corpus, a provider-side model change, a system-prompt edit deployed that morning and ordinary drift. Six hours will usually run out long before you can say which. CERT-In anticipates that — Q30 of its FAQ on the Cyber Security Directions, May 2022, states that entities “may provide information to the extent available at the time of reporting” and that “additional information may be reported later within reasonable time”. So the obligation is to tell CERT-In that something is happening, on what you know, and to keep the thread open — not to arrive at hour five with a finished investigation. Everything else on this page follows from that: what plausibly counts, what belongs under a different item, what you can write at hour four, and the logging without which none of it is possible.

Each is worked through in full below, with the clause behind it.

Note that the channel sentence is part of the direction, not a footnote to it. Note also that direction (ii) says “cyber incidents as mentioned in Annexure I”, and that Annexure I is headed as a list of cyber security incidents — the Directions use both phrases and point to the IT Act, 2000 and the CERT-In Rules, 2013 for their meaning. The FAQ of May 2022 defines only one of them, at Q3: “‘Cyber Security Incident’ means any real or suspected adverse event in relation to cyber security that violates an explicitly or implicitly applicable security policy resulting in unauthorised access, denial of service or disruption, unauthorised use of a computer resource for processing or storage of information or changes in data, information without authorisation.” The words “or suspected” in that definition do a great deal of work in an AI incident.

Item (xix) is worth a second look while you are here. It is the emerging-technology sibling of item (xx) and it names Big Data, block chain, virtual assets, virtual asset exchanges, custodian wallets, robotics, 3D and 4D printing, additive manufacturing and drones. Two consequences follow. An AI system embedded in a robotics or drone platform may engage both items rather than one. And AI and ML have an item of their own rather than sitting inside item (xix) with the rest of the emerging-technology list — that is what the instrument does, whatever the reason for it.

For the whole instrument — the other five directions, the point-of-contact format, the five-year subscriber records and the KYC annexure — see our page on the CERT-In Directions of 2022, explained, and for what CERT-In itself is and where its authority comes from, see what CERT-In is.

The clause does not say “attacks on AI systems”. It says activities affecting systems, servers, software or applications related to Artificial Intelligence and Machine Learning, and “related to” is broad enough on a literal reading to swallow any product with an AI feature anywhere in it. The test we use, and it is ours rather than CERT-In’s, is to ask which of four roles the AI component actually played. If it played none of them — if it was merely present in the same product and had nothing to do with the mechanism or the loss — the incident is not related to AI, and calling it an AI incident degrades your own reporting. Write down which role it played. That sentence is most of the analysis, and it is the sentence a reader of your filing needs.

A credential deserves a word, because it is the case people argue about. An API key for an inference endpoint is not one of the four nouns the clause names, so nothing turns on the key itself. What matters is what the key reached: an attacker using it affects the systems and software it gives access to, which is a reading about effect rather than about the key being a listed thing. Say it that way in the report and the classification survives scrutiny. Say “a credential is an AI system” and it does not.

Fifteen fact patterns, each with the role the AI played, so the table visibly applies the test above rather than sitting beside it.

In our reading, a prompt injection that crossed a trust boundary is reportable under item (xx), and usually under a second item as well. The activity is malicious, it affected software related to AI, and the AI played the role of path: content the model ingested carried instructions it acted on, and the action reached something it should not have. File the AI item and the item describing what was reached. A blocked attempt against a working control is the harder case, and it is answered in the boundary section below rather than here, because it is a judgement rather than a classification.

Yes, in our reading, and it is the one fact pattern CERT-In’s own explanatory note for type (xx) actually describes: deceptive data used to corrupt the model and cause it to behave erroneously. The same reading covers a poisoned retrieval index, which is the form this most often takes in a deployed system. Two things decide whether you can report it at all: dataset and index write provenance, and log retention. Poisoning is usually discovered long after the write, so the six-hour clock runs from the day you notice and the occurrence goes in as a date range that you say is a range.

Three things, and they are worth stating plainly because over-classification costs you as much as under-classification. A classical web vulnerability in a product that happens to contain an AI feature is reportable on its own facts under item (iii), (x) or (xi), and is not item (xx) — the AI played none of the four roles. A model that was simply wrong, with nobody attacking it, is not an incident under a clause that covers attacks and malicious or suspicious activities. It is a governance matter, with the honest caveat that erroneous behaviour is also what successful poisoning looks like from outside. And a vulnerability found in your AI stack with no evidence it was used is not mandatorily reportable as a standalone matter: Q15 of the CERT-In FAQ of May 2022 says so in terms. Check the logs before you conclude it was standalone.

On vocabulary: the attack classes above are described in the words practitioners use, and the closest thing to a common reference for them is the OWASP Top 10 for LLM Applications, 2026 edition, published on 4 August 2026, which carries Prompt Injection at LLM01 and Excessive Agency at LLM03 — the latter having moved up from LLM06 in the 2025 edition. It also carries categories for supply-chain risk, for data and model poisoning and for sensitive information disclosure, which we name without numbers here because item numbers move between editions and a stale number is worse than no number. One warning about how to use that list in a scope of work: §8(ii) of CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines (version 1.0, 25 July 2025) states that “limited lists such as OWASP Top 10, SANS Top 25 and similar, should not be considered as standards or references for audits”. A ranked list of common categories is excellent shared vocabulary for describing an incident, and it is not an audit criterion. Use it for the first purpose and name something comprehensive for the second — which is the argument made at length on what VAPT actually is.

At the moment of noticing, or of being brought to notice. Direction (ii) says so in those words, and it is the single most consequential sentence on this page: it means the clock is already running while you are still deciding whether anything happened. It does not start when triage confirms it, when a root cause is found, or when somebody senior agrees it is serious. A researcher’s email at 19:40 on a Friday starts the clock at 19:40 on the Friday, whatever your process does with it on Monday morning. Where two defensible moments exist — the engineer who saw it and the engineer who recognised it — record both and work to the earlier.

Two things the FAQ does not address. We searched the CERT-In FAQ of May 2022 for both and found nothing, and a silence is worth publishing as a silence rather than filling with a rule nobody issued.

Nothing in the instruments says it does not. Direction (ii) says six hours and carves out no nights, weekends or holidays, and nothing in the FAQ suspends or extends the period. Treat the window as running continuously and staff for it: an incident noticed at 23:00 on a Saturday has the same deadline as one noticed at 11:00 on a Tuesday. Practically that means a named deputy, a monitored mailbox out of hours, and a filing template somebody can complete without waking the person who wrote it.

The instruments describe no retraction mechanism. The closest thing is Q30, which contemplates additional information being reported later within reasonable time — so the approach we take, and we are labelling this as a reading, is to correct forward on the same thread: state what has changed, what it was previously reported as, and what the current position now is. That leaves a clean record, which is the point, and it is why a first filing that describes observations rather than asserting a cause almost never needs a correction at all — only an update.

Six paragraphs, in this order, and none of them long. What we observed — the behaviour, the system, the window, with timestamps and time zone. What we have established — only what the evidence supports. What remains open — the competing explanations, named, with what would distinguish them. What is affected — the application, the model and version, the environment, the region, whether data is in scope and whether it is personal data. What we have done — containment, preservation, and anything we had to destroy in order to contain. What happens next — the next checkpoint, and a commitment to update on the same thread. Nothing in that structure requires you to know whether the model was manipulated, which is exactly why it can be written at hour four.

Everything above tells you what the fields are. This is the artefact itself, because a team at hour four should not be rediscovering the structure of a document. Read it as a skeleton of ours, not a form CERT-In publishes — the Incident Reporting Form’s own notes state that it is “not mandatory to fill and/or sign this form” and that incidents may be reported by providing the relevant information in the communication itself. The placeholders are left in brackets deliberately, so that nothing here reads as a filing anybody made. Fill them, delete what does not apply, and send it from the point of contact you notified under direction (iii).

Two notes on using it. Send it to incident@cert-in.org.in, not to info@cert-in.org.in — the latter is the address the Annexure II point-of-contact format goes to, and mixing the two up costs an hour nobody has. And keep the sent item, its timestamp and any acknowledgement in the same place as the preserved evidence, because the record that you filed inside six hours is itself something you may later have to produce.

The following example is invented for this page. It is not a client, it is not drawn from any engagement, it describes no sector, and it makes no claim about anyone’s outcomes. It exists to show how the six-hour window is actually used when the facts are genuinely unclear, and every time and detail in it was made up to that end.

Three things in that invented sequence are worth naming, because they are what separates a controlled response from a scramble. The team worked to the earlier of two defensible start times. They preserved before they contained, which is the decision that made the 18:40 update possible at all. And they filed a report that asserted nothing they could not support, which is why new facts arriving in the evening required an update rather than a correction. None of those three is technical.

This second example is also invented for this page. It is not a client, it is not drawn from any engagement, it describes no sector, and it makes no claim about anyone’s outcomes. The first example was the tractable case: a visible artefact, a write log, an answer by the evening. This is the case the readiness checklist calls the real measurement — a model behaving oddly with nothing alerting, where four explanations survive contact with the evidence and the six hours run out while three of them are still alive.

That invented sequence is the one worth rehearsing, because it demonstrates the method rather than illustrating it. Nothing was confirmed inside six hours and the filing was still on time and still accurate. The replay eliminated two explanations for the price of forty-five minutes. The report’s most valuable sentence was an admission — that the served model could not be identified per request — and that sentence is what produced the fix. And the characterisation moved twice after filing without anybody having to retract anything, because the first report never claimed more than it could show.

A third case is worth naming even though it is not worked here, because the page takes a position on it repeatedly: the incident that surfaces in your product but originates on a model provider’s side. On paper the honest output is short and it is two lists — here is our side of the boundary, the interface, the orchestration, the prompts, the retrieval, the tools and the data we sent and received, with what we observed in each. And here is what we cannot see, named as such. A filing that describes the first list accurately and declares the second is a better document than one that speculates across the gap.

Two sentences, and the second is the one that connects logging to reporting: the logs are not an archive, they are part of what you hand over. Q38 of the FAQ adds who may ask for them — an officer of CERT-In not below the rank of Deputy Secretary to the Government of India.

Direction (iv) says logs “shall be maintained within the Indian jurisdiction”, and Q35 of the CERT-In FAQ of May 2022 adds a nuance that changes the practical answer: “The logs may be stored outside India also as long as the obligation to produce logs to CERT-In is adhered to by the entities in a reasonable time.” Read the direction and the answer together before you take a region decision rather than after one — this is a common and expensive sequence, because a logging architecture is far harder to move than to site. The FAQ’s own note applies: it is not a legal document, it calls itself evolving, and if the point is material to a decision, confirm the current position with CERT-In.

Q37 of the FAQ answers the “which logs” question with a list it expressly calls non-exhaustive: firewall logs, intrusion prevention system logs, SIEM logs, web, database, mail, FTP and proxy server logs, event logs of critical systems, application logs, ATM switch logs, SSH logs and VPN logs, given “to provide flavour of logs to be maintained by the relevant teams”. It closes with the line that matters most for AI systems: “From the incident response and analysis perspective both successful as well as unsuccessful events shall be recorded.” Nothing in that list is AI-specific, because the list predates the estate most organisations now run. Application logs is the heading an AI stack falls under, and the table below is what that has to mean in practice if an AI incident is to be describable at all.

Eleven signals. The column on the right is the part teams skip and then regret, because each of these carries a decision about sensitivity or cost that is far cheaper to take now than at hour two.

Finding these gaps before an incident does is what testing is for. Where the AI estate is in scope, the exercise that surfaces them is adversarial rather than scanner-driven — see what AI red teaming is, red teaming an LLM application and how AI red teaming differs from VAPT. Where inference, retrieval and orchestration run as managed services, item (xviii) and the cloud material apply alongside item (xx): what cloud security covers and cloud security audits in India. And because almost every AI system is reached through an interface rather than a screen, API security testing is usually where the first real finding lands.

It is also worth knowing that the Indian audit ecosystem is already organising around this. CERT-In’s own conference proceedings for CERT-In SAMVAAD 2026, the national annual conference held from 27 to 29 April 2026, record a working group on Indian standards for cybersecurity auditing whose stated aim includes standardised reporting formats, RFP templates and scope templates for various types of audit, expressly including emerging technologies such as artificial intelligence, and the Government of India’s press release on the conference names AI-driven cyber risks, including “emerging frontier AI models with advanced cyber capabilities”, and AI-driven red teaming methodologies among the topics presented. Read that as direction of travel rather than as obligation: it tells you what the assurance market is about to start asking for, and it does not add a duty. The duty is already item (xx). For the management-system side of the same estate, see integrating ISO 42001 with ISO 27001 and AI risk assessment versus AI impact assessment.

Section 8(6) of the Digital Personal Data Protection Act, 2023 requires a Data Fiduciary, in the event of a personal data breach, to give the Board and each affected Data Principal intimation of the breach “in such form and manner as may be prescribed”. That phrase is routinely quoted as though nothing had been prescribed. It has been. The Digital Personal Data Protection Rules, 2025 were notified by G.S.R. 846(E) of 13 November 2025 and published in the Gazette of India Extraordinary, Part II, Section 3, Sub-section (i), and rule 7 supplies the manner. We fetched and read that Gazette text directly rather than relying on a summary of it, on the same date as the CERT-In sources below.

Rule 7(1): on becoming aware of any personal data breach, the Data Fiduciary shall, to the best of its knowledge, intimate each affected Data Principal “in a concise, clear and plain manner and without delay”, through her user account or any mode of communication she has registered, giving (1) a description of the breach including its nature, extent and timing, (2) the consequences relevant to her, (3) the measures implemented and being implemented to mitigate risk, (4) the safety measures she may take, and (5) the business contact information of a person able to respond to her questions. Rule 7(2): on becoming aware, the Data Fiduciary shall intimate the Board — without delay, a description of the breach including its nature, extent, timing and location of occurrence and the likely impact, and then, within seventy-two hours of becoming aware of the breach, or within such longer period as the Board may allow on a written request, updated and detailed information, the broad facts of the events, circumstances and reasons leading to the breach, measures implemented or proposed, any findings about the person who caused it, remedial measures to prevent recurrence, and a report on the intimations given to affected Data Principals.

Two things about timing, and the second is the one to plan against. The first is that rule 7 creates a different clock from direction (ii) and not a competing one: six hours to CERT-In from noticing a cyber security incident, and under rule 7 an intimation to the Data Principal and a first description to the Board without delay, with the detailed Board filing inside seventy-two hours of becoming aware of a personal data breach. Different triggers, different recipients, different deadlines, and one AI incident can engage both — prompts, retrieval corpora and training sets routinely contain personal data that nobody catalogued as personal data. The second is commencement. Rule 1 of the Rules brings them into force in stages: rules 1, 2 and 17 to 21 on publication, rule 4 one year after publication, and rules 3, 5 to 16, 22 and 23 eighteen months after publication. Rule 7 is in that last group, so on the face of the Gazette date of 13 November 2025 the breach-intimation machinery bites from 13 May 2027. The CERT-In six-hour duty has been running since 2022 and does not wait for it.

The practical consequence for an AI estate is a scoping question rather than a legal one: you cannot run the second clock if you do not know which of your prompt logs, retrieval corpora and evaluation sets hold personal data, and that inventory is the same inventory the first clock needs. For the roles and duties behind it, see what a Data Fiduciary is and the DPDP Act in plain English.

We deliver CERT-In audits, end to end, with our CERT-In empanelled partners. On the subject of this page specifically, the work that matters most is the preparation — the AI asset inventory, the logging review, the classification threshold written down, the filing template, the tabletop. The six-hour report itself is filed by the organisation, because under Q13 of CERT-In’s own FAQ that duty cannot be handed to anybody.

Named but not linked, and for two different reasons. Three non-Indian instruments are cited here without links, the two EU regulations counted as one. The OWASP Top 10 for LLM Applications, 2026 edition, published 4 August 2026, with Prompt Injection at LLM01 and Excessive Agency at LLM03 having moved up from LLM06 in the 2025 edition. Regulation (EU) 2024/1689 with Regulation (EU) 2026/1744, in force 27 July 2026, deferring the stand-alone Annex III high-risk obligations to 2 December 2027 and the Annex I obligations to 2 August 2028. Those two are carried with their edition, version and dates from our own verified-facts record, and they are unlinked because they were not among the documents fetched and content-checked for this page — not because they are hard to find. ISO/IEC 42001:2023 is the third, and it is a different case: it is paywalled, so there is no public text to link at all. Two CERT-In documents are also named rather than linked because the paths their own instruments print do not serve them — “Method of verifications to compliance with CERT-In Directions issued on 28.04.2022”, named at §15.2.1(iv) of the 2025 audit policy guidelines, and the notified text of the Information Technology (The Indian Computer Emergency Response Team and Manner of Performing Functions and Duties) Rules, 2013, which Annexure I refers to at Rule 12(1)(a) and which we quote only through instruments that reproduce it.