AI security audits, explained in plain language Beta

Last updated: 5 November 2026. This is a beta: try it out and tell us what you think.

An independent self-assessment aid by AI Tātparya, built on the AI Security Auditing Guidelines v1.0 (4 November 2026) as circulating in the industry, and cross-referenced with ISO/IEC 42001, the NIST AI Risk Management Framework, the EU AI Act and the OWASP guidance for LLM applications. Not an audit, not legal advice, and not an official publication of CERT-In or any regulator. Always check the original documents.

More organisations in India now use AI to answer customers, review documents or help make decisions. A new framework, AI Security Auditing Guidelines v1.0 (4 November 2026), is circulating in the industry on how such systems should be audited. It is long (107 pages). We read it, cross-referenced it with international frameworks, and wrote this guide to give you the shape of it in a few minutes, plus a free check that tells you roughly where one of your AI systems would sit.

Take the free 2-minute check

Step 1: every AI system gets a risk tier

The document scores each AI system on eight things: how bad a wrong answer could be, how much the AI can do on its own, how sensitive the data is, how widely it is used, how reversible mistakes are, how critical its job is, how exposed it is to attackers, and how hard it is to understand. The total decides the tier. The higher the tier, the deeper and more independent the audit.

Tier 1 (Low) score 8 to 12
Limited security, safety, operational or data risk. Outputs mainly advise or assist, with limited autonomy and no material effect on critical processes.
Tier 2 (Moderate) score 13 to 19
The AI influences business processes, services or user interactions, with defined human oversight. A failure or compromise should be recoverable.
Tier 3 (High) score 20 to 26
The AI makes or materially influences consequential decisions or core operations. Failure, bias or manipulation could have significant financial, safety, operational or data-security impact.
Tier 4 (Critical) score 27 to 32
The AI operates in critical infrastructure, national-security or safety-critical settings where failure or uncontrolled action could cause systemic or irreversible harm.

Step 2: nine areas are checked

1. AI Governance and Accountability. Who is responsible for the AI, and what rules govern how it is used.
2. Data Lifecycle, Quality and Privacy. Where the data comes from, how good and how private it is, and when it is deleted.
3. Model Risk Management. How you check that the AI is accurate and safe before and after you rely on it.
4. AI Ethics, Bias and Fairness. Whether the AI treats people fairly and how you would find out if it did not.
5. Explainability and Transparency. Whether people can understand why the AI answered as it did.
6. Security, Adversarial Resilience and Incident Reporting. How the AI is protected from attack and misuse, and how incidents are handled and reported.
7. Continuous Monitoring, Drift Management and Validation. How you notice when the AI starts getting worse.
8. Human Oversight and Decision Accountability. Where a person can review, stop or overrule the AI.
9. Third-Party and AI Supply-Chain Assurance. How you check the vendors, models and tools your AI depends on.

Systems built on generative AI, document-based chatbots (RAG) or AI agents carry extra requirements, such as protection against prompt injection, unsafe use of tools and leaking sensitive information.

Two example controls, in plain words

AI Threat Modelling

Security, Adversarial Resilience and Incident Reporting, page 55 of the guidelines

What the document asks: A structured threat model should cover the attack surfaces across data, models, APIs, prompts, document-retrieval parts, tools and agents, infrastructure and supply chain.

In plain words: A written list of the ways someone could attack or misuse your AI, and what stops each one.

Example: A chatbot that answers from documents can be tricked by instructions hidden inside a document. A good threat model lists that, and the fix: treat document text as untrusted data and give the model no tools to act with.

What an auditor looks for: The threat model document, its date, and who reviewed it.

Roles and Responsibilities

AI Governance and Accountability, page 47 of the guidelines

What the document asks: AI lifecycle roles (such as model owner, developer, reviewer, business owner, risk officer, data protection officer and security head) should be defined and documented, with a responsibility chart kept up to date.

In plain words: Everyone knows who is in charge of the AI system and who decides when something goes wrong.

Example: A one-page table: who owns the AI, who reviews its answers, who handles a security incident, who answers a customer complaint. In a very small company one person can hold several roles, as long as it is written down.

What an auditor looks for: The roles table, and proof that it is reviewed from time to time.

What subscribers will get

In development: we are building these first for subscribers, and we will say here when each one is ready.

The full list of controls that apply to your system, as a draft Statement of Applicability
Each control explained in plain words, with an example and what an auditor looks for
A place to record Yes, Partly, No or Not applicable, with notes
A gap list, a maturity level and a prioritised plan
Exports to Word and Excel
A view for auditors: evidence requests and a findings register

Create a free account to see the plans.

This is a beta: tell us what you would like

We are building this with the people who use it. Ask for anything: more controls, other standards, a different report, a clearer explanation. Every idea is read by a person.

This guide is a plain-language aid for self-assessment. It is not an audit, not legal advice and not an official publication. Always check the original document. AI Tātparya is run by Sri Sakhi Enterprises.