CERT-In Issues AI Security Auditing Guidelines With a Four Tier Risk Model
Most AI governance documents hand out labels. The new AI security auditing guidelines hand out a score, and the score decides how often a system is audited and by whom. That makes it an operational document rather than a statement of principle.
What Was Issued
The Indian Computer Emergency Response Team issued the Artificial Intelligence (AI) Security Auditing Guidelines, version 1.0, on November 4, 2026. The document was prepared by a sub-group of the Working Group on Indian Standards for Cybersecurity Auditing.
It is issued as guidelines. It uses mandatory language throughout and sets minimum audit requirements by tier, it marks some domain coverage as recommended rather than mandatory, and it does not state its own legal enforceability.
Who Is Within Scope
The framework reaches AI systems developed, procured, deployed or operated in India, and systems that process Indian data or serve Indian users. The second limb is the one that matters for a foreign supplier, because it attaches to the data and the users rather than to where the system sits.
The addressees are drawn widely: government bodies and public sector undertakings, critical infrastructure operators, regulated entities, private organisations, developers and service providers, internal and external auditors, empanelled auditing organisations, and risk and compliance functions. There is a scaled-down provision for micro, small and medium enterprises and startups, which confines them to the first two tiers. Research AI, non-AI automation and consumer personal use are excluded, with research AI left outside the mandatory scope but encouraged to adopt the framework voluntarily.
The definition of an AI system is deliberately broad. It covers predictive, generative, hybrid, embedded and multimodal systems, retrieval-augmented systems, agentic and multi-agent systems, autonomous and cyber-physical systems, and AI consumed as a service, whether the model is internal, third party, open source or reached through an interface.
The Tier Is a Score, Not a Category
Each system is scored on eight risk factors, each on a scale of one to four: impact severity, autonomy, data sensitivity, scale and exposure, reversibility, sector criticality, adversarial exposure, and complexity and auditability.
The composite score maps to a tier. Eight to twelve is Tier 1, low. Thirteen to nineteen is Tier 2, moderate. Twenty to twenty-six is Tier 3, high. Twenty-seven to thirty-two is Tier 4, critical. Because the scale runs from eight at the floor, no system in scope can score below Tier 1, and a system that is highly autonomous and hard to reverse can climb into the upper tiers on those factors even where the data it handles is not sensitive.
What the Tier Determines
The tier is not descriptive. It sets the minimum audit requirement, and the requirement rises steeply. Systems in the second tier require independent audit by an empanelled auditing organisation at least annually. The third and fourth tiers require independent audits, and the fourth adds continuous monitoring and reassessment triggered by a significant change or an incident rather than by the calendar.
So the tier assignment is the decision with the budget attached to it. A system that scores one point above a band boundary acquires an annual external audit that the same system one point below does not, which is why the reasoning behind each factor matters more than the arithmetic.
Nine Domains, and the Two Most Organisations Will Not Have
The audit itself is organised across nine domains, with the depth of coverage set by the tier.
AI governance and accountability
Data lifecycle, quality and privacy
Model risk management
Ethics, bias and fairness
Explainability and transparency
Security, adversarial resilience and incident reporting
Continuous monitoring, drift management and validation
Human oversight and decision accountability
Third-party and AI supply-chain assurance
Most of those domains map onto work that an organisation with a functioning information security programme has already done in some form. The two that usually do not exist are drift management, which requires a system to be watched for degradation after deployment rather than signed off at launch, and supply-chain assurance, which requires knowing what is inside a model that somebody else built.
The Lifecycle Framing Matters for Procurement
The framework is built around seven lifecycle stages: design and procurement; data collection and preparation; model development and training; validation and testing; deployment and operations; continuous monitoring and retraining; and decommissioning and retirement.
Starting at design and procurement rather than at deployment is the consequential choice. An organisation that buys a system and audits it afterwards has already missed the first stage, and the questions that stage asks are the ones that cannot be answered later without the supplier's cooperation.
What the Document Does Not Do
Three absences are worth naming, because they decide how much weight the framework can bear. It prescribes no penalty. It does not state its own legal enforceability. And it marks some domain coverage as recommended rather than mandatory, so the mandatory core is narrower than the document's length suggests.
None of that makes it ignorable. It is published by the national computer emergency response team and it sets out what a competent audit of an AI system is taken to involve. The useful question is therefore not whether it binds, but whether an organisation could show that it had done the equivalent.
Key Takeaways
The instrument is dated November 4, 2026: The Artificial Intelligence (AI) Security Auditing Guidelines, version 1.0, issued by the Indian Computer Emergency Response Team.
It is issued as guidelines: With mandatory language and minimum requirements by tier, some coverage marked recommended, and no statement of its own legal enforceability.
Scope follows the data and the users: Systems operated in India, and systems processing Indian data or serving Indian users, which reaches a supplier located anywhere.
Four tiers, assigned by score: Eight risk factors, each scored one to four, with composite bands of 8 to 12, 13 to 19, 20 to 26 and 27 to 32.
Autonomy and reversibility do heavy work: A system that acts on its own and whose actions are hard to undo can climb the tiers even where the data is not sensitive.
The tier sets the audit, not the adjective: Annual independent audit by an empanelled organisation from the second tier, with continuous monitoring and event-triggered reassessment at the fourth.
Nine domains, two of them usually missing: Drift management after deployment, and assurance over what is inside a model built by somebody else.
The lifecycle starts at procurement: Which means the first stage is already behind an organisation that buys a system and audits it afterwards.
Key Statutory Provisions
Artificial Intelligence (AI) Security Auditing Guidelines, version 1.0, dated November 4, 2026: Issued by the Indian Computer Emergency Response Team. Establishes a four tier risk model scored on eight factors, a nine domain audit scope with depth set by tier, seven lifecycle stages from design and procurement to decommissioning, tier-based minimum audit requirements including independent audit by an empanelled auditing organisation from the second tier upwards, and a scaled-down provision for micro, small and medium enterprises and startups. The document does not state its own legal enforceability and prescribes no penalty.
Sources and References
Independent report of the issue and the four risk categories
Artificial Intelligence (AI) Security Auditing Guidelines, version 1.0, dated November 4, 2026, issued by the Indian Computer Emergency Response Team
Disclaimer: This article is for informational purposes only and does not constitute legal advice. Readers should consult a qualified legal professional for advice specific to their circumstances.
Comments