CERT-In's AI Security Auditing Guidelines (2026): What Organisations Must Know

On 4 November 2026 CERT-In published its Artificial Intelligence (AI) Security Auditing Guidelines, Version 1.0: a 107-page framework for auditing the security, governance and responsible operation of AI systems in India. It runs from a four-tier risk classification and nine core audit domains to dedicated requirements for generative AI, RAG, AI agents and multi-agent systems, AI-specific penetration testing, and how audit findings are rated and closed. If you build, buy or run AI systems in India, or audit them, this is the framework CERT-In has set out for doing it. Here is our section-by-section analysis, with the official PDF to download.

The guidelines were prepared by Sub-group 03 of the Working Group on 'Indian Standards for Cybersecurity Auditing' constituted by CERT-In. They are written for government bodies, regulated entities, private organisations, AI developers and service providers, internal and external auditors, and CERT-In empanelled auditing organisations. Everything below is sourced from the official PDF on cert-in.org.in. The framing is ours, the requirements are CERT-In's, and section numbers refer to the guidelines.

What are CERT-In's AI Security Auditing Guidelines?

CERT-In's AI Security Auditing Guidelines are a national framework for auditing AI systems that are developed, procured, deployed or operated by organisations in India, or that process Indian data or serve Indian users. Every AI system is placed in one of four risk tiers (Low, Moderate, High or Critical) using eight scored risk factors, and the tier sets how deeply, how often and how independently the system must be audited. Audits assess nine core domains, from governance and data to security, monitoring, human oversight and the AI supply chain, plus dedicated requirements for generative AI, RAG, agentic, multimodal, multi-agent and cyber-physical systems. The guidelines also prescribe a six-phase audit methodology, a catalogue of AI-specific security tests, a four-level finding severity scale with remediation timelines, a standard report structure and a five-level maturity model. All of it is mapped to ISO/IEC 42001, the NIST AI RMF, MITRE ATLAS, OWASP guidance and MeitY's India AI Governance Guidelines.

Who and which AI systems do the guidelines cover?

Scope is deliberately wide. The guidelines apply to organisations of every type and size that operate AI systems in India or process Indian citizens' data, with obligations proportionate to the risk tier of each system (Section 4.4):

• MSMEs adopting AI automation, analytics or optimisation tools, with simplified audit pathways for low-risk systems.
• Large corporations and multinationals deploying AI across business lines such as BFSI, healthcare, telecom, manufacturing and retail, with independent third-party audits for high-risk and critical systems.
• Central and state government bodies and PSUs using AI in citizen services, e-governance, law enforcement, defence or public administration.
• Startups and innovation labs developing, piloting or commercialising AI products and services.
• AI service providers and platform operators, Indian and international, offering AI-as-a-Service, AI-integrated SaaS, cloud AI APIs or AI development tools to Indian customers. They are audited both as providers and as third-party vendors to their customers.

Coverage is architecture-neutral (Section 4.5). Predictive, generative, hybrid, embedded, AI-as-a-Service, multimodal, agentic, retrieval-augmented generation (RAG), foundation-model, multi-agent and autonomous or cyber-physical systems are all in scope. So is every model source (Section 4.6): models you build, proprietary models you buy, open-source or open-weight models, and models you only reach through an API. Coverage turns on your ability to identify and manage the risks a model introduces, not on who owns it. The artefacts in scope (Section 4.7) include training, validation and test data, inference data, RAG knowledge sources, synthetic data, model artefacts, prompts and guardrail configurations, embeddings and vector stores, and logs.

How does the four-tier AI risk classification work?

Every AI system is first scored on eight inherent-risk factors, without credit for controls the organisation claims to have (Section 5.3). Each factor is scored from 1 (Low) to 4 (Critical), so the composite runs from 8 to 32, and the composite sets the tier and the minimum audit requirement (Section 5.4).

The tier drives the rest of the obligations (Section 5.5). An AI Risk and Impact Assessment (AIIA) is optional for Tier 1, mandatory in simplified form for Tier 2, and mandatory in comprehensive form for Tiers 3 and 4. Technical testing scales from a basic security assessment at Tier 1, through AI threat modelling and API security testing at Tier 2 and a comprehensive AI security assessment with VAPT at Tier 3, to advanced adversarial testing, red-team exercises and continuous monitoring at Tier 4. Tiers are not permanent. They must be reassessed at least annually, before planned material changes reach production, after incidents, bias events or regulatory findings, and when a system moves from pilot to production (Section 5.6). A downgrade needs a documented reassessment showing a sustained reduction in risk.

What are the nine core audit domains?

Section 8 is the control baseline. Each of the nine domains comes with control requirements, an auditor checklist and tier-specific applicability. Tier 1 audits must cover governance and security at a minimum; Tier 2 to Tier 4 audits must cover all nine, plus the advanced requirements wherever the relevant AI architecture is deployed (Section 7.3).

What do the guidelines require for generative AI, RAG and AI agents?

Section 9 adds dedicated requirements for generative AI, RAG, agentic, multimodal, multi-agent and autonomous or cyber-physical AI. They supplement the nine domains rather than replace them. CERT-In's generative AI threat list (Section 9.2) follows the OWASP Top 10 for LLM applications: prompt injection, sensitive information disclosure, excessive agency, supply chain, data and model poisoning, unbounded consumption, misinformation, hidden context exposure, vector and embedding weaknesses, and improper output handling. Several controls stand out:

• Prompt injection: input sanitisation alone must not be the primary control. Trusted instructions are separated from untrusted content where feasible, backed by least-privilege tool and data access, approval gates for consequential actions, output validation, monitoring and adversarial testing (Section 9.3).
• System prompts: they must not contain credentials or other secrets and must not be the only security boundary for authorisation or policy enforcement. Controls have to keep working even if hidden context is partly disclosed (Section 9.4).
• Hallucination: each generative AI use case needs a documented hallucination risk assessment, grounding such as RAG for factual applications, and risk-based human review of high-impact outputs (Section 9.3).
• Disclosure and synthetic media: users must be told when they are interacting with AI, AI-generated content must be identified in external outputs, synthetic media needs C2PA or equivalent provenance marking, and policy must prohibit deepfakes of real individuals without explicit consent (Section 9.3).
• Copyright: a documented copyright risk assessment for each generative AI deployment, output screening, an IP policy for AI-generated content and vendor indemnification terms (Section 9.3).

For RAG systems (Section 9.6), retrieved content is untrusted input: it must never override higher-priority system instructions or bypass a user's access restrictions. Controls cover knowledge-source provenance, secure ingestion, document- and chunk-level access control, tenant isolation, vector-store security, indirect prompt injection, poisoned or stale content, deletion propagation and retrieval logging.

AI agents get the strictest treatment (Section 9.7). Each agent needs a documented identity, authorised objectives, approved tools, permission boundaries and action limits. It runs under least privilege and must not automatically inherit permissions from users, tools or other agents. Consequential actions go through human approval gates, and the execution chain of tool calls, delegated tasks, approvals and external actions must be logged and protected against tampering. High-risk agents must support emergency interruption, credential revocation, rollback and prevention of uncontrolled automatic restart. Agents that connect to external tool servers, plugins, Model Context Protocol (MCP) services or agent-to-agent channels must work from an approved inventory of permitted connections, with authenticated tool identities and validated tool descriptions. Our agentic AI security testing checklist shows how these controls are tested in practice.

Multi-agent systems (Section 9.9) add unique agent identities, authenticated and integrity-protected messages between agents, delegation limits that stop privileges propagating down agent chains, protection of shared memory against poisoning, controls against recursive delegation and agent loops, and the ability to suspend one agent or the whole workflow. Multimodal systems (Section 9.8) must be tested for hidden instructions in images, audio, video and documents, and for cross-modal prompt injection. Autonomous and cyber-physical AI (Section 9.10) needs defined operating boundaries, sensor-integrity checks, safety interlocks independent of the AI model where practicable, a safe or degraded state, manual takeover, authenticated and reversible updates, and simulation, fault-injection and hardware-in-the-loop testing for applicable Tier 3–4 systems.

What does AI-specific VAPT cover under the guidelines?

Section 10.4 states that standard VAPT methodologies must be supplemented with AI-specific testing, and lists the test categories. The tools it names are illustrative: equivalent tools are acceptable if they give appropriate coverage, evidence quality and reproducibility.

Testing is not one-off. AI-specific security tests must be repeated after material changes to the model, system prompt, RAG corpus, embedding model, tool or plugin set, agent permissions, deployment architecture, major dependencies or the provider's model version (Section 10.4). Each test must be recorded well enough to reproduce: model or provider version, artefact hash, dataset and prompt versions, RAG index version, parameters such as temperature and seed, tool versions, payloads, expected and actual results, and raw evidence (Section 7.5). Tier 3 systems need comprehensive AI VAPT across every applicable category, and Tier 4 adds continuous monitoring, advanced adversarial testing and periodic red-team exercises (Section 10.7).

The rest of Section 10 turns security into day-to-day operations. AI workloads are segmented, container images are hardened, scanned and signed, GPUs are isolated, secrets are centrally managed, and data is protected with AES-256 and TLS 1.2 or higher (Section 10.3). The MLOps/LLMOps pipeline is part of the security boundary: model artefacts are hashed or signed, promotion requires evaluation gates and, where risk warrants, approval independent of whoever built the model, and automated retraining can never push a model to production on its own. The SOC ingests AI logs into the SIEM, runs detection rules for extraction, probing and unusual agent activity, and keeps AI incident playbooks, with annual AI red-team exercises for Tier 4 systems (Section 10.5). Incident response reports reportable AI incidents to CERT-In within 6 hours, quarantines poisoned data, rolls back to a known-good model, and maintains business-continuity plans for Tier 3–4 systems (Section 10.6).

How is an AI security audit planned and run?

Section 7 sets out a six-phase lifecycle aligned with ISO/IEC 42001 Clause 9, ISO 19011, ISACA and IIA guidance: engagement initiation, risk assessment and scoping, detailed audit planning, fieldwork and evidence collection, analysis and finding development, and reporting and follow-up. A few rules will change how organisations prepare:

• Your AI inventory is the starting point. The auditor reviews the complete AI system inventory, and an incomplete or missing inventory is itself a governance non-conformity (Section 7.3).
• A Statement of Applicability is required. It lists applicable controls and external requirements, exclusions with justification, compensating controls and accepted residual risks. A control cannot be marked 'not applicable' just because evidence, technical access or vendor transparency is unavailable; that is a scope limitation (Section 7.3).
• External requirements are mapped in. CERT-In directions, sector rules and contractual security obligations that apply to each AI system are identified with the auditee and mapped to framework controls as audit criteria (Section 7.3).
• Policies are not proof. Each control is assessed for both design and operating effectiveness, and no control can be concluded effective on policy or design documents alone. Interview evidence must be corroborated by at least one other source (Section 7.5).
• Critical issues surface immediately. Active vulnerabilities, ongoing bias in production decisions or regulatory non-compliance found during fieldwork go straight to the audit sponsor and, where required, to CERT-In or the relevant regulator (Section 7.5).
• Limited access is not a pass. Where proprietary or AI-as-a-Service models restrict access, auditors use black-box or API testing, independent assurance reports and the deploying organisation's own controls, and absence of access is never treated as evidence of conformity (Section 7.9).

The guidelines also regulate auditors' own use of AI (Section 7.10). AI tools may support document review, control mapping, log analysis and report drafting, but only with the auditee's written authorisation before its non-public information is processed, without submitting restricted evidence to unapproved public AI services, and with a competent auditor validating every output relied on. AI-generated summaries are working aids, not audit evidence, and material AI use must be disclosed in the audit report.

How are AI audit findings rated, reported and closed?

Section 12 introduces a four-level severity scale, each level with its own remediation expectation:

Each finding records the condition, criteria, cause, effect and recommendation, with a standards mapping to ISO 42001, the NIST AI RMF or MITRE ATLAS, the management response and evidence references (Section 12.2). The report has eight sections, from an executive summary of at most two pages to positive observations, and ends in one of four assurance opinions: Satisfactory, Satisfactory with Reservations, Requires Significant Improvement or Unsatisfactory (Sections 12.3–12.4). The opinion is not a count of findings; materiality, systemic weakness, compensating controls, risk tier and scope limitations all weigh in. Every Critical, High and Moderate finding needs a Corrective Action Plan with a named individual owner, not a team, and closure is verified by checking that the root cause, not just the symptom, has been fixed (Sections 12.5–12.6).

What do contestability and human decision review mean for AI systems?

Section 11 makes human oversight testable. Contestability means an AI decision, recommendation or action can be reviewed, validated, overridden, corrected or escalated when its accuracy, safety or appropriateness is questioned. Organisations must define review triggers such as low confidence, anomalous output, high-impact actions, policy exceptions, security alerts or model disagreement; give reviewers enough context to judge an output; provide escalation routes; and feed repeated overrides back into model governance. Auditors sample AI decisions to confirm required reviews happened, test whether approval gates can be bypassed through alternate interfaces, APIs or workflows, and analyse override rates and reviewer agreement for signs that humans are simply accepting AI outputs. The guidelines are explicit that oversight is not effective just because a manual-review procedure exists: reviewers must be technically capable, sufficiently informed and empowered to challenge or override the AI.

What is the AI governance maturity model?

Section 13 adds a five-level maturity model for self-assessment and improvement planning, informed by CMMI and COBIT and aligned with ISO/IEC 42001:

1. Initial / Ad hoc: no AI governance policy, inventory, risk classification or AI-specific incident response.
2. Developing / Repeatable: a basic policy and inventory, risk classification started for some systems, a CERT-In reporting process in place, and oversight defined for high-impact decisions.
3. Defined / Standardised: all nine domains covered with documented controls, a formal AI Governance Committee, an ISO 42001-aligned management system, and independent validation for Tier 3 and above.
4. Managed / Measured: governance KPIs such as fairness scores, drift rates and incident response times tracked and reported, with continuous monitoring and board-level reporting.
5. Optimising / Leading: continuous improvement, automated compliance verification and contribution to national and international AI governance standards.

Overall maturity is set by the weakest domain: an organisation at Level 4 in eight domains and Level 1 in security is not a Level 4 organisation (Section 13.4). Maturity provides context only and never changes the severity of an audit finding (Section 13.1).

How do the guidelines align with ISO 42001, the NIST AI RMF and India's AI Governance Guidelines?

The framework rests on seven guiding principles: security-by-design; accountability and human oversight; transparency and explainability; fairness and bias management; data security and privacy; auditability and traceability; and resilience and continuous assurance (Section 6.2). They align with the seven 'sutras' of MeitY's India AI Governance Guidelines (2025). In CERT-In's framing, the national guidelines say what India's AI governance should look like, and the audit guidelines say how to verify that organisations are doing it (Section 15).

Controls are mapped to ISO/IEC 42001, ISO/IEC 23894, ISO/IEC 42005, ISO/IEC 27001, the NIST AI RMF and NIST AI 100-2, the EU AI Act, MITRE ATLAS, and OWASP's Machine Learning Top 10, LLM Top 10 and Top 10 for Agentic Applications (Section 14). These references are informative; mandatory requirements enter an audit through the Statement of Applicability. If you already run an ISO 27001 ISMS, the guidelines note that it can be extended to AI-specific controls alongside ISO 42001; see our ISO/IEC 42001 audit page.

Auditors must also identify the CERT-In publications that apply to each AI system (Section 14.4). The guidelines name advisory CIAD-2026-0020 on frontier AI-driven cyber risks; the Blueprint for Reducing Exposure and Defending against AI-Assisted Vulnerabilities Exploitation in Digital Infrastructure; the guidelines on AI-accelerated vulnerability protection and response for OEMs and technology providers; the Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM (Version 2.0); and the Comprehensive Cyber Security Audit Policy Guidelines, which govern how empanelled audits are conducted and reported. For the patching side of the same threat picture, see our explainer on CERT-In's 12-hour patch mandate.

What should organisations do now?

1. Build or complete your AI system inventory: every model, agent, RAG application, AI API and embedded AI feature, with owner, purpose, data, model source and deployment status. An incomplete inventory is a finding in its own right.
2. Score each system on the eight risk factors and record the rationale and evidence. Check the escalation triggers in Sections 5.4 and 9.5, especially for anything that calls tools, executes code, keeps memory or faces the public.
3. Run an AI Risk and Impact Assessment for every Tier 2–4 system before it reaches production, and again after material changes.
4. Start an AIBOM for production AI systems: models and hashes, datasets, prompts, guardrails, embedding models, vector stores, tools and APIs.
5. Check incident readiness: AI scenarios in your playbooks, 6-hour CERT-In reporting for reportable incidents, 180-day log retention with time synchronisation across AI components, and a tested model rollback.
6. Commission AI-specific security testing that covers the Section 10.4 categories relevant to your architecture, and plan to repeat it after material changes.
7. Test human oversight rather than just documenting it: approval gates, overrides, emergency stops, and whether reviewers actually challenge AI outputs.
8. Review AI vendor contracts for security obligations, incident, vulnerability and model-change notification, audit rights, and exit and fallback arrangements.
9. Self-assess maturity for each domain and let the weakest domain set the priorities in your roadmap.

How Macksofy helps

Macksofy is a CERT-In empanelled auditing organisation, the category of auditor the guidelines rely on for independent audits of Tier 2, Tier 3 and Tier 4 AI systems. We can help you apply the framework: building the AI system inventory and validating risk tiers, preparing the Statement of Applicability and AI Risk and Impact Assessment, and testing the Section 10.4 categories that apply to your systems, including prompt injection, RAG pipelines, AI agents and MCP tool use, and model supply-chain risk. See AI / LLM security testing for the testing scope, the CERT-In empanelled audit for empanelled-format engagements, the ISO/IEC 42001 audit for AI management systems, and managed SOC for bringing AI logs and detection rules into security operations. If you are still comparing providers, our guide to AI security assessment companies in India sets out what to ask.