Cloud Security for AWS & Azure: A Guide for Indian Companies

Nearly every cloud breach I have investigated in India in the last five years began with the same words in the client's mind: we thought AWS took care of that. They did not. Nobody did. An S3 bucket sat open to the internet, a security group allowed 0.0.0.0/0 on port 3389, or an Azure storage account had anonymous blob access switched on by a developer three sprints ago and never revisited.

The cloud does not fail the way people imagine. It is almost never the provider getting hacked. It is you, or your team, leaving a door open and assuming someone else would close it. This guide is about who actually owns which door, where Indian companies keep tripping, and what a real remediation looks like when a CERT-In auditor or a data-protection regulator comes asking.

AWS calls it security of the cloud versus security in the cloud. Azure publishes a nearly identical division. The provider secures the physical data centres, the hypervisor, the network backbone, and the managed-service control plane. Everything you put on top — identity, data, configuration, patching of your own workloads, network rules — is yours. That single sentence decides who is liable when things go wrong, and most Indian boards have never seen it written down.

The trap is that responsibility shifts depending on the service model. Run a virtual machine on EC2 or Azure VM, and you patch the guest OS. Move to a managed database like RDS or Azure SQL, and the provider patches the engine but you still own users, encryption keys, backups, and network exposure. Go fully serverless with Lambda or Azure Functions, and you own almost nothing infrastructural — but you own every line of code and every IAM permission it runs with. The table below is the version I draw on a whiteboard in the first workshop with every client.

Notice the bottom four rows. They are yours in every column. Identity, network configuration, encryption, and data are always your problem. That is where more than nine in ten of the incidents I see actually live, and it is why buying a bigger cloud plan never fixes a security posture.

After enough audits you stop being surprised. The same handful of misconfigurations account for the overwhelming majority of exposure. Here are the five I find in almost every first-time cloud assessment, roughly in order of how often they lead to real damage.

None of these are exotic. They are the digital equivalent of leaving the shop shutter half up overnight. And every one of them is detectable in an afternoon with the right tooling — which brings us to CSPM.

Cloud Security Posture Management, or CSPM, is software that continuously scans your cloud accounts against a library of misconfiguration checks and compliance benchmarks. Think of it as an automated auditor that never sleeps and never gets bored of reading IAM policies. AWS ships Security Hub and Config; Azure ships Microsoft Defender for Cloud; and there is a healthy market of independent tools like Prisma Cloud, Wiz, and the open-source Prowler and ScoutSuite.

What CSPM buys you is coverage and continuity. A manual review captures a point in time; by next Tuesday a developer has spun up a new resource and the picture has changed. CSPM catches that drift automatically and maps every finding to a framework — CIS Benchmarks, PCI DSS, ISO 27001, and increasingly the DPDP-aligned controls Indian clients ask for. The distinction that matters for Indian teams looks like this.

My honest advice for most Indian mid-market companies: start with the native tools. Defender for Cloud and Security Hub cost a fraction of the third-party licences and will surface the five misconfigurations above on day one. Graduate to a Wiz or Prisma when you are genuinely multi-cloud or when attack-path analysis and data lineage become board-level concerns. Do not let a vendor sell you a fighter jet when you have not yet learned to close the hangar door.

A digital-lending client came to us after a security researcher emailed them. The researcher had found an S3 bucket named with the company's brand, listable, containing PDF loan agreements — names, PANs, Aadhaar-linked KYC documents, bank statements. Roughly forty thousand documents. No breach in the classic sense; the bucket had simply been created for a batch export eighteen months earlier and made public so a partner could pull files without a signed URL. The partner integration was scrapped weeks later. The bucket stayed.

The clock started the moment they realised what this was. Under the CERT-In directions of April 2022, a body corporate must report a covered cyber incident within six hours of noticing it. This was a personal-data exposure of financial and identity documents — squarely reportable. We had them close public access, enable S3 Block Public Access at the account level, rotate the partner credentials, pull CloudTrail data-event logs to establish who had actually accessed the objects, and file the CERT-In report inside the window with a clear factual timeline.

The forensic answer was almost merciful: CloudTrail showed the researcher's IP and a handful of automated scanners, no evidence of bulk exfiltration before that. But that answer only existed because data-event logging happened to be on. Had it been off — as it is by default — we could not have proven anything, and under DPDP the presumption when you cannot prove containment runs against you. The whole episode cost the client a few lakhs in incident response and remediation. Had it become a public breach of KYC data, the DPDP penalty exposure runs up to 250 crore rupees per instance, and the RBI reputational damage to a regulated lender would have dwarfed even that.

Indian companies rarely have the luxury of one framework. A fintech faces RBI directions, PCI DSS if it touches card data, the DPDP Act for personal data, and CERT-In for incident reporting all at once. The good news is that the underlying cloud controls overlap heavily. Fix the misconfiguration once, and you satisfy several clauses at the same time. The table below is the crosswalk I hand to compliance leads so they stop treating each audit as a fresh project.

Two India-specific items deserve emphasis because auditors and examiners ask about them by name. First, the CERT-In direction requiring logs to be maintained securely for 180 days within Indian jurisdiction and clock-synchronised to NTP servers traceable to Indian standard time — a genuine architecture decision, not a checkbox, when your logs sit in a US region. Second, RBI's expectation, reinforced in its storage-of-payment-system-data circular, that payment data resides in India. If your workload processes card or payment data, the AWS Mumbai (ap-south-1) or Azure Central India / South India regions are not optional, they are the whole point.

When I sit on the auditor's side of the table, I am not looking for a glossy architecture diagram. I am looking to see whether you actually know your own environment. These are the questions that separate teams who have a handle on their cloud from teams who are hoping. If you cannot answer any of them in under a minute with evidence, that is your next month's work.

The last one catches people out. Reporting inside six hours is not a technical problem, it is a rehearsal problem. If the first time your team assembles the facts is during a real incident, you will miss the window. Run the drill on a quiet Tuesday.

You do not need a transformation programme to move the needle. Most of the exposure I find is remediated with configuration changes that carry no licence cost. Work through this list in order — it is roughly sequenced by risk reduction per hour of effort.

Come back to where we started. The breach almost never comes from the provider's side of the line. It comes from an assumption — that AWS or Azure was quietly taking care of the thing that was, in fact, always your responsibility. The whole discipline of cloud security in India comes down to knowing exactly where that line sits, watching your side of it continuously, and being able to prove, on the day an auditor asks, that you had it covered.

If you want a second pair of eyes on your AWS or Azure estate, that is the work we do hands-on. CyberSigma's team are CERT-In empanelled auditors and PCI QSAs who have sat in the audit room and run the six-hour drill for real — we can baseline your posture against CIS, PCI, ISO 27001, and DPDP, and tell you plainly which doors are open.