Tool · Free · No sign-up
CERT-In AI audit self-assessment
Describe one AI system, score its risk tier, check it against the nine audit domains in CERT-In's AI Security Auditing Guidelines, and get a gap report with the ISO/IEC 42001 mapping for each domain.
Where it stands
Score the eight factors in step 2 to see the tier the Guidelines put this system in.
How CERT-In sets the tier
CERT-In issued its AI Security Auditing Guidelines, version 1.0, on 4 Nov 2026. They cover AI systems that organisations in India develop, buy, deploy or run, and AI systems that process Indian data or serve users in India. Each system gets its own tier, from Tier 1 (Low) to Tier 4 (Critical), and the tier decides how deep, how often and how independent its audit is.
You score each of the eight factors from 1 to 4 on inherent risk, before any credit for controls. The scores add up to between 8 and 32, and the total sets the tier. The system owner or auditor then looks for characteristics that call for a higher tier whatever the total, such as an AI that can run code, carry out transactions or send messages on its own, and records the reason and who approved it.
The auditor does not rely on the organisation's own score. It scores each system again, and where the two differ, the higher tier sets the audit's scope. The Guidelines do not name the law they are issued under or a date from which they apply.
What each tier needs
Source: CERT-In AI Security Auditing Guidelines v1.0, 4 Nov 2026, Sections 5.4 and 5.5. These are minimums: a sectoral regulator or the auditor can ask for more.
| Tier | Score | Minimum audit | Security testing | Governance |
|---|---|---|---|---|
| Tier 1 (Low)Minimal impact | 8 to 12 | Self-assessment or basic internal review with documented evidence.Section 5.4 | Basic security assessmentSection 5.5 | Designated AI ownerSection 5.5 |
| Tier 2 (Moderate)Limited impact | 13 to 19 | Documented internal audit with evidence of control implementation and effectiveness. Independent audit by CERT-In empanelled auditing organisations at least annually.Section 5.4 | AI threat modelling and API and security testingSection 5.5 | AI governance functionSection 5.5 |
| Tier 3 (High)Significant impact | 20 to 26 | Periodic independent third-party audit by CERT-In empanelled auditing organisations; enhanced audit frequency where material changes, incidents or risk conditions warrant.Section 5.4 | Comprehensive AI security assessment and VAPTSection 5.5 | AI Governance CommitteeSection 5.5 |
| Tier 4 (Critical)Severe or systemic impact | 27 to 32 | Independent audit by a CERT-In empanelled auditing organisation with continuous monitoring.Section 5.4 | Advanced adversarial testing, red-team exercises and continuous monitoringSection 5.5 | Board or senior-management oversight with defined independent assurance and escalationSection 5.5 |
The nine audit domains
Section 8 sets nine domains that every audit covers. At Tier 1 only AI governance and security are mandatory and the rest are recommended. From Tier 2 all nine are mandatory, along with the Section 9 checks for any generative, RAG, agentic, multimodal, multi-agent or autonomous capability the system has.
Source: CERT-In AI Security Auditing Guidelines v1.0, 4 Nov 2026, Section 8 and Table 27. The mappings are the Guidelines' own.
| Domain | What it covers | ISO/IEC 42001 | At Tier 1 |
|---|---|---|---|
| AI governance and accountabilitySection 8.1 | Policies, roles, the AI governance committee, AI impact assessments and the chain of accountability. | Clauses 5 and 6, Annex A.2 and A.3NIST AI RMF: Govern | Mandatory |
| Data lifecycle, quality and privacySection 8.2 | Data authorisation, classification, access, provenance, lineage, integrity, quality, retention, disposal and the line between training and production data. | Annex A.7ISO/IEC 25012, ISO/IEC 5259, NIST AI RMF: Map | Recommended |
| Model risk managementSection 8.3 | Model registry, version control, risk identification, validation, performance monitoring and decommissioning. | Clause 8, Annex A.6NIST AI RMF: Map and Manage, SR 11-7 | Recommended |
| AI ethics, bias and fairnessSection 8.4 | Bias detection, fairness metrics, proxy variable screening, the ethics policy and ongoing fairness monitoring. | None givenIEEE P7003, NIST AI RMF: Measure | Recommended |
| Explainability and transparencySection 8.5 | Interpretability, explainability techniques, decision logging, explanations for users and transparency reporting. | Transparency and information controlsNIST AI RMF: Measure | Recommended |
| Security, adversarial resilience and incident reportingSection 8.6 | Adversarial testing, VAPT, CERT-In incident reporting, model integrity, supply-chain security and forensic readiness. | None givenMITRE ATLAS, OWASP ML and LLM Top 10, NIST AI RMF: Secure and Resilient | Mandatory |
| Continuous monitoring, drift management and validationSection 8.7 | Performance tracking, data and concept drift, re-validation triggers, fairness dashboards and retraining governance. | Clause 9NIST AI RMF: Measure and Manage | Recommended |
| Human oversight and decision accountabilitySection 8.8 | Human-in-the-loop and on-the-loop models, approval gates, manual override, reviewer competence and decision accountability. | Clause 5, Annex A.3EU AI Act human oversight, NIST AI RMF: Govern | Recommended |
| Third-party and AI supply-chain assuranceSection 8.9 | Supplier due diligence, model and component provenance, AIBOM and SBOM, contracts, provider changes, AI-as-a-service monitoring and exit plans. | Annex A.10NIST AI RMF: Govern | Recommended |
When to assess it again
A tier is not permanent. Score each system again at least once a year, before a planned material change goes live, and when a pilot moves into production or a research system starts serving customers. Score it again after an AI-related security incident, a bias event, a regulatory finding or a public complaint that shows a risk nobody assessed, and when a sectoral regulator issues new guidance on tiers.
Moving a system to a lower tier needs a documented reassessment that shows the risk has fallen for good, approved by your risk authority. Size does not lower the bar for Tier 3 or Tier 4: those systems carry the full obligations in an MSME or startup as in a large company.
This page explains the law in plain English. It is not legal advice.