CERT-In AI Security Auditing Guidelines: prepare evidence for the deployed system

CERT-In published its Artificial Intelligence Security Auditing Guidelines v1.0 on 4 November 2026. The framework covers AI systems across their lifecycle, including third-party models and services. For enterprise security teams, the practical starting point is the system deployed around the model.

What the framework asks auditors to examine

The document sets out risk-based audit expectations. Its scoping methodology calls for mapping external requirements and distinguishing mandatory from informative criteria. The generative AI checklist says system instructions should not be the sole boundary for authorisation. Its agentic AI section addresses identities, tool permissions, consequential-action approvals and reconstructable execution logs.

Source: CERT-In, AI Security Auditing Guidelines v1.0, sections 4, 7.3, 9.4 and 9.7, available from CERT-In's Security Guidelines listing, document CISG-2026-04.

Those framework expectations should be assessed alongside the laws, sector directions and contracts applicable to the organisation. Do not infer a universal implementation deadline from the publication date.

Start with a workflow someone can explain

Our recommendation is to select a consequential AI workflow and draw its route through the business. A useful example is an assistant that reads a support request and prepares an account change. Write down where the request arrives, which records the assistant reads, which identity it uses and where a proposed change becomes an executed action.

Bring the product owner, platform engineer and security lead into that discussion together. Ask each person to describe the approval boundary. If their answers differ, resolve that difference before selecting test cases.

Record the deployed configuration rather than relying on a product demonstration. Keep a dated copy of the relevant permission settings with the workflow diagram. That gives the assessment an identifiable subject and makes later changes easier to evaluate.

Test what the account can actually do

For that example workflow, we recommend testing whether a request can influence which account is changed, whether approval refers to the exact proposed change and what happens when the user cancels.

Use controlled test data and an agreed environment. Define the permitted actions and stop conditions before testing. Record both the expected result and what happened. A screenshot of an approval button is less useful than evidence showing that the execution service refused an unapproved change.

These are suggested preparation exercises, not a substitute for an audit programme tailored to the organisation.

Prepare a record that survives handover

Build an evidence pack around the workflow diagram, dated configuration, test results and open findings. Give each finding an owner and a clear retest condition. Ask a colleague who did not participate to reconstruct the example action from that pack.

If the evidence does not explain which identity acted or which change was approved, make the gap explicit. Do not turn missing supplier information into an assumption that the control passed.

The immediate management decision is straightforward: choose the first workflow, assign its owner and agree the evidence needed to assess it. That produces a concrete starting point for audit scoping without promising a compliance conclusion before the system has been examined.