What a Cloud Security Audit Covers in India
A cloud security audit is a configuration and posture review of a tenancy you control, read against a named control set. It examines identity and privilege, network exposure, data protection and key management, and logging coverage — across every account and every region, not just the one the application runs in. It is not a penetration test, and it stops at a line the provider draws.
CERT-In lists this as its own class of engagement. Cloud Security Testing is item (xviii) of the twenty-six in §6 of the Comprehensive Cyber Security Audit Policy Guidelines (version 1.0, 25 July 2025), and §13.1.1(a) puts “cloud architecture” inside the audit scope in its own right. The benchmark the guidelines name for it is the CSA Cloud Controls Matrix — not the one we most often see cited.
Plain-English explainer · CERT-In Comprehensive Cyber Security Audit Policy Guidelines v1.0 (25 July 2025) · CERT-In Directions of 28 April 2022 · GIGW 3.0 manual · Every clause locator and URL checked 22 September 2026
What is a cloud security audit? A posture review, not an attack
A cloud security audit is a systematic review of how a cloud environment is configured and governed, conducted with read access rather than with exploits, and measured against a named control set. It covers five things: configuration and posture against a benchmark, identity and privilege, network exposure and segmentation, data protection and key management, and logging and detection coverage. Its output is a coverage statement with control results attached — which accounts, which regions, which controls, which failed, and what could not be reached.
In India the activity has a name and a place. CERT-In, the Indian Computer Emergency Response Team, lists Cloud Security Testing as item (xviii) of the twenty-six classes of engagement in §6 of its Comprehensive Cyber Security Audit Policy Guidelines, version 1.0, dated 25 July 2025, and defines it there as “evaluating and assessing the security measures, configurations, and vulnerabilities of cloud-based systems, applications, and infrastructures”. §13.1.1(a) of the same document requires the scope of audits to include the entire cyber infrastructure, naming “cloud architecture” expressly alongside applications, network infrastructure, operational technology, APIs, databases and hosting infrastructure. And §8(ii) names the benchmark: the CSA Cloud Controls Matrix, “for Cloud Security”.
Two facts about that instrument set the shape of everything below. The first is that CERT-In treats cloud as a distinct engagement class rather than as a variant of application testing, which means an engagement scoped as a web application test with the word cloud in the preamble is not the thing (xviii) describes. The second is a limit worth stating plainly: the word “cloud” appears exactly seven times in the sixty-nine pages of the guidelines, in four places — the definition at §6(xviii), the framework list at §8(ii), the scope clause at §13.1.1(a), and the contract clause at §13.1.7(i)(a) which repeats the framework list. The method, so you can repeat it: seven occurrences of the string “cloud”, case-insensitive, in a text extraction of version 1.0 of the published PDF as downloaded and counted on 22 September 2026. There is no cloud chapter. Anybody who tells you CERT-In has detailed cloud audit rules has not counted.
The four things people most often get wrong about a cloud audit
Each one is addressed in full further down, with the clause behind it.
It is not a penetration test, and buying one when you needed the other is expensive.
A penetration test establishes consequence on the paths a tester walked. A cloud audit establishes coverage across the estate — including the parts of it no attacker has reached yet, which is the population you actually want enumerated. The two answer different questions and both are legitimate purchases. The failure is signing for one and reading the result as the other.
Your auditor cannot test the provider, and no amount of scope will change that.
§13.1.5 of the 2025 guidelines allocates audit responsibility for infrastructure you do not own and operate to the organisation that does, for a reason the clause itself gives: the content owner “does not have access to or control over these assets”. The gap is filled by the provider’s own assurance reporting, and that filling is partial in ways set out below.
The benchmark CERT-In names for cloud is the CSA Cloud Controls Matrix, not CIS.
CIS Benchmarks are named by GIGW’s cybersecurity chapter preamble, for government websites and apps, alongside ISO 27001, OWASP ASVS and the OWASP Top 10. They are not named anywhere in CERT-In’s audit policy guidelines. Use CIS by all means — cite it to the instrument that actually names it.
Closure looks different when the fix is a policy change rather than a patch.
There is no version number to compare and no hash to re-compute. Closure evidence for a cloud finding is the changed configuration, read back through the API by a party that did not make the change, plus the guardrail that stops it recurring — and §16.3(iv) puts the verification with the auditing organisation, not with the team that did the work.
Key Takeaways
- A cloud security audit is a configuration and posture review conducted with read access against a named control set — configuration against a benchmark, identity and privilege, network exposure, data protection and key management, and logging and detection coverage.
- CERT-In treats it as its own class of engagement. Cloud Security Testing is §6(xviii) of the Comprehensive Cyber Security Audit Policy Guidelines (v1.0, 25 July 2025), defined as “evaluating and assessing the security measures, configurations, and vulnerabilities of cloud-based systems, applications, and infrastructures”. Unlike vulnerability assessment and penetration testing, it is defined only once — it is not repeated in §5 Definitions.
- The benchmark the guidelines name is the CSA Cloud Controls Matrix, at §8(ii) and again as a contract term at §13.1.7(i)(a). CIS Benchmarks are named by GIGW’s chapter 5.3 preamble, not by CERT-In’s audit policy guidelines. Cite each to the instrument that actually names it.
- The audit stops at the provider. §13.1.5 allocates responsibility for auditing infrastructure to the organisation that owns and operates it, because the content owner “does not have access to or control over these assets”. Provider assurance reports fill part of that gap and leave the complementary controls with you.
- Read-only assessment access is an approval step with its own risk. §15.1.2 requires temporary access only, revoked immediately on completion. §9.6(i) makes providing access one of the auditee-side duties that must not be delegated. And a cloud “read” role frequently includes reading secrets, key metadata and object data.
- A cloud audit carries the 2022 Directions with it. §15.2.1(iv) requires verification of compliance with the Directions of 28 April 2022 in every audit assignment — which puts time synchronisation, the 180-day rolling log obligation and the point-of-contact designation inside a cloud engagement whether or not anyone scoped them.
- Multi-account scoping is where coverage is lost. §13.1.1(c) requires the scope to be derived from the consolidated and updated asset inventory. §16.1(iii) requires every in-scope asset to be named in the report. §10.1(ii) requires inaccessible in-scope assets to be named with reasons and brought to CERT-In’s notice.
- Closure is allocated by clause, not by convention. §16.3(iv) puts verification of closure with the auditing organisation, and §9.3(iii) leaves the fix itself with you. §9.2 requires any decision to accept rather than fix to be authorised by the head of the auditee organisation, and is not scoped by severity.
- We deliver CERT-In audits, end to end, with our CERT-In empanelled partners.
What a cloud security audit actually covers
What is included in a cloud security audit?
§6(xviii) gives the activity three nouns — measures, configurations, vulnerabilities — and stops. Below is the operational version: five workstreams, what each one examines, what a finding from it looks like when it is written properly, what the evidence behind it is, and what a penetration test of the same estate would not have reached. The last row is the one to read if somebody has told you the two engagements overlap.
1. Configuration and posture, against a named benchmark
| What is examined | Every service in the tenancy that holds, moves or controls something, read against a control set you named before the work started: storage exposure, database and cache reachability, snapshot and image sharing, default-VPC and default-security-group use, instance metadata service version, public IP assignment defaults, serverless function permissions, container registry visibility, drift between the deployed state and the infrastructure-as-code that is supposed to produce it. |
| What a finding looks like | A control objective, an account, a region, a resource identifier, the current value, the expected value, and what becomes reachable while the gap is open. Not “S3 misconfiguration” — “this bucket, in this account, in this region, with this policy, serving these objects”. |
| What the evidence is | The API response or exported configuration that shows the setting, timestamped, with the identity that read it. The benchmark row it fails. And the ticket that changes it. Screenshots are corroboration, not evidence — a console screenshot cannot be re-run six weeks later against the same account. |
| What a penetration test would not reach | Almost all of it. A penetration test finds what is exploitable from where the tester stands. A posture review finds what is wrong whether or not anybody has yet walked to it — including the things that are only reachable once an attacker has a foothold, which is the population a test by definition has not reached yet. |
2. Identity and privilege
| What is examined | Who and what can do what: human principals, federation and directory integration, break-glass accounts, service principals and workload identities, long-lived access keys and their age, role trust policies and who may assume them, permission boundaries, wildcard actions and wildcard resources, privilege-escalation paths that exist inside the policy graph rather than inside any application, and cross-account trust to tenancies nobody on the call can name. |
| What a finding looks like | A path, written as a path. “This build role in the deployment account may assume this role in production. That role carries a wildcard action on the key management service. Therefore anybody who can merge to this branch can read this data.” The individual permissions are all intentional. The path is not. |
| What the evidence is | The policy documents themselves, the trust relationships, the last-used timestamps, and a written statement of which paths were enumerated and which were not. Access analysis is enumerable, which means coverage is claimable — unusually for security work, you can say what you looked at. |
| What a penetration test would not reach | The graph. A tester with one set of credentials walks the paths available from that principal. The audit enumerates the paths available from every principal, including the ones nobody has used for eleven months and the ones that only open during a deployment. |
3. Network exposure and segmentation
| What is examined | What is reachable from the internet and what is reachable from everywhere else: security groups and network ACLs, load balancer listeners and certificates, public endpoints on managed services, private connectivity and service endpoints, peering and transit routing, egress paths, and whether the segmentation drawn on the architecture diagram exists in the route tables. |
| What a finding looks like | An exposure with a blast radius attached. A management port open to the world is a finding. A management port open to the world on an instance whose role can read the production database is a different finding with the same title. |
| What the evidence is | Exported rule sets and route tables, reachability analysis output where the provider offers it, and the diagram the customer believes is true annotated with where it is not. The gap between the two documents is frequently the most useful artefact the engagement produces. |
| What a penetration test would not reach | The inside. External testing establishes the perimeter, but it says nothing about east-west reachability, and east-west reachability is what decides whether one compromised workload is an incident or an outage. |
4. Data protection and key management
| What is examined | Where the data is, which region it is in, whether encryption at rest is on and with whose key, who may use and who may administer each key, key rotation and deletion protection, backup and snapshot encryption and sharing, public snapshot exposure, transport security policy on every endpoint, and whether a copy of production sits in a development account with weaker controls and a smaller audience of people who remember it exists. |
| What a finding looks like | Usually a key policy rather than an absent control. Encryption is almost always on. The question is who is allowed to use the key, because a principal that may call decrypt does not need to break the encryption. |
| What the evidence is | Key policies, grants, rotation configuration, the resource inventory by region, and the storage-and-residency statement the audit report will carry. This is also where the CERT-In log-residency question lands, dealt with in its own section below. |
| What a penetration test would not reach | The key policy. A test demonstrates that data could be read through a path it found. The audit establishes who is permitted to read it through paths nobody has tried. |
5. Logging, monitoring and detection coverage
| What is examined | Whether the control-plane audit trail is on in every account and every region, whether it is centralised into an account the rest of the estate cannot write to, retention against your own obligations, integrity protection on the log store, resource-level and data-plane logging where it is available, whether alerts exist for the events that matter, and whether anybody has ever tested that an alert reaches a human. |
| What a finding looks like | Coverage gaps, stated as gaps. “Trail enabled in twelve of nineteen accounts, absent in the two sandbox accounts and the five accounts inherited in the 2025 reorganisation. Retention set to ninety days against a stated obligation of one hundred and eighty.” |
| What the evidence is | Trail configuration per account and region, the retention setting, the destination bucket policy, and a dated extract proving events were being written during the audit window rather than switched on for it. |
| What a penetration test would not reach | Nothing, and everything. A test can tell you whether it was detected, which is a genuinely useful signal about one attack path on one day. Only the review can tell you whether the coverage exists across nineteen accounts, and coverage is what you are actually buying. |
Two adjacent surfaces belong in the same purchase order and almost never arrive in it. The first is the deployment pipeline, which is a production system holding long-lived credentials and the right to change everything above — §8(ii) names the OWASP DevSecOps Maturity Model for assessing continuous integration and deployment pipeline security, and a cloud scope that stops at the running infrastructure leaves the thing that produces it untested. The second is the API tier, which in a cloud-native estate is most of the application: API security testing takes that one on its own. If you are still working out what the boundary between the two engagements should be, start with what cloud security is and then read VAPT scoping for how §13.1.1 turns into a statement of work.
What the tool does, and what a person has to do
Can we just run a posture tool ourselves instead of buying a cloud audit?
You can, and you should, and it will not produce a cloud audit. This section is here because a posture review is overwhelmingly tool-collected and the instrument has something pointed to say about that. §8(i) of the audit policy guidelines: “Solely tools-based testing should be discouraged as tool-based audits may focus primarily on automated processes and may overlook non-automated or manual components of the IT infrastructure. This limitation can result in an incomplete view of the overall security.” A page that recommends a benchmark sweep and never reconciles it with that clause is ducking the sharpest question its own product raises.
The reconciliation is a split rather than an argument. Collection is automated, nearly complete and cheap — and it is the part a tool does better than a person, because it does not get bored at account nine. Analysis is manual, and it is the expensive half. Below is the split workstream by workstream, so you can read a proposal instead of comparing two totals.
| What the tooling collects | What a person still has to do | |
|---|---|---|
| Configuration and posture against the benchmark | Almost entirely. Every setting on every resource in every account and region is an API call, and a platform makes those calls faster and more completely than a person ever will. Coverage here is a machine’s strength: it does not get bored at account nine. | Deciding which control objectives apply to this estate, at which version of the framework. Judging the exceptions — the bucket that is public because it serves a website, the security group that is open because it fronts a load balancer. And the cluster analysis: eight hundred failing rows produced by six decisions is a report about six things, and no tool has ever drawn that boundary correctly on its own. |
| Identity and privilege | The raw material: principals, policies, trust relationships, last-used timestamps, permission boundaries. Some platforms will also compute reachability, which is genuinely useful and genuinely partial. | The graph. A tool lists over-permissive policies. A person finds the path from a build role, through an assume-role hop nobody remembers authorising, to a production key. Every permission on that path was granted for a reason and is individually defensible. The composition is the finding, and a composition is an argument rather than a row. |
| Network exposure and segmentation | Rule sets, route tables, listener configuration, and reachability output where the provider offers it. | Reconciling that against the architecture diagram the organisation believes is true, and attaching a blast radius to each exposure. A management port open to the world is a row. A management port open to the world on an instance whose role can read the production database is a finding, and the difference is work. |
| Data protection and key management | Encryption settings, key inventory, rotation configuration, snapshot attributes, resource inventory by region. | Reading the key policies. Encryption is almost always on. The question is who may call decrypt, and that answer lives in the composition of a key policy, an identity policy and a grant. It is the most consistently manual reading in a cloud audit. |
| Logging, monitoring and detection coverage | Trail configuration, retention values, destination policies, per account and per region. | Turning that into a coverage statement, and writing the sentence about what could not be reached. §10.1(ii) requires inaccessible in-scope assets to be named with reasons. No tool writes that paragraph, and it is the paragraph a customer’s reviewer reads first. |
The arithmetic that tells you which half you are buying
§13.2.2(ii) requires the test plan to include both calendar time and man-hours, which gives you a number to divide. Take the quoted man-hours. Divide by accounts multiplied by enabled regions — not by accounts, because resources exist per region. Subtract what you think the sweep itself takes, which in a well-run engagement is a small and shrinking share. What is left is the analysis budget: the identity graph, the segmentation reconciliation, the blast radius attached to each exposure, the cluster work that turns hundreds of failing rows into a handful of causes, and the paragraph about what could not be reached. When the remainder is close to zero, you are buying an export with a cover page, and §8(i) is the clause that describes what is wrong with it.
Running the tool yourself is still worth doing, and it changes the engagement for the better: it removes the findings nobody needed to pay an auditor to notice, and it means the assessor arrives at a baseline rather than at a backlog. What it cannot give you is the independence §7 is about, the coverage statement §16.1(iii) and §10.1(ii) require, or a report somebody else will accept.
How a cloud audit differs from a penetration test
Is a cloud security audit the same as cloud penetration testing?
No, and CERT-In keeps them apart in its own vocabulary: Cloud Security Testing is class (xviii) of §6, Penetration Testing is class (iv), and Vulnerability Assessments is class (iii). One difference in the drafting is worth noticing before the table. The definitions of vulnerability assessment, penetration testing and red team assessment each appear twice in the instrument — once in §5 Definitions and once, word for word, in §6. Cloud Security Testing appears once, in §6 only. It has a class and a one-line definition, and no more machinery than that, which is exactly why the scope of work has to do the work the instrument does not.
| Cloud security audit — §6(xviii) | Penetration test — §5(xxii), §6(iv) | |
|---|---|---|
| What CERT-In calls it | Cloud Security Testing, §6(xviii): “Evaluating and assessing the security measures, configurations, and vulnerabilities of cloud-based systems, applications, and infrastructures”. | Penetration Testing, §5(xxii) and §6(iv): “a security testing methodology in which individual components or the application as a whole are actively tested to identify and exploit potential vulnerabilities”. |
| The unit of work | A control objective checked against a resource. The estate is enumerable, so the work is countable and so is the coverage. | An attack path pushed until it gives or does not. The estate is not enumerated. The tester chooses where to spend the hours. |
| How quality is measured | Coverage. Which accounts, which regions, which services, which benchmark rows, and which of them could not be reached and why. | Consequence. What was reached, from where, with what privilege, and what became available once it was reached. |
| What it needs from you | Read access at the organisation level, a region list, and an account list you are prepared to swear is complete. §15.1.2 governs the credentials. | A target, a window, written authorisation per class of test under §13.2.2(v) and §15.2.2(ii), and — in cloud — a look at the provider’s own published customer-testing policy. |
| What it cannot tell you | Whether any of it is exploitable in practice, or whether your detection works. A posture review reports a state, not an outcome. | What was examined and not found wanting. Without an enumerated estate behind it, a test has no denominator. |
| Where it stops | At the boundary of what your credentials can read, which in a public cloud is the customer side of the shared-responsibility line and nothing beyond it. | At the same boundary, plus whatever the provider’s terms forbid. The line is the same line. Only the reason for stopping differs. |
The practical answer for most estates is both, scoped as two things and priced as two things, with the audit first. A posture review produces the enumerated estate a tester should start from, and §13.2.2(ii) gives you the arithmetic to check that each half was really bought: the test plan “must include both calendar time and man-hours”. Man-hours divided by accounts, regions and surfaces is what each one is actually getting. VAPT vs penetration testing vs red teaming sets out the three definitions side by side, and what VAPT actually is covers the breadth-and-depth distinction this table is an instance of.
Is any of this actually mandatory
Is a cloud security audit mandatory in India, and does it have to be a CERT-In empanelled auditor?
It depends on what sits behind the engagement, and the honest answer has five parts. This is the second question every Indian buyer asks and it is worth answering before the benchmark argument rather than after it.
If it is a Government website, portal or application going to production, there is a named certificate and four permitted issuers.
GIGW 3.0 statement 5.3.1 requires that it “have been Security Audited and an Audit Clearance certificate has been issued by NIC/ STQC/ STQC empanelled laboratory/CERT-In empanelled laboratory before hosting in production environment”. Four bodies, and a CERT-In empanelled laboratory is one of them. Note what that certificate is about: the application being hosted, not the cloud tenancy underneath it.
If it is a commercial engagement with no Government nexus, no instrument read for this page imposes empanelment as a precondition.
That is a statement about what we checked, not a clearance. Your sector regulator or your customer contract may impose one, and §12.1(i) shows the mechanism: CERT-In’s published snapshot information “should be utilized by the organizations or sectoral regulators to identify and select the auditing organizations”. §2 of the guidelines declares them binding on auditee entities “covered under the relevant provisions” without enumerating those provisions. Check the requirement behind your own engagement rather than assuming there is none.
The frequency expectation exists whether or not anybody is compelling you.
§13.1.2(i) says the cyber security audit “should be conducted at least once in a year” and adds that sectoral regulators may increase that frequency based on the size of the organisation, the criticality of the assets and the complexity of the adoption of digital infrastructure. §13.1.2(ii) treats the stated frequency as a minimum, §13.1.2(iv) requires an audit after every major change, and §6 states the general expectation in its own words: auditee organisations “are expected to ensure a comprehensive audit covering all aspects of their Information and Communication Technology (ICT) systems at least once a year”.
Whoever you appoint, the 2022 Directions come with the engagement.
§15.2.1(iv) requires verification of compliance with the CERT-In Directions of 28 April 2022 in every audit assignment, with findings and evidence in the report. That is what puts a time-synchronisation check, a 180-day log check and a point-of-contact check inside a cloud audit nobody scoped them into.
And empanelment is a standing, not a capability statement.
This matters more for cloud than for most engagements. CERT-In publishes a snapshot per empanelled organisation whose capability field is a Yes or No answer against the categories that organisation itself lists, under a heading inviting it to add more — there is no fixed taxonomy, so cloud appears on some snapshots and not on others. §12.2(iv) puts the checking duty on you: understand the auditing organisation’s methodology, tools and “experience in the relevant domain” before selecting. Read the specific organisation’s snapshot rather than assuming a standard set of categories.
The certificate question is the one people most often arrive with, and it has its own page: what a safe-to-host certificate is covers the Government route in full, and what CERT-In is covers the statutory basis for all of it.
Which benchmark, and which instrument actually names it
What standard is a cloud security audit conducted against in India?
This is the question most cloud proposals answer wrongly, and the error is one of attribution rather than of security. Below is what each instrument actually names, in its own words, with the clause. Copy the relevant rows into the scope of work with a version against each and you have converted an argument about quality into a checkable specification.
CSA Cloud Controls Matrix (CCM)
Named by: CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines, v1.0, 25 July 2025 — §8(ii), and again at §13.1.7(i)(a)
§8(ii) lists it among the comprehensive standards an audit should discover known vulnerabilities against, and names its purpose in the same breath: “CSA Cloud Controls Matrix (CCM) for Cloud Security”. §13.1.7(i)(a) then repeats the identical list as a term the audit contract should identify. It is therefore named twice — once as what the audit is conducted against, and once as what the contract says it is conducted against.
How to use it: This is the answer to “which benchmark” in an Indian engagement, and it is the only cloud control framework the guidelines name. Cloud Security Alliance describes the CCM — at version 4.1, when its project page was read on 22 September 2026 — as a cybersecurity control framework for cloud computing “composed of 197 control objectives that are structured in 17 domains”, and — the part that matters for an audit — as providing “guidance on which security controls should be implemented by which actor within the cloud supply chain”. That actor allocation is what makes it usable for the provider-boundary problem further down this page. The count is version-bound, so name the version in the scope of work alongside the framework: at the date above, that is CCM v4.1, in which CSA states the CCM and the Consensus Assessment Initiative Questionnaire are combined.
Cyber Security Audit Baseline Requirements
Named by: Audit policy guidelines §8(iii) and §13.1.8(i), in identical words
Both clauses say the document “should be used by auditees and auditing organizations to build their audit program”. It is published on CERT-In’s website but issued by the National Security Council Secretariat, as publication NSCS-46-16 Rev 1.0, October 2020, and its abstract describes it as “the minimum-security assurance baseline expected across the Cyber Information Infrastructure of organisations”.
How to use it: The programme, not the technical rules. It tells you what the audit is expected to establish. The CCM tells you what to test a tenancy against. Naming the first and skipping the second produces a cloud audit with governance language and no control results.
CIS Benchmarks
Named by: The GIGW 3.0 manual — the preamble to the cybersecurity chapter, 5.3. NOT the audit policy guidelines.
GIGW’s chapter 5.3 preamble says the government organisation “will ensure and monitor that the host service provider and the developer adhere to the industry best security practices and guidelines such as ISO 27001, OWASP ASVS, OWASP Top 10 vulnerabilities and CIS benchmarks as per the prevailing security policy”. That is where CIS enters Indian public-sector practice.
How to use it: Use them, and cite them to the right instrument. It is the sourcing error we see most often in Indian cloud proposals: a scope of work that says “audited against CIS Benchmarks as required by CERT-In”. CERT-In’s audit policy guidelines do not name CIS anywhere. GIGW does, in a preamble, for government websites and apps, alongside three other references. A CIS-benchmarked cloud audit is a good audit. The attribution is simply wrong, and a customer’s reviewer who checks will find it.
GIGW 3.0 guideline 5.3.2 — hosting environment
Named by: The GIGW 3.0 manual, chapter 5.3
Statement: “Hosting Environment has been secured for ensuring confidentiality, integrity and availability (CIA).” Its government-organisation action is a list of mandatory aspects to check when choosing a hosting service provider, and it is the closest thing India has to a written cloud-hosting baseline: hosting of the web infrastructure within the geographical boundaries of India. DC, BCP and DR environments in high-availability mode. Disaster-recovery drills at least once a year. A web application firewall deployed, patched and available on demand. Logs of the ICT infrastructure enabled and maintained for a rolling period of 180 days as per CERT-In directions. Servers and network devices hardened with the latest patches and periodic vulnerability assessment and penetration testing with corrective actions. And, where applicable, securing containerised environments — image provenance and signing, private registry access control, vulnerability scanning, host hardening, orchestration role-based access control, immutable deployments, separate virtual networks, least privilege, exposing only serving ports, TLS everywhere, network policies, private subnets for nodes, a separate etcd cluster behind a firewall, key rotation, static analysis of manifests and secret management.
How to use it: If you are a government organisation, this is your cloud configuration scope and almost nobody scopes against it. If you are not, it is still the most detailed hosting and container control list published by an Indian instrument, and it reads across to a private tenancy without much translation. Take the clause numbers from the manual: the live attributes page mis-numbers the third cybersecurity statement as 5.3.2, so that number appears on it twice.
Provider-published security guidance and well-architected material
Named by: Nothing in the Indian instruments
No CERT-In document read for this page names a hyperscale provider, a provider benchmark, or a provider certification as an audit criterion.
How to use it: Useful input, not an audit criterion. A provider’s own guidance tells you how the provider thinks its service should be configured, which is worth knowing and is not independent. Where it matters is the provider’s published customer-testing policy, which is a contractual constraint on what your auditor may do rather than a standard to test against — read it before the scope is signed, not on day three.
The clause that catches a lot of cloud scopes
The same sentence that names the CSA Cloud Controls Matrix opens by ruling something out: “The limited lists such as OWASP Top 10, SANS Top 25 and similar, should not be considered as standards or references for audits.” A scope of work whose cloud criterion is a ranked list of the year’s most common cloud mistakes is, on our reading of “and similar”, inside what §8(ii) is written against — for the same reason the Top 10 is: a list of common categories cannot support a coverage claim, and coverage is the entire product of a posture review. That reading is ours. The clause names two lists and then says “and similar”, and it is for your auditor to say which side of the line their criterion falls on.
Which CCM domains does an Indian cloud audit cover?
All seventeen, in the sense that all seventeen are in the criterion. Not all seventeen are evidenced from your tenancy, which is the distinction the §13.1.5 boundary forces and the reason the CCM is the right instrument for an Indian cloud engagement: CSA describes it as providing guidance on which security controls should be implemented by which actor within the cloud supply chain, so the framework itself carries the allocation the clause only gestures at.
The seventeen domain names and codes below are CSA’s own, read from the Cloud Controls Matrix project page on 22 September 2026. The last two columns are ours — our mapping of each domain onto the five workstreams and onto the boundary — and no CERT-In document draws them. Use the table to write Annexure B of the scope of work: one row per domain, one decision per row about where the evidence comes from, agreed before fieldwork rather than argued in week four.
| Domain | What it asks about | Which workstream | Where the evidence comes from |
|---|---|---|---|
| A&A Audit & Assurance | Whether an audit programme exists at all, whether it is independent, and whether findings are tracked to closure. | The audit programme itself | Your tenancy — and this is the domain your engagement is an instance of. |
| AIS Application & Interface Security | Application and API design, secure development, and the interfaces the tenancy exposes. | Configuration and posture, plus the API tier | Yours. It is also the domain that most often belongs to a separate engagement. |
| BCR Business Continuity Management & Operational Resilience | Backup, restoration, resilience testing and the plans behind them. | Data protection and key management | Split. Durability machinery is the provider’s, but whether you have ever restored is yours. |
| CCC Change Control & Configuration Management | How change is authorised, deployed and baselined, and how drift is detected. | Configuration and posture | Yours. It is also the domain §13.1.2(iii)’s Minor and Major change classification lands in. |
| CEK Cryptography, Encryption & Key Management | Which keys exist, who may use them, who may administer them, and how they rotate. | Data protection and key management | Yours, for customer-managed keys. Provider-managed key infrastructure is theirs. |
| DCS Datacenter Security | Physical access, environmental controls and facility operations. | None of the five | Theirs, entirely. This is the clearest case in the CCM of a domain a provider assurance artefact has to answer, because nothing in your tenancy can. |
| DSP Data Security & Privacy | Classification, retention, residency, deletion and the lifecycle of the data itself. | Data protection and key management | Yours. This is where the residency question and your own DPDP obligations meet. |
| GRC Governance, Risk Management & Compliance | Policy, risk treatment, exception handling and the authority behind each. | The audit programme itself | Yours, and §9.2 names the office that has to authorise an acceptance. |
| HRS Human Resources Security | Screening, onboarding, offboarding and the removal of access when people leave. | Identity and privilege | Split. Your joiners and leavers are yours, while the provider’s staff are a complementary control in their report. |
| IAM Identity & Access Management | Who and what can do what, how they authenticate, and how privilege is bounded. | Identity and privilege | Yours. It is the largest single domain in a cloud audit and the one the graph analysis serves. |
| IPY Interoperability & Portability | Whether data and workloads can be moved out, and in what format. | Data protection and key management | Split. The export interfaces are theirs, but whether you have ever used them is yours. |
| IVS Infrastructure & Virtualization Security | Segmentation, hardening, virtualisation isolation and the network the workloads sit in. | Network exposure and segmentation | Split down the middle, and this is the domain where §13.1.5’s ownership test is hardest to apply: tenancy isolation is theirs, your route tables are yours. |
| LOG Logging & Monitoring | What is logged, where it is kept, for how long, and whether anybody watches it. | Logging, monitoring and detection coverage | Yours, and it is where Direction (iv) of the 2022 Directions lands. |
| SEF Security Incident Management, E-Discovery & Cloud Forensics | Detection, response, forensic readiness and the evidence an investigation would need. | Logging, monitoring and detection coverage | Yours for the procedure and the six-hour clock, theirs for what the platform can hand you during an investigation. |
| STA Supply Chain Management, Transparency & Accountability | Which third parties are in the chain, what they are accountable for, and how that is evidenced. | Multi-account scoping and third parties | Split, and §13.1.1(f) puts third-party, vendor and supply-chain risk assessment in the audit scope in its own right. |
| TVM Threat & Vulnerability Management | How weaknesses are found, triaged, scored and closed. | Configuration and posture | Yours for your workloads, theirs for the managed services you no longer patch. |
| UEM Universal Endpoint Management | The devices from which the tenancy is administered. | Outside the tenancy | Yours, and outside the cloud account. A tenancy administered from unmanaged laptops is a finding the posture sweep will never see. |
One thing to do before the scoping call, which costs nothing and changes the conversation. The Consensus Assessment Initiative Questionnaire, which CSA describes as built into the CCM and as offering a set of yes-or-no questions for assessing cloud providers, works just as well pointed inwards. Complete it against your own tenancy first. You will arrive at the scoping call knowing which domains you cannot currently answer, which is a far better starting position than discovering it in the draft report — and the domains you cannot answer are, reliably, where the engagement’s findings will be.
Does it matter which cloud provider you are on?
For the criterion, no. No CERT-In instrument read for this page names a hyperscale provider, a provider benchmark or a provider certification, and no provider is named anywhere on this page for that reason. The control questions are the same in every tenancy: which principals can do what, what is reachable from where, whose key decrypts what, and whether the trail is on. The service names differ and the arguments do not.
Three things do turn on the provider, and all three are practical rather than regulatory. The first is the provider’s own published security guidance, which is useful input and is not independent — it tells you how the provider thinks its service should be configured. The second is the provider’s published customer-testing policy, which is a contractual constraint on what your auditor may do and should be read before the scope is signed rather than on day three. The third is the shape of the read role: the capability classes set out further down this page exist on every major platform under different names, and translating them is the platform work the assessment team does, not a decision you have to make.
What an empanelled auditor cannot test
Can a CERT-In empanelled auditor test my cloud provider?
No, and the reason is written down. §13.1.5 of the 2025 guidelines is titled “Planning for Hosted and Third-Party Infrastructure”, and it allocates audit responsibility by who owns and operates the asset. It is the nearest thing in Indian instruments to a shared-responsibility clause, it was written about hosted websites rather than about hyperscale cloud, and it is quoted here in full because paraphrasing it loses the reason it gives.
“In cases where a service or website is hosted on a web server owned by another organization, the responsibility for information security auditing of the web server, its operating system, the web hosting application software, and any backend database application software lies with the organization that owns and operates the server, as the website content owner does not have access to or control over these assets. However, since the data and software related to the website are managed by the organization owning the website content, it is their responsibility to ensure that these components are audited by a CERT-In empaneled information security auditing organization.”
§13.1.5(ii) continues that the organisation owning the website content may select any auditing organisation from CERT-In’s published list, and that the audit report “should explicitly certify that the audited web application including backend databases and scripts, if any, are free from vulnerabilities and malicious code that could be exploited to compromise or gain unauthorized access, including escalated privileges, to the web server hosting the website”. Read that sentence before you sign anything: it is a certification about your workload’s effect on somebody else’s infrastructure.
What the clause settles
Infrastructure you do not own and operate is not your auditor’s to assess, and the report should not imply it was. The duty that stays with you is the data and software you do manage, audited by a CERT-In empanelled organisation of your choosing.
What the clause does not settle
The clause speaks of a web server owned by another organisation. A public cloud is not one server and the split is not one line: in infrastructure as a service the provider owns the hypervisor and you own the guest. Applying §13.1.5 to a cloud tenancy is a reading, and it is ours.
What to do about the gap
Draw the line yourself, in the engagement letter §14.1(ii) requires, control area by control area, and record for each one whether the evidence comes from your tenancy or from a provider assurance artefact. The CSA Cloud Controls Matrix helps here because it allocates controls by actor in the cloud supply chain.
Where the line falls, by service model
The allocation below is the standard shared-responsibility split as it applies to an audit scope. It is our own mapping of a well-understood commercial arrangement onto §13.1.5’s ownership test — no CERT-In document draws it, and no provider is named.
| Yours | Theirs | What your auditor can actually assess | |
|---|---|---|---|
| Infrastructure as a service — virtual machines, block storage, virtual networking | Guest operating system and everything above it, the machine image, patching, host-level configuration, the network rules you write, the identity and key policies you attach, and the data. | The hypervisor, the physical host, the storage fabric, the physical network, the region and its facilities, and the control-plane software itself. | Nearly all of your side. This is the service model where a cloud audit looks most like a conventional infrastructure audit, and where the §13.1.5 split is hardest to apply cleanly: the clause allocates by ownership and operation of “the server”, and in this model the server is divided down the middle. Say which half you mean in the scope of work rather than relying on the clause to say it for you. |
| Platform and managed services — managed databases, queues, functions, object storage | Configuration, exposure, access policy, encryption and key choice, logging settings, version and patch level where you select it, and the data. | The service implementation, the underlying operating systems, the patching you no longer control, tenancy isolation, and the durability machinery. | Configuration and exposure, thoroughly. Implementation, not at all. This is where a posture review is at its most valuable, because the customer-side surface has been reduced to settings and the settings are enumerable. |
| Software as a service — the applications your teams sign up for | Tenant configuration, identity integration and single sign-on, role assignment inside the tenant, data classification and retention settings, external sharing settings, and the API tokens issued to integrations. | Everything else, including the application itself. | The tenant configuration and the identity plumbing. Nothing beneath it. Note that a SaaS tenant is often outside the cloud-audit scope by assumption because it is not in the cloud account inventory — and it usually holds the data the audit is about. |
| The provider’s own control plane and corporate environment | Nothing. | All of it. | Nothing at all, by you or by your auditor. This is the part of the estate for which independent assurance reporting exists, and the reason the next section is on this page. |
One consequence of that table is worth stating on its own, because it decides how a scope is priced. The further up the service models you go, the smaller the auditable surface and the larger the share of your assurance that comes from somebody else’s report. That is not a weakness of cloud — it is the trade. What makes it a problem is an audit file that never says which share is which. Cloud provider assurance and shared responsibility takes that division apart in detail.
Where provider assurance reports help, and where they do not
Does my cloud provider’s audit report cover my environment?
It covers the provider, not you. That sentence is the whole section, and the reason it needs a section is that assurance artefacts are routinely filed as though they answered a question about the customer’s configuration. Below is what each artefact does, what it does not, and the use it has in an audit file that is honest about the boundary.
| Artefact | What it covers | What it does not | How to use it in your audit file |
|---|---|---|---|
| A service organisation control report on the provider | The provider’s own controls over a defined system for a defined period, described by the provider and tested by an independent auditing firm, with the tests and results set out so a reader can judge them. | Say anything about your tenancy. The report is about the service organisation, not about the configuration you built on top of it. It also covers a stated period, which ends — and your audit window is usually not inside it. | Read the scope section first and check the services you actually use are in it, then read the complementary user entity controls: the things the report assumes you are doing, without which the provider’s controls do not deliver the result. Those are audit findings waiting to happen on your side of the line. complementary user entity controls. |
| An ISO/IEC 27001 certificate held by the provider | That a management system, within a stated scope, was certified by an accredited certification body against the standard. | Tell you which controls apply to which service, or what was tested. A certificate is a conclusion. The statement of applicability and the scope statement are where the content is, and neither is usually published. | Check the scope statement covers the services and the locations you use, and check the certificate is current. Treat it as evidence that a system exists, not as evidence about a specific control. |
| A CSA STAR entry | In CSA’s own words, at level one “organizations submit a self-assessment”, made against the Consensus Assessment Initiative Questionnaire, which CSA describes as built into the Cloud Controls Matrix. At level two, “organizations earn a certification or third-party attestation”. | Make a level-one self-assessment into third-party assurance. The two levels are different things and the registry says which is which. | Because the entry is answered against the CCM, and the CCM is the framework §8(ii) names for cloud security, a STAR entry maps directly onto the control set your own audit is using. That alignment is the practical reason to look at it. |
| The provider’s published region, residency and compliance pages | Where a service runs, what the provider commits to about data location, and which attestations it holds. | Constitute audit evidence about your deployment. A provider offering an Indian region is not evidence that your resources are in it. | Use them to frame the question and answer it from your own account: enumerate your resources by region and put that inventory in the audit file. The provider’s page is the claim. Your inventory is the evidence. |
| The provider’s customer penetration-testing policy | What the provider permits a customer or a customer’s auditor to do against services in its estate, and what requires notice or is prohibited outright. | Appear in any CERT-In instrument. No document read for this page names a provider or its terms. | Read it before the scope is signed. It is a contractual constraint on the engagement, and it sits alongside — not instead of — the written approvals §13.2.2(v) and §15.2.2(ii) require from you. |
The part of a provider report that actually changes your engagement is the complementary controls section — the controls the report assumes you are operating, without which the provider’s own controls do not deliver the result described. Those read across almost one to one into a cloud audit scope: identity and access administration on your side, key administration, network configuration, logging configuration, and the removal of access when people leave. Read them as a to-do list rather than as boilerplate, and the boundary stops being an abstraction. Complementary user entity controls covers what they are and how to evidence them.
Getting read-only assessment access, properly
What access does a cloud security auditor need, and how should it be granted?
A cloud audit runs on read access to your control plane. That single grant is the most consequential decision in the engagement, and it is usually made in a chat message on a Friday. Seven clauses govern it, and they line up into a sequence you can run. Note the first one especially, because it decides who makes the grant: §9.6(i) lists “providing access to the information infrastructure” among the duties that belong to the owner of the infrastructure and adds that “this responsibility must not be delegated”.
| §9.6(i) | Providing access to the information infrastructure is one of the four duties the clause enumerates as belonging to the owner of that infrastructure: “from defining the audit scope, selecting the auditing organization, providing access to the information infrastructure, to ensuring closure of all audit observations”. It adds that “this responsibility must not be delegated”, and that the organisation “may seek external support for specialized expertise, while retaining full ownership and accountability”. | In a cloud tenancy: The role is created by you, in your organisation, by a named person, on a change record. Not by the auditor “sending a template we usually use”, and not by a partner who happens to have administrative access already. |
| §15.1.2 | Titled “Managing Access and Testing Credentials”: “If privileged testing is necessary, the auditee organization must provide only temporary access such as login credentials, access tokens, certificates, or secure ID numbers and must ensure that all such privileges are revoked immediately upon completion of the audit.” | In a cloud tenancy: Put an expiry on the role or the credential at the moment you create it, rather than putting a reminder in a calendar. In a cloud tenancy this is a condition on the trust policy or a session-duration limit, which means the revocation is enforced by the platform and evidenced by it too. |
| §13.2.2(iv) | “The auditing organization must have a thorough understanding of the tools they use, including their origin and functionality. These tools should be tested in a controlled test environment prior to deployment on the auditee’s systems. The results of such testing must be formally reviewed and approved by an authorized representative of the auditee organization.” | In a cloud tenancy: Name the posture-assessment tooling before access is granted and ask where it runs. Many cloud assessment tools are themselves hosted services that will hold a copy of your configuration — which is a map of your estate — outside your tenancy. |
| §13.2.2(v) | “Appropriate written approvals must be obtained prior to conducting any penetration tests, and the installation of tools should be carried out in the presence of the auditee’s system administrator.” | In a cloud tenancy: Where the engagement deploys an assessment role, a collector or an agent inside your accounts, treat the deployment as installation: an approved change, witnessed by your administrator, with a removal step at the end. The 2018 auditor guidelines are explicit about removal with the auditee’s acceptance. |
| §12.2(iii) | The auditee must verify identity, official identity cards or government documents and designations, and “Auditing organizations should not field freelancers, interns, freshers, moonlighters, third party consultant or employees who are serving their notice period and the auditee organizations should verify compliance.” | In a cloud tenancy: Issue one identity per named auditor rather than one shared role for “the audit team”. Shared credentials defeat the attribution the audit trail is supposed to give you, and they make the revocation step unverifiable. |
| §10.3 and the 2014 data-handling policy | Auditee data is stored only on systems located in India, encrypted on auditor devices, and wiped on completion so that it “cannot be retrieved by any known forensic technique”, with a formal certificate of deletion issued to the auditee. Where the agreement is silent, retention defaults to one year from completion and is limited to the audit reports. The 2014 policy adds that an audit report “should not be shared / hosted on online internet file services, online sharing platforms and cloud services, unless the service is under technical and administrative control of the auditing organization or as specifically authorized by the auditee”. | In a cloud tenancy: Ask three questions in writing before access: where does the assessment platform run, in which tenancy and region do the findings live, and what is the date of the deletion certificate. A cloud audit is the engagement where this most often breaks, because the tooling is itself cloud-hosted. |
| §13.2.7 | For remote and high-risk test scenarios, the auditing organisation discloses the identity, mobile number and/or IP addresses from which testing will originate. Written permission is required for testing of survivability failures, denial of service, process testing and social engineering. | In a cloud tenancy: Take the source addresses and allow-list them, then alert on assessment-role activity from anywhere else. This is the control that turns a granted read role from a standing risk into a monitored one. |
Why “read-only” is an approval step with its own risk
The clauses above govern the grant. What they cannot tell you is what a read role actually permits in a cloud tenancy, because that is a platform fact rather than a regulatory one. Everything in this table is our own operational reading, and it is the part of the engagement where we most often see an otherwise careful organisation move fast.
| What people assume | What is actually true | The control to apply |
|---|---|---|
| “Read-only cannot hurt us.” | A broad managed read policy in a public cloud typically permits reading configuration, resource metadata, key metadata and, depending on the policy chosen, the contents of objects and database snapshots. Read access to a configuration store or a secrets manager is read access to credentials for systems that are not in your cloud account at all. | Grant a role built for assessment rather than a general-purpose read policy, and explicitly deny the actions that return secret material and object data unless the scope genuinely requires them. Where the scope does require them, say so in the engagement letter and treat it as the sensitive grant it is. |
| “It is only for two weeks.” | A trust policy naming an external principal is a standing relationship, not a booking. Nothing in the platform expires it when the invoice is paid: the engagement ends, the role does not, and the only thing that removes it is a change somebody remembers to make. In the second-year engagements we see, the first-year assessment role is routinely still there — still trusted, still assumable, and now unattached to any live contract. | §15.1.2 requires revocation immediately on completion. Build the revocation into the same change that creates the role, with a condition or an expiry, and put the removal evidence in the closure pack. |
| “We gave them an account, so we can see what they did.” | Only if the control-plane trail is on in that account and that region, and only if somebody looks. In the estates where an assessment role is most useful, trail coverage is exactly what the audit is about to find is incomplete. | Confirm trail coverage in every account before the role is created, not after. It is also the first finding of the engagement if the answer is no, and it is better found by you than by the auditor. |
| “The auditor will tell us what access they need.” | They will, and it will be the widest role that reliably works, because a failed check costs them a day. That is a rational answer to their problem and not to yours. | Ask for the check list first and the permissions second. Then §13.2.2(iv) gives you the right to see the tooling tested and approved before it runs, which is the moment to find out that four of the checks needed the wide permission and the other four hundred did not. |
| “External identity is simpler than a federated one.” | An external account identifier in a trust policy is a permanent relationship with a principal you do not control, and it survives staff changes at the auditing organisation. | Where your provider supports it, prefer time-bounded federated access with an external condition value over a long-lived key. §12.2(iii)’s rule against fielding freelancers and staff on notice period is much easier to honour when each auditor authenticates as themselves. |
The ten capability classes, and which side of the line each belongs on
“Deny the actions that return secret material and object data” is a principle, and a principle is not a policy document. Below is the principle enumerated: the capability classes a cloud read role is built out of, what each one actually returns, and the default we would argue for. It is provider-neutral because the classes exist on every major platform under different names, and it is our operational reading rather than clause text — §15.1.2 governs the grant and says nothing about its contents. Hand this table to your supplier and ask them to work inside it. A supplier who can is running a posture review. A supplier who cannot should say which checks need the wider grant, which is exactly the conversation §13.2.2(iv) entitles you to before the tooling runs.
| Capability class | What it returns | Default | Allow only if |
|---|---|---|---|
| Secret and credential retrieval | The live value of a stored secret: database passwords, third-party API keys, signing keys, service-account credentials. Frequently credentials for systems that are not in the cloud account at all. | Deny | Never for a posture review. The audit question — is the secret store used, is it encrypted, who may read it, does anything rotate — is answerable from metadata and policy alone. |
| Object and blob content reads, as distinct from bucket metadata | The contents of stored objects, rather than the container’s policy, encryption setting and public-access configuration. | Deny | The scope is data classification or a confirmed-exposure investigation. Say so in the engagement letter, name the containers, and treat it as the sensitive grant it is. Exposure findings do not need it: a container’s access policy is metadata. |
| Database snapshot export, restore and snapshot sharing | A copy of the data, in a place the original controls do not reach. | Deny | Never for an audit. Whether snapshots are encrypted, whether any snapshot is shared publicly, and who may share one are all readable from snapshot attributes. |
| Parameter and configuration store reads with decryption | Decrypted values from a configuration store, which in most estates is where the secrets nobody classified as secrets live. | Deny | Never. Read the parameter names, types and policies, but do not read the values. This is the denial most often left out, because the service is filed mentally as configuration rather than as secrets. |
| Key material use — decrypt, sign, generate data key | Plaintext, or a valid signature. It is the capability the key policy exists to ration. | Deny | Never. The finding in this area is almost always about the key policy, not about the key: who may use it, who may administer it, whether rotation is on, whether deletion is protected. |
| Key policy, grant and rotation reads | Who is permitted to use and to administer each key, the grants outstanding, and the rotation configuration. | Allow | This is the audit. It is the single most productive read in the data-protection workstream. |
| Signed-URL and presigned-link generation | A credential-free URL that hands object contents to anybody who holds it, and that survives the revocation of the role that minted it. | Deny | Never. It is the capability that most cleanly defeats the revocation §15.1.2 requires, because the artefact outlives the identity. |
| Support case and billing reads | Correspondence, account contacts, and spend by service and by account. | Deny by default, allow billing reads on request | Billing is genuinely useful for the inventory cross-check this page recommends, and it is a narrower grant than it sounds. Support-case contents are correspondence and should stay out. |
| Control-plane configuration reads across every service in scope | The settings, policies, resource attributes and relationships the posture sweep is made of. | Allow | This is the audit. If this is refused, there is no engagement — say so at scoping rather than at week two. |
| Trail, log-destination and retention configuration reads | Which trails exist, in which accounts and regions, where they write, with what retention, and under what bucket or workspace policy. | Allow | This is the audit, and it is the workstream that decides whether any future incident is reconstructable. Note that it is configuration, not log contents — reading the events themselves is a separate and much wider grant. |
The four checks that drive the widest permission, and what you lose by refusing them
Ask for the check list first and the permissions second, and this is what the conversation looks like when you do. In almost every engagement a small number of checks are responsible for the widest grant in the role, and in three of the four cases below the narrow answer is as good as the wide one. Knowing which is which turns §13.2.2(iv)’s tooling approval from a formality into a negotiation with an agenda.
Is any object in this container actually readable without authentication?
What it needs: An unauthenticated fetch from outside, plus object-level metadata.
What refusing it costs: Little. The container’s public-access configuration and policy answer the control question. An anonymous fetch from outside the tenancy confirms it without any grant at all. Prefer the outside test to the inside permission.
Is the value in this secret or parameter store actually a secret?
What it needs: Decrypted reads of stored values.
What refusing it costs: Nothing an audit needs. Refuse it. You lose the ability to say a particular parameter holds a credential, and you keep the ability to say the store is unencrypted, world-readable within the account, or never rotated — which is the finding.
What is in the data, and is any of it regulated?
What it needs: Object and database content reads, or snapshot restore.
What refusing it costs: Real, and it is a scope decision rather than a security one. Refusing it means the report cannot say which findings touch regulated data, so blast radius is stated in terms of systems rather than of data classes. If you want the data-class column, buy it deliberately and write it into the engagement letter.
Can this identity actually reach that resource, in practice?
What it needs: Policy-simulation and reachability APIs, which are control-plane reads — and occasionally the credential itself.
What refusing it costs: Little, if you grant the simulation APIs. Refusing the credential loses nothing: a simulated evaluation is reproducible and a live assume is not. This is the check most often used to justify a wide grant, and the one where the narrow answer is genuinely as good.
There is a second, quieter exposure in the same decision, and it is about where your configuration goes rather than about what the role can read. A posture assessment produces a complete map of your estate, and many assessment platforms are themselves hosted services. §10.3 requires auditee data to be stored only on systems located in India and wiped on completion beyond forensic recovery, with a formal deletion certificate. §16.6 bars sharing with an overseas entity or partner unless authorised in writing, and CERT-In’s 2014 Policy Guidelines for Handling Audit related Data add the line that names the medium directly — an audit report “should not be shared / hosted on online internet file services, online sharing platforms and cloud services, unless the service is under technical and administrative control of the auditing organization or as specifically authorized by the auditee”. The 2018 auditor guidelines put the same point in six words: the auditor “will ensure there is no mirroring of data outside the country”. Ask where the platform runs before you create the role, not after. The rules of engagement an empanelled auditor works under sets out the full set.
If your accounts are not in an Indian region
This is the common Indian software setup — a tenancy whose primary region is somewhere else because that is where the product was first deployed — and it is where three separate residency questions get blurred into one. They have different answers and only one of them is about the audit.
Where your production data sits.
A design question, governed by your own obligations rather than by the audit. No clause in the 2025 audit policy guidelines tells you which region to run in. If you are a Government organisation, GIGW’s hosting-environment guideline does say to ensure hosting of the web infrastructure within the geographical boundaries of India. If you are not, your obligations come from your sector, your contracts and the law that applies to the data.
Where your logs sit.
Direction (iv) of the 2022 Directions says logs shall be maintained for a rolling period of 180 days “and the same shall be maintained within the Indian jurisdiction”. Read it with FAQ Q35, which says: “The logs may be stored outside India also as long as the obligation to produce logs to CERT-In is adhered to by the entities in a reasonable time.” The FAQ states of itself that it is not a legal document and does not replace, amend or alter any part of the IT Act, 2000 or the CERT-In Rules, 2013 — so treat Q35 as CERT-In’s published reading and take your own advice before designing a region strategy around it.
Where the audit artefacts sit. This one is India-only regardless of where the estate is.
Testing a system hosted abroad is not itself constrained by anything read for this page. What is constrained is where the exports land. Every configuration export, console capture and log extract the auditor takes out of an offshore console is auditee data, and §10.3 requires auditee data to be stored only on systems located in India, encrypted on auditor devices, and wiped on completion beyond forensic recovery with a certificate of deletion issued to you. §16.6 bars sharing with an overseas entity or partner unless authorised in writing. The 2014 data-handling policy adds the line aimed at the medium itself: an audit report “should not be shared / hosted on online internet file services, online sharing platforms and cloud services, unless the service is under technical and administrative control of the auditing organization or as specifically authorized by the auditee”.
The practical consequence is a sentence in the engagement letter, and it is the sentence most often missing when the estate is offshore: artefacts taken from accounts in any region, including regions outside India, are held in India-resident storage for the duration of the engagement and deleted on completion. Ask where the assessment platform itself runs, in which tenancy and in which region the findings will be held, and on what date the deletion certificate is issued — before the role is created, not after. A cloud engagement is where this most often breaks, because the tooling is itself cloud-hosted and frequently in the same offshore region as the estate.
The 2022 Directions inside a cloud audit
Do the CERT-In Directions of 2022 apply to a cloud environment?
They do, and §15.2.1(iv) of the 2025 guidelines drags them into the engagement whether or not your scope of work mentions them: an auditing organisation “must include the verification of compliance to CERT-In direction … dated 28 April 2022 in every audit assignment and findings along with relevant evidences should be included in the audit report”. That clause is why a properly run cloud audit carries a time-synchronisation check, a log-retention check and a point-of-contact check that nobody asked for. The table below is what each limb turns into when the estate is a cloud tenancy.
| What the instrument says | What it means in a tenancy | What the evidence is | |
|---|---|---|---|
| Direction (i) — time synchronisation | All ICT system clocks are to be synchronised to the NTP server of NIC or NPL, or to NTP servers traceable to them. An entity spanning multiple geographies may use another accurate and standard time source, but that source “shall not deviate from NPL and NIC”. | Whether your instances, containers and managed services take time from the provider’s native time service, and whether that arrangement is documented. FAQ Q41 and Q42 address this directly: cloud customers “have an option to use the native time services offered by the Cloud” or may run their own NTP server, and where they run their own against non-native sources, the NTP servers of NPL, NIC “or other accurate and standard time sources may be used as long as the accuracy of time is maintained”. Q43 gives the hostnames, with CERT-In’s own hedge that they are the details “currently” — samay1.nic.in and samay2.nic.in for NIC, time.nplindia.org for NPL. | Configuration showing the time source for each workload class, plus the drift measurement if you have one. Q40 adds a point worth writing into the logging standard: system clocks need not be set to Indian Standard Time, but the time zone “shall also be recorded along-with time”. |
| Direction (iv) — 180 days of logs, and where they live | Quote-exact: “All service providers, intermediaries, data centres, body corporate and Government organisations shall mandatorily enable logs of all their ICT systems and maintain them securely for a rolling period of 180 days and the same shall be maintained within the Indian jurisdiction. These should be provided to CERT-In along with reporting of any incident or when ordered / directed by CERT-In.” | Trail and log coverage per account and per region, the retention setting against 180 days, and the storage region. Read the residency limb with FAQ Q35, because a page that states one without the other sends a cloud buyer to the wrong region decision: “The logs may be stored outside India also as long as the obligation to produce logs to CERT-In is adhered to by the entities in a reasonable time.” The FAQ states of itself that it “is not a legal document and in no way whatsoever replaces, amends or alters any part of the IT Act, 2000” or the CERT-In Rules, 2013 — so treat Q35 as CERT-In’s published reading, and take your own advice on the direction’s text. | Per-account trail configuration, retention values, destination bucket or workspace policy, and a dated extract proving events were being written during the audit window. FAQ Q37 is the list to scope against: firewall, intrusion prevention, SIEM, web, database, mail, FTP and proxy server logs, event logs of critical systems, application logs, SSH and VPN logs — “not exhaustive”, and with both successful and unsuccessful events recorded. |
| Direction (iii) — the point of contact | A point of contact must be designated to interface with CERT-In and kept updated. Annexure II sets the format — name, designation, organisation name, office address, email, mobile, office phone and fax — and the instruction is to send it to info@cert-in.org.in. | Whether one exists, whether the named person has left, and whether anybody on the cloud platform team knows who it is. The asymmetry catches people out: incidents go to incident@cert-in.org.in, the point-of-contact form goes to info@cert-in.org.in. | The submitted form and the date it was last updated. This is a two-minute finding and it comes up repeatedly in first audits. |
| Annexure I item (xviii) — cloud incidents are reportable in six hours | “Attacks or malicious/suspicious activities affecting Cloud computing systems/servers/software/applications” is one of the twenty types that must be reported to CERT-In within six hours of noticing, or of being brought to notice. The FAQ’s own explanation of the type names “Cloud API vulnerabilities, weak cryptography, exposed data repositories and unauthorised access to victims’ cloud credentials”. | Whether your incident procedure names the six-hour clock, who starts it, and which alert conditions in the cloud estate trigger it. FAQ Q13 removes the commonest escape route: “Any entity which notices the cyber security incident, shall report to CERT-In. The obligation of reporting of cyber incident is neither transferrable nor indemnified or dispense with.” Q31 covers the case where the affected data sits in a third party’s systems, and Q30 says you may report on the information available and supplement it later. | The procedure itself, the escalation path, and a test record. An incident-response capability is inside the audit scope in its own right under §13.1.1(a), which names “testing of Incident response capability of the auditee”. |
| Direction (v) and (vi) — if you are the provider rather than the customer | Data centres, virtual private server providers, cloud service providers and VPN service providers must register and maintain, for five years or longer as mandated by law and after any cancellation or withdrawal of registration, validated names of subscribers, the period of hire with dates, IP addresses allotted or in use, email, IP and time stamp at onboarding, the purpose of hiring, validated address and contact numbers, and the ownership pattern of subscribers. | Whether the registry exists, whether the validation is real validation, and whether the retention clock survives an account cancellation. Note the effective dates: the Directions took effect sixty days after 28 April 2022, but the extension order of 27 June 2022 made them effective on 25 September 2022 for micro, small and medium enterprises, and made the validation limbs at paragraph (v)(a) and (v)(f) effective on the same date for all four provider classes. Three dates, not one. | A sample reconstruction: pick a subscriber and show the seven data elements with their sources and the date each was validated. |
Two things about that table are worth carrying away. The first is that the Directions reach you as a customer and, separately and more heavily, as a provider — and an organisation running a platform on which other people build is both. The 2022 Directions explained goes limb by limb, and what CERT-In is covers the statutory basis. The second is the penalty position, which CERT-In states through its own FAQ rather than in the Directions: the introduction reproduces section 70B(7) of the Information Technology Act, 2000, under which a failure to provide information called for, or to comply with a direction, “shall be punishable with imprisonment for a term which may extend to one year or with fine which may extend to one lakh rupees or with both”. FAQ Q23 adds CERT-In’s own gloss that the power “will be exercised reasonably and on occasions when the non-compliance is deliberate”.
Multi-account scoping, and the accounts that get left out
How should a multi-account cloud environment be scoped for audit?
From the organisation’s own account list, enumerated by API, dated, and cross-checked against the bill — not from the architecture diagram, which is a drawing of the accounts somebody remembered. §13.1.1(c) says the scope “must be derived from the consolidated and updated asset inventory”, and the word doing the work in a cloud estate is consolidated. Eight classes of account go missing, in our experience with the estates we are asked to review, and each one has a clause that should have caught it.
The sandbox or experimentation accounts
Why it is missed: Nobody thinks of them as production, so nobody inventories them.
They are usually the accounts with the widest permissions, the fewest guardrails and a copy of a production dataset somebody pulled in to test something in 2024. They are also frequently missing the control-plane trail, which means an incident in them is unreconstructable.
The clause that should catch it: §13.1.1(e) requires assets related to testing, UAT, development and production environments to be included “to achieve complete audit coverage”.
The deployment or CI/CD account
Why it is missed: It is infrastructure for building, not infrastructure that runs the product.
It holds the credentials that change everything else and the role every production account trusts. It is the highest-value target in most cloud estates and the one least often in scope.
The clause that should catch it: §13.1.1(a) puts the entire cyber infrastructure in scope, and §8(ii) names the OWASP DevSecOps Maturity Model for pipeline security.
The disaster-recovery region, and the secondary regions nobody deploys to
Why it is missed: The scope names the environment, not the regions.
Resources in a secondary region are real resources with real exposure and frequently older configuration, because the automation that hardened the primary was never run against them. They also carry data, which puts them inside the residency question.
The clause that should catch it: §13.1.1(c) requires the scope to be derived from the consolidated and updated asset inventory. An inventory by account and not by region is half an inventory.
Accounts inherited in an acquisition or a reorganisation
Why it is missed: They joined the organisation after the last scope was written and nobody rewrote it.
They arrive with their own identity arrangements, their own trust relationships and their own idea of what a guardrail is, and they are usually connected to the rest of the estate by a peering link somebody set up in a hurry.
The clause that should catch it: §14.3 names the legitimate triggers for revising a scope, including “changes in organizational structure, ownership, or regulatory environment”. That is this, exactly.
The account on somebody’s personal or departmental payment method
Why it is missed: It is not in the organisation and not on the bill anybody reviews.
It is outside every organisation-level guardrail, outside the centralised logging, and outside the scope by construction. It is normally found by asking finance rather than by asking engineering.
The clause that should catch it: §13.1.1(b) puts scope definition with the auditee in consultation with the auditor. Only the auditee can find this one, and only by looking somewhere the auditor cannot.
The tenancy a managed service provider or integrator runs on your behalf
Why it is missed: It is somebody else’s account, so it feels like somebody else’s audit.
The data is yours and the exposure is yours. §13.1.5 allocates the audit of infrastructure the other party owns and operates to that party — which means you need their audit result, not an assumption about it.
The clause that should catch it: §13.1.4(i) requires that where audited activities are outsourced, “relevant personnel from outsourced organization are available at the time of audit”, and §13.1.1(f) puts third-party, vendor and supply-chain risk assessment inside the scope.
The logging and security tooling account itself
Why it is missed: It is the thing doing the watching, so it is assumed to be safe.
It holds the evidence every other finding depends on. If its bucket policy lets a production role write to it, the integrity of the whole audit trail is a matter of trust rather than of control.
The clause that should catch it: §18(iv) requires audit evidence to be stored securely with restricted access and encryption or access controls. The same logic applies to the evidence your platform generates about itself.
The SaaS tenants the cloud inventory does not know about
Why it is missed: They are not cloud accounts, so they are not in the cloud account list.
They hold data, they are integrated into your identity provider, and they have issued API tokens to things. A cloud audit that stops at the infrastructure provider stops short of where a large share of the data actually is.
The clause that should catch it: §13.1.1(c) again: the consolidated asset inventory is consolidated or it is not. If the SaaS estate has its own spreadsheet, you have two inventories and no scope.
Two clauses turn the exercise above into something checkable after the fact. §16.1(iii) requires that “all the assets provided in the scope by auditee organization must be mentioned in the report” — so the report itself is a coverage statement, and a count you can compare against your inventory. And §10.1(ii) requires that where in-scope assets were inaccessible, the auditor informs you promptly, requests resolution, and if it is unresolved names them in the report with reasons, with the same “brought to the notice of CERT-In”. An account that was in scope and never assessed is not a silence in a well-run engagement. It is a named line in the report.
The evidence a cloud audit produces, and the clause behind each artefact
What are the deliverables of a cloud security audit?
Quality in this field is usually discussed in adjectives. The guidelines discuss it in artefacts, which is far more useful to a buyer, because an artefact can be asked for by name and its absence is a fact rather than an impression. Ask for these in the scoping call, not in the dispute.
The account, region and service inventory the scope was derived from, with an as-of date
The scope “must be derived from the consolidated and updated asset inventory”, and the date to which that inventory was updated must be reflected in the audit reports. For cloud that means a list of accounts or subscriptions, the regions enabled in each, and the services in use — produced from the organisation’s own APIs rather than typed from memory.
Where it is missing: Coverage is an assertion. There is no way, afterwards, to tell whether nineteen accounts were assessed out of nineteen or out of twenty-four, and the twenty-fourth is where the incident will be.
A control results file: one row per control objective, per resource
The benchmark row, the account, the region, the resource identifier, the observed value, the expected value, the result, and the timestamp of the read. §18(iii) states, in the declarative rather than as a command, that observations “are well supported with objective evidences and all evidences are compiled carefully and correctly with the report”, and that evidence is presented so that decision makers “are able to use them effectively in making credible risk-based decisions”. Two clauses in the same section are genuine musts and are worth naming alongside it: §18(i), under which auditee organisations “must seek the working notes” on completion, and §18(iv), under which audit evidence “must be stored securely”. The column specification is set out under the artefacts heading below.
Where it is missing: You have a narrative. A narrative cannot be re-run, which means the re-test is a fresh opinion rather than a comparison.
The raw configuration extracts, retained as working notes
“Auditee organizations must seek the working notes” on completion, with provision for it in the contract, and the evidence as an appendix to the final report. For a cloud audit the working notes are the API responses and exported configuration the findings were derived from.
Where it is missing: You cannot reproduce a finding, which means you cannot verify a fix, which means closure is asserted rather than demonstrated.
A named, enumerated list of what could not be assessed, and why
“All the assets provided in the scope by auditee organization must be mentioned in the report.” Where in-scope assets were inaccessible, §10.1(ii) requires the auditor to inform the auditee promptly, request resolution, and if unresolved name them in the report with reasons — and the same “must be brought to the notice of CERT-In”. In cloud this is usually an account whose read role was never approved, or a region the assessment role could not assume into.
Where it is missing: The gap between what you paid to have assessed and what was assessed is invisible, and it is exactly where the next incident lives.
The identity and privilege analysis, as a graph rather than a list
Principals, the policies attached to them, the roles they may assume, and the paths between them. The deliverable that makes this useful is not a list of over-permissive policies but a small number of named paths from a low-trust starting point to a high-value ending point.
Where it is missing: Every individual permission looks defensible, because each one was granted for a reason. The composition is the finding, and nobody sees a composition in a list.
The environment statement
The auditing organisation “must clearly specify the environment such as Test, Development, UAT, Pre-Production, or Production, in which the application has been tested”. Note “such as” — the list is open, which in cloud is convenient, because the honest answer is usually “these nine accounts, of which four are production”.
Where it is missing: A clean result that describes a non-production estate reads, to anybody who did not sit in the scoping call, as a statement about the production one.
Findings scored, with the scoring basis stated — including where a score does not exist
§16.2(ii) requires severity on CVSS supplemented with EPSS, and that “Every reported observation / vulnerability shall be mapped with Common Weakness Enumeration (CWE) and Common Vulnerabilities and Exposures (CVE) number.” A configuration finding generally has a weakness class but no CVE, and EPSS is published per CVE — so there is no EPSS value to print. Note also what §16.2(ii) does not say: it names CVSS and pins no version. Version 4.0 is current and version 3.1 remains widely used, so the report should name the version it scored on and print the vector either way — the version is readable from the vector prefix, and a severity word with no vector behind it cannot be argued with. Where you are on v4.0, use FIRST’s own nomenclature: CVSS-B where only base metrics were supplied, CVSS-BE where environmental values were. That tells a reader how much of the instrument the number actually represents.
Where it is missing: An auditor who wants the field filled will either invent a CVE or drop the finding. The correct answer is to state that the observation is a configuration weakness with no associated CVE and therefore no EPSS value, and to say so in the report’s methodology note. That formulation is ours, not the instrument’s. The instrument requires the mapping and does not address the case where no identifier exists.
An executive summary written for the board
A concise overview of findings, associated risks and overall posture, intended for board members or top management, which “should translate the technical findings into relevant business risks”. For a cloud audit the translation that lands is exposure and blast radius, not control counts.
Where it is missing: The report is forwarded and not read, and the remediation decisions get made from a covering email.
Closure timelines by severity, and the guardrail plan
“Audit report should mention appropriate timelines for closure of vulnerabilities according to severity.” That is the whole clause. It asks for the field and fixes no number for any severity band — the days are yours to set, and the CVSS bands the severities are expressed in are FIRST’s, not CERT-In’s. For cloud, add a second column the instrument does not ask for and every mature estate wants: which findings will be closed by a preventive control rather than by an individual fix.
Where it is missing: The same finding returns next cycle as a repeat observation under §15.2.1(iii), because the thing that produced it was never changed.
Evidence that a second team checked the first
The clause asks the auditing organisation to “implement the maker-checker concept”, with “a separate verification team (checker)” deployed “to review and validate the work performed by the audit team (maker)”. It is a recommendation rather than a requirement, and it is directly checkable by a buyer without any technical knowledge: §9.5(iii) requires the report to be reviewed and signed by a designated reviewer who is not part of the audit team and is from mid-management, so the reviewer signature on the report is the visible end of the maker-checker arrangement. For a posture review the checker’s work is unusually verifiable, because control results are re-runnable — the checker can re-read a sample of rows rather than re-read the narrative about them.
Where it is missing: One person’s sweep, formatted as an organisation’s opinion. Ask, at scoping, who checks the audit team’s work and whether that person is inside the team.
The report distribution list, and the channel the password travelled on
§13.2.5, “Planning Report Handling and Distribution”, says a distribution list of the official email IDs of designated auditee-side contacts “should be obtained prior to report distribution”, that the mobile number of the designated contact “should be collected for securely sharing passwords related to password-protected reports”, and that “Both the audit reports and their passwords must be shared exclusively with the authorized contact”. §16.5 adds official email IDs only, delivery to the specified point of contact only, and that “All communication channels for delivery of report are end to end confidential.” This matters more for a cloud report than for most: the deliverable is a map of the estate, with account identifiers, exposed endpoints and the exact reason each one is reachable.
Where it is missing: The most complete description of how to attack your estate that has ever existed is forwarded to a distribution list nobody agreed, with the password in the same thread.
The exit conference, and a record of what was presented at it
§17(iii) says entry and exit conferences “should be organized and attended by the senior management of the auditee organization to ensure alignment and commitment throughout the audit process”. It sets out what each one is for: the entry conference settles scope, objectives, timeline and responsibilities, with a formal presentation to the Board and senior management outlining the auditor’s understanding of the scope, the methodology, the key phases and the expected timelines. The exit conference is the structured forum for presenting what was found. For a cloud audit the exit conference is where the cluster analysis earns its keep, because six root causes can be discussed by a board and eight hundred control-result rows cannot.
Where it is missing: The report is a file transfer. Remediation then competes with the delivery backlog with nobody senior having heard the argument for it.
A revocation record and a deletion certificate
Evidence that the assessment role, the credentials and the trust relationship were removed, and a formal certificate that auditee data held by the auditing organisation was wiped so that it “cannot be retrieved by any known forensic technique”.
Where it is missing: The engagement leaves behind a permanent external trust relationship and a copy of your estate map on somebody’s laptop for the §10.3(vi) default year.
One difference between a cloud report and an application report is worth planning for, because it changes what the deliverable looks like. An application test produces a small number of narrative findings, while a posture review produces a large number of machine-generated rows that collapse into a small number of decisions. The report you want states both: the rows, so the coverage is checkable and the re-test is a comparison, and the causes, so somebody can act. Reading a VAPT report covers what to believe and what to question in the narrative half.
What the artefacts actually look like
Three artefacts above do most of the work and are the easiest to promise and not deliver. Here they are rendered rather than described, so that “a control results file” stops being a phrase in a proposal. The column names and the worked findings are ours — no clause prescribes a schema — but every column answers to a clause, and the clause is named against it.
1. The control results file, column by column
One row per control objective per resource. Machine-readable, supplied alongside the narrative report rather than instead of it, and the thing that makes the re-test a comparison rather than a fresh opinion.
| Column | Example value | Why it is there |
|---|---|---|
| control_objective_id | IAM-04 | The row in the named framework, at the named version. It is what makes the result a control result rather than an observation. §8(ii), §13.1.7(i)(a). |
| ccm_domain | IAM — Identity & Access Management | The domain the objective belongs to. It is what lets eight hundred rows be reported as a small number of areas without losing the row underneath. |
| account_id | acct-prod-payments | Which account. §16.1(iii) requires every in-scope asset to be named in the report, and an account is an asset. |
| region | ap-south-1 | Which region. An inventory by account and not by region is half an inventory — §13.1.1(c). |
| resource_id | role/deploy-runner | The specific resource, as the provider identifies it. Not a description of one. This is the field that makes a finding re-readable by somebody who was not there. |
| observed_value | Action: "kms:*" on Resource: "*" | What was actually there, quoted rather than characterised. “Over-permissive” is a conclusion. This is the evidence under it — §18(iii). |
| expected_value | Enumerated actions, resource-scoped | What the control objective asks for. Without it the reader is trusting the assessor’s memory of the framework. |
| result | FAIL | Pass, fail, not applicable, or not assessed. “Not assessed” is a real value and belongs in the file — it is what §10.1(ii) is about. |
| read_at | 2026-03-18T09:14:22+05:30 | The timestamp of the read, with the offset. In an estate that changes daily, a finding with no timestamp cannot be pinned to a moment and therefore cannot be defended at retest. |
| read_by | assessment-role/auditor-3 | The identity that made the call. It is the attribution that a shared role destroys, and the reason §12.2(iii) is worth honouring at the identity layer. |
| root_cause_id | RC-02 (no permission boundary on deployment roles) | The cluster the row belongs to. Added at triage rather than at collection, and it is the column that turns an export into a report — §16.2(i), §16.3(i). |
2. The logging coverage table
One row per account, one column per region, the retention value, and the date of the earliest event actually present — which is the column that catches a trail switched on for the audit. The grid below is filled with the numbers from the invented engagement further down this page. The shape is the point, not the values.
| Account | ap-south-1 | ap-southeast-1 | eu-west-1 | us-east-1 | Retention | Earliest event present |
|---|---|---|---|---|---|---|
| acct-prod-payments | Trail on | Trail on | Not enabled | Trail on | 90 days | 19 Dec 2025 |
| acct-prod-platform | Trail on | Trail on | Not enabled | Trail on | 90 days | 19 Dec 2025 |
| acct-data-warehouse | Trail on | Not enabled | Not enabled | Trail on | 365 days | 4 Mar 2025 |
| acct-sandbox-01 | No trail | No trail | No trail | No trail | — | No events |
| acct-sandbox-02 | No trail | No trail | No trail | No trail | — | No events |
| acct-logging | Trail on | Trail on | Not enabled | Trail on | 365 days | 4 Mar 2025 |
Read what the grid says that a sentence would not. Two accounts have no trail anywhere, so an incident in either is unreconstructable. One region is unlogged across the whole estate, including in the logging account itself. Three accounts carry ninety days against a stated obligation of one hundred and eighty under Direction (iv) of the 2022 Directions. And the earliest-event column shows that the ninety-day accounts have events going back only to December, which is consistent with the retention setting and is the check that would have caught a trail enabled the week before fieldwork. A report that answers “is logging enabled?” with a single yes contains none of that.
3. Two findings, written out in full
One configuration finding and one identity-path finding, because they are different animals and the second is the one a cloud audit exists for. Both are invented, for the same estate as the worked engagement below. Neither describes any client, and no outcome claim is being made by either.
Storage container serving exported records is readable without authentication
CCM domain: DSP — Data Security & Privacy. Workstream: configuration and posture.
Locator: Account acct-data-warehouse, region ap-south-1, container exports-reconciliation-2025. Read 2026-03-18T09:41:07+05:30 by assessment-role/auditor-1.
Observed: Container-level public-access block: disabled. Container policy: grants the read-object action to the anonymous principal, unconditioned. Objects enumerated from outside the tenancy with no credential: 41,208. Object naming indicates monthly reconciliation exports.
Expected: Public-access block enabled at the container and at the account. No policy statement naming an anonymous or wildcard principal for object reads.
Weakness and identifiers: CWE-732, Incorrect Permission Assignment for Critical Resource. No associated CVE — this is a configuration weakness rather than a software defect — and therefore no EPSS value, because EPSS is published per CVE. The report’s methodology note says so rather than leaving the field blank.
Severity: Critical. Scored on CVSS v4.0, vector printed in full so the reasoning is visible, and labelled CVSS-B because only base metrics were supplied. The number is the consequence of exploitation. It is not a statement of how likely anybody is to have found it.
Evidence: The container policy document as returned by the API, the public-access-block configuration, the unauthenticated enumeration output with its timestamp, the object count, and the access-log extract from which the exposure window was inferred. All timestamped, all re-runnable.
Notification: Notified the day it was found, in writing, to the named point of contact — §16.3(ii) requires critical and high findings to be notified during the course of the audit on an as-and-when-found basis, and §16.4 requires high-risk vulnerabilities to be reported immediately on discovery with a recommended practical solution.
Closure evidence: Public-access block enabled at the container and at the account, and the policy statement removed. Verified by the auditing organisation re-reading both settings through the API, with timestamp and reading identity recorded, plus a repeated unauthenticated enumeration returning access denied. An organisation-level preventive control now refuses the creation of a public container, evidenced by a denial record rather than by its existence. §16.3(iv).
Privilege path from the deployment account to a production encryption key
CCM domains: IAM — Identity & Access Management, and CEK — Cryptography, Encryption & Key Management. Workstream: identity and privilege.
Locator: Start principal: role/ci-deploy-runner in acct-deploy. Ending capability: decrypt under key/prod-payments-cmk in acct-prod-payments, region ap-south-1. Read 2026-03-24T15:02:51+05:30 by assessment-role/auditor-2.
Observed: Three hops. One: role/ci-deploy-runner is assumable by the pipeline identity, which is in turn assumable by anybody who can merge to the release branch. Two: its policy permits assuming role/platform-deployer in acct-prod-payments, whose trust policy names the deployment account with no external condition and no branch condition. Three: role/platform-deployer carries a wildcard action on the key management service, resource-scoped to the account. The key policy for key/prod-payments-cmk does not independently restrict which principals in the account may call decrypt.
Expected: Trust conditioned on a specific workload identity rather than on the whole deployment account, enumerated key actions rather than a wildcard, and a key policy that names the principals permitted to use the key, so that the identity policy alone cannot confer use.
Weakness and identifiers: CWE-269, Improper Privilege Management, with CWE-266, Incorrect Privilege Assignment, on the wildcard limb. No associated CVE and therefore no EPSS value.
Severity: High. Every individual permission on this path was granted deliberately and is defensible on its own. That is precisely why the finding is the composition and not any one row. A list of over-permissive policies would have carried all three entries and been triaged to nothing.
Evidence: The three policy documents and the two trust policies, exported verbatim. The key policy. The last-used timestamps for each role. A policy-simulation result for the ending call, which is reproducible in a way that a live assume is not. And a written statement of which principals were enumerated and which were not, so that coverage is claimable.
Notification: Reported in the draft and walked through at the exit conference, because the remediation is a design change rather than a setting.
Closure evidence: A condition added to the trust policy on role/platform-deployer naming the specific workload identity, the wildcard replaced with four enumerated actions, and the key policy narrowed to the two roles that genuinely decrypt. Closure evidence is the policy documents before and after, plus a re-run of the policy simulation showing the original path now denied — because the finding was a path, closure is the path failing. A policy diff alone would not establish it: effective permission in a cloud tenancy is a composition.
Compare the two. The first could have come out of a posture tool and been written up in ten minutes. The value a person added was the object count, the exposure window and the notification the same day. The second could not have come out of a tool at all, because every permission on the path is individually defensible and only the composition is wrong — and a list of over-permissive policies, which is what a tool produces, would have carried all three entries into a triage meeting and out of it. That difference is the whole argument of the collection-and-analysis section above.
How closure is demonstrated when the fix is a policy change
How do you evidence remediation of a cloud misconfiguration?
An application finding closes against a version: a new build, a new hash, a re-test of the same request. A cloud finding usually has none of those. There is no patch and no version number — there is a setting that used to be one value and is now another, in an estate that changes every day. Five closure modes cover almost everything, and only one of them looks like a patch. The fifth, where the fix is a prompt or a model, is the one where re-reading the changed thing does not settle the question at all, because the system does not give the same answer twice.
| Mode | What it looks like | What closure evidence is | What to watch for |
|---|---|---|---|
| The fix is a setting | Public access is disabled on a storage container. A security group rule is narrowed. A trail is enabled in the two accounts that were missing it. | The setting, read back through the API by a party that did not change it, with the timestamp and the reading identity. §16.3(iv) puts the verification with the auditing organisation: “After remediation actions, follow-up audits should be performed by auditing organizations to verify closure of vulnerabilities and non-conformities highlighted in the previous audit.” | A screenshot from the person who made the change. That is a claim with an image attached. §16.3(iv) puts verification of closure with the auditing organisation, not with the team that made the change. §5(xvii) defines conflict of interest by reference to an auditor’s personal, financial or organisational interests, and names the overlap of remediation and audit expressly. Reading the same principle across onto an auditee verifying its own fix is our extension of it rather than the clause itself. |
| The fix is a policy — an identity policy, a key policy, a bucket policy | A wildcard action is replaced with an enumerated list. A key policy is narrowed to the roles that genuinely need to decrypt. A trust policy gains a condition. | The policy document before and after, plus a demonstration that the path the finding described is now refused. The second half is what makes it evidence rather than a diff: the finding was a path, so closure is the path failing. | A narrowed policy that is shadowed by a wider one elsewhere. Effective permission in a cloud tenancy is a composition, and a policy diff on its own does not establish the composition. |
| The fix is a preventive control — a guardrail, a service control policy, a pipeline check | An organisation-level policy that prevents disabling the trail. A deployment check that fails a template granting a wildcard. Automated remediation on a specific drift condition. | The control, plus evidence that it fires. A guardrail that has never refused anything is a configuration, not a control. Ask for the denial record, the failed build, or the remediation event. | The guardrail applied to the organisational unit that contains the accounts you already fixed, and not to the one that contains the accounts you have not looked at. |
| The fix is a prompt, a model or a tool schema | A system prompt is rewritten. A model endpoint is repinned to a different version. A tool is removed from the schema the model is given, or its arguments are constrained. An approval step is added before a consequential action. | Not a screenshot, because the system does not give the same answer twice. Closure is the same suite of attempts re-run in fresh sessions, at the same sampling parameters, against a stated model version, with the reproduction rate printed before and after. Nineteen successes in twenty attempts before and one in twenty after is a real, defensible closure, but “we could not reproduce it” is not, because nobody said how many times they tried. | A retest that ran three times and stopped, and a retest whose denominator is not stated at all. Watch also for the finding reopening on a provider model update with no change on your side — which is why the model version and the sampling parameters belong in the closure record itself, not only in the original finding. |
| The fix is a decision not to fix | The exposure is accepted for a stated period because the service is being decommissioned, or because the change would break a dependency outside your control. | Not closure at all, and the report should not call it that. §9.2(i) requires risk treatment — “retain, avoid, transfer and reduce” — for any reported vulnerability or observation to be “authorized & accepted by the head of the auditee organization”, and §9.2(ii) requires exceptions to be authorised by the head of the organisation who owns the application. The clause is not scoped by severity. | Acceptance recorded at the wrong level, or with no expiry. And note the consequence for an unfixed critical: clause 3.2.2 of the empanelment terms requires an empanelled auditor to report critical vulnerabilities with auditee details to CERT-In within five days where they were identified but not fixed even during follow-up audits, and clause 3.1.7 says audit reports and data go to CERT-In without the auditee’s permission. |
The sequencing problem nobody has written down
§13.1.2(iii) requires every change to be classified Minor or Major, and defines a Major Change by risk rather than by size — “high-risk, impactful to security”, expressly including “configuration adjustments that affect sensitive data or critical infrastructure” — and requires a major change to undergo a cyber security audit before implementation. In a cloud estate the remediation of a finding is a configuration adjustment, and a narrowing of a key policy plainly affects sensitive data. So a literal reading has some fixes requiring an audit before they can be applied, which is not a sensible way to run a remediation programme. The guidelines do not address this, and we are not going to pretend they do. The practical answer is to settle it in the engagement letter §14.1(ii) requires: state how remediation changes will be classified, and what assurance accompanies a major one — ordinarily the auditing organisation’s own review of the proposed change, followed by the follow-up audit §16.3(iv) already requires. Five lines in advance instead of a dispute at the re-test.
One more thing belongs in a closure pack for a cloud audit and rarely appears: the version record. §9.5(ii) asks that “version control and change management be effectively implemented so that the assets that were/are part of audit scope can be backtracked” — the sentence carries no modal in the original, so treat it as what the clause asks for rather than as a requirement. Where infrastructure is defined as code, the backtrack is the commit, and naming the commit that produced the audited state is the nearest cloud analogue to the application hash and version numbers §15.2.3(ii) requires to be obtained from the auditee and included in the audit report — and which §9.5(i) and §16.1(v) separately recommend be prominently featured in the audit certificate and reports. Keep those apart: §15.2.3(ii) is the mandatory limb and it is about the report. The certificate limb is a recommendation. Where infrastructure is not defined as code, there is no backtrack, and that is itself a finding. Re-testing and closure covers the general rules this section specialises.
If the account runs AI workloads
Does a cloud security audit cover AI and model-serving workloads?
Model-serving infrastructure, vector stores, training pipelines and agent runtimes are cloud resources, so they are inside the posture review by default and most of the work on them is ordinary work: an inference endpoint has a network exposure, a training job has an execution role, a vector store has an access policy and an encryption setting. Three things change when they are present, and one of them is the only genuinely hard problem on this page.
The first is incident classification. Annexure I of the 2022 Directions makes attacks affecting cloud computing systems reportable at item (xviii), and attacks on systems related to artificial intelligence and machine learning reportable at item (xx), both within six hours of noticing. Which item an incident in a model-serving account falls under — one, the other, or both — is a judgement the reporting entity makes on the facts: the Annexure classifies types, not incidents, and that reading is ours. CERT-In’s own explanation of item (xx) is narrower than most readers expect: “Attacks that target Machine Learning models with the intention to cause a malfunction are a growing threat. The attacks employs various techniques such as deceptive data, environment manipulation etc. to corrupt the model and cause the model to behave erroneously.” CERT-In describes its own annexure of explanations as illustrative. It is not a reportability test for a fact pattern.
The second is the criterion. The OWASP Top 10 for LLM Applications, 2026 edition, published on 4 August 2026, is a good orientation document — Prompt Injection is LLM01, and Excessive Agency moved up to LLM03 from LLM06 in the 2025 edition — and it is a ranked list of common categories. §8(ii) of the audit policy guidelines rules out “limited lists such as OWASP Top 10, SANS Top 25 and similar” as standards or references for audits, and on our reading the same logic reaches a list of the ten commonest weaknesses in large-language-model applications. Use it to orient, but do not put it in the criterion line of the scope of work. Where a management system is wanted rather than a testing criterion, ISO/IEC 42001:2023 is the AI management system standard, and CERT-In has its own class of engagement at §6(xxiii), AI System Audits, defined as “evaluation of AI systems for security, ethical alignment, transparency, data integrity, and resilience to adversarial manipulation”.
The third is evidence, and it is the one a general cloud methodology does not carry. Every other finding on this page closes by reading something back: the setting, the policy, the trail configuration. A behavioural finding in a model-serving application cannot be read back, because the same input does not produce the same output twice. That single fact changes what has to be recorded, what a finding looks like, and what closure means — and it is the subject of the rest of this section.
What you have to pin down before the first prompt
A finding against a model-serving application is a finding against a configuration, not against a model. If the configuration is not recorded, the finding cannot be retested, argued with, or defended when it stops reproducing. Seven fields, captured before testing starts and captured again at closure.
| Model identifier and version, exactly as the API returns it | The single field that decides whether a finding can be retested at all. Record the dated snapshot suffix if there is one. At closure, record it again — a changed string is the first thing to check when a result moves. |
| Whether the endpoint is pinned to a version or points at a floating alias | A floating alias moves when the provider moves it. It is a configuration finding in its own right on a regulated workload, and it is the reason a closed finding can reopen with no change on your side. |
| The system prompt text, and a hash of it | A finding is against a configuration, not against a model alone. §15.2.3(ii) already requires application hash values and version numbers to be obtained from the auditee and included in the audit report. Extending that discipline to the instruction layers is our reading of what the clause is for, not something the clause says. |
| The retrieval corpus, and its as-of date | Which documents were in it, and which sources may write into it. Without the date, a retest that fails to reproduce tells you nothing, because the corpus has moved under both runs. §13.2.3(ii)(b) treats the as-of date of the asset inventory as a report field, and the corpus deserves the same treatment. |
| The tool and function schema, exported verbatim | Tool definitions change more often than models do. Without the schema as the model received it, a behavioural finding cannot be distinguished at retest from one that was fixed by a tool being renamed. |
| The identity the workload acts under, and what it can reach | This is the part that is squarely inside the ordinary identity and privilege workstream, and it is the part that decides consequence. A model that says a forbidden sentence is a content problem. A model whose execution role can read the production database is a cloud finding. |
| Sampling parameters: temperature, top_p, and a seed where the provider exposes one | Temperature is the dial that turns a reproducible finding into an intermittent one. A fixed seed with fixed parameters is the closest thing to determinism available, and whether one was used changes how the reproduction rate should be read — so it is worth one line in the report either way. |
One limb of the data-handling thread belongs here and is easy to miss. Prompt and completion logs contain whatever a user pasted in, which in practice means customer records, contract text, support tickets and occasionally credentials. They are auditee data in the ordinary sense, so §10.3’s India-only storage rule, the encryption requirement and the deletion certificate all reach them — and an assessment platform that ingests a prompt log is ingesting exactly the material the clause is about. Ask where those logs go before the first export, not after.
What a finding looks like when the system is non-deterministic
A screenshot proves that something happened once. It does not carry the model version, the sampling parameters, the prompt bytes, the corpus state or the denominator, so it cannot be retested and it cannot be defended. The replacement is a measurement: repeat each successful variant in fresh sessions and record successes over attempts. One session is an anecdote. Twenty attempts with the denominator printed is a finding somebody can act on and argue with.
| The prompt, byte for byte | Including whitespace, invisible characters, line breaks and any encoding, kept as a raw artefact and pasted as a code block. A paraphrase is not a reproduction step, and a screenshot of a prompt is not a prompt. |
| The completion, in full | Not the interesting sentence. On an agent stack the interesting behaviour is in the intermediate steps: which tool was chosen, with what arguments, what came back, and what the model did next. |
| Successes over attempts, in fresh sessions, with the denominator printed as its own named field | This is the field that replaces the screenshot. Nineteen in twenty is a different finding from two in twenty, and both are real. State whether sessions were fresh or continued, because a continued session is contaminated by everything earlier in it. |
| The model version the rate was measured against | A reproduction rate with no model version attached is a number with no referent six weeks later, when the behaviour has either been fixed or has moved. |
| The severity, and the reproduction rate, as two separate things | CVSS scores the consequence of a successful exploitation. It has no probability metric: v4.0’s Threat group carries a single metric, Exploit Maturity, and its new Attack Requirements metric describes conditions outside the attacker’s control rather than a success rate. Stretching either into a reproduction rate misstates what the vector says. Score the consequence, print the rate beside it as a named field, and say in the methodology note that you have done so. Use FIRST’s nomenclature — CVSS-B where only base metrics were supplied, CVSS-BE where environmental values were — so the reader knows how much of the instrument the number represents. |
| The weakness class, and the honest statement that there is no CVE | §16.2(ii) requires every observation to be mapped to a CWE and a CVE. A behavioural finding in a model-serving application has a weakness class and no CVE, and because EPSS is published per CVE there is no EPSS value either. The correct answer is to say so in the methodology note — not to invent an identifier and not to drop the finding. That formulation is ours. The instrument requires the mapping and does not address the case where no identifier exists. |
Closure when the fix is a prompt or a model
The closure table further up this page carries a fifth mode for exactly this case, and it is the one that breaks the page’s own rule. Everywhere else, closure is the changed thing read back through the API by a party that did not change it. Here there is nothing to read back: a system prompt can be re-read, but re-reading it tells you the words changed, not that the behaviour did. Closure is the same suite of attempts re-run in fresh sessions, at the same sampling parameters, against a stated model version, with the reproduction rate printed before and after. Nineteen in twenty before and one in twenty after is a defensible closure. “We could not reproduce it” is not, because nobody said how many times they tried.
And one consequence belongs in the closure record itself rather than in a footnote. A behavioural finding can reopen on a provider model update with no change on your side, which is why the model version and the sampling parameters are part of the closure evidence and not just part of the original finding. Where the endpoint points at a floating alias rather than a pinned version, that is a configuration finding in its own right on any workload whose behaviour you have to be able to account for — and it is the ordinary cloud finding hiding inside the AI one.
Three sibling pages take this further: what AI red teaming is, red teaming an LLM application and AI incidents under CERT-In. If the question is whether an AI assessment replaces a conventional one, AI red teaming versus VAPT answers it.
What drives the cost and the duration
How much does a cloud security audit cost in India, and how long does it take?
No figures here, and that is a position rather than an evasion: a price quoted without a scope is a number attached to nothing, and in a cloud estate the scope is a count nobody has until the inventory is produced. What is useful is the arithmetic. Below are the variables an honest quote is built from, with the clause behind each, so you can read a proposal instead of comparing two totals.
| Accounts multiplied by enabled regions §13.1.1(c), §13.2.3(ii)(b) | Not accounts. A cloud account is not a place, and resources exist per region. Nineteen accounts with four enabled regions each is seventy-six units of sweep, not nineteen. The inventory the scope is derived from, and its as-of date, decide the count — which is why an out-of-date inventory produces a cheap quote and an expensive surprise. |
| How many of the twenty-six §6 classes are genuinely in play §6 | Cloud Security Testing is one class of twenty-six. A posture review, an identity-graph analysis and a penetration test are different specialists, and adding the API tier at §6(xii), source code review at §6(ix) or an AI system audit at §6(xxiii) is another person rather than another afternoon. |
| Whether the pipeline, the API tier and the SaaS estate are in or out §13.1.1(a), §13.1.1(f), §8(ii) | These are the three adjacent surfaces that belong in the same purchase order and almost never arrive in it. The deployment pipeline holds the credentials that change everything else, and §8(ii) names the OWASP DevSecOps Maturity Model for it. The SaaS estate holds a large share of the data. Each is a real addition to the price and each is cheaper bought now than bought after the incident. |
| The split between automated collection and analysis §8(i), §13.2.2(ii) | The clause that says solely tools-based testing should be discouraged is, commercially, a statement about labour. Collection is cheap and nearly complete, while the graph, the clusters, the blast radii and the coverage statement are the expensive half — and the half a buyer cannot see in a total. |
| Whether non-production accounts are in scope §13.1.1(e) | Testing, UAT and development assets are inside the scope the clause describes, “to achieve complete audit coverage”. In a cloud estate that is frequently more than half the accounts, and they are the accounts with the widest permissions and the thinnest guardrails. |
| Whether the follow-up audit is inside the price §9.3(iv), §13.1.1(g), §16.3(iv) | A quote without a re-test is a quote for half the job and will always look cheaper than one that includes it. §9.3(iv) puts the follow-up inside the scope or RFP and requires it to be conducted by the auditing organisation after closure, and §16.3(iv) makes it the mechanism by which closure is verified at all. |
| How the fee itself is structured §7 | Read this one before the total. §7 states that commercial arrangements “must be structured to maintain independence”, that payments “should not be contingent upon the outcome of the audit—whether favorable or unfavorable—nor should they be tied to the submission or approval of any closure reports”, and that it is recommended fees be based on predefined scopes, deliverables and timelines. Note the modality: the “must” attaches to structuring for independence, and the contingency limbs are “should not”. A quote priced on issue of a clean result is not a price. It is an arrangement §7 is written about. |
| What your own side has ready on day one §13.1.4(ii), §15.1.2 | The cheapest engagement is the one that does not wait. The account list exists, the assessment role is approved, a technical point of contact is assigned under §13.1.4(ii), and the trail is already on. Every day the team waits for a change approval is a day you bought. |
On duration, and why the fieldwork is the short part
The shape of a cloud engagement is front-loaded and back-loaded, with a narrow middle. Seven of the twelve steps happen before anybody reads a resource, and the closure and follow-up work happens after the draft. The invented engagement set out below — invented, to show the shape of the work — runs sixty-eight days from scope freeze to final report, of which twelve are fieldwork. Most of the rest is governance before it and closure after it, and none of that is padding: the scope, the boundary, the benchmark and the access design are what decide whether the twelve days mean anything, and the follow-up audit §16.3(iv) requires is what turns a report into a reduction in risk.
Two questions catch a bad quote faster than anything else. Ask for the man-hours as well as the calendar days, which §13.2.2(ii) requires the test plan to carry, and divide them by accounts multiplied by enabled regions. Then ask how the fee is structured, because §7 says the commercial arrangements “must be structured to maintain independence” and that payments “should not be contingent upon the outcome of the audit” nor tied to the submission or approval of any closure reports. A quote priced on issue of a clean result is not a cheaper audit. It is the arrangement that clause is written about.
What it looks like with dates and counts against it
The engagement below is invented. It is not a client, it is not a sector, the numbers are made up to show the shape of the work, and nothing in it is a claim about an outcome we have achieved for anybody. It is here because “a cloud audit takes a few weeks” is useless next to a proposal, and a gate-by-gate sequence with counts against it is something you can hold up beside the document in front of you. Read the last column: it is what happens when the gate is skipped.
| When | Gate | The artefact | Who | What happens when it is skipped |
|---|---|---|---|---|
| Day −18 | Estate enumerated, scope frozen against a dated inventory | Inventory extract marked “updated to 4 March”: 19 accounts, 4 enabled regions, 61 distinct services in use. Scope schedule names 17 accounts in scope and excludes 2 by decision, with the reason written down. | Platform owner and internal audit, per §13.1.1(c) and (d) | The scope is written from the architecture diagram. The diagram has 6 accounts on it, the organisation has 19, and the difference is where the finding that matters lives. |
| Day −14 | Benchmark, boundary and test plan agreed | Engagement letter naming the CSA Cloud Controls Matrix at a stated version as the audit criterion, a shared-responsibility table saying which side of the line each control area sits on, and a test plan quoting 12 calendar days and 150 man-hours. | Authorised representatives of both organisations, per §13.1.7(i)(a) and §14.1(ii) | Only calendar days are quoted. Twelve days across 17 accounts can be 40 man-hours or 400, and the invoice looks the same. |
| Day −7 | Assessment access designed, not requested | A purpose-built assessment role, created by the platform team on a change record, trusted only from the auditor’s named source addresses, with a 30-day expiry condition and explicit denials on secret retrieval and object reads. One identity per named auditor. Trail coverage confirmed in all 17 accounts first — and found absent in 2. | Auditee, per §9.6(i), §15.1.2 and §12.2(iii) | A broad managed read policy is attached to a single shared role because that is what the template said. Attribution is lost, secret material is readable, and the role outlives the engagement. |
| Day −4 | Tooling reviewed and approved | Tool list with licensing confirmation, a written note of where the assessment platform runs and in which tenancy and region findings will be held, and the results of the controlled test formally approved by a named representative. | Both sides, per §13.2.2(iii)–(iv) | The tooling is a hosted service in another jurisdiction and nobody asks. A complete map of the estate leaves the country on day one, against §10.3 and the 2014 data-handling policy. |
| Day 1–4 | Configuration and posture sweep | Control results file: 17 accounts × 4 regions, one row per control objective per resource. 812 rows failing before triage, clustered on 6 root causes. | Assessment team | The output is delivered as 812 findings. Nobody can act on 812 of anything, and the cluster analysis is the part that makes it a report rather than an export. |
| Day 5–7 | Identity and privilege analysis | Policy graph across all 17 accounts. 3 named escalation paths, each written as a path with a start principal, the assume-role hops and the ending capability. One of them starts at a build role and ends at a production key. | Assessment team | A list of over-permissive policies is produced instead. Every entry on it is individually defensible, so the list is triaged to nothing and the composition survives. |
| Day 6 | A critical, notified the day it was found | Written notification of a storage container holding exported records, readable without authentication, with the object count, the exposure window inferred from the access log and a recommended immediate action, sent to the named point of contact on the agreed channel. | Audit lead, per §16.3(ii) and §16.4 | It is held for the draft. The exposure continues for eleven days for no reason, and the incident-reporting clock under Annexure I item (xviii) starts later than it should have. |
| Day 8–12 | Network, data, keys and logging coverage | Reachability results and the annotated segmentation diagram, resource-and-data inventory by region, key policies with their grants, and trail coverage stated per account and region, including the 2 accounts with no trail and the retention value against 180 days. | Assessment team, with the 2022 Directions verification per §15.2.1(iv) | The logging workstream is dropped for time. It is the workstream that decides whether any future incident is reconstructable, and it is the one most often cut. |
| Day 19 | Draft report and exit conference | Draft carrying the §16.1(ii) contents, an executive summary for the board, 812 control failures resolved into 41 observations with 6 root causes, closure timelines by severity, every in-scope account named, and 1 account named as unassessed because its read role was never approved. | Auditing organisation to senior management, per §16.2(i) and §17(iii) | A PDF arrives and nothing is agreed. Remediation competes with the delivery backlog and loses. |
| Day 20–38 | Remediation, mostly by guardrail | 4 of the 6 root causes closed by organisation-level preventive controls rather than by individual fixes, and 2 closed account by account. The build-role-to-production-key path closed by a condition on the trust policy. 3 observations formally accepted for a stated period with the authorising office recorded. | Platform engineering per §9.3(iii), and acceptances per §9.2 | Each of the 812 rows is fixed individually and nothing prevents the 813th. The next cycle produces the same clusters, recorded as repeat observations under §15.2.1(iii). |
| Day 39–43 | Follow-up audit verifying closure | Re-read of each changed setting through the API by the auditing organisation, with timestamps and the reading identity. A denial record from each new guardrail proving it fires. And the unassessed account brought into scope and assessed. | Auditing organisation, per §16.3(iv) | The closure column is filled in by the engineers who made the changes. That is a self-assessment wearing a report’s formatting. |
| Day 44–50 | Final report, revocation, deletion certificate | Final report issued after closure and the follow-up audit, signed under §9.5(iii). Assessment role and trust relationship removed, with the change record as evidence. Working notes and evidence appendix supplied. Data deletion certificate issued. Scope freeze to final report: 68 days. | Audit file owner, per §9.5(iii), §10.3(iv) and §18(i) | The role is left in place “in case we need it for the re-test”. Two years later it is the first finding of the third audit. |
The same engagement as a sequence of steps
Twelve steps, and seven of them happen before anybody reads a single resource. That ratio is not bureaucracy: the scope, the boundary, the benchmark and the access design are what decide whether the fieldwork means anything.
Enumerate the estate before you write the scope
Produce the account or subscription list from the organisation’s own API, the enabled regions per account, and the services in use, and date it. §13.1.1(c) requires the scope to be derived from the consolidated and updated asset inventory and §13.2.3(ii)(b) requires that as-of date to appear in the audit report. Cross-check the list against the billing data, because the accounts missing from the organisation are the accounts missing from the inventory.
Declare the engagement class and the benchmark in the scope of work
§13.2.3(i)(a) requires the scope to state the type of audit. Say Cloud Security Testing in the sense of §6(xviii), name the CSA Cloud Controls Matrix that §8(ii) and §13.1.7(i)(a) name, state the version, and say which accounts and regions it applies to. Where you are also using CIS Benchmarks, name the benchmark and the platform version and attribute it to GIGW’s chapter 5.3 preamble rather than to CERT-In.
Draw the shared-responsibility line in writing, and say which side each control sits on
§13.1.5 allocates the audit of infrastructure to whoever owns and operates it. Put the line in the engagement letter by service model — infrastructure, platform, software — and record, for each control area, whether the evidence will come from your tenancy or from a provider assurance artefact. This is the single document that prevents an argument in week four about why nobody tested the hypervisor.
Have the scope vetted by someone who does not run the platform
§13.1.1(d) requires the scope to be vetted by the internal audit team in consultation with the CISO. Include non-production under §13.1.1(e) and third-party, vendor and supply-chain risk under §13.1.1(f). The platform team’s scope will be the accounts the platform team looks after, which is a smaller number than the accounts you own.
Sign the NDA, then fix the terms in an audit engagement letter
§13.1.7(ii) requires a non-disclosure agreement before the commencement of any audit activities and points at CERT-In’s own template. §14.1(ii) then requires the agreed terms to be “formally documented in an audit engagement letter” signed by authorised representatives of both organisations. For a cloud engagement, add four fields the general template will not have: where the assessment tooling runs, in which tenancy and region findings are stored, the deletion-certificate date, and the source addresses testing will originate from under §13.2.7.
Create the assessment access yourself, time-bounded, and log it
§9.6(i) makes “providing access to the information infrastructure” one of the duties that must not be delegated. §15.1.2 requires temporary access only, revoked immediately on completion. Create a purpose-built assessment role rather than attaching a broad managed read policy, and build its denials capability class by capability class — the table under Getting read-only assessment access sets out the ten classes and which side of the line each belongs on. Give each auditor their own identity under §12.2(iii), and confirm the control-plane trail is on in every account before the role exists rather than after.
Approve the tooling before it runs
§13.2.2(iii) requires a tool list with written confirmation on intellectual property and licensing. §13.2.2(iv) requires the auditing organisation to understand the origin and functionality of its tools, to have tested them in a controlled test environment, and to have those results “formally reviewed and approved by an authorized representative of the auditee organization”. Where a collector or agent is deployed inside your accounts, §13.2.2(v) treats installation as something done in the presence of your system administrator — and the 2018 auditor guidelines require removal afterwards with your acceptance.
Run the posture review across every account and region in scope
Configuration against the benchmark, identity and privilege as a graph, network exposure and segmentation, data protection and key management, logging and detection coverage. §15.2.1(iii) requires observations from the previous cycle to be revalidated, with unresolved ones recorded as repeat observations. §15.2.1(iv) requires verification of compliance with the CERT-In Directions of 28 April 2022 in every audit assignment, with findings and evidence in the report — which is where the time-synchronisation, 180-day log and point-of-contact checks enter a cloud engagement.
Take critical and high findings as they arrive
§16.3(ii) requires critical and high findings to be notified “during the course of audit on as and when found basis”, as well as in the final outcome report, and §16.4 requires high-risk vulnerabilities to be reported to the auditee immediately on discovery with a recommendation for a practical solution. In a cloud audit the as-and-when finding is usually an exposed data store, and the hours between discovery and the draft report are hours of live exposure with no upside.
Close the findings, then have the closure verified by the auditor
Patching and correction is the auditee’s responsibility under §9.3(iii). Verification is the auditor’s under §16.3(iv). What counts as closure evidence depends on which of the five modes the fix falls into, and those are set out in full under Closure when the fix is a policy change. Where something is accepted instead of fixed, §9.2 requires the treatment or exception to be authorised and accepted by the head of the organisation, and the clause is not scoped by severity.
Revoke the access, collect the deletion certificate, and file the pack
Remove the assessment role and the trust relationship, and keep the evidence that you did. §10.3 requires auditee data to be held in India, encrypted, and wiped so that it cannot be retrieved by any known forensic technique, with a formal certificate of deletion issued to you. Where the agreement is silent, retention defaults to one year and is limited to the audit reports. Collect the working notes §18(i) contemplates while the team still remembers the engagement.
Classify every change from that point on
§13.1.2(i) sets the floor at one audit a year and notes that sectoral regulators may increase the frequency, and §13.1.2(ii) treats that as a minimum. §13.1.2(iii) requires every change to be classified Minor or Major, with a Major Change — “high-risk, impactful to security”, expressly including “configuration adjustments that affect sensitive data or critical infrastructure” — requiring a cyber security audit before implementation. In a cloud estate that definition is unusually live, because configuration adjustments are what the estate is made of. §9.5(ii) asks that “version control and change management be effectively implemented so that the assets that were/are part of audit scope can be backtracked” — which, for infrastructure defined as code, is the commit you can point at.
Ten ways a cloud audit goes wrong
Each one is common, each one has a clause behind it, and each one carries a diagnostic you can run this week against an engagement that has already happened.
The cloud audit is a web application test with the word cloud in the preamble
The engagement tests the application running on the infrastructure and never reads the infrastructure. §6(xviii) describes something else — evaluating the security measures, configurations and vulnerabilities of cloud-based systems, applications and infrastructures — and §13.1.1(a) names “cloud architecture” as a scope item in its own right, alongside applications rather than inside them.
Where it starts: Scoping, discovered at the report
The signal: The findings are all HTTP. No finding names an account, a region, a role, a key or a bucket policy.
What it costs: The engagement, plus the one you now have to buy properly.
The diagnostic: Read the last cloud report and count the findings whose subject is a cloud resource rather than a request. If the count is zero, the control plane was never assessed.
The scope names accounts and forgets regions
A cloud account is not a place. Resources exist per region, and the automation that hardened the primary region was frequently never run against the others. §13.1.1(c) requires the scope to come from the consolidated and updated asset inventory. An inventory by account only is half an inventory.
Where it starts: Scoping, discovered by an incident in a region nobody deploys to
The signal: The scope schedule has one column. Nobody can say how many regions are enabled per account.
What it costs: Unassessed resources with production data in them, and a coverage claim that is not true.
The diagnostic: Enumerate enabled regions per account this afternoon. Every organisation that does this for the first time finds something in a region it does not use.
“Read-only” is granted as a broad managed policy on a shared role
A general-purpose read policy typically permits reading configuration, key metadata and, depending on the policy, secret material and object data. §15.1.2 requires temporary access only, revoked immediately on completion. §12.2(iii) requires the auditee to verify identities and designations, which a shared role makes impossible. The risk here is ours to state rather than the instrument’s: the clauses govern the grant, and the breadth of a cloud read policy is a platform fact.
Where it starts: Access grant, discovered at the second audit
The signal: One role, one external trust, no expiry condition, and nobody can name who used it on which day.
What it costs: A standing external path into the estate and no attribution for anything done through it.
The diagnostic: List the roles in your accounts that are assumable by an external principal, and check each one against an engagement that has finished. The ones you cannot tie to a live engagement should not exist.
The audit stops where the provider starts, and nobody says so in the report
§13.1.5 is explicit that responsibility for auditing infrastructure owned and operated by another organisation lies with that organisation, because the content owner “does not have access to or control over these assets”. That is a correct limitation, and a limitation only helps a reader if it is written down. §16.1(ii) requires the report to state exemptions, limitations and other constraints.
Where it starts: Reporting, discovered by a customer’s reviewer
The signal: The report has no limitations paragraph, or one that says “standard limitations apply”.
What it costs: A conclusion that reads wider than it is, which is the kind of overstatement that costs a deal when the other side reads carefully.
The diagnostic: Turn to the limitations paragraph of your last cloud report first. If you cannot tell from it which half of the shared-responsibility model was assessed, nor can anybody else.
A provider assurance report is treated as covering your configuration
It covers the provider’s controls over the provider’s system for a stated period. Your tenancy configuration is yours, and the complementary controls the report identifies are the specific things it assumes you are doing. A provider’s report is evidence about the part of the estate your auditor cannot reach — not a substitute for assessing the part they can.
Where it starts: Evidence assembly, discovered in a questionnaire
The signal: The audit file contains the provider’s report and no control results from your own accounts.
What it costs: A file that answers a question nobody asked, and does not answer the one they did.
The diagnostic: Open the report at its complementary user entity controls section and count how many of them you can currently evidence. That count is your real starting position.
Logging is assessed as a setting rather than as coverage
“Is the trail on?” is answered for the account somebody is looking at. The useful question is per account and per region, against a retention number, with the destination protected from the accounts being logged. Direction (iv) of the 2022 Directions requires logs of all ICT systems for a rolling period of 180 days, and §15.2.1(iv) requires compliance with the Directions to be verified in every audit assignment.
Where it starts: Fieldwork, discovered during an incident
The signal: A single yes in the report. No per-account table, no retention value, no destination policy.
What it costs: An incident nobody can reconstruct, in the account nobody was logging.
The diagnostic: Ask for the coverage table. One row per account, one column per region, the retention value, and the date of the earliest event actually present.
The findings are counted instead of resolved into causes
A posture tool will produce hundreds of failing rows from a handful of underlying decisions. §16.2(i) requires an executive summary that translates technical findings into relevant business risks, which cannot be done from a count. §16.3(i) requires recommendations to be practical and implementable.
Where it starts: Reporting
The signal: The headline number is in the hundreds and the recommendations are one per row.
What it costs: A remediation programme that closes rows and never changes what produced them, so the same clusters return next cycle.
The diagnostic: Group the failing rows by the decision that caused them. If eight hundred rows collapse into six causes, the report should have been about six things.
Remediation is itself a major change, and nobody sequences it
§13.1.2(iii) requires every change to be classified Minor or Major, and defines a Major Change by risk rather than size — “configuration adjustments that affect sensitive data or critical infrastructure” are named expressly — with a major change requiring a cyber security audit before implementation. A cloud fix is a configuration adjustment, which means some remediations are themselves changes the clause bites on. The guidelines do not address the sequencing of a fix that is also a major change. That gap is real and this reading of it is ours.
Where it starts: Remediation
The signal: Nobody has classified the remediation changes at all, so the question has not arisen.
What it costs: Either a stalled remediation or an unclassified change, and an argument at the next audit about which.
The diagnostic: Settle it in the engagement letter under §14.1(ii): how remediation changes will be classified, and what assurance accompanies a major one. It is a five-line paragraph written in advance and a six-week dispute discovered late.
The estate changes during the engagement
§15.1.1(ii) asks the auditee to refrain from unusual or major network changes during the audit period. In a cloud estate with continuous deployment, ordinary operation changes the thing being assessed while it is being assessed. Where the account serves models, there is a second version of this that nobody is responsible for: a managed model endpoint pointed at a floating alias moves when the provider moves it, mid-window, with no change on your side and no entry in your change record.
Where it starts: Fieldwork
The signal: The control results file has no timestamps, so a disputed finding cannot be pinned to a moment. For model-serving accounts, the signal is that nobody can say which model version was behind the endpoint on the day the finding was raised.
What it costs: Unwinnable arguments about whether a finding was ever true, and a re-test that compares two different estates.
The diagnostic: Timestamp every read and record the deployment events inside the window. This is also what §9.5(ii) is asking for when it asks that assets in the audit scope “can be backtracked”. For model endpoints, record whether each one is pinned to a version or points at a floating alias, and record the version as returned by the API at the time of test.
The auditing organisation cannot actually audit cloud
Empanelment is a standing, not a capability statement. CERT-In publishes a snapshot per empanelled organisation whose capability field is a Yes or No answer against the categories that organisation itself lists, under a heading inviting it to add more — and there is no fixed taxonomy, so cloud appears on some snapshots and not on others. §12.2(iv) puts the checking duty on you: the auditee should understand the auditing organisation’s methodology, tools and “experience in the relevant domain” before selecting.
Where it starts: Selection
The signal: The proposal is a web application methodology with a cloud heading, and nobody on the team can name a cloud control framework.
What it costs: A correctly empanelled organisation delivering the wrong engagement, competently.
The diagnostic: Read the specific organisation’s snapshot in CERT-In’s published list rather than assuming a standard set of categories, and ask which control framework they will use and at which version. “CIS, because CERT-In requires it” is a wrong answer to a fair question.
Eight sentences you will hear, and what to say back
The failure modes above are the retrospective version. This is the live one: the moment in a scoping call where a reasonable-sounding sentence costs you the engagement, and the clause that answers it. Each reply is a sentence to say out loud rather than a paragraph to absorb, and none of them is an argument about competence — every one is a request that something be written down.
“We audit against CIS Benchmarks, because that is what CERT-In requires.”
Say: “CERT-In’s audit policy guidelines name the CSA Cloud Controls Matrix for cloud security, at §8(ii) and again at §13.1.7(i)(a). CIS is named in the preamble to chapter 5.3 of the GIGW manual. Which one are you proposing, and at which version?” CIS Benchmarks are excellent and a CIS-benchmarked cloud audit is a good audit. The reply is not an objection to the benchmark. It is a request that the scope of work cite it to the instrument that actually names it, because a customer’s reviewer who checks will find the attribution wrong.
“The scope is fixed — it is our standard cloud package.”
Say: “§13.1.1(b) puts scope definition with the auditee, in consultation with the auditing organisation, and §13.1.1(c) says it must be derived from the consolidated and updated asset inventory. Here is our account and region list with its as-of date. Price against that.” A standard package is a legitimate commercial product. It is also, in a cloud estate, a guess at a number of accounts — and the gap between the guess and the inventory is where the coverage claim stops being true.
“We will send you the access template we usually use.”
Say: “§9.6(i) lists providing access to the information infrastructure among the duties that belong to the owner of the infrastructure, and says that responsibility must not be delegated. We will create the role, in our tenancy, on our change record — send us the check list and we will derive the permissions from it.” A template is the widest role that reliably works, which is a rational answer to their problem and not to yours.
“Read-only access cannot hurt you.”
Say: “Then it will not mind these denials.” Hand over the capability list: secret and credential retrieval, object and blob contents, database snapshot export and sharing, decrypted parameter-store reads, key use as distinct from key-policy reads, and signed-URL generation. A supplier who can work inside those denials is running a posture review. A supplier who cannot should say which checks need the wider grant and what is lost by refusing them — which is exactly the conversation §13.2.2(iv) gives you before the tooling runs.
“The provider is independently audited, so the infrastructure is covered.”
Say: “Agreed, and §13.1.5 allocates that half to them. Which of our control areas will you evidence from their report, and which from our tenancy?” The provider’s report covers the provider’s controls over the provider’s system for a stated period. It says nothing about your configuration, and the complementary controls it identifies are a list of things it assumes you are doing — which is a to-do list for your side of the line, not a substitute for assessing it.
“Twelve days, all accounts.”
Say: “§13.2.2(ii) requires the test plan to include both calendar time and man-hours. What are the man-hours, and how are they split across accounts, regions and workstreams?” Twelve days across seventeen accounts can be forty man-hours or four hundred and the invoice looks the same. Then ask the second question: how much of that figure is automated collection and how much is analysis. §8(i) says solely tools-based testing should be discouraged because it can produce an incomplete view — commercially, that clause is a statement about labour.
“Retesting is a separate purchase order.”
Say: “§9.3(iv) says follow-up audits should be included within the scope or RFP proposal and must be conducted by the auditing organisation after closure, and §13.1.1(g) says the scope of work should clearly specify the requirement to conduct them. Please price the follow-up inside this engagement.” Until closure is verified, none of the risk has moved. A quote without a re-test is not cheaper. It is a quote for the half of the job that does not change anything.
“We do not need to look at the sandbox accounts.”
Say: “§13.1.1(e) requires assets related to testing, UAT, development and production environments to be included to achieve complete audit coverage.” The sandbox accounts usually have the widest permissions, the fewest guardrails, a copy of a production dataset somebody pulled in to test something, and no control-plane trail. Excluding them is a decision the auditee is entitled to make — it is not a decision that can be made silently, because §16.1(iii) puts every in-scope asset in the report and the exclusion has to be visible somewhere.
Twenty questions to ask before you sign anything
What should I ask a cloud security audit vendor before signing?
Read these down the phone. Every one has a clause behind it, so none of them is an opinion a supplier can argue with, and the answers to the first four will usually tell you whether to ask the rest.
- 01 Which engagement class is this — Cloud Security Testing under §6(xviii), a penetration test under §6(iv), or both scoped and priced separately? (§13.2.3(i)(a))
- 02 Which control framework, at which version, and which profile within it? The guidelines name the CSA Cloud Controls Matrix for cloud security at §8(ii) and again as a contract term at §13.1.7(i)(a).
- 03 Exactly which accounts and which regions, and from which inventory as of which date? (§13.1.1(c), §13.2.3(ii)(b))
- 04 Are non-production accounts in scope, and are the sandbox, deployment and logging accounts named individually? (§13.1.1(e))
- 05 Where does the shared-responsibility line fall for each control area, and which provider assurance artefact covers the other side of it? (§13.1.5)
- 06 What are the man-hours as well as the calendar days, and how are they split across accounts and workstreams? (§13.2.2(ii))
- 07 Exactly which permissions does the assessment role need, check by check — and which four or five checks are driving the widest permission? Ask for the check list first and the permissions second. (§15.1.2)
- 08 Which of the ten capability classes below the role will hold, and which are denied outright — secret retrieval, object contents, snapshot export, decrypted parameter reads, key use, signed-URL generation? (§15.1.2)
- 09 Where does the assessment tooling run, in which tenancy and region will the findings be stored, and when is the deletion certificate issued? (§13.2.2(iv), §10.3)
- 10 From which source addresses will the assessment originate, so we can allow-list them and alert on anything else? (§13.2.7)
- 11 How will critical findings reach us during the engagement — on what channel, to which named person, on what timescale? (§16.3(ii), §16.4)
- 12 Will the deliverable include the raw control results file and the configuration extracts as working notes, or only the narrative report? (§18(i), §18(iii))
- 13 How will observations with no associated CVE be scored and presented, given the mapping requirement? (§16.2(ii))
- 14 Is the follow-up audit in the scope and in the price, and will the auditor re-read the changed settings themselves? (§13.1.1(g), §9.3(iv), §16.3(iv))
- 15 How is the fee structured — against predefined scope, deliverables and timelines, or against an outcome or a closure report? (§7)
- 16 How much of the quoted effort is automated collection and how much is analysis, and what is the man-hour figure behind each? (§8(i), §13.2.2(ii))
- 17 If any account serves models, how will a non-deterministic finding be evidenced — reproduction rate over how many attempts, against which model version? (§18(iii), our own reading for the AI case)
- 18 Will the verification of compliance with the CERT-In Directions of 28 April 2022 be included, and what evidence will it produce? (§15.2.1(iv))
- 19 Who reviews the audit team’s work, and is that verification team separate from the people who did the sweep? (§15.2.5(iii), §9.5(iii))
- 20 Which named people will perform the work, are any of them freelancers, consultants or serving notice, and are they declared to CERT-In? (§12.2(iii), §10.2(vi))
Two of those do most of the work and are the two most often left blank: the account and region list with its as-of date in question three, and the permission-by-check breakdown in question seven. A scope that fixes both has removed the two largest sources of disagreement about what was covered and the largest single source of standing risk in the engagement.
What should a cloud security audit scope of work actually say?
This page has told you a dozen times to write something into the scope of work. Here is the wording. Seven paragraphs that turn §6(xviii), §8(ii), §13.1.1(a)–(g), §13.1.5, §15.1.2 and §10.3 into contract language. Fill the bracketed fields, delete what does not apply, and have your own counsel read it — this is a starting point written from published clauses, not legal advice, and the clause numbers are there so your supplier can check them.
- Type of audit. The engagement is Cloud Security Testing in the sense given at §6(xviii) of CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines, version 1.0, dated 25 July 2025 — the evaluation and assessment of the security measures, configurations and vulnerabilities of cloud-based systems, applications and infrastructures. It comprises configuration and posture review, identity and privilege analysis, network exposure and segmentation review, data protection and key management review, and logging and detection coverage review. It is not a penetration test. Any penetration testing of the same estate is scoped, approved and priced separately under §6(iv).
- Audit criteria. The tenancy shall be assessed against the CSA Cloud Controls Matrix, version [X], being the cloud security framework named at §8(ii) and again at §13.1.7(i)(a). The audit programme shall be built from the Cyber Security Audit Baseline Requirements as §8(iii) and §13.1.8(i) provide. Where CIS Benchmarks are additionally used, the benchmark and the platform version shall be named, and shall be attributed to the preamble to chapter 5.3 of the GIGW 3.0 manual rather than to CERT-In. Limited lists, including the OWASP Top 10 and SANS Top 25, shall not be used as the audit criterion, in accordance with §8(ii).
- Scope and inventory. The scope comprises the [N] accounts or subscriptions listed at Annexure A and the [N] enabled regions per account listed against each, derived from the consolidated asset inventory as updated to [date], which date shall be stated in the audit report per §13.2.3(ii)(b). Non-production accounts — testing, UAT and development — are [included / excluded], and the sandbox, deployment and logging accounts are named individually at Annexure A, per §13.1.1(e). Every account listed at Annexure A shall be named in the audit report per §16.1(iii). Any in-scope account that could not be assessed shall be named with reasons per §10.1(ii).
- Shared-responsibility allocation. For each control area at Annexure B, the parties shall record before fieldwork begins whether the evidence originates from the auditee tenancy or from a provider assurance artefact, consistent with the allocation at §13.1.5. The auditing organisation shall not represent that any assessment was performed on infrastructure owned and operated by the cloud service provider, and the report’s limitations paragraph shall state the boundary expressly per §16.1(ii).
- Access. [Auditee] shall create a purpose-built assessment role in each in-scope account, on its own change record, issuing one identity per named auditor. The role shall carry an expiry condition of [date] and the explicit denials listed at Annexure C, and shall be revoked immediately on completion of the audit per §15.1.2. Assessment shall originate only from the source addresses disclosed by the auditing organisation under §13.2.7. Tooling shall be named, its results of controlled testing formally reviewed and approved by [named representative] before deployment per §13.2.2(iv), and any collector or agent deployed inside the accounts shall be installed in the presence of [auditee]’s system administrator per §13.2.2(v) and removed on completion.
- Data handling. Auditee data, including configuration exports, console captures and log extracts, shall be stored only on systems located in India, encrypted at rest on auditor devices, and wiped on completion so that it cannot be retrieved by any known forensic technique, with a certificate of deletion issued to [auditee] per §10.3. This applies to artefacts taken from accounts in any region, including regions outside India. The assessment platform and the findings tracker shall run in [named tenancy and region]. No auditee data shall be shared with an overseas entity or partner without written authorisation per §16.6.
- Plan, reporting and closure. The test plan shall state both calendar time and man-hours, split by account and by workstream, per §13.2.2(ii). Critical and high findings shall be notified as and when found per §16.3(ii) and §16.4. The deliverable shall include the machine-readable control results file and the raw configuration extracts as working notes per §18(i), the environment statement per §15.2.3(i), severities scored on CVSS with the version and the vector printed and supplemented with EPSS where a CVE exists, every observation mapped to a CWE per §16.2(ii), and closure timelines by severity per §16.3(iii). A follow-up audit verifying closure, conducted by the auditing organisation, is included in this scope of work and in the price per §9.3(iv), §13.1.1(g) and §16.3(iv).
Three bracketed fields do most of the work and are the three most often left blank: the CCM version in the second paragraph, the inventory date in the third, and the denials at Annexure C in the fifth. The mapping table under the benchmarks heading above is how you build Annexure B, and the capability table under the access heading is how you build Annexure C.
The roles, stated plainly
Who does what in a cloud audit, from scope to closure?
Here is who owns each part of an Indian cloud audit engagement under CERT-In’s own rules.
| Activity | Who owns it | What everyone else does |
|---|---|---|
| Defining the cloud scope and selecting the auditor | The auditee organisation | §9.6(i) is explicit that the complete audit process “must be undertaken up by the auditee organization itself” — defining the audit scope, selecting the auditing organisation, providing access to the information infrastructure, and ensuring closure of all audit observations — and that “this responsibility must not be delegated”. The same clause adds that the organisation “may seek external support for specialized expertise, while retaining full ownership and accountability”. |
| Granting the assessment access | The auditee organisation | Providing access is one of the four duties §9.6(i) enumerates, and §15.1.2 governs its form: temporary only, revoked immediately on completion. The role is created by you, in your tenancy, on your record. |
| Performing the audit | The empanelled auditing organisation, on engagements where empanelment is required | §10.5(vii) prohibits an empanelled organisation from sub-letting or outsourcing an audit assignment, which is a rule about the auditor’s own work — it does not touch the auditee-side work §9.6(i) describes. |
| Auditing the provider’s infrastructure | The provider | §13.1.5 allocates the audit of a server, its operating system, the hosting application software and any backend database application software to the organisation that owns and operates it. Neither you nor your auditor can reach that side of the line. What you can do is read the provider’s assurance reporting and act on the complementary controls it identifies. |
| Signing the audit report | The empanelled auditing organisation | §9.5(iii) requires reports to be signed only by manpower declared to CERT-In in the organisation’s snapshot information: by the auditors who conducted the audit, then by a designated reviewer from mid-management who was not part of the audit team, then authorised and signed by the head of the auditing organisation. |
| Sending the report and metadata to CERT-In within five days | The empanelled auditing organisation | §10.6 of the 2025 guidelines and clause 3.2.2 of the empanelment terms both impose it, and §13.2.1(iii) requires the auditor to tell you about the duty before the assignment begins. Clause 3.2.2 also requires critical vulnerabilities that were identified but not fixed even during follow-up audits to be reported to CERT-In with auditee details. An auditee neither files nor controls those submissions. |
| Changing the configuration | The audited organisation | §9.3(iii) states that the responsibility for patching and correcting vulnerabilities is the auditee’s. §9.2 requires risk treatment decisions and exceptions to be authorised and accepted by the head of the auditee organisation. |
| Verifying that the change worked | The auditing organisation, in the follow-up audit | §16.3(iv) puts verification of closure with the auditor, which is why the re-test belongs in the scope of work at §13.1.1(g) rather than in a change request six weeks later. What counts as closure evidence differs by the kind of fix, and is set out in full under Closure when the fix is a policy change. |
| Reporting a cloud incident to CERT-In within six hours | The entity that notices it | Annexure I item (xviii) makes attacks or malicious or suspicious activities affecting cloud computing systems, servers, software and applications mandatorily reportable within six hours. FAQ Q13 states that the obligation “is neither transferrable nor indemnified or dispense with”, and Q31 confirms the Directions apply to all entities so far as reporting a cyber incident is concerned, including where the affected data sits in a third party’s systems. No auditor, provider or managed service provider discharges this for you. |
We deliver CERT-In audits
We deliver CERT-In audits, end to end, with our CERT-In empanelled partners. See how a CERT-In audit runs with us.
The primary sources, with the clauses relied on
Every assertion on this page traces to one of the documents below, each named with its issuing body, its version and its date. Every primary-source PDF was fetched and checked on content type and byte count rather than on status code, because cert-in.org.in answers 200 with a small HTML page for unknown paths. Two entries are web pages rather than documents and are labelled as such. Where a later version exists, it supersedes what is written here.
- CERT-In, Comprehensive Cyber Security Audit Policy Guidelines, version 1.0, 25 July 2025. 69 pages, 20 numbered sections. The instrument this page is built on. Relied on at §2 (the binding formula, which does not enumerate the provisions it refers to), §5(vi)–(viii) and §5(xiv)–(xv) (non-conformity, root cause analysis, closure report, staging and production), §5(xvii) (conflict of interest, and its scope), §5(xxiv) and §16.2(ii) (CVSS, EPSS, CWE and CVE), §6 and §6(xviii) (the twenty-six classes, and Cloud Security Testing), §7 (independence and the structuring of fees), §8(i)–(iii) (solely tools-based testing and its stated reason, the framework list naming the CSA Cloud Controls Matrix, and the audit baseline), §9.2, §9.3(iii)–(iv), §9.5(i)–(ii), §9.6(i), §10.1(i)–(ii), §10.3, §10.5(vii), §12.1(i), §12.2(iii)–(iv), §13.1.1, §13.1.2, §13.1.4, §13.1.5, §13.1.7(i)(a), §13.2.2(ii)–(v), §13.2.3, §13.2.5, §13.2.7, §14.1(ii), §14.3, §15.1.1–§15.1.2, §15.2.1(iii)–(iv), §15.2.2, §15.2.3(i)–(ii), §15.2.5(iii), §16.1, §16.2, §16.3, §16.5, §16.6, §17(iii) and §18. cert-in.org.in
- Directions under sub-section (6) of section 70B of the Information Technology Act, 2000, No. 20(3)/2022-CERT-In, 28 April 2022, including Annexure I and Annexure II. Direction (i) on time synchronisation, direction (iii) on the point of contact, direction (iv) on the 180-day rolling log period maintained within Indian jurisdiction, direction (v) on the five-year subscriber records kept by data centres, virtual private server providers, cloud service providers and VPN service providers, and Annexure I item (xviii), which makes attacks or malicious or suspicious activities affecting cloud computing systems, servers, software and applications mandatorily reportable within six hours. cert-in.org.in
- CERT-In, Extension of timelines for enforcement of the Cyber Security Directions of 28 April 2022 for MSMEs and for implementation of the mechanism for validation of subscribers’ and customers’ details, No. 20(3)/2022-CERT-In, 27 June 2022. The order almost every vendor summary omits. It made the Directions effective on 25 September 2022 for micro, small and medium enterprises, and made the validation limbs of paragraph (v)(a) and (v)(f) — validated names, and validated addresses and contact numbers — effective on the same date for data centres, virtual private server providers, cloud service providers and VPN service providers. There are three effective dates for the 2022 Directions, not one. cert-in.org.in
- CERT-In, FAQ on the Cyber Security Directions of 28.04.2022, May 2022. 44 questions plus an annexure of explanations for the twenty incident types. Relied on at Q13 (the reporting obligation “is neither transferrable nor indemnified or dispense with”), Q30 (report on the information available and supplement later), Q31 (incidents affecting your data in a third party’s systems), Q35 (logs may be stored outside India provided the obligation to produce them is met in reasonable time), Q37 (what to log), Q41 and Q42 (native cloud time services), Q43 (the NTP hostnames) and the annexure explanation of incident type (xviii). The FAQ carries its own limitation, which should be quoted whenever it is relied on: it “is not a legal document and in no way whatsoever replaces, amends or alters any part of the IT Act, 2000” or the CERT-In Rules, 2013. cert-in.org.in
- Guidelines for Indian Government Websites and Apps (GIGW 3.0), manual — National Informatics Centre with STQC and CERT-In, chapter 5.3. The cybersecurity chapter preamble, which names ISO 27001, OWASP ASVS, the OWASP Top 10 and CIS benchmarks as the industry best security practices a host service provider and developer must adhere to, and guideline 5.3.2, “Hosting Environment has been secured for ensuring confidentiality, integrity and availability (CIA)”, whose government-organisation action is the hosting and container control list reproduced in part on this page. Cite the manual for every GIGW number: the live attributes page mis-numbers the third cybersecurity statement as 5.3.2, so that number appears on it twice. GIGW 3.0 manual (PDF)
- National Security Council Secretariat, Cyber Security Audit Baseline Requirements, publication NSCS-46-16 Rev 1.0, October 2020. Named at §8(iii) and again at §13.1.8(i) of the 2025 guidelines as the document auditees and auditing organisations should use to build their audit programme. Published on CERT-In’s website, but issued by the National Security Council Secretariat rather than by CERT-In itself. cert-in.org.in
- Cloud Security Alliance, Cloud Controls Matrix — project page, read 22 September 2026 (HTTP 200, text/html, 82,939 bytes). A web page rather than a document. Cited for what the CCM is, in CSA’s own words: a cybersecurity control framework for cloud computing “composed of 197 control objectives that are structured in 17 domains covering all key aspects of cloud technology”, which “provides guidance on which security controls should be implemented by which actor within the cloud supply chain”, with the Consensus Assessment Initiative Questionnaire built into it. The same page carries the banner “Version 4.1 of the CCM and CAIQ are now combined!”, and the 197-and-17 count is version-bound, so the two facts belong together. The seventeen domain names and codes listed on this page are read from the same source. §8(ii) and §13.1.7(i)(a) of the 2025 guidelines name the CCM “for Cloud Security”, but the CCM is not a Government of India publication and CSA is not a Government body. cloudsecurityalliance.org
- Center for Internet Security, CIS Benchmarks — web page. Cited on this page for one purpose: to place the attribution correctly. CIS Benchmarks are named in the preamble to GIGW 3.0’s cybersecurity chapter, alongside ISO 27001, OWASP ASVS and the OWASP Top 10. They are not named in CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines, which name the CSA Cloud Controls Matrix for cloud security instead. cisecurity.org
- CERT-In, Empanelment of Information Security Auditing Organisations — Terms and Conditions for Empanelment, version 7.2, April 2024. 10 pages. Relied on at clause 2.1 (CERT-In is not a party to the auditor–auditee contract), clause 3.1.7 (no sharing of client data without written permission, but audit reports and data go to CERT-In without it), clause 3.2.2 (report and metadata within five days of completion, and unfixed critical vulnerabilities with auditee details), and clause 4.2 (the single permitted sentence describing an auditor’s relationship with CERT-In). cert-in.org.in
- CERT-In, Policy Guidelines for Handling Audit related Data, version 1.0, June 2014. 5 pages. Required by name at §10.3(vii) of the 2025 guidelines. Its §5.3.3 is the rule most directly aimed at cloud: an audit report “should not be shared / hosted on online internet file services, online sharing platforms and cloud services, unless the service is under technical and administrative control of the auditing organization or as specifically authorized by the auditee”. §5.1.6 restricts storage to systems located in India, and §5.2.2 bars sharing with an overseas partner unless the auditee specifically authorises it. cert-in.org.in
- CERT-In, Guidelines for CERT-In Empanelled Information Security Auditing Organizations, version 3.0, May 2018. 6 pages, under three headings: People, Technical, Process. The 2018 ancestor of the tools rule, the verification team that checks the audit team, the prohibition on distributed denial of service testing over the internet and on “any form of flood testing where a person, network, system, or service, is overwhelmed from a larger and stronger source”, the duty to remove tools afterwards with the auditee’s acceptance, and the line that reads across to every cloud-hosted testing platform: the auditor “will ensure there is no mirroring of data outside the country”. cert-in.org.in
- CERT-In, published list of empanelled information security auditing organisations, with snapshot information per organisation. The roster §10.2(vi) and §12.3(iii) require an auditing organisation to deploy from, and the snapshot §12.1 tells an auditee to use when selecting one. Its capability field is a Yes or No answer against the categories each organisation itself lists, under a heading inviting it to add more — cloud is one of the lines some organisations answer against, and there is no fixed taxonomy, so read the specific organisation’s snapshot rather than assuming a standard list. cert-in.org.in
- FIRST, Common Vulnerability Scoring System — specification documents for version 4.0 and version 3.1. Cited for the severity vocabulary. §5(xxiv) and §16.2(ii) of the 2025 guidelines require both CVSS and EPSS in an audit report and require every observation to be mapped to a CWE and a CVE number — and §16.2(ii) pins no CVSS version, so both 4.0 and 3.1 reports answer to it. This page recommends naming the version and printing the vector either way. On 4.0 it also recommends FIRST’s own nomenclature, CVSS-B where only base metrics were supplied and CVSS-BE where environmental values were, because that tells a reader how much of the instrument the number represents. The numeric severity bands belong to the CVSS specification’s own qualitative severity rating scale rather than to CERT-In. first.org (CVSS v4.0)
- FIRST, Exploit Prediction Scoring System (EPSS). The second scoring framework §16.2(ii) requires. EPSS publishes a probability per CVE, which is the source of the difficulty this page describes: a cloud configuration finding generally has a weakness class and no CVE, so there is no EPSS value to print. FIRST’s own material confirms that scoring without a CVE identifier is not currently available. The v3.1 CVSS specification, which remains widely used and which this page also references, is at first.org/cvss/v3.1/specification-document. first.org (EPSS)
One document is named on this page and deliberately not linked. §15.2.1(iv) of the 2025 guidelines directs organisations to a document it calls “Method of verifications to compliance with CERT-In Directions issued on 28.04.2022” and prints a cert-in.org.in path for it. That path did not serve the document when it was last checked on 22 September 2026: it returns a small HTML page rather than a PDF. We name the document as the guidelines name it, and we do not render it as a working link. Clause locators and URLs throughout this page were checked on 22 September 2026. If you find one that has moved, we would rather correct the page than be quoted accurately on something stale.
Frequently Asked Questions
What is a cloud security audit?
Is a cloud security audit the same as cloud penetration testing?
What standard is a cloud security audit conducted against in India?
Does CERT-In require CIS Benchmarks for a cloud audit?
Can a CERT-In empanelled auditor test my cloud provider’s infrastructure?
Does my cloud provider’s audit report cover my environment?
What access does a cloud security auditor need?
Is read-only cloud access actually safe to grant?
Do the CERT-In Directions of 2022 apply to cloud environments?
Do cloud logs have to be stored in India?
Which cloud NTP servers satisfy the CERT-In time synchronisation direction?
How should a multi-account cloud environment be scoped for audit?
What evidence does a cloud security audit produce?
How do you evidence closure of a cloud misconfiguration?
Does remediating a cloud finding itself count as a major change?
How often should a cloud environment be audited?
How are cloud misconfigurations scored when there is no CVE?
Does a cloud security audit cover our model-serving account?
How do you evidence a finding in an AI system that is not deterministic?
Can we just run a posture tool ourselves instead of buying a cloud audit?
Our cloud accounts are not in an Indian region — does that change the audit?
Does a cloud security audit produce a certificate?
Do I need a CERT-In empanelled auditor for a cloud audit?
Will a cloud audit affect our production environment?
Does the audit report leave India?
Who is responsible for reporting a cloud incident to CERT-In?
What does a cloud security audit cost, and how long does it take?
Where to go next. For the concepts underneath this page, start with what cloud security is and then API security testing, which covers the surface a cloud-native estate is mostly made of. On the testing side, what VAPT actually is sets out the breadth-and-depth distinction, types of VAPT takes the engagement classes one at a time, and VAPT scoping turns §13.1.1 into a statement of work. On the regulatory side, the 2022 Directions explained goes limb by limb, AMBAK covers what CERT-In published about audit monitoring and how to verify a certificate today, and the safe-to-host certificate covers the one certificate that does exist.
Related Reading
What Cloud Security Covers
The shared responsibility split, the control planes that matter, and where cloud breaches come from.
Read moreThe Types of VAPT
Web, network, mobile, API, cloud configuration and wireless — what each can and cannot find.
Read moreRules of Engagement for an Empanelled Auditor
What the auditor must do, must not do, and needs your written permission for.
Read moreAPI Security Testing
The surface behind every mobile app and single-page frontend, and why testing the UI misses it.
Read moreHow to Read a VAPT Report
Scope, severity, evidence and the parts that reveal a weak test.
Read moreWhat VAPT Actually Is
Vulnerability assessment and penetration testing are two activities. Why India bundles them, and what a real one covers.
Read more