CERT-In SAMVAAD 2026: what it signals for audit scope

Two distinct things travel under this name, and a scope document should say which it means before anyone prices it. The first is adversarial testing of an AI system: prompt injection delivered through content the system retrieves rather than content the user types, extraction of system instructions or training data, jailbreaks that defeat a safety layer, abuse of tool-calling and agentic permissions, and the classic failure where a model holding database credentials becomes a query interface nobody authorised. The second is the use of AI inside conventional testing — generating payloads, triaging findings, expanding coverage — which is a statement about the auditor’s tooling rather than about your system.

SAMVAAD 2026 named AI-driven red teaming methodologies as a subject area, and named AI-driven cyber risks including emerging frontier AI models with advanced cyber capabilities as another. Neither is hypothetical for an Indian organisation. Under the Directions of 28 April 2022, attacks or malicious or suspicious activities affecting systems, servers, software or applications related to artificial intelligence and machine learning are already a mandatorily reportable incident class — item xx of Annexure I — with the same six-hour window as every other listed type. The obligation to report exists whether or not your audit scope reached the component.

What belongs in a scope document: the model or models in use and where they are hosted. The system prompt and whether it is treated as a secret. Every source of untrusted content the model can read, which is usually a longer list than the team expects. The tools the model can call and the permissions each carries. The identity the system acts under when it calls them. Rate limits and cost controls. And what is logged about model inputs and outputs, given that those logs will contain whatever a user pasted in. What goes wrong: an engagement scoped as a web application test that treats the chat interface as one more form field, and returns a clean report about a system whose most consequential trust boundary was never examined.

An application test reaches the application. Most serious cloud findings are not in the application. They are in the control plane: over-permissive identity and access management roles, trust policies that let one account assume roles in another, storage exposed through a policy rather than a port, secrets in build configuration, logging disabled in the one account that mattered, and a deployment pipeline that can reach production from a repository anyone can open a pull request against.

Auditing cloud systems was named explicitly at SAMVAAD 2026, and §13.1.1 of the 2025 audit policy guidelines puts cloud inside the audit scope in its own right, alongside databases, hosting infrastructure and code review. It follows that a cloud line item needs its own access requirements in the scope document — read access to the cloud accounts and the identity configuration, not just a URL and a test user. An auditor given only the application will report only on the application, and will be right to.

What belongs in a scope document: the account or subscription inventory and which are in scope. The identity model, including federation, break-glass accounts and any long-lived keys. Network boundaries and what is genuinely public. Storage and database exposure. Logging and its retention, which CERT-In separately requires to run for a rolling 180 days within Indian jurisdiction under the 2022 Directions. The CI/CD pipeline and what it is permitted to deploy where. And the shared-responsibility line, stated explicitly, so that neither party assumes the other tested the boundary.

The surface with no user interface is the one that gets missed, because discovery for a web application test starts from a browser and machine-to-machine traffic never appears in one. Internal APIs exposed through a gateway that was supposed to be private. Versioned endpoints kept alive for one legacy client and patched on a different schedule from everything else. Webhook receivers that trust anything with the right shape. Object-level authorisation that the front end enforces and the API does not.

An auditor cannot test what they were not told exists, which makes the API inventory an auditee deliverable rather than an auditor discovery task. §13.1.1 of the 2025 audit policy guidelines names APIs as a scope item and says the scope should be derived from the consolidated and updated asset inventory, vetted by the internal audit team in consultation with the CISO — which is the same point stated as a requirement. An incomplete inventory is a common reason a clean report describes a system that was never fully examined.

What belongs in a scope document: the endpoint inventory with versions, including deprecated versions still serving traffic. The authentication and authorisation model for each, and specifically whether object-level checks live server-side. Machine-to-machine credentials and their rotation. Webhook receivers and how their callers are authenticated. Rate limiting. And the internal APIs, which are the ones most likely to be omitted on the assumption that the network protects them.

Operational technology and IoT both break assumptions an IT audit runs on: devices that cannot be patched on your schedule, protocols with no authentication, vendors whose support contract forbids the change you need, and testing constraints that are safety constraints rather than preferences. That last point is why the published rules of engagement matter here more than anywhere else — auditors are to refrain from distributed denial of service testing over the internet and from any form of flood testing, and from testing or exploiting high-risk vulnerabilities that may put lives at immediate risk, and §15.2.2(iv) of the 2025 guidelines says that in critical environments where availability is a top priority, testing should be conducted in a passive manner to avoid downtime or service disruption.

The reporting position is already settled even where audit practice is not. Attacks on critical infrastructure, SCADA and operational technology systems, and attacks on IoT devices and their associated systems, networks, software and servers, are separately listed reportable incident classes under the 2022 Directions.

The bill-of-materials work sits underneath all of it. Software, cryptographic, quantum and hardware inventories are what turn “are we affected” from a week of meetings into a query — and they are what makes a post-quantum migration plannable at all, since you cannot migrate cryptography you cannot enumerate. Organisations that can answer “what is in this system, at what version, with what cryptography, on what hardware” will pass the audits of the next few years faster than organisations that treat the question as a project.