Do India’s new AI audit guidelines create binding rules? They set a four-tier framework—but legal force is unclear
CERT-In's 107-page framework grades AI systems by impact, autonomy, data, scale and other risks, then links each tier to stronger audit expectations. It is the agency's most detailed AI-audit playbook yet, but the document does not identify a legal basis, start date or penalty for non-compliance.
The short version
- What happened
- CERT-In's version 1.0 framework scores AI systems across eight risk factors and places them in four tiers, from basic internal review to independent audit with continuous monitoring.
- Who it affects
- Security and audit staff gain a common structure for evidence, but will need access to models, logs, suppliers and sector expertise to apply it credibly.
- What remains unproven
- The guidelines do not identify a legal provision, commencement date or consequence for non-compliance, so their general binding effect remains unclear.
Keep in mind
The guidelines do not identify a legal provision, commencement date or consequence for non-compliance, so their general binding effect remains unclear.
No public implementation dataset shows how systems are being tiered, how often auditors agree or whether remediation reduces incidents.
The framework combines many sectors and architectures; individual regulators and organizations still need system-specific threat models and outcome measures.
Industry summaries help interpret the 107-page document but do not constitute independent legal advice or empirical validation.
Existing incident-reporting and log-retention directions should not be confused with proof that every new audit expectation is a separate legal obligation.
Multi-source analysis · 5 linked sources. Primary analysed source date: 4 November 2026. Latest linked supporting source: 6 November 2026.
Read the full report · 11 min The evidence, methods, implications and limitations
The answer: a detailed operating framework, not a clearly enacted new rulebook
India's Computer Emergency Response Team has published its most extensive framework yet for examining the security of artificial-intelligence systems. The 107-page version 1.0 document gives system owners and auditors a common way to classify risk, plan an engagement, collect evidence, test controls, grade findings and follow remediation. It covers AI developed, procured, deployed or operated in India, as well as systems that process Indian data or provide AI-enabled services to people in the country. That scope makes it relevant well beyond specialist model developers: banks, hospitals, public agencies, software suppliers and organizations buying AI services may all encounter the framework.
The immediate legal conclusion is narrower than the operational detail might suggest. Independent reporting notes that the guidelines do not identify the legal provision under which every expectation is imposed, a commencement date or a stated consequence for non-compliance. CERT-In's publication page describes them as guidelines. That does not make the document unimportant, and existing cyber-incident reporting directions remain separate obligations. It means organizations should not describe every audit frequency, maturity level or technical safeguard in this new document as a verified new statutory duty unless CERT-In, the Ministry of Electronics and Information Technology, a sector regulator or a court supplies that authority.[1][2][3][4]
Four tiers turn system characteristics into an audit plan
The framework assesses eight dimensions: severity of possible impact; autonomy and ability to take actions; sensitivity of data; scale and exposure; reversibility and recoverability; importance of the sector; exposure to adversaries; and technical complexity or auditability. Each factor receives a score. Totals from 8 to 12 place a system in Tier 1, 13 to 19 in Tier 2, 20 to 26 in Tier 3 and 27 to 32 in Tier 4. The calculation is a triage device, not a measured probability of harm. Auditors are also expected to raise a system's treatment when a particular characteristic makes the numerical total misleading.
Tier 1 anticipates self-assessment or a basic internal review. Tier 2 adds a stronger internal programme and an independent audit at least annually. Tier 3 calls for periodic independent audit, with frequency responding to material changes and incidents. Tier 4 combines independent audit with continuous monitoring for systems whose failure could be severe or difficult to reverse. Independent reporting says critical systems are expected to undergo annual red-team exercises and that a re-audit may follow within three months when an opinion is unsatisfactory or two or more critical findings remain. These are the framework's stated expectations; public evidence does not yet show how consistently organizations or regulators will apply them.[2][3][4][5]
The distinction that matters
How the four-tier audit model escalates
Eight scored risk factors guide the starting tier; system context can justify a stricter treatment.
Tier 1 · 8–12
Self-assess or basic internal review
Lower-risk controls and evidence
Tier 2 · 13–19
Strengthen internal review and add annual independence
Regular external challenge
Tier 3 · 20–26
Run periodic independent audits
Frequency follows changes and incidents
Tier 4 · 27–32
Add continuous monitoring to independent audit
Highest-consequence oversight
Nine domains make the audit wider than penetration testing
The nine domains are governance and accountability; data lifecycle, quality and privacy; model-risk management; ethics, bias and fairness; explainability and transparency; security, adversarial resilience and incident reporting; monitoring, drift and validation; human oversight; and third-party or supply-chain risk. Together they ask whether an organization knows what the system is, who can approve it, which data and models it depends on, how performance can change and who can stop it. A security audit under this model is therefore not a single vulnerability scan. It joins technical testing to records, responsibilities, human decisions and supplier evidence.
The lifecycle begins with scoping and tiering, moves through evidence gathering and testing, and ends with findings, management responses, remediation and follow-up. Findings are classified by severity, while a five-level maturity model distinguishes ad hoc practice from optimized and continually improved control. The framework permits AI-assisted audit tools but says their output does not replace evidence or professional judgement. That qualification matters: an automated scanner can help locate suspicious configurations or inconsistent records, but the auditor remains responsible for verifying the finding, its consequence and any conclusion presented to management or a regulator.[2][3][5]
Agentic and generative systems receive architecture-specific checks
CERT-In does not treat every advanced system as a conventional predictive model. The document adds controls for generative AI, retrieval-augmented generation, multimodal models, agentic and multi-agent systems, and autonomous or cyber-physical applications. Auditors are directed toward risks such as prompt injection, disclosure of sensitive data, excessive agency, poisoning, unsafe tool use, manipulated retrieval stores, persistent memory, communication between agents and attacks that cross text, image, audio or physical interfaces. The list is a testing agenda, not evidence that every listed attack has occurred in a particular system.
For agents, the framework stresses least privilege and says an agent should not simply inherit all the permissions of the person or service that launched it. High-risk systems should support emergency interruption, credential revocation, rollback and safeguards against an uncontrolled restart. A kill switch is useful only if it is reachable, independently authorized, tested under realistic failure conditions and linked to recovery procedures. An audit therefore needs to observe what happens after interruption: whether queued actions stop, credentials become invalid, data remain consistent and a human can restore a safe state without silently recreating the unsafe one.[2][3][5]
An AI bill of materials is meant to expose hidden dependencies
The framework calls for an AI bill of materials covering models, datasets, prompts, tools and software components. That inventory can help an organization answer practical questions after a vulnerability, licensing change or data problem: which services use the affected model, which agents can call the tool and which records need to be preserved? It is also intended to support third-party scrutiny. A buyer cannot evaluate supply-chain risk if it does not know which external models, retrieval stores, plugins or monitoring services sit inside a product, but suppliers may resist disclosing commercially sensitive details.
For generated content, the guidance points to watermarking and provenance approaches, including C2PA or an equivalent method. Provenance can show that an item passed through a participating tool or that metadata was attached; it cannot prove a statement is true, identify every edit or prevent metadata from being stripped. Auditors should therefore test the full process—creation, signing, storage, display and verification—and state where the signal disappears. Treating a provenance badge as a truth label would turn a useful chain-of-custody control into a misleading promise to readers, investigators or people affected by a synthetic record.[2][3][4]
Incident deadlines sit alongside the new audit framework
The document incorporates CERT-In's existing expectations around reporting specified cyber incidents within six hours and retaining relevant logs for 180 days. Those time and retention requirements matter to an AI audit because an investigation cannot reconstruct an agent's action or a model-service compromise without logs, identities, tool calls and timestamps. They should not be presented as brand-new obligations created solely by the November AI document. The accurate reading is that CERT-In has integrated existing incident-response directions into an AI-specific audit method.
Organizations will need to decide which AI events cross a reportable threshold and who makes that decision outside office hours. A poor model answer is not automatically a cyber incident, while a prompt-injection attack that exposes data or causes unauthorized actions may be. Useful preparation includes a named incident lead, synchronized clocks, tamper-resistant records, a documented escalation path and a rehearsed method for disabling compromised tools without destroying evidence. The framework supplies structure, but it does not provide public denominators for AI incidents, audit findings or remediation outcomes against which an organization can benchmark itself.[2][4][5]
What this changes for auditors, system owners and affected people
For audit teams, the framework creates a demanding evidence checklist. A credible engagement will need more than policies: model and data inventories, access records, evaluation results, red-team evidence, change logs, supplier attestations, incident records, human-override tests and proof that previous findings were closed. Skills must span cybersecurity, data protection, model behaviour, sector operations and legal interpretation. Small organizations and public bodies may struggle to obtain independent expertise, while providers can make evidence collection difficult when models and logs are hosted outside the customer environment.
For people subject to an AI-assisted decision, the potential benefit is a clearer path from a harmful outcome to accountable evidence. The framework asks about fairness, explanation, human review and reversibility, not only technical availability. Yet the publication itself does not create a proven complaint mechanism, compensation route or public audit register. A patient, borrower, worker or citizen cannot infer that a system is safe merely because its owner says it followed the guideline. Confidence requires transparent scope, an independent auditor where risk warrants it, disclosed limitations and evidence that corrective actions changed the system rather than only the paperwork.[1][2][3][4][5]
The next evidence must show authority, adoption and outcomes
The clearest unresolved question is legal force. A formal CERT-In or ministry notice could identify the statutory basis, effective date, entities covered and enforcement consequences. Sector regulators could also incorporate the framework into binding banking, insurance, health, telecoms or public-procurement rules. Until that happens, organizations should map the guideline against duties they already have and seek qualified Indian legal advice where compliance decisions are consequential. Editorially, the distinction between recommended practice and enforceable obligation should remain visible in every account of the document.
Implementation evidence is equally important. Publication of audit statistics, anonymized findings, re-audit results and incident trends would show whether the tiers change real controls. Independent comparisons could test whether the scoring method places similar systems in similar tiers and whether a higher maturity grade predicts fewer or less severe failures. Evidence would weaken confidence if tiering becomes a box-ticking exercise, vendors withhold essential records or severe systems remain in low tiers. For now, the guidelines are a substantive security blueprint and a signal of regulatory direction—not proof that India's AI systems have been audited or that a new binding regime is already in force.[1][2][3][4]