CERT-In’s AI Security Auditing Guidelines: What Enterprises Need to Review

On 4 November 2026, the Indian Computer Emergency Response Team (CERT-In) published its Artificial Intelligence (AI) Security Auditing Guidelines, Version 1.0. The document sets out a risk-based framework for assessing the governance, security, privacy, reliability and auditability of AI systems. It covers systems developed within an organisation as well as AI obtained from third parties, including capabilities accessed through software platforms and APIs.[1]
For businesses, the important questions are which AI systems fall within the framework, how their risks would be classified, what an audit would examine and what evidence should be maintained. The Guidelines do not specify a commencement date or clearly establish that every provision is independently enforceable. Their status must therefore be distinguished from existing CERT-In Directions and applicable sector-specific requirements.
Which AI systems are covered?
The framework addresses AI systems developed, procured, deployed or operated by organisations in India, and systems processing Indian data or providing AI-enabled services to Indian users. It contemplates internally developed models, third-party proprietary models, open-weight models and AI services accessed through APIs. Using a model supplied by a vendor does not, by itself, remove an organisation from the scope described in the Guidelines.
The framework also provides for proportionality. Lower-risk AI systems operated by MSMEs and start-ups may qualify for simplified assessment and documentation, while the Guidelines contemplate fuller assurance for systems classified as High or Critical. They distinguish academic research from systems entering pilots or production, and exclude purely rule-based automation that does not use statistical learning. Businesses should check the applicable definitions and exclusions rather than assume that a small deployment or an outsourced model is outside the framework.
How does the risk-based approach work?
The Guidelines classify AI systems into four tiers, from Low (Tier 1) to Critical (Tier 4), using eight inherent-risk factors scored from one to four. Factors include the seriousness of possible harm, autonomy, sensitivity of the data involved, scale of impact, exposure, reversibility and the ability to assess the system. Importantly, the initial classification is based on inherent risk: the existence of controls does not automatically justify assigning a lower tier. Missing information is not, by itself, a reason to award a low score.
For Tier 1 (Low), the framework contemplates a self-assessment or basic internal review. Tier 2 (Moderate) involves more formal documentation and, under the Guidelines’ audit matrix, at least annual independent audit by a CERT-In-empanelled auditing organisation.
For Tier 3 (High), the framework calls for a more comprehensive risk and impact assessment, independent audit and security testing. Tier 4 (Critical) is subject to the most intensive assurance arrangements, including continuous monitoring. The precise scope and frequency of testing must be determined by reference to the Guidelines’ tier-specific requirements, not merely the labels assigned to the four categories.
Certain characteristics can also trigger a higher classification regardless of the composite score. These include systems with privileged access to production environments and systems that cannot reliably be stopped, rolled back or placed into a safe state. The distinction is particularly relevant to agentic AI applications that can invoke tools or initiate actions without a human approving each step.
What would an AI security audit examine?
The Guidelines organise AI auditing around nine domains: governance and accountability; data lifecycle, quality and privacy; model risk management; ethics, bias and fairness; explainability and transparency; security and resilience against attacks; continuous monitoring and model drift; human oversight; and third-party and AI supply-chain assurance. The framework sets out checks and evidence requirements across these areas, with the depth of assessment linked to the risk tier.
Additional controls address generative AI and more autonomous applications. For an AI assistant using company information or accessing other systems, relevant issues may include prompt injection, unintended disclosure of data, permissions granted to tools, approval gates for consequential actions, audit logs and the ability to intervene. These considerations apply whether the capability is built in-house or introduced through a third-party product or API.
What should businesses review?
An appropriate starting point is an inventory of AI systems being used or tested across the organisation. This should include internally developed applications, vendor products with embedded AI, API-based services and pilots that have moved into business use. For each system, the organisation should record its purpose, owner, users, data accessed, supplier and degree of decision-making autonomy.
The next step is to assess the system against the Guidelines’ risk factors and document the basis for its classification. Organisations should identify any escalation triggers, record existing controls and determine whether the evidence available is sufficient to support the assessment. Higher-risk applications, particularly those affecting customers or regulated functions, may call for more detailed technical and legal review.
Vendor arrangements also merit attention. Businesses should assess the supplier’s security and testing assurances, access to data, use of subcontractors, incident notification commitments, audit rights and arrangements for changes to models or features. A vendor’s assurance report may be relevant evidence, but the business must still understand the risks arising from its own deployment and use of the system.
Finally, organisations should review their governance processes for approving AI deployments, monitoring performance and responding to incidents. The Guidelines’ references to incident reporting and log retention should be read alongside the existing CERT-In Directions and any sectoral requirements; they should not automatically be described as new obligations arising for the first time under this document.
What is the legal status of the Guidelines?
The Guidelines frequently use mandatory language when describing risk assessments, audits and controls. However, unlike CERT-In’s July 2025 Comprehensive Cyber Security Audit Policy Guidelines, this document does not set out an equivalent statement of statutory authority and binding effect, nor does it specify an implementation date. It would therefore be premature to present every tier-specific measure as an immediately enforceable requirement solely on the strength of this document. Existing CERT-In Directions, sectoral regulations and any subsequent adoption or clarification must be considered separately.[2] The framework nevertheless gives businesses a useful basis for evaluating how securely their AI systems are deployed and governed. The immediate practical response is to identify AI systems in use, understand their access and autonomy, assess the risks and review available evidence and controls. Organisations should monitor further clarification from CERT-In and relevant sectoral regulators before treating the framework as a new set of binding compliance deadlines.
AI governance is moving from experimentation to accountability. Organisations that begin building this visibility now will be better positioned as regulatory expectations develop.
Once AI-related requirements and risks have been identified, organisations also need to assign ownership, track applicable obligations, monitor review cycles and maintain evidence of compliance. KomriskAI, our compliance management software, can support this compliance governance layer by helping organisations identify, assign, track and monitor regulatory obligations across their AI and wider business operations.
[1] CERT-In, Artificial Intelligence (AI) Security Auditing Guidelines: Framework for Secure, Ethical and Auditable Artificial Intelligence Systems, Document Identifier “AI Security Auditing Guidelines v1.0”, prepared by CERT-In Sub-group 03 of the Working Group on Indian Standards for Cybersecurity Auditing, dated 4th November 2026. The risk tiering methodology, eight risk factors, composite scoring bands and escalation triggers appear at section 5; audit intensity by tier at section 5.5 and Table 14; organisational applicability at section 4.4; model source coverage at section 4.6; exclusions at section 4.9; and MSME proportionality at section 5.7. The document has been reported as carrying the identifier CISG-2026-04: see https://rmaindia.org/cert-in-releases-ai-security-auditing-guidelines-2026/.
[2] CERT-In, Comprehensive Cyber Security Audit Policy Guidelines, Version 1.0, dated 25th July 2025, section 2 (Authority for Issuance), issued under section 70B of the Information Technology Act, 2000 and rule 9 of the Information Technology (The Indian Computer Emergency Response Team and Manner of Performing Functions & Duties) Rules, 2013. The text states that the guidelines “are binding on all CERT-In empanelled auditing organizations and auditee entities covered under the relevant provisions”. On CERT-In’s powers under section 70B generally, including the directions issued under sub-section (6), see https://www.cert-in.org.in/Directions70B.jsp. On the Reserve Bank’s incident reporting through CERT-In and DAKSH, see the Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, dated 31st July 2026: https://rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=13643.
Author: Dwaipayan Das
Co-Author: Amiya Mukherjee
This content is intended for informational purposes only and does not constitute a legal opinion. Readers are encouraged to seek legal counsel prior to acting upon any of the information provided herein. Despite our efforts to maintain accuracy, we do not make representations, warranties or undertakings regarding the quality, completeness or reliability of the content. This content, including the design, text, graphics, their selection and arrangement, is Copyright 2026, Lexplosion Solutions Private Limited or its licensors. ALL RIGHTS RESERVED, and all moral rights are asserted and reserved.
For any clarifications, please reach out to us at 91-33-40618083 or inquiries@lexplosion.in. Refer to our privacy policy by clicking here.