How to Scope and Staff an AI Security Audit Under the CERT-In Guidelines
The hard part of an AI security audit is not the testing. It is deciding what is being audited, who is allowed to audit it, and what will be left on the file afterwards. The guidelines issued on November 4, 2026 answer all three, and they answer them differently depending on the tier a system scores.
Step 1: Build the Inventory Before Anything Else
The framework requires an inventory covering all AI systems. Until that exists there is nothing to scope, because the question of what is in scope is answered by the inventory and not by the audit plan.
Two categories are reliably missing from a first attempt. Systems reached through an interface rather than installed, which nobody thinks of as deployed software, and features inside a bought product where the supplier added a model to something the organisation has used for years without calling it AI.
Step 2: Score the System, and Write Down Why
Each system is scored against the risk factors and the composite score places it in a tier. The score is mechanical; what is not mechanical is the judgment behind each factor, and that is what will be disputed.
So record, against each factor, the reason for the number, the person who decided it and the date. A tier assignment with no reasoning behind it is indistinguishable from a tier assignment chosen to reduce the audit obligation, and the second is what an auditor will suspect when the first is all that exists.
Step 3: Read the Tier as an Obligation, Not a Description
From the second tier upwards the system requires independent audit by an empanelled auditing organisation at least annually. The third and fourth tiers require independent audits, and at the fourth tier continuous monitoring is required along with reassessment triggered by a significant change or an incident rather than by the calendar.
The event trigger is the one that breaks an annual compliance rhythm. A model replaced in March reopens the assessment in March, which means the audit calendar has to be capable of being interrupted rather than planned once a year.
Step 4: Fix the Boundary, Including the Parts Nobody Owns
The boundary is set across the audit domains, with the depth of coverage determined by the tier. The useful discipline is to draw it by attack surface rather than by organisational chart.
Threat modelling is to cover data, models, interfaces, prompts, retrieval-augmented components, tools and agents, infrastructure and supply-chain dependencies. Prompts and retrieval components are the surfaces that typically have no owner, because they were configured by whoever built the feature and are not treated as infrastructure by anyone since.
Step 5: Assemble the Bill of Materials Early
A bill of materials for the system has to record the model provider, the version and hash, any base models, and the external interfaces and plugins in use. Supply-chain security scanning extends across third-party model components and libraries, and a change of provider requires revalidation.
This is the item to start on first and the one that takes longest, because the information sits with suppliers who have no contractual obligation to give it unless the agreement already says so. Asking for a version and a hash during an audit is a very different conversation from asking for them during a procurement.
Step 6: Staff the Team to the Tier
At the third and fourth tiers a sole-auditor engagement is not permitted. Every team must include at least one member with demonstrated competence in AI or machine learning and at least one holding a professional audit certification, the document naming the certified information systems auditor, certified internal auditor and lead auditor qualifications as examples.
The pairing is deliberate and it is the requirement most often met on paper only. An auditor who can read a control matrix but not a model card, or a data scientist who can read a model card but has never written a working paper, satisfies one half of the requirement and neither of them satisfies it alone.
Step 7: Separate Validation From Development as the Tier Rises
Validation independence is graduated. At the second tier validation must be documented and independent from day-to-day model operation where practicable. At the third and fourth tiers it must be performed by a function sufficiently independent of the model development team, with independent governance and fairness review at the third tier.
At the fourth tier the requirement hardens into an independent model risk management function, an external model audit and independent data assurance. For most organisations that is a structural change rather than a staffing one, and it is worth identifying before a system is allowed to reach that tier.
Step 8: Keep the Assessment and the Testing in Date
An AI risk and impact assessment is required before deployment and again after material changes, and vulnerability assessment and penetration testing must have been conducted within the past twelve months.
Both are date-sensitive and both are usually discovered to be stale at the worst moment. A register that records the date of the last assessment and the last test against each inventoried system, reviewed at the governance committee, is the cheapest way to avoid that.
Step 9: Write Working Papers That Will Survive Being Read
Where AI assists the audit itself, the working papers must record the tool and provider, the model version, the date and time, the prompts, the configuration, the source evidence identifiers, the outputs, the validation steps taken, any corrections and the reviewer's approval. A competent auditor must validate every AI-assisted finding.
A set of decisions is reserved to people: scope, applicability, severity, risk acceptance, closure, and the assurance opinion itself. None may be delegated solely to AI, and a conclusion may not be expressed without qualification where limitations remain. If reliability or confidentiality is compromised, the affected use is suspended, the evidence preserved, the impact assessed, the engagement parties notified and the affected work performed again.
Common Pitfalls to Avoid
Scoping from the audit plan instead of the inventory: The inventory defines what is in scope, and systems reached through an interface or embedded in a bought product are the ones it misses.
Recording the tier without the reasoning: A score with no recorded basis reads as a score chosen to reduce the obligation.
Planning the audit annually at the top tier: A significant change or an incident reopens the assessment when it happens, not at the next cycle.
Leaving the bill of materials to the audit: Provider, version, hash, base models and plugins come from suppliers, and asking during an audit is far harder than asking during procurement.
Meeting the team requirement on paper: One member who can read a model card and one who can write a working paper are both required, and neither suffices alone.
Letting a tool form the opinion: Scope, severity, risk acceptance and closure, and the assurance opinion, are reserved to a competent auditor.
Key Statutory Provisions
Artificial Intelligence (AI) Security Auditing Guidelines, version 1.0, dated November 4, 2026: Issued by the Indian Computer Emergency Response Team. The requirements used here are the AI system inventory; tier-based minimum audit requirements, including independent audit by an empanelled auditing organisation at least annually from the second tier and continuous monitoring with event-triggered reassessment at the fourth; graduated validation independence, rising to an independent model risk management function and external model audit at the fourth tier; the bar on sole-auditor engagements at the third and fourth tiers and the requirement of both AI competence and an audit certification on every team; threat modelling across the listed attack surfaces; the AI bill of materials and supply-chain scanning, with revalidation on a provider change; an AI risk and impact assessment before deployment and after material change; penetration testing within the past twelve months; and the working paper, human-decision and remediation requirements where AI assists the audit.
Sources and References
Artificial Intelligence (AI) Security Auditing Guidelines, version 1.0, dated November 4, 2026, issued by the Indian Computer Emergency Response Team
Disclaimer: This article is for informational purposes only and does not constitute legal advice. Readers should consult a qualified legal professional for advice specific to their circumstances.
Comments