How Indian Companies Are Securing Their AWS and Azure Environments

The Cloud Is Now Core Infrastructure for Indian Business

Three years ago, cloud adoption in Indian enterprises was still a conversation about migration strategy. In 2026, that conversation is largely over. AWS and Microsoft Azure between them host a significant majority of India’s enterprise workloads — from core banking systems at private sector banks to patient record management at hospital chains, from payment processing infrastructure at fintech unicorns to the data pipelines of India’s largest e-commerce platforms.

Cloud is not emerging technology for Indian businesses anymore. It is plumbing. And like all plumbing, when it is well-designed and properly maintained it is invisible and reliable. When it is poorly configured and neglected, the consequences are expensive, disruptive, and sometimes catastrophic.

What separates Indian organisations that are genuinely securing their AWS and Azure environments from those that are accumulating dangerous cloud security debt? That is the question this blog answers — drawing on the patterns that security firms like FactoSecure observe across cloud security assessments conducted for Indian enterprises, growth-stage companies, and regulated sector organisations in 2026.

The gap between the two groups is not primarily about budget. It is about discipline, methodology, and the willingness to treat cloud security as an ongoing operational function rather than a one-time configuration exercise.

The Starting Point: Understanding What You Actually Have

The most consistent finding in cloud security assessments across Indian organisations is not a specific vulnerability class — it is a lack of visibility. Organisations routinely do not have an accurate, current picture of what is running in their cloud environment, who has access to it, and what data it contains.

This is not negligence in the straightforward sense. Cloud environments are dynamic by design. Developers provision resources, experiments spin up and are forgotten, third-party integrations are added during product sprints, and the cumulative result over months and years is a cloud environment that bears little resemblance to whatever was originally architected on a whiteboard.

Security-mature Indian organisations have addressed this through a combination of cloud asset inventory tooling and formal processes. AWS Config, Azure Resource Graph, and third-party cloud security posture management platforms like Wiz, Orca, or Lacework give security teams continuous visibility into what resources exist, how they are configured, and how that configuration has changed over time.

The organisations that FactoSecure assesses with the strongest security postures share a common characteristic: they know what they have. They can answer, within minutes, how many cloud accounts they operate, what data classifications apply to which storage resources, which services are internet-facing, and who has administrative access to what. This visibility is the foundation on which every other security control is built. Without it, security efforts are directionally correct at best and dangerously blind at worst.

Identity and Access: Where Indian Enterprises Are Getting It Right

IAM — Identity and Access Management — is the control plane of cloud security. Compromise a privileged cloud identity and an attacker inherits the capabilities of that identity across every resource it can reach. Getting IAM right is therefore the highest-leverage security investment an Indian organisation can make in its cloud environment.

Here is what the organisations doing this well are actually implementing:

Least Privilege as an Engineering Discipline

The principle of least privilege is not new. What distinguishes mature Indian cloud users is that they have operationalised it — built it into their engineering workflows rather than treating it as a configuration task to be completed once and forgotten.

In practice this means IAM roles are scoped to the minimum permissions required for the specific workload they serve, reviewed automatically when the workload changes, and audited periodically against actual usage. AWS IAM Access Analyzer and Azure’s built-in access review tools make this tractable at scale — they show which permissions are being actively used and which are granted but never exercised. Permissions that are granted but never used represent unnecessary risk surface and should be removed.

Indian fintech companies operating under RBI cybersecurity guidelines have been among the earliest adopters of rigorous least-privilege enforcement, driven partly by regulatory pressure and partly by the recognition that overpermissioned roles are the most common amplifier of cloud security incidents.

Service Control Policies and Management Groups

Organisations operating multiple AWS accounts — a standard pattern for separating development, staging, and production environments — are using AWS Organizations with Service Control Policies to enforce guardrails across their entire account structure. SCPs function as permission boundaries that apply regardless of what individual IAM policies grant — even an administrator in a member account cannot exceed what the SCP allows.

Common SCP guardrails that Indian security teams are deploying include: preventing the disabling of CloudTrail logging, restricting resource creation to approved regions (enforcing data localisation), requiring encryption on all new storage resources, and preventing the creation of public S3 buckets. These guardrails act as a safety net beneath individual account-level controls — a misconfiguration in one account cannot cascade into a company-wide security failure.

The Azure equivalent — Management Groups with Azure Policy — is being similarly adopted by Indian enterprises standardised on Microsoft’s cloud platform, with policy assignments that enforce security baselines across entire Azure tenants rather than individual subscriptions.

Privileged Identity Management

For administrative access — the cloud equivalent of the keys to the building — security-mature Indian organisations are moving away from standing privileged access toward just-in-time models. AWS IAM Identity Center and Azure Privileged Identity Management allow administrators to request elevated access for specific tasks, with time-limited grants that expire automatically and full audit trails of what was done during the elevated session.

This approach dramatically reduces the risk window associated with privileged credentials. Instead of an administrator account with permanent read-write access to production infrastructure being one phishing attack away from a catastrophic compromise, privileged access exists only for the duration of a specific, approved task — and every action taken during that window is logged.

What Security-Mature Indian Organisations Do With Storage

Cloud storage misconfiguration has been responsible for more Indian data exposures than any other single vulnerability class. The response from organisations that have taken this seriously is a layered approach that goes well beyond checking a “block public access” toggle.

Automated Configuration Enforcement

The most effective defence against storage misconfiguration is not periodic auditing — it is automated enforcement that prevents misconfiguration from persisting. AWS Config rules and Azure Policy assignments can be configured to automatically remediate non-compliant storage resources: a bucket that is set to public access triggers an automatic correction that restores private access and generates an alert for the security team.

Indian e-commerce companies and fintech platforms that handle high volumes of customer data have been among the earliest adopters of this automated enforcement model, driven by the recognition that the speed of their development cycles makes manual configuration review impractical.

Data Classification and Access Tiers

Storage security is most effective when it is tied to data classification. Security-mature Indian organisations maintain a formal data classification framework — typically ranging from public to internal to confidential to restricted — and enforce different access controls, encryption requirements, and monitoring intensity based on classification.

Customer PII, payment data, and health records are classified at the highest tier and subject to the most stringent controls: encryption with customer-managed keys, access logging on every read and write operation, strict IAM policies limiting access to specific services and roles, and automated alerts on any access pattern that deviates from the established baseline.

Encryption Key Management

Encryption is a foundational requirement under India’s DPDP Act for personal data, and under PCI-DSS for payment card data. But the security value of encryption depends entirely on key management — encrypted data protected by a poorly managed key is not meaningfully more secure than unencrypted data.

Indian organisations with mature cloud security programmes are using AWS Key Management Service and Azure Key Vault to manage encryption keys with formal rotation schedules, access policies that restrict who can use keys for which operations, and key usage logging that creates an audit trail of every decryption operation. Critically, they are separating key management from data access — the IAM role that can read an encrypted S3 bucket is not the same role that can use the KMS key to decrypt the data.

Network Architecture: Defence in Depth in the Cloud

The network layer of cloud security is an area where Indian organisations have made significant progress, partly driven by the experience of finding exposed databases and administrative interfaces during security assessments.

VPC Architecture and Segmentation

Security-conscious Indian cloud users are designing their VPC architecture around the principle of segmentation — separating workloads into distinct network segments with controlled, minimal connectivity between them. Public subnets contain only resources that genuinely need internet exposure — load balancers, NAT gateways, and API endpoints. Application servers sit in private subnets with no direct internet access. Databases are in isolated subnets reachable only from the application tier.

This layered architecture means that compromising an internet-facing component does not automatically grant access to internal services and databases. An attacker who exploits a web application vulnerability finds themselves in a DMZ-equivalent network segment, not in direct network adjacency to the production database.

Private Endpoints for Cloud Services

A critical and widely adopted pattern in security-mature Indian cloud environments is the use of private endpoints — AWS PrivateLink and Azure Private Endpoint — to access cloud services like S3, RDS, and Azure Storage without traffic traversing the public internet. This eliminates the exposure of service traffic to internet-based interception and removes the need for internet gateway routing for internal service communication.

Indian financial services organisations in particular have driven adoption of private endpoint architecture, both for the security benefits and because RBI guidelines around data security encourage — and in some interpretations require — minimising internet-facing data paths.

Web Application Firewalls and DDoS Protection

AWS WAF, Azure Web Application Firewall, and third-party solutions like Cloudflare are now standard components of the security architecture for Indian customer-facing cloud applications. Security-mature organisations are going beyond default rule sets to develop custom WAF rules tuned to the specific attack patterns targeting their industry — common SQL injection patterns against Indian e-commerce search endpoints, OTP brute force patterns against Indian fintech authentication flows, and credential stuffing signatures targeting high-value user accounts.

AWS Shield Advanced and Azure DDoS Protection Standard are similarly being adopted by Indian organisations whose applications are sufficiently business-critical that a volumetric DDoS attack represents meaningful operational and revenue risk. The festive season sale events of Indian e-commerce — the equivalent of Black Friday in the Indian market — have made DDoS resilience a serious operational priority for platforms in that sector.

Detection and Response: What Security Teams Are Actually Monitoring

The detection and response capability of Indian cloud security teams has matured considerably in the last two years, driven partly by a series of high-profile incidents that demonstrated the cost of operating without adequate monitoring.

Cloud-Native Security Services

AWS GuardDuty and Microsoft Defender for Cloud have become standard components of the security stack for Indian organisations that take cloud security seriously. GuardDuty uses machine learning and threat intelligence to identify suspicious activity — unusual API call patterns, access from known malicious IP addresses, cryptocurrency mining behaviour, credential exfiltration attempts — and generates findings that can be routed to security teams through automated alerting pipelines.

Indian security teams that get the most value from these services have invested in tuning them to their specific environment — suppressing findings that represent known, expected behaviour in their context, and amplifying alerting on the finding types most relevant to their threat model. A raw GuardDuty deployment with no tuning generates noise. A tuned deployment generates signal.

SIEM Integration and Centralised Logging

Security-mature Indian organisations are shipping cloud audit logs — AWS CloudTrail, Azure Activity Log, VPC Flow Logs, DNS query logs, and application logs — to a centralised SIEM platform for correlation, retention, and alerting. Microsoft Sentinel is widely adopted in Azure-heavy Indian environments. Splunk and IBM QRadar maintain a presence in enterprise deployments. Elastic Security is gaining traction in cost-conscious mid-market organisations.

The critical architectural decision that separates mature from immature logging postures is log storage separation — logs are shipped to a dedicated security account or external platform where the development and operations teams do not have write access. An attacker who compromises a production account cannot cover their tracks by deleting CloudTrail logs if those logs have already been shipped to a separate account with independent access controls.

Automated Incident Response Playbooks

The most sophisticated Indian cloud security teams have moved beyond manual incident response toward automated playbooks that execute immediate containment actions when specific findings are triggered. A GuardDuty finding indicating that an IAM role is being used from an unusual geographic location automatically triggers an IAM policy attachment that restricts the role’s permissions while the security team investigates. A finding indicating that an EC2 instance is communicating with a known command-and-control server automatically triggers network isolation of that instance.

This automation reduces the time between detection and containment from hours — the typical human response time for an alert generated at 3 AM — to seconds. In cloud security, that time difference is frequently the difference between an incident that is contained and one that results in a full data breach.

What FactoSecure Finds When They Assess Indian Cloud Environments

FactoSecure’s cloud security assessment practice provides a ground-level view of where Indian organisations actually stand relative to where they believe they stand. The gap between the two is consistently larger than security teams expect.

In a typical cloud security engagement, FactoSecure’s assessment methodology covers external reconnaissance of cloud-exposed assets, authenticated review of IAM configuration and policy analysis using a combination of manual review and automated tooling, storage and database security assessment across all accounts and regions in scope, network configuration review including security group rules, VPC architecture, and internet-facing service exposure, API gateway and serverless function security assessment, CI/CD pipeline security review, logging and monitoring gap analysis, and regulatory compliance mapping against DPDP Act, RBI, PCI-DSS, and ISO 27001 requirements where applicable.

The findings that appear most consistently across Indian cloud environments — regardless of company size, industry, or cloud platform — are overpermissioned IAM roles that violate least privilege, missing MFA on privileged accounts, publicly accessible storage resources containing sensitive data, disabled or incomplete audit logging, and the absence of automated alerting on high-risk events.

These are not sophisticated vulnerabilities requiring advanced exploitation techniques. They are configuration failures that automated scanners and criminal reconnaissance tools find routinely. The organisations that fix them — through a combination of internal remediation and third-party validated assessment — are not doing anything exotic. They are doing the basics rigorously and consistently.

FactoSecure’s cloud security reports are structured to give Indian security teams exactly what they need to address these findings: a prioritised remediation roadmap that sequences fixes by risk severity, technical remediation guidance that is specific enough for a cloud engineer to implement directly, and executive-level risk communication that gives leadership the business context to prioritise security investment appropriately.

The Compliance Dimension: Mapping Security Controls to Indian Regulatory Requirements

For regulated Indian organisations — banks, NBFCs, payment aggregators, insurance companies, healthtech platforms, and any company handling significant volumes of personal data — cloud security is not just a technical discipline. It is a regulatory obligation.

RBI’s cloud adoption guidelines for regulated financial entities require, among other provisions, a documented cloud security framework, formal vendor risk assessment of cloud providers, data localisation controls, independent security assessment of cloud infrastructure, and incident reporting protocols. Indian banks and fintech companies that have aligned their cloud security programme to RBI requirements have found that the alignment also produces a meaningfully stronger technical security posture — the regulatory requirements and the security best practices point in the same direction.

SEBI’s cybersecurity circular for market infrastructure institutions and registered intermediaries imposes similar requirements for cloud-hosted systems handling securities market data and transaction processing.

IRDAI’s information and cybersecurity guidelines for insurers cover cloud security explicitly, requiring formal cloud risk assessment and penetration testing of cloud-hosted systems.

The DPDP Act applies to every Indian organisation handling personal data on cloud infrastructure — which in 2026 means nearly every organisation in every sector. The Act’s requirement for reasonable security safeguards translates directly into the cloud security controls described throughout this blog: encryption, access control, audit logging, and regular independent security assessment.

FactoSecure’s cloud security assessments include a regulatory compliance mapping component that aligns findings and recommendations to the specific frameworks applicable to each client — giving regulated Indian organisations a single assessment output that serves both their security programme and their compliance evidence requirements.

A Practical Roadmap for Indian Organisations Still Building Cloud Security Maturity

For organisations that recognise they are not yet where they need to be on cloud security, the path forward does not require a wholesale transformation overnight. It requires a disciplined, sequenced approach that addresses the highest-risk gaps first.

Week one through four — Establish visibility and fix critical exposures. Enable AWS Config or Azure Policy across all accounts and subscriptions. Run an immediate audit of all storage resources for public access settings. Enable MFA on all root and administrator accounts. Rotate any access keys that have been active for more than 90 days or that may have been exposed. Enable CloudTrail and Azure Activity Log in all regions.

Month two through three — Tighten identity and access. Conduct a full IAM review using AWS IAM Access Analyzer or Azure Access Review. Remove permissions that are granted but not actively used. Implement service control policies or Azure Policy to enforce least-privilege guardrails at the organisation level. Enforce environment separation between development and production.

Month three through six — Commission an independent cloud security assessment. Internal remediation addresses known gaps. An independent assessment from FactoSecure surfaces the gaps that internal teams have missed — the forgotten development account with a public database, the third-party integration with administrator permissions, the CI/CD pipeline with production credentials stored in plaintext environment variables. The external perspective is not a luxury — it is the quality control mechanism that validates whether internal efforts have actually worked.

Ongoing — Build detection and maintain hygiene. Deploy GuardDuty or Defender for Cloud with tuned alerting. Centralise logs in a separate security account. Establish a formal process for reviewing and acting on security findings. Schedule annual cloud security assessments and conduct targeted reviews after significant architectural changes.

The Bottom Line

Indian organisations using AWS and Azure are operating in a threat environment that is more active, more sophisticated, and more consequential than at any previous point. The regulatory framework has matured. The attackers have matured. And the expectation — from investors, from regulators, from enterprise customers — that cloud infrastructure will be secured to a demonstrable standard has matured with them.

The organisations that are getting cloud security right in India are not doing something mysterious or prohibitively expensive. They are implementing least-privilege IAM discipline, automated configuration enforcement, proper network segmentation, comprehensive logging, and regular independent validation of their security posture. They have built security into their cloud operating model rather than bolting it on after the fact.

The organisations that are not doing these things are accumulating cloud security debt that will eventually be called in — by an attacker, by a regulator, or by a customer who asks the wrong question at the wrong time and receives an honest answer.

Working with a firm like FactoSecure to independently assess your AWS or Azure environment is the clearest way to understand which side of that line you are currently on — and to build the programme that puts you firmly on the right side of it.