Cert-In issues AI security audit guidelines, sets 4-tier risk framework
Cert-In’s AI Security Auditing Guidelines set a common process for checking whether AI systems are secure. They matter because AI can make decisions, process sensitive information, use tools, and affect many people. The document requires regular security assessments rather than treating AI security as a one-time exercise. The rules cover organisations that have developed or deployed AI in India. They also cover organisations handling Indian data, including foreign companies offering AI services or tools to Indian users. For example, a foreign provider serving Indian users could fall within the guidelines even without being based in India. The risk level determines the audit’s strictness. Low-risk systems may use self-assessment or a basic internal review. Moderate-risk systems need annual independent audits by Cert-In-empanelled organisations. High-risk and critical systems also require independent audits, while critical systems face continuous monitoring. The article does not state when the guidelines apply or which legal provision issued them.
What are Cert-In’s new AI security auditing guidelines, and which organisations must follow them?
Cert-In’s AI Security Auditing Guidelines set a common process for checking whether AI systems are secure. They matter because AI can make decisions, process sensitive information, use tools, and affect many people. The document requires regular security assessments rather than treating AI security as a one-time exercise.
The rules cover organisations that have developed or deployed AI in India. They also cover organisations handling Indian data, including foreign companies offering AI services or tools to Indian users. For example, a foreign provider serving Indian users could fall within the guidelines even without being based in India.
The risk level determines the audit’s strictness. Low-risk systems may use self-assessment or a basic internal review. Moderate-risk systems need annual independent audits by Cert-In-empanelled organisations. High-risk and critical systems also require independent audits, while critical systems face continuous monitoring. The article does not state when the guidelines apply or which legal provision issued them.
How many risk tiers does Cert-In define, and what factors determine whether an AI system is low, moderate, high, or critical risk?
Cert-In places AI systems into four risk tiers: low, moderate, high, and critical. This framework helps match the depth of a security audit to the possible consequences of failure. A system is not judged only by its technical design. Its real-world impact also matters.
The guidelines consider an AI system’s capacity for autonomous decision-making, the sensitivity of the data it handles, and how many people it can affect. They also consider how easily harm can be undone. For example, an AI system making limited, reversible decisions could be lower risk than one acting independently on sensitive data for a large population.
The tier controls the required oversight. Low-risk systems can undergo self-assessment or a basic internal review. Moderate-risk systems require annual independent audits. High-risk and critical systems require independent audits by Cert-In-empanelled auditors, with critical systems receiving continuous monitoring. The article does not provide numerical thresholds for each tier.
How do audit requirements change as an AI system moves from low risk to critical risk?
Audit requirements become more demanding as an AI system moves up the risk scale. Low-risk systems can be checked through self-assessment or a basic internal review. This gives organisations a lighter route where possible harm is more limited or easier to reverse.
Moderate-risk systems must receive an annual independent audit from an organisation empanelled with Cert-In. High-risk systems also require independent audits by empanelled auditors. The guidelines state that high-risk and critical compliance requirements apply uniformly, with no relaxed standards for smaller firms or startups.
Critical systems face the strongest oversight. They need independent audits, continuous monitoring, and annual red-team attack exercises. If auditors identify two or more critical problems, or issue an unsatisfactory opinion, a fresh audit is required within three months. The article does not state a separate penalty for failing to complete that repeat audit, but it says incident reporting and log-retention rules form part of compliance.
What extra checks apply to generative AI, agentic AI, and critical systems?
The guidelines add safeguards for different AI capabilities. Organisations using generative AI must have a policy against creating deepfakes of real people without consent. They must also mark AI-generated media with content-provenance labels, such as C2PA or an equivalent.
Agentic AI receives extra scrutiny because it can act on its own. Its checks must address risks including prompt injection and misuse of tools. In practice, the audit focus follows the system’s ability to receive instructions, make choices, and perform actions through connected tools. The article identifies these risks but does not list every test auditors must perform.
Critical systems face the most demanding additional measure: annual red-team attack exercises. These exercises are part of broader independent auditing and continuous monitoring. If auditors find at least two critical problems, or give an unsatisfactory opinion, the organisation must arrange a fresh audit within three months. The document also makes an AI bill of materials an audit item.
What could happen to organisations that fail to identify serious security problems, given the requirements for repeat audits, incident reporting, and continuous monitoring?
The framework creates several ways for serious problems to trigger further scrutiny. If auditors find two or more critical problems, or issue an unsatisfactory opinion, the organisation must complete a fresh audit within three months. Critical systems must also be monitored continuously, making serious weaknesses harder to leave unexamined.
Incident obligations add another layer. Cert-In’s existing requirements are extended to AI-related incidents: reportable incidents must be flagged within six hours, and logs must be kept for 180 days. Compliance with these requirements becomes part of the AI security audit. A critical AI system suffering a reportable incident would therefore face both incident duties and audit scrutiny.
The article does not specify fines, shutdowns, or another legal penalty for organisations that fail to comply. It also notes that the document does not state when the guidelines apply or under which legal provision they were issued. The clear stated consequences are repeat auditing, continuous monitoring, and the existing reporting and retention obligations.
Why do the guidelines require an AI bill of materials, and what kinds of components must it record?
The guidelines require organisations running AI systems in production to maintain an AI bill of materials. This is a structured record of the components an AI system relies on. It matters because auditors need visibility into the system’s construction and dependencies, rather than examining only its final outputs.
The record must include the models, datasets, prompts, tools, and software used by each system. For example, an organisation’s production system might depend on a particular model, training data, operational prompts, external tools, and supporting software. Recording these elements gives an audit a clearer map of where security problems could arise.
The bill of materials is scaled to the system’s complexity and risk. Cert-In had already issued technical guidance on such records, but the new document makes them an audit item. The article does not prescribe a single format or state how often the record must be updated. Its required purpose is to support security assessment of production AI systems.
What makes an AI system secure enough to trust when it can make decisions, use tools, process sensitive data, or affect large numbers of people?
The guidelines treat trust as a risk-management question. An AI system deserves stronger scrutiny when it can make decisions independently, process sensitive data, affect many people, or cause harm that is difficult to undo. These factors determine its risk tier and therefore the intensity of required auditing.
For example, an autonomous system using sensitive data and affecting a large population would receive more oversight than a limited system whose mistakes are easily reversed. High-risk and critical systems require independent audits by Cert-In-empanelled auditors. Critical systems add continuous monitoring and annual red-team attack exercises, while agentic systems face checks for prompt injection and tool misuse.
Trust also requires operational records and response procedures. Production systems need an AI bill of materials, and reportable AI incidents must be flagged within six hours, with logs retained for 180 days. The article does not define a single point at which an AI system becomes fully trustworthy. Instead, it sets layered checks based on risk.
This brief was written by AI from the original reporting and checked by other models. Names, figures and quotes come from the source; read it for full context.
Read more in the JupiteX app
Pulse is free. New stories every 4 hours, each one broken into the questions that explain it.
Or read more news on the web