What Cloud Security Actually Covers

Cloud security is not a product. It is a division of labour, and the whole subject turns on being able to draw the line: what the provider secures, what remains yours, and how that line moves between IaaS, PaaS and SaaS. Everything above the line is configuration, identity and data — which is where cloud incidents actually happen.

Indian obligations follow the workload, not the data centre. Direction (iv) of CERT-In’s Directions of 28 April 2022 requires logs of all ICT systems to be enabled and maintained for a rolling period of 180 days within Indian jurisdiction — a limb FAQ Q35 qualifies, since logs may sit outside India provided they can be produced to CERT-In in a reasonable time. Annexure I item (xviii) makes attacks affecting cloud computing systems mandatorily reportable within six hours. Neither duty is discharged by your provider.

Cloud security is the practice of securing the half of a cloud system that the provider does not secure for you. The provider is responsible for the cloud — the facilities, the hardware, the hypervisor, the managed services it operates. You are responsible for what you put in it and how you configure it: your identities and permissions, your network exposure, your data and your keys, your workloads, and the management plane through which all of it is created and destroyed. That division is called the shared responsibility model, and where the line sits depends on the service, not on the vendor.

The practical consequence is that cloud security is mostly a configuration and identity discipline rather than a patching one. The recurring patterns sit above the provider’s line: storage left readable, roles far broader than the job they were created for, keys that never expire, trust relationships nobody maintains, and logging that was never turned on in the region where it mattered. CERT-In’s own explanation of the cloud incident type in its FAQ of May 2022 names the same territory: “Cloud API vulnerabilities, weak cryptography, exposed data repositories and unauthorised access to victims’ cloud credentials”. Every one of those sits above the provider’s line.

For an Indian organisation there is a third thing to hold alongside the architecture and the controls: the obligations follow the workload. Moving a system into a cloud region does not move the duty to enable and retain logs, and does not move the duty to report an incident. Direction (iv) of the Directions of 28 April 2022 requires logs of all ICT systems to be maintained securely for a rolling period of 180 days within Indian jurisdiction, and item (xviii) of Annexure I makes attacks and malicious or suspicious activities affecting cloud computing systems one of the twenty types that must be reported within six hours of noticing. Those are quoted in full, with their qualifications, further down this page.

Each one is addressed in full further down, with the clause or the mechanism behind it.

The shared responsibility model is the statement, published by every major cloud provider, of which security duties the provider performs and which remain the customer’s. The usual shorthand is that the provider is responsible for the security of the cloud and the customer for security in it. That is memorable and slightly misleading, because the boundary is not one line across the whole relationship — it is a different line for every service you consume.

The table below is stated vendor-neutrally and by layer, because layers are what the line actually cuts through. Read the last column first. It is the one that decides what goes in a scope of work, what your customers are entitled to ask you about, and what you will be explaining if something goes wrong.

Two rows never change colour. Identity is yours at every service model, and data classification is yours at every service model. Everything else moves. That is the whole reason a cloud security programme that begins with the identity model and the data inventory is a programme, and one that begins with a scanning tool is a report.

CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines (version 1.0, 25 July 2025) address the hosted case at §13.1.5 in terms that map closely onto the shared responsibility idea. Where a website is hosted on a web server owned by another organisation, responsibility for auditing that web server, its operating system, the web hosting application software and the backend database software lies with the organisation that owns and operates the server, while the owner of the website content remains responsible for ensuring that the website data and software are audited by a CERT-In empanelled information security auditing organisation. Same principle, written into an audit instrument rather than into a provider’s terms: the infrastructure owner audits the infrastructure, and the tenant is not relieved of auditing the tenancy.

The service-model question — IaaS, PaaS or SaaS — answers what you operate. The deployment-model question answers who operates the platform underneath it, and it moves the responsibility line in a different direction. The two are independent: you can buy IaaS from a public provider, run IaaS yourself on a private cloud, or consume SaaS that is itself hosted on somebody else’s public cloud.

This matters more in India than the public-cloud diagram suggests, because the normal shape of a regulated Indian estate is hybrid or colocated rather than purely public, and government and financial-sector procurement frequently pushes towards private and community models. An organisation that reads only the public-cloud shared-responsibility picture has read the model for the part of its estate it worries about least.

One Indian instrument speaks to the hybrid and hosted cases directly, and it is worth reading before the architecture conversation rather than after it. §13.1.5 of the 2025 audit policy guidelines addresses the split where a website is hosted on a web server owned by another organisation: responsibility for auditing that web server, its operating system, the web hosting application software and the backend database software lies with the organisation that owns and operates the server, while the owner of the website content remains responsible for having the website data and software audited by a CERT-In empanelled information security auditing organisation. The clause also asks that the report explicitly certify that the audited web application, including backend databases and scripts, is free from vulnerabilities and malicious code that could be exploited to compromise or gain unauthorised access, including escalated privileges, to the web server hosting the website. Read that last sentence carefully in a colocated or hybrid estate: it is a certification about your application’s effect on infrastructure somebody else runs.

The word to avoid in all of this is “sovereign”. It is a marketing term with no fixed meaning across providers, and it is used to describe arrangements ranging from a region located in India to a separately operated entity with locally vetted staff. If a proposal uses it, ask which of those it means, who holds the encryption keys, who can access the control plane and from where, and which entity the contract is actually with. Those four answers are the substance, and the adjective is not.

Five, and they are better called planes than pillars, because a pillar holds something up and a plane is somewhere a decision is made. Identity and access. Network. Data and encryption. Workload. And the management plane — the provider’s own API, through which every resource above is created, reconfigured and destroyed. Most published lists of cloud security “pillars” or “types” give the first four and omit the fifth, which is the one where a single finding has estate-wide consequences.

“Plane” rather than “control” deliberately. Each of the five below is a place where policy is decided, enforced and recorded, and each produces a different kind of evidence. A scope of work that names all five is a cloud security review, one that names the first four is an infrastructure review, and one that names none of them and says “cloud VAPT” is an application test with an ambitious title.

CERT-In treats this as its own discipline rather than as a variety of application testing. §6(xviii) of the Comprehensive Cyber Security Audit Policy Guidelines lists Cloud Security Testing as a class of engagement in its own right, defined as “evaluating and assessing the security measures, configurations, and vulnerabilities of cloud-based systems, applications, and infrastructures”. Note the middle word: configurations. And §8(ii) names the framework to build the programme from — the CSA Cloud Controls Matrix “for Cloud Security” — in the same clause that says limited lists such as the OWASP Top 10 and SANS Top 25 “should not be considered as standards or references for audits”.

The management plane is the provider’s own API: the interface through which resources are created, reconfigured, copied and destroyed, and through which permissions themselves are granted. The console is a client of it. The command-line tool is a client of it. Your infrastructure-as-code pipeline is a client of it. It is reachable from the public internet by design, because that is what makes cloud cloud.

That makes it the real perimeter, and it behaves unlike any perimeter a data-centre estate ever had. A network boundary fails gradually — an attacker lands somewhere and works outwards. The management plane fails instantly and completely: a credential with sufficient permissions does not need to traverse anything. It can read a database by taking a snapshot and restoring it elsewhere. It can reach a private subnet by creating a route to it. It can stop being observed by turning the audit trail off. None of that touches a firewall, triggers an intrusion sensor, or appears in an application log.

This is why an estate can pass an application test and a network scan and still be one leaked token away from total compromise. It is also why CERT-In’s explanation of the cloud incident type opens with “Cloud API vulnerabilities” rather than with anything about servers. The management plane is the cloud API.

Every one is answerable from the provider’s own API. None of them requires a tool purchase, and each has a wrong answer that is worth knowing about today rather than during an incident.

The five planes are how to think about the estate. This is what somebody opens on a Tuesday morning. Each row is written so that the middle column can be answered from the provider’s own API rather than from an opinion, which is what lets an observation be supported by objective evidence, as §18(iii) requires. The third column is the finding this surface produces when nobody has looked — stated so you can search for it yourself before anyone else does.

Five rows deserve to be read twice, and they are the five most likely to be absent from a proposal. The build pipeline, because it is a principal with estate-wide permissions that nobody thinks of as a production system. The SaaS tenant, because the vendor’s certification was read as covering it and it does not. Backup and disaster recovery, because the controls that protect the primary store were frequently never applied to its copies. Queues and event buses, because a queue is thought of as transport and is in fact storage with a retention period. And managed inference, because it is the newest surface on the list and the one whose logs are off by default. None of the five is normally named in a scope of work unless the buyer names them, which is why they appear in the thirteen questions and in the scope-of-work block further down.

A landing zone is a cloud environment that has been structured before workloads arrive rather than around them: the account or subscription hierarchy, the organisation-level guardrails, the identity federation and the logging destination all decided and established first. The word describes a decision, not a product — every major provider sells tooling that builds one, and an estate assembled by hand to the same design is equally a landing zone.

Because an account is the strongest boundary a cloud provider gives you. Inside one account, separation depends on permissions being written correctly for every principal and every resource, forever. Between accounts, separation is the default and connection is the exception — which is the right way round. A “landing zone” is simply the name for having decided this deliberately, with the accounts, the guardrails, the identity federation and the logging destination established before the first workload arrives rather than retrofitted around it.

Most estates do it retrospectively, which is normal and survivable. What matters is that each separation below is bought for a stated reason, and that each one has a check attached that someone can run this week.

One warning about structure, because it is the mistake that follows from doing this well. Separating accounts moves risk into the things that cross them: the identity provider, the deployment pipeline, and the transit network. Those three become the new concentration of privilege, and they deserve the scrutiny the individual accounts no longer need. A landing zone does not remove the single point of failure. It relocates it somewhere you can defend properly and watch closely.

This is the question that most often sends a cloud architect to the wrong region decision, because the answer is in two documents and almost every summary quotes only the first. Direction (iv) is the obligation. FAQ Q35 is the qualification. Read together they say something narrower — and more workable — than direction (iv) alone appears to.

The FAQ states its own limitation, and it should be reproduced 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, and it is “an evolving document and hence, the version of this document may undergo changes”. So the sensible reading is not “residency does not matter”. It is that the duty CERT-In has said it will test is production on demand in a reasonable time, and that an architecture which can satisfy that is what the answer has to be built around. If your logs sit in another geography behind a vendor support ticket and a fourteen-day export, you have a residency problem regardless of how the clause is read.

Two more answers in the same FAQ are worth carrying into the design. Q36 states that “any service provider offering services to the users in the country needs to enable and maintain logs and records of financial transactions in Indian jurisdiction”. Q38 tells you who can ask: a requisition for logs “may be given by an officer of CERT-In not below the rank of Deputy Secretary to the Government of India”. And Q20 limits the shape of the demand — the Directions “do not envisage seeking of information by CERT-In from the service providers on continuation basis as a standing arrangement”. Information is sought case to case.

Q37 is the closest thing to a specification, and it is deliberately open: “The logs that should be maintained depend on the sector that the organisation is in, such as Firewall logs, Intrusion Prevention Systems logs, SIEM logs, web / database/ mail / FTP / Proxy server logs, Event logs of critical systems, Application logs, ATM switch logs, SSH logs, VPN logs etc.” CERT-In adds that the list “is not exhaustive but has been mentioned to provide flavour of logs to be maintained”, and — the sentence most worth acting on — that “from the incident response and analysis perspective both successful as well as unsuccessful events shall be recorded”.

Translate that into cloud sources and the list is short and concrete: the management-plane audit trail in every account and region, identity and authentication events including failures, network flow logs, load balancer and web application firewall logs, managed database audit logs, object storage access logs for anything holding regulated data, container orchestration audit logs, and the build pipeline’s own record of who deployed what. The unsuccessful-events sentence matters most for the first two — a denied API call and a failed authentication are the earliest signals a cloud estate produces, and they are the ones most often filtered out to reduce cost.

One source belongs on that list and is almost never on it: inference logs, where the estate runs an AI or machine-learning workload. On most managed inference services, invocation logging is off by default, and where it is on it frequently records request metadata without retaining the prompt and the completion. Annexure I item (xx) makes attacks and malicious or suspicious activities affecting artificial-intelligence and machine-learning systems mandatorily reportable within six hours — and the log that would let you describe such an event is exactly the one nobody enabled. Turning it on is a configuration change, but deciding what may be retained, for how long, and under which classification is a data-protection question you should settle before you turn it on rather than after.

One practical test settles the whole section better than any configuration review. Ask somebody to retrieve every management-plane event for a single named day six months ago, from a region you do not normally use, and watch how long it takes. That exercise answers retention, coverage, regional completeness and producibility in one go — and it is the same exercise CERT-In’s own demand would be.

Where it falls within Annexure I, yes. Item (xviii) of Annexure I to the Directions of 28 April 2022 is “Attacks or malicious/suspicious activities affecting Cloud computing systems/servers/software/applications”, and direction (ii) requires the twenty Annexure I types to be reported “within 6 hours of noticing such incidents or being brought to notice about such incidents”. Annexure I carries a note referring to Rule 12(1)(a) of the Information Technology (The Indian Computer Emergency Response Team and Manner of Performing Functions and Duties) Rules, 2013.

Note where the clock starts. It runs from noticing, not from confirming, not from completing an investigation, and not from a decision that the incident is material. A cloud estate makes that distinction sharper than an on-premises one, because the first signal is frequently an anomalous management-plane call rather than an outage — something noticed by a detection rule at two in the morning, days before anyone can say what it was.

The FAQ defines one of the two terms in play and not the other, which is worth knowing before an argument about it starts. Q3 gives “cyber security incident” as “any real or suspected adverse event in relation to cyber security that violates an explicitly or implicitly applicable security policy resulting in unauthorised access, denial of service or disruption, unauthorised use of a computer resource for processing or storage of information or changes in data, information without authorisation”. Note suspected, and note that a policy violation is enough — both of which bite earlier in a cloud estate than people expect, because an anomalous management-plane call is a suspected adverse event long before anyone can characterise it. “Cyber incident” is not defined in the FAQ. The Directions point to the IT Act, 2000 and the CERT-In Rules, 2013 for it, and we do not assert a definition for it here.

Q30 of the FAQ is the answer that makes the six hours workable: entities “may provide information to the extent available at the time of reporting. Additional information may be reported later within reasonable time to CERT-In.” The same answer names categories that should be reported within the stipulated six-hour time. Incidents of severe nature such as denial of service, distributed denial of service, intrusion and the spread of computer contaminant including ransomware on any part of the public information infrastructure including backbone network infrastructure. Data breaches or data leaks. Large-scale or most frequent incidents such as intrusion into computer resources and websites. And cyber incidents impacting safety of human beings.

Two silences are worth naming rather than filling. The FAQ says nothing about filing out of hours or on a public holiday, and nothing about withdrawing or correcting a report already made. Anyone who tells you the rule on either is inventing it. Q30’s “additional information may be reported later” is the closest thing available, and it supports correcting forward on the same thread — which is a reading, and is labelled as one here. For the AI-specific side of the same Annexure, see AI incidents under CERT-In.

A control you cannot evidence is an intention. The useful property of a cloud estate is that almost every control can be evidenced from the provider’s own API as a dated export, which is stronger than a screenshot and far stronger than an assertion. CERT-In’s audit policy guidelines ask for exactly this at §18(iii): all observations “well supported with objective evidences”, compiled with the report and presented so that decision makers can use them in making credible risk-based decisions.

Where a finding does make it into a report, the Indian instruments are specific about how it should be expressed. §16.2(ii) requires severity to be scored with CVSS and supplemented with EPSS for real-world exploitation likelihood, and requires every reported observation to be mapped to a CWE and a CVE number. Worth knowing for a cloud review: a misconfiguration usually has a CWE and frequently has no CVE, because there is no vendor product flaw to enumerate — and a report that handles that honestly, rather than by inventing an identifier, is telling you something good about itself. The numeric severity bands belong to the CVSS specification, not to CERT-In, and EPSS is a daily-recomputed probability, so a value printed in a report needs the date it was pulled. There is a fuller treatment in reading a VAPT report.

§16.1(ii) sets the contents in one sentence: the report “should be clear, precise and comprehensive to include all details of audit process, detailed scope, duration of audit, methodologies/standard used, tools, manual process, findings, prioritization, sampling decisions, manpower involved, exemptions, limitations and other constraints”. The rest of the instrument fills that out. The table below names each artefact, its locator and what it costs you when it is absent, so you can ask for them by name instead of by adjective.

Note the modality, because it decides how hard you can push. Where a clause says must or shall, it is written below as a requirement. Where it says should — and several of the most useful ones do — it is written as what the instrument expects. Nobody is helped by a page that upgrades a recommendation into a rule, least of all in a conversation with the supplier who has read the same document.

The last row is the one that behaves differently in cloud than anywhere else, and it is worth a sentence on its own. On a network or application engagement the evidence is produced inside your estate. On a cloud engagement almost all of it is produced in somebody else’s console: screenshots of an offshore control plane, configuration exports pulled from a provider API, log extracts from a platform that may have no Indian region at all. §10.3 requires that material to be stored only on systems located in India and encrypted on auditor devices, and the 2014 data-handling guidelines add that a report should not be hosted on an online file service outside the auditing organisation’s own technical and administrative control without your authorisation. Where a log platform genuinely cannot export to Indian storage, that is a limitation to record in the report under §16.1(ii), not a problem to solve by uploading it somewhere convenient. The rules of engagement side of this is set out at length in what a CERT-In empanelled auditor may do.

Almost nobody starts from an empty account. The order below assumes an estate that grew organically and now needs to be brought under control, and it is ordered by dependency rather than by effort: each step makes the next one cheaper, and doing them out of order means doing several of them twice.

The following example is invented for this page. It is not a client, it is not a sector, it describes no engagement TCSA has performed, and it makes no claim about outcomes. It exists to show how a single mundane decision moves through the control planes, because that sequence is the argument of this page and it is easier to see than to assert.

Imagine an engineering team asked to deliver a reporting feature. They need production-shaped data for the queries, so somebody exports a table into an object storage bucket in a development account. To make the export work from the pipeline they attach a broad managed policy to the deployment role — the narrow one was going to take an afternoon to derive and the release was Thursday. The bucket is created in a region the team finds convenient and nobody else uses. The export script needs credentials, so an access key is created and stored in the pipeline’s variables. The feature ships. Everyone moves on.

Nothing in that sequence is negligent and nothing in it is unusual. But trace it through the planes and count the decisions that are now permanent. On the data plane, regulated data now exists in a second account that was never classified, never inventoried, and is outside whatever retention rule the primary store has. On the identity plane, a deployment role holds permissions far beyond its job, and a static key exists that has no expiry and no owner. On the network plane, the bucket’s exposure depends entirely on policy, because object storage has no network position to hide behind. On the management plane, the pipeline that holds the key is now a principal that can deploy infrastructure, authenticated by a value in a repository setting. And on the logging side, the new region has no audit trail, because the audit trail was enabled where the estate started and nobody made it organisation-wide.

Now suppose the key leaks — from a laptop, from a fork of the repository, from a log line that printed an environment variable. The attacker does not need to traverse anything. They call the management plane with a valid credential, enumerate what the role can reach, and read the bucket. There is no firewall event, no intrusion signature, and no application log entry, because no application was involved. And in the region concerned there is no audit trail either, so the question “what did they access, and when” has no answer available.

That last sentence is where the Indian obligations arrive. Direction (iv) required logs of all ICT systems for a rolling period of 180 days, and the region with no audit trail is a gap in that, and it is discovered on the worst possible day. Direction (ii) with Annexure I item (xviii) requires reporting within six hours of noticing — and items (iii), (xi) and (xii) would on our reading also be described, on the same clock. That last sentence is our reading of the item text rather than a CERT-In determination: CERT-In calls the Annexure-I explanations illustrative at Q9, and they are not a reportability test for a fact pattern. CERT-In may then order the logs, and the ones that would answer the question do not exist. Note what would have changed the outcome: not a product, and not a larger budget. An organisation-wide audit trail, a permission boundary above roles a team can create, a guardrail denying unapproved regions, and federation instead of a static key. Four configuration decisions, none of which anybody would call a security investment, and all four sit above the provider’s line.

This page has told you several times to name the CSA Cloud Controls Matrix in a scope of work, because §8(ii) of CERT-In’s 2025 audit policy guidelines names it — “CSA Cloud Controls Matrix (CCM) for Cloud Security” — among the comprehensive standards an audit should be built from, in the same clause that says limited lists such as the OWASP Top 10 and SANS Top 25 “should not be considered as standards or references for audits”. Telling you to name it without saying what it is leaves you with a word to put in a contract and no way to tell whether you got it. So here is what it is.

The Cloud Controls Matrix is published by the Cloud Security Alliance, which is not a Government of India body and is not CERT-In. It appears here because §8(ii) names it by title. The version, the control count and the domain count below were read off CSA’s own research page on 22 September 2026, which gave version 4.1 as the current release of the CCM and CAIQ combined. That page prints no release date on its face, so we state the version with the date we checked it and no more.

The second row is the one that closes the loop on this whole page. The argument of the first third — that cloud security turns on being able to draw the responsibility line per service, in writing — is an argument for a deliverable, and the CCM is the shape that deliverable already has. A responsibility split written against a named control framework, with each control assigned to the provider, to you, or to both, is something a customer can review, a regulator can read and next year’s team can inherit. The same split written as a paragraph in a slide deck is a memory. If you want the assurance-report side of the same question, our pages on cloud provider SOC 2 and shared responsibility and CUECs and CSOCs cover what a provider’s report hands back to you.

One caution about how the clause is worded, because it matters commercially. §8(ii) does not say the CCM is the only acceptable framework. It lists it alongside ISO/IEC standards, the Cyber Security Audit Baseline Requirements, OSSTMM3 and the OWASP guides, and the list is prefaced by the instruction that audits should discover all known vulnerabilities against comprehensive frameworks rather than limited lists. A supplier proposing a different comprehensive framework has not failed the clause. A supplier proposing a ten-item defect list as the audit criterion has.

No figures on this page, and that is a position rather than an evasion. A price quoted against an undefined cloud estate is a number attached to nothing, and the argument of everything above is that the scope is what decides whether the result is worth having. What is useful is the arithmetic. This page tells you three times to ask for the test plan in man-hours, because §13.2.2(ii) requires it to state both calendar time and man-hours. Below are the variables that number is built from, so you can read a proposal rather than compare two totals.

Count the units: accounts multiplied by regions holding resources, plus each SaaS tenant, plus the pipeline if it is in scope as a principal. Multiply by the number of privilege levels that will actually be tested, where an authenticated application test is included. Then divide the quoted man-hours by that result. The answer is the effort each unit is getting. When it comes out as a couple of hours, what has been quoted is an enumeration: enough time to run a posture tool across the estate and read its output, which is a real and useful thing but is not a review. When it comes out in days, somebody is going to sit with your identity model.

Then ask for the split between tool-assisted and manual effort, which is the commercial form of §8(i)’s instruction that solely tools-based testing should be discouraged — a clause whose stated reason is that tool-based audits “may focus primarily on automated processes and may overlook non-automated or manual components of the IT infrastructure”. In cloud, the manual half is where the cross-account trust relationships, the permission-boundary gaps and the guardrail tests live, because a tool can tell you a role has a wildcard and cannot tell you whether the wildcard matters.

One last driver sits on your side of the table and is the cheapest to fix: have the read-only audit roles issued across every account in scope before the window opens. Two days spent waiting for credentials is two days you have already paid for, and it is the single most common way a cloud engagement loses time that nobody later remembers losing.

Each of these is answerable by the other side in a sentence. Each also has a wrong answer that tells you something, which is the point of asking them before the engagement rather than reading about them in the limitations paragraph afterwards. Scoping in more depth lives on VAPT scoping.

We deliver CERT-In audits, end to end, with our CERT-In empanelled partners. See how a CERT-In audit runs with us.

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. The same caution applies more generally on that host — a 200 response is not evidence that a document exists, which is why every source above was checked on content type and size. Clause locators throughout this page were checked against the PDFs on 22 September 2026. If you find one that has moved, we would rather correct the page than be quoted accurately on something stale.

Where to go next. On the delivery side of this subject, cloud security audits in India covers how a review is actually scoped and run here, and API security testing takes the surface that most cloud estates expose and most scopes under-specify. On the testing vocabulary, what VAPT actually is and types of VAPT are the places to start, with VAPT scoping for turning §13.1.1 into a statement of work and VAPT vs penetration testing vs red teaming for the three definitions. On the Indian instruments, what CERT-In is, the 2022 Directions explained and what a CERT-In empanelled auditor may do are the three that matter most for a cloud estate. If your workload is an AI system, start with what AI red teaming is, red-teaming an LLM application for the reproduction-rate, snapshot-identifier and decoding-parameter vocabulary a six-hour filing about an item (xx) event needs, and AI incidents under CERT-In. AI red teaming vs VAPT is the comparison to read when the scoping question is which of the two you are buying. And if the system is a Government website or application, the safe-to-host certificate is where the hosting-environment requirements become a deliverable.