CERT-In’s AI Security Auditing Guidelines: Will Your AI System Need an Independent Audit?
Picture a customer-support chatbot at a mid-sized Indian e-commerce company. It answers questions about orders and returns. It runs on a third-party large language model. Nobody thinks of it as high-risk.
Now the product team gives it one new permission: it can issue refunds up to ₹5,000 without human sign-off. It’s a small feature that saves agents hours a week.
Under the Artificial Intelligence (AI) Security Auditing Guidelines that CERT-In issued on 4 November 2026, that one change can be enough to move the chatbot into a higher risk tier. And the tier decides how the system gets audited, how often, and by whom.
The 107-page framework scores every AI system on eight risk factors. Most coverage so far has stopped at “four risk tiers, from low to critical.” This post goes further: it explains how the scoring actually works, walks through the chatbot example factor by factor, and sets out what security teams should do now.
Key Takeaways
- CERT-In’s AI Security Auditing Guidelines (v1.0, 4 November 2026) cover AI systems developed, procured, deployed, or operated in India, plus systems that process Indian data or serve Indian users.
- Every AI system is scored from 1 to 4 on eight risk factors. The total (8–32) sets one of four tiers, and the tier sets audit depth, frequency and independence.
- From Tier 2 upward, the minimum requirement includes an independent audit by a CERT-In empanelled auditing organisation.
- Giving an AI system the ability to act, such as issuing refunds or calling tools, raises its autonomy score and is a named escalation trigger.
- AI incidents meeting CERT-In’s reportable criteria must be reported within six hours, with 180-day log retention, in line with CERT-In’s existing 2022 Directions.
What CERT-In Issued and Who It Covers
The Artificial Intelligence (AI) Security Auditing Guidelines set a common, risk-based framework for auditing the security, governance, and resilience of AI systems across their full lifecycle. CERT-In lists the document on its official guidelines page under reference CISG-2026-04.
The scope is deliberately wide. It covers AI systems developed, procured, deployed or operated by organizations in India, as well as systems that process Indian data or provide AI-enabled services to Indian users. That brings in global AI-as-a-Service providers and SaaS platforms selling into India, not just Indian companies.
It also doesn’t matter where the model came from. The guidelines say AI systems stay in audit scope regardless of model origin, ownership, or delivery mechanism. Internally built models, proprietary vendor models, open-weight models, and models consumed through an API are all covered. If you can’t get evidence from your vendor, that’s recorded as a scope limitation, because the absence of access is not treated as evidence of conformity.
There are three narrow exclusions:
- Academic research AI that doesn’t make decisions about individuals and isn’t in production. It enters full scope once it moves to a pilot.
- Purely rule-based automation, such as traditional RPA with no machine learning. Hybrid systems that mix rules and ML are in scope.
- Consumer personal use, such as an individual using a photo-editing app. The providers of those tools remain in scope.
Small companies get some relief, but only for low-risk systems. MSMEs and startups can use simplified self-assessment for Tier 1 systems. For Tier 3 and Tier 4 systems, the guidelines state there is no proportionality exemption: the full requirements apply regardless of organizational size.
Is It Mandatory?
The honest answer is: partly, and probably more so over time. The document is issued as guidelines and doesn’t state a penalty or a compliance deadline. But it is written in mandatory language (“shall”) and sets minimum audit requirements for each tier.
Three things give it teeth in practice:
- It plugs into rules that are already binding. The six-hour incident reporting window and 180-day log retention come from CERT-In’s Directions of 28 April 2022 under Section 70B of the IT Act. The new guidelines bring AI incidents squarely into that regime: AI incidents meeting CERT-In’s reportable criteria must be reported within six hours.
- Regulators are named as intended users. The document lists RBI, SEBI, IRDAI and TRAI among the bodies it is written for. If a sectoral regulator adopts it, the tiers become obligations for banks, brokers, insurers and telecom operators.
- Buyers will ask for it. Government tenders and enterprise customers already demand CERT-In empaneled audit reports for traditional systems. Expect AI audit evidence to show up in procurement questionnaires next.
For security leaders, the practical takeaway is to treat the framework as the benchmark your AI systems will be judged against, whether by a regulator, a customer or an auditor.
How the Eight-Factor Risk Score Works
Each AI system is scored from 1 (low) to 4 (critical) on eight inherent-risk factors, and the scores are added up. Organizations must score what the system can actually do, without taking credit for controls they claim to have in place.
| Factor | What it asks |
| F1: Impact severity | How bad is the consequence of a wrong, compromised or unsafe output? |
| F2: Autonomy and actionability | What actions, tool calls or decisions can the AI take before a human approves? |
| F3: Data sensitivity | How sensitive is the data it processes, from public to biometric or classified? |
| F4: Scale and exposure | How many users, transactions or systems does it reach? |
| F5: Reversibility | How easily can the damage from a bad output or action be undone? |
| F6: Sector criticality | Does it support an essential, regulated or critical-infrastructure function? |
| F7: Adversarial exposure | Is it internal, internet-facing, or in an actively targeted environment? |
| F8: Complexity and auditability | How opaque is the model and its dependencies? Missing evidence can’t justify a low score. |
The total maps to a tier, and the tier sets the minimum audit requirement:
| Score | Tier | Minimum audit requirement |
| 8–12 | Tier 1 (Low) | Self-assessment or basic internal review, reviewed annually |
| 13–19 | Tier 2 (Moderate) | Documented internal audit, plus an independent audit by a CERT-In empaneled auditing organization at least annually |
| 20–26 | Tier 3 (High) | Periodic independent third-party audit by a CERT-In empaneled organization, every six months where risk or material change warrants |
| 27–32 | Tier 4 (Critical) | Independent audit by a CERT-In empaneled organization with continuous monitoring |
The score isn’t the final word. The guidelines list escalation triggers that can push a system up a tier regardless of its total. They include AI that can autonomously execute code, transactions, or external communications; AI with privileged access to production systems or sensitive data; and AI that can’t be reliably interrupted, rolled back, or placed in a safe state.
Two more rules matter. Auditors must validate your tier independently, and where their assessment is higher than yours, the higher tier applies for scoping. And a tier can only be lowered after a documented reassessment shows a sustained drop in risk, approved by the organization’s designated risk authority.
The Chatbot That Jumps a Tier
The same chatbot lands in Tier 2 when it only answers questions, and in Tier 3 once it can issue refunds. Here is an illustrative scoring using the calibration guide in Section 5.3 of the guidelines.
Version A answers questions, checks order status through retrieval-augmented generation (RAG) over help articles and order history, and hands refunds to human agents. Version B is the same bot, but it can issue refunds up to ₹5,000 on its own.
| Factor | Version A: answers only | Version B: issues refunds | Why it changes |
| F1: Impact severity | 2 | 2 | A wrong answer or a single bad refund is still limited and recoverable |
| F2: Autonomy | 2 | 3 | Version B initiates consequential actions instead of advising a human |
| F3: Data sensitivity | 2 | 3 | Refunds bring payment and financial data into play |
| F4: Scale and exposure | 3 | 3 | Large-scale, customer-facing in both cases |
| F5: Reversibility | 2 | 3 | Money paid out to the wrong account is costly and slow to recover |
| F6: Sector criticality | 2 | 2 | An important business function, not critical infrastructure |
| F7: Adversarial exposure | 3 | 3 | Internet-facing, so anyone can send it hostile prompts |
| F8: Complexity | 3 | 3 | A third-party LLM is partially opaque to the deploying company |
| Total | 19 (Tier 2) | 22 (Tier 3) |
Three factor changes add three points, enough to cross from the top of Tier 2 into Tier 3.
Two things stand out.
First, even the “harmless” Version A sits at the top of Tier 2. That already means a documented internal audit, a simplified AI impact assessment, AI threat modelling and API security testing, plus an independent audit by a CERT-In empaneled organization at least annually. Many companies running customer-facing LLMs may not realize they’re here.
Second, Version B doesn’t just cross a score threshold. Its ability to initiate transactions is also a named escalation trigger, and an internet-facing bot that can move money is an obvious prompt-injection target. Moving to Tier 3 adds a comprehensive AI impact assessment, validation independent of the development team, a comprehensive AI security assessment with VAPT, a formal AI Governance Committee, and audits as often as every six months.
Note: This scoring is illustrative. Actual tiers depend on each system’s real capabilities and context, and auditors will reach their own assessment.
What Auditors Will Test Your AI For
Section 9 of the guidelines adds dedicated requirements for generative AI, RAG, agentic, multimodal, and multi-agent systems. These are the threats auditors are told to focus on, and the ones attackers are already using:
Mapped onto the refund chatbot, each component becomes a separate test case, and the leaked-credential risk sits outside the system entirely
CERT-In takes prompt injection seriously enough to apply it to auditors too. Audit teams using AI tools must treat auditee documents, logs and tool outputs as untrusted data and test for injection attempts designed to alter audit criteria or suppress findings.
The guidelines also expect AI threat models to draw on MITRE ATLAS, OWASP guidance, CERT-In advisories and “other relevant threat intelligence.” That’s where many teams have a blind spot.
Threat actors trade stolen AI API keys, discuss jailbreak and injection techniques on underground forums, and leak cloud and model credentials in breach dumps. Cyble’s threat intelligence tracks this activity across the surface, deep and dark web, so security teams can build AI threat models on what attackers are actually doing rather than on assumptions.
What to Do in the Next 90 Days
The first step is the one most organizations will find hardest: knowing what AI they actually run. The guidelines treat an incomplete or missing AI inventory as a governance non-conformity in its own right.
- Build your AI inventory. List every AI system in use, including vendor APIs, copilots built into SaaS tools, and shadow AI that teams adopted without approval. Record purpose, owner, model source, data processed and deployment status.
- Score each system honestly. Apply the eight factors to what each system can actually do today. Flag any system that can act on its own, such as issuing refunds, sending messages, executing code or calling tools, since those are the ones most likely to sit higher than you expect.
- Review permissions before you add features. Treat every new agent capability as a potential tier change. Put human approval gates on consequential actions and make sure agents run with least privilege.
- Map your AI incidents to the six-hour clock. Define what an AI incident looks like, such as a successful prompt injection, data leakage through a model, or a poisoned knowledge source. Then check that you can detect, classify, and report one within six hours, with 180 days of time-synchronized logs to support the investigation.
- Lock down AI secrets and watch for leaks. Move API keys and model credentials into a secrets manager and rotate them. Then monitor for those credentials turning up outside your environment. With Cyble’s dark web monitoring, teams get alerts when credentials, keys or data tied to their organization appear in breach dumps, underground markets, paste sites or code repositories, so a leaked key can be revoked before it’s abused.
- Bring in threat intelligence for your AI threat model. Use current intelligence on attacker techniques, rather than a generic checklist, to decide what your red-team and VAPT exercises test.
- Engage a CERT-In empaneled auditor early. If any system scores Tier 2 or above, start scoping the independent audit now rather than when a regulator or customer asks for the report.
How Cyble Helps You Get AI-Audit Ready
CERT-In’s framework asks organizations to prove three things about their AI: that they understand the threats, that they monitor continuously, and that they can respond fast. Cyble’s AI-native platform supports each of them.
- Threat intelligence for AI threat modelling. Cyble Vision, powered by Cyble Blaze AI, tracks threat actors, attack techniques, and emerging campaigns across the surface, deep, and dark web. That gives your AI threat model and red-team scope a grounding in real attacker behavior, as the guidelines expect.
- Continuous monitoring for exposed credentials and data. Cyble’s dark web monitoring watches underground forums, marketplaces, paste sites, and code repositories for leaked API keys, credentials, and datasets linked to your organization, which supports the guidelines’ secrets-management and continuous-assurance controls.
- Faster detection for the six-hour window. Real-time alerts on ransomware activity, data leaks, and brand impersonation help security teams spot incidents early enough to classify and report them within CERT-In’s deadline.
- Visibility into third-party and supply-chain risk. Monitoring vendor exposure supports the guidelines’ requirements for third-party and AI supply-chain assurance.
Cyble was named a Challenger in the 2026 Gartner® Magic Quadrant™ for Cyberthreat Intelligence Technologies and is trusted by organizations in more than 50 countries.
Is your organization ready for CERT-In’s AI security audits? Request a demo to see how Cyble helps you find exposure, track AI-focused threats, and respond inside the six-hour window.
Frequently Asked Questions
What are CERT-In’s AI Security Auditing Guidelines?
They are a risk-based framework, issued by CERT-In on 4 November 2026, for auditing the security, governance, and resilience of AI systems across their lifecycle. Each AI system is scored on eight risk factors and placed in one of four tiers that set its audit requirements.
Do the guidelines apply to foreign AI companies?
Yes. They cover AI systems that process Indian data or provide AI-enabled services to Indian users, not only organisations based in India.
Does using a third-party AI model or API take my system out of scope?
No. AI systems stay in scope regardless of model origin or delivery mechanism, and lack of access to vendor evidence is treated as a scope limitation, not as proof of conformity.
Which AI systems need an independent audit?
Systems scoring 13 or above (Tier 2 and higher) require an independent audit by a CERT-In empanelled auditing organisation, with frequency and depth increasing at Tier 3 and Tier 4.
How quickly must AI security incidents be reported to CERT-In?
AI incidents that meet CERT-In’s reportable criteria must be reported within six hours, consistent with CERT-In’s April 2022 Directions, which also require 180-day log retention.
Sources
Disclaimer: This article is for general information only and does not constitute legal or compliance advice. It is based on CERT-In’s AI Security Auditing Guidelines, version 1.0, dated 4 November 2026, which may be revised or supplemented by sectoral regulators. Risk scores shown are illustrative. Organizations should consult their legal advisers and a CERT-In empaneled auditing organization to determine how the guidelines apply to their AI systems.
The post CERT-In’s AI Security Auditing Guidelines: Will Your AI System Need an Independent Audit? appeared first on Cyble.