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]
Keep following the evidence
Join The Impact Brief founding list for selected AI reports, their effect on people and the evidence limits. Read a sample first.
Continue the story
Read next
Continue exploring cybersecurity: compare the finding and its evidence limits.
AI agents probed 1,200 sites—what should defenders change first?
Exposed Cairn dashboards showed agents moving from target lists to persistent access with little human direction. The report documents more than 100 apparent compromises, but the extent of data theft remains unknown.
Read the next reportExplore the full source and evidence record
What this means for people
- 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.
- System owners may face more independent review and continuous monitoring as autonomy, scale, sensitive data and potential harm increase.
- People affected by AI decisions may benefit from stronger oversight and reversibility, but the document does not itself prove a complaint route, remedy or public audit result.
Global context
The framework applies through an Indian jurisdictional lens while drawing on international approaches including ISO standards, NIST guidance, MITRE and OWASP resources, and the EU's risk-based regulatory experience. Organizations operating across borders may reuse evidence, but cannot assume that a CERT-In tier equals an EU AI Act category, an ISO certification or compliance with another country's law. Local sector rules, data-protection duties, procurement terms and incident-reporting regimes still need separate mapping.
What the evidence does not yet show
- 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.
What to watch next
- A CERT-In or ministry notice clarifying legal authority, commencement, scope and enforcement.
- Sector regulators incorporating the framework into binding supervision or procurement rules.
- Publication of audit, incident, re-audit and remediation outcomes rather than maturity labels alone.
- Independent tests of whether different auditors assign comparable tiers to the same system.
- Evidence that agent interruption, permission controls and recovery procedures work in live environments.
Living evidence record
Impact record IAI-0PEZGFK
Evidence stage
Announced
Confidence
Corroborated
Reporting basis
Multi-source analysis
Independent or research support
Present
Record status
Monitoring
Last checked
7 November 2026
Source trail
5 direct sources across 2 source types.
People impact
Documented in this record.
Uncertainty
Limits and next checks are explicit.
Stages describe the evidence available—not whether a technology is good or bad. See the public method.
Evidence trail
Sources used for this report
Links checked 7 November 2026
Research question, topics and regions
How CERT-In's four-tier AI security-audit framework classifies systems, what evidence auditors should examine and what remains uncertain about legal force and implementation
Topics: AI auditing · Cybersecurity · Agentic AI · Governance · Incident response
Regions: India · Asia
This report is labelled multi-source analysis. We summarise and analyse source material in our own words; company statements remain attributed claims until independently supported. Translated summaries preserve the meaning of the original source and link back to it. Read our editorial standards.
Reader commentary
What does this mean where you are?
Tell us what you have seen at work, in your community or in everyday life. A question is welcome too. No account is needed; we review notes before publishing them.
Explore commentary across the portal →Published reader notes
0No published reader notes yet. You can start the evidence-led discussion above.
Prefer a private correction or response? Contact the newsroom.