ODA3 Institute | Independent Research Insight

India’s 2022 incident-reporting directions already expressly covered attacks and suspicious activity affecting AI/ML systems. CERT-In’s November 2026 auditing guidance raises a different question: can an organization show how it classified an AI incident, when it became aware of it, and whether the AI controls it claims actually operated?

Methodology and limits. This independent technical analysis reviews CERT-In’s 28 April 2022 Directions, the explanatory May 2022 FAQ and the AI Security Auditing Guidelines, v1.0 (4 November 2026). For context it also notes CERT-In’s July 2025 audit policy and the commencement provisions of the Digital Personal Data Protection (DPDP) Rules, 2025. It separates what the primary sources say from ODA3 Institute’s suggested evidence practices. It is not legal advice, an official CERT-In interpretation, an empaneled audit, a certification or a compliance determination, and readers should take advice on their own circumstances. No production system or customer evidence was examined. It reflects the cited instruments as published on the dates shown; later revisions by the issuing authorities may change the position.

The decision facing leadership

An organization can have an AI incident-response policy, an approved human-oversight procedure and an agent permission diagram, and still lack the evidence to show what happened during a specific event. For a CISO or risk committee, the question is therefore not only whether a control exists, but which bounded conclusion the available records can support. Those records differ in kind. Policies, procedures and diagrams document intended design. Configuration and deployment records show what was put in place at a point in time. Only operating records, such as logs, decisions and outcomes during a defined period, bear on whether a control actually operated, and then only for the period, configuration and paths they cover.

The six-hour reporting rule is not new to AI. Direction (ii) of the 2022 CERT-In Directions requires the incidents listed in Annexure I to be reported within six hours of noticing the incident or being brought to notice of it. Annexure I item (xx) specifically includes attacks or malicious/suspicious activities affecting AI/ML-related systems, servers, software and applications. The May 2022 FAQ discusses attacks that target machine-learning models. It describes its Annexure I explanations as illustrative (Q9); it does not replace the operative Directions or settle every ambiguous incident scenario. [1][2]

Nor is AI auditing new as a category in CERT-In’s publications. Its July 2025 Comprehensive Cyber Security Audit Policy Guidelines listed AI system audits among audit engagement types. The November 2026 guidance provides a separate, AI-specific risk-tiered audit framework. That earlier listing does not by itself establish the legal applicability of the later framework. [6]

The 2026 guidance requires attention to AI-specific incident-response testing (§8.6) and describes six-hour reporting for AI incidents meeting CERT-In reportable criteria (§10.6). It separately states that the classification of an audit finding does not, on its own, determine external reporting (§12.7). An observed AI event, a security incident within a reportable category and an audit finding are therefore three different things, and need not coincide. [3]

1. Evidence needed to examine an AI reportability decision

The 2022 Directions address two foundations for reconstructing an incident. Direction (i) requires specified entities to synchronise ICT clocks using the National Informatics Centre (NIC) or National Physical Laboratory (NPL) Network Time Protocol sources, or sources traceable to them; it also provides a qualified alternative for infrastructure spanning multiple geographies. Direction (iv) requires specified entities to enable ICT-system logs and retain them securely for a rolling 180 days within Indian jurisdiction. [1] These are pre-existing 2022 requirements, not new duties created by the 2026 AI auditing guidance.

Evidence-design implication (ODA3 Institute analysis). An AI incident may need records from model serving, orchestration, gateways, connected tools and downstream systems to reconstruct the event and its timeline. Each organization should determine which of these systems and records fall within its applicable ICT logging and time-synchronization scope; the 2022 Directions do not prescribe this example component list or guarantee that retained logs are sufficiently complete for AI incident reconstruction.

On top of that foundation, an illustrative internal decision record—not a CERT-In incident-reporting form or a substitute for the applicable reporting process—could preserve:

  • the original event observation and its source;
  • the affected component and system boundary;
  • the applicable Annexure I category, including item (xx) where relevant;
  • the earliest supported noticing or notification time;
  • the classification rationale, the evidence relied on and its source, and the decision owner;
  • submission or acknowledgement records, if a report was made;
  • information still unresolved at the time of decision; and
  • any revised classification, with the earlier determination and reasons for change retained where appropriate under the organizations applicable record-keeping requirements. This is a suggested evidence practice, not a new statutory retention obligation.

CERT-In FAQ Q30 explains that an entity may report the information available at the time and provide additional information later within a reasonable time. In ODA3 Institute’s reading, that does not justify deferring a reporting decision until every forensic fact is known. Applicability still has to be assessed against the Directions and the FAQ. [2]

A simulated six-hour reporting exercise is evidence that a procedure was rehearsed; it does not prove timely reporting of a real incident. Equally, an unreported event cannot be declared non-reportable solely because it was labelled “model drift” internally. Classification requires examination of observed facts against the applicable reporting criteria. [1][3]

Adjacent reporting regimes, not assessed here. A particular event may engage other CERT-In categories or separate sectoral reporting obligations, depending on the entity and facts. The Digital Personal Data Protection (DPDP) Rules, 2025 provide, under Rule 7, for intimation to affected Data Principals and the Data Protection Board without delay, as well as further information to the Board within 72 hours (subject to any permitted extension). Rule 7 is scheduled to commence on 13 May 2027; until then, it does not itself add a reporting deadline. This does not mean personal-data incidents currently go unreported: Annexure I of the 2022 CERT-In Directions expressly lists Data Breach (item xi) and Data Leak (item xii) among its reportable-incident categories. Whether any particular event meets the applicable reporting criteria remains a separate determination; sectoral obligations may also apply. [1] Rule 7’s future application, and interaction with CERT-In or sectoral obligations in a particular incident, is outside this Insight’s legal scope. [5]

2. What a risk-tier decision establishes—and what it does not

Section 5 of the 2026 guidelines identifies eight risk factors and four risk tiers. Section 5.4 identifies risk-escalation circumstances and expressly requires that an escalation or exception be documented with its rationale and approval authority (p.25). In ODA3 Institute’s reading, the underlying factor values, system scope and approval rationale should therefore remain examinable; a tier label alone is not sufficient evidence of its basis. [3, §§5.3–5.5]

Tier 2. The composite-score table in §5.4 and the audit-intensity table in §5.5 place an at-least-annual independent audit by a CERT-In-empanelled auditing organization within the Tier 2 column, alongside documented internal audit and continuous assessment. [3, pp.25–26] These stated audit expectations do not, without separate legal analysis, establish an automatically enforceable procurement timetable for every organization; precise applicability and enforceability remain dependent on the relevant legal and sectoral context. If a tier determination changes, its earlier scoring and decision record should remain traceable.

3. When evidence is inaccessible, the conclusion must narrow

Section 7.9 addresses restricted access to supplier-controlled models and systems. Auditors should identify the unavailable information, assess the resulting coverage limitation and consider alternative procedures. Evidence that could not be obtained should be distinguished from evidence the provider explicitly refused to provide. As an evidence-examination principle, restricted access limits what can be concluded for that scope: absence of access is not evidence of conformity, and it is not, by itself, evidence of failure. Nor does a provider’s representation resolve the question merely because direct evidence is unavailable. Vendor assurance for a provider’s environment does not necessarily establish that enterprise-side permissions, API configurations or execution records were effective. [3, §7.9, p.43]

Section 7.7 identifies a self-review threat: auditors shall not assess controls for which they had direct responsibility for design, implementation or operation where that involvement could impair independent judgement. Advisory or commercial relationships should be assessed separately for conflicts under the same section. The distinction matters when separating evidence-readiness work from an external audit. [3, §7.7]

Section 7.10 addresses auditors’ own use of AI tools. Such procedures are subject to scope, confidentiality, tool-validation, traceability and competent human-review safeguards. AI-generated outputs cannot replace examined evidence or an auditor’s independent judgement. [3, §7.10, pp.43–45]

4. Agent controls: four different claims, four different tests

Illustrative scenario only. All actors and events are fictional; no actual transaction or production test is claimed.

Agentic activity can span several decision and execution boundaries. A correct denial at one gateway may coexist with unexamined downstream or alternative execution paths. Suppose an AI agent attempts a funds transfer that requires authorization. A conceptual evidence examination separates four claims:

  1. Policy requirement: Did an approval rule apply to that action at that time? Examine the versioned rule, its effective window and its scope.
  2. Approval applicability: Was any valid approval applicable? Examine the authoritative approval sources, their identity, scope and time coverage, and whether the search was complete. An empty partial export cannot prove absence. Evidence not identified in an incomplete search is different from a defined search in which the relevant event was checked for but not observed. Neither can be treated as proof of what happened on unexamined paths.
  3. Gateway enforcement: Did the gateway reject the specified request? Examine authenticated, correlated request and decision records.
  4. Execution outcome: Was there a prohibited commit within the examined boundary and period? Examine destination or authoritative execution records, including alternate paths and delayed outcomes.

A denial at one gateway can support the gateway claim without resolving the execution-outcome claim. If approval-source coverage or destination records are incomplete, the conclusion must say what remains unknown. Likewise, a defined search of destination records that finds no prohibited commit supports only that none was observed on the paths and in the period searched; it does not establish that none occurred elsewhere. A rejected request could also result from an upstream cancellation or a different control; a matching outcome alone does not establish which mechanism caused it. This illustrates the principle of bounded evidence sufficiency; CERT-In does not prescribe these exact four illustrative tests. It is relevant to the agentic safeguards in §9.7. [3]

Human oversight raises the same issue. Section 11.3 distinguishes a documented review mechanism from evidence that intervention works in practice. For cyber-physical systems, §9.10 makes it important to distinguish a software cancellation command from verified physical response, fallback or safe-state behavior. Tests in simulation do not, on their own, establish live deployment behaviour. [3]

5. Four decisions for responsible executives

Decision owner Question to resolve Records to request
CISO / incident-response lead Can potentially reportable AI events be classified and escalated without losing the noticing timeline? Original events, timestamp-source evidence, relevant ICT log coverage and retention records, classification decisions and report receipts
AI governance lead / risk function Is each system’s risk tier reproducible? Scored inputs, system boundary, escalations and approvals
Engineering / system owner Do agent approvals and restrictions hold at execution, not only at design? Policy versions, approval scope, gateway decisions and downstream outcomes
Procurement / internal assurance What does restricted third-party access prevent the assessor from concluding? Access limitations, alternative procedures and bounded findings

These are suggested governance questions, not new statutory requirements. Requesting the records does not guarantee regulatory acceptance or confer legal safe harbour. Organisations operating across jurisdictions should also address where source records are held, which legal entity is responsible, vendor access, and applicable local or sector-specific instruments.

Notably Absent

This analysis does not:

  • establish that every hallucination, unsuccessful prompt injection, model-drift signal or audit finding must be reported within six hours;
  • classify any particular real incident, or resolve all edge cases under Annexure I item (xx);
  • attest that any production control worked;
  • claim any official mapping or equivalence between CERT-In’s guidance and ODA3 Institute frameworks;
  • represent CERT-In empanelment, endorsement, a statutory audit opinion, certification or insurer acceptance. ODA3 Institute does not issue CERT-In audit opinions or compliance certificates;
  • offer a sector-by-sector determination of legal applicability or enforceability. The examined 2026 provisions do not establish a single universal commencement or effective date;
  • treat referenced standards as mandatory. They do not become mandatory solely by appearing in the guidelines’ reference catalogue (§14);
  • establish any insurance consequence. Well-scoped evidence may help an insurer or insured characterise an AI-related exposure, but the materials reviewed do not show that insurers demand CERT-In evidence bundles, that the guidance changes pricing, or that control evidence guarantees cover.

Related published methodology. ODA3 Institute’s How to Assess an AI System (ODA3-2026-08-WHP-COM-020, Public Version 1.1, 28 October 2026) describes a bounded, evidence-led method for organizations examining their own AI systems. This reference points to relevant ODA3 Institute methodology; it does not imply equivalence with CERT-In guidance or any regulatory recognition. [4]

Conclusion

Specified AI/ML-related security incidents were already covered by the 2022 reporting Directions. The November 2026 auditing guidance makes the evidence behind AI incident classification, risk-tier decisions, human oversight and execution-control claims an explicit subject of audit examination. A bounded technical finding states what the examined evidence supports, under which system conditions, scope and period, and what remains unverified. It does not, without a separate legal or assessment basis, establish regulatory conformity, acceptability, certification, functional safety or risk acceptance.

Primary references

[1] CERT-In, Directions under Section 70B(6) of the Information Technology Act, 28 April 2022, Directions (i), (ii) and (iv), Annexure I items (xi), (xii) and (xx): https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf

[2] CERT-In, FAQs on Cyber Security Directions, May 2022, Q9, Q30 and explanatory material on item (xx): https://www.cert-in.org.in/PDF/FAQs_on_CyberSecurityDirections_May2022.pdf

[3] CERT-In, Artificial Intelligence (AI) Security Auditing Guidelines, v1.0, 4 November 2026, 107 pp., §§5, 7.7, 7.9–7.10, 8.6, 9.7, 9.10, 10.6, 11.3, 12.7, 14: https://www.cert-in.org.in/PDF/AI_Security_Auditing_Guidelines.pdf

[4] ODA3 Institute, How to Assess an AI System, ODA3-2026-08-WHP-COM-020, Public Version 1.1, 28 October 2026: https://docs.oda3.org/documents/com-020/

[5] Ministry of Electronics and Information Technology, Digital Personal Data Protection Rules, 2025, Gazette notification G.S.R. 846(E), 13 November 2025, Rule 1 and Rule 7: https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf . See also the Act commencement notification G.S.R. 843(E): https://egazette.gov.in/WriteReadData/2025/267647.pdf

[6] CERT-In, Comprehensive Cyber Security Audit Policy Guidelines, v1.0, 25 July 2025, §6, p.17, item xxiii (AI System Audits): https://www.cert-in.org.in/PDF/Comprehensive_Cyber_Security_Audit_Policy_Guidelines.pdf

Institutional boundary: ODA3 Institute does not claim CERT-In empanelment, government affiliation or endorsement. This article is independent research, not an official interpretation, legal advice, certificate or audit opinion.

© 2026 ODA3 Pvt Ltd. Published by ODA3 Institute. All rights reserved.

Methodology note

Source-bounded review and clause-specific comparison; separates statutory directions from auditing guidance and ODA3 proposed evidence practices. Includes synthetic agentic-control illustration; no execution tests performed.

Notably Absent

No production-system or customer evidence; no actual incident classification; no control-operation test; no statutory audit, CERT-In empanelment, official interpretation, certification or endorsement; no proven framework equivalence, insurance outcome or universal applicability/enforceability determination.