Key Takeaways
- 80% of cloud breaches trace back to 4 root causes: weak IAM, exposed storage buckets, missing encryption, no logging. Fix these first.
- Identity is the new perimeter. Enforce MFA on every console account, use roles not long-lived keys, rotate credentials, enable least privilege.
- Encrypt everything by default, S3, EBS, RDS, EFS, GCS, Azure Storage. Use customer-managed keys for sensitive workloads.
- Centralize logs from CloudTrail/AzureActivity/AuditLogs into a SIEM or at minimum a dedicated logging account with 1-year retention.
- Test before you grow. A cloud penetration test on a 50-person startup costs INR 2-4 lakh; the same breach at 500 people costs INR 5-10 crore.
Why Cloud-Native Startups Are Disproportionately Targeted
Indian startups born on AWS, Azure or GCP move fast, and that speed is exactly what attackers count on. The same DevOps culture that ships product weekly also pushes infrastructure as code without security review, hands developers admin access to production, and skips threat modeling because "we're too small to be a target." That assumption is wrong. Cloud attackers don't pick targets by company size; they scan continuously for misconfigurations and exploit whatever they find.
We see the same patterns repeatedly when running cloud assessments for Indian Series A and Series B startups: public S3 buckets exposing customer documents, RDS instances reachable from 0.0.0.0/0, unrotated IAM keys checked into private GitHub repos, root accounts without MFA, CloudTrail disabled in 6 of 8 regions, and security groups labeled "temporary" that have been temporary for 3 years. None of these are sophisticated attacks, they're hygiene failures that any cloud penetration test would have caught.
The 2025 IBM Cost of a Data Breach Report puts the average Indian breach at INR 19.5 crore. For a startup, that's existential. The cost of preventing it through a structured cloud security program is two orders of magnitude lower.
1. Identity and Access Management (IAM), The Real Perimeter
Network perimeters disappeared the moment you moved to cloud. The new perimeter is identity. Every breach investigation we run in cloud environments traces back to an identity that should not have had the access it used. IAM is therefore the highest-leverage area for any startup to invest the first 30 days of a cloud security program.
- Root account discipline, Enable hardware MFA on the root account, store credentials in a sealed envelope, never use root for daily operations. Create an org admin user instead.
- SSO + MFA everywhere, Federate cloud console access via Google Workspace, Microsoft Entra, or Okta. Enforce MFA on every IAM user. No exceptions for founders.
- Roles instead of keys, EC2 instances should use IAM roles, not long-lived access keys. Lambdas, ECS tasks, EKS pods all support role-based authentication.
- Least privilege baseline, Start every user/role with zero permissions and add only what's needed. Use AWS IAM Access Analyzer or Azure PIM to identify over-privileged identities.
- Automated rotation, Rotate IAM keys every 90 days. Use AWS Secrets Manager or Azure Key Vault for application credentials. Never commit keys to Git.
- Just-in-time admin, Production admin access should require an approval workflow (AWS IAM Identity Center + permission sets, or Azure PIM). Standing admin access is a recurring breach pattern.
Get a Cloud Security Health Check
Free 30-minute review of your AWS, Azure or GCP environment with an OSCP/CCSP-certified consultant. We will identify the top 5 risks in your account and give you a prioritized fix plan, no obligation.
Book Free Cloud Review →2. Encryption at Rest and in Transit
Every major cloud provider gives you encryption for free. There is no excuse for unencrypted production data in 2026. Yet we still routinely find unencrypted EBS volumes, S3 buckets without server-side encryption, and RDS instances with encryption disabled. The fix is usually a single configuration flag.
Enable encryption at rest by default for every storage service: S3, EBS, EFS, RDS, DynamoDB, Redshift on AWS; Storage Account, Managed Disks, SQL Database on Azure; Cloud Storage, Persistent Disk, Cloud SQL on GCP. Use customer-managed keys (KMS, Key Vault, Cloud KMS) for anything involving personal data, payment data, or health data, this gives you cryptographic deletion when the key is destroyed.
Encryption in transit means TLS 1.2 or higher on every endpoint. Disable older protocols at load balancers. Force HTTPS on every S3 bucket and CloudFront distribution. Internal service-to-service traffic should also use TLS, "it's a private VPC" is not a defense once an attacker gets a foothold.
3. Storage Bucket Hygiene: The #1 Public Cloud Leak
Public S3 buckets, public Azure Blob containers, and public GCS buckets are responsible for some of the largest data leaks in cloud history. The pattern is always the same: someone needed to share a file quickly, made the bucket public "temporarily," forgot about it, and three years later a security researcher's automated scanner found it.
Modern cloud providers now block public access by default at the account level, turn this on. Use signed URLs (S3 presigned URLs, Azure SAS tokens, GCS signed URLs) for any temporary external sharing. Audit existing buckets monthly with Macie, Defender for Storage, or open-source tools like ScoutSuite. Tag every bucket with an owner, purpose, and data classification.
- Block public access at organization level (AWS Organizations SCP / Azure Policy)
- Enable bucket versioning and MFA delete on critical buckets
- Configure lifecycle policies, old logs and backups should auto-delete after retention
- Enable Object Lock or WORM for compliance-critical data
- Use CloudFront/Front Door signed URLs instead of public buckets for content delivery
4. Logging, Monitoring and Detection
If you can't see it, you can't defend it. The first question we ask in any breach investigation is "can we get the CloudTrail/AzureActivity/AuditLogs for the past 90 days?", and depressingly often the answer is no, because logging was disabled, regional, or never centralized.
Set up a dedicated logging account (or subscription) on day one. Ship all audit logs there, lock it down so only security operations can read it, retain for at least 1 year (3 years if you're working toward SOC 2 or ISO 27001). Layer detection on top: GuardDuty / Defender for Cloud / Security Command Center catch the obvious stuff (port scanning, credential exfiltration, crypto mining); a real SIEM catches what they miss.
For startups that don't yet have a 24x7 SOC, partner with a managed detection service or invest in a lightweight SIEM like Wazuh, Elastic Security, or our SOC-as-a-Service. Detection without response is theatre, make sure someone is paged when alerts fire.
Full Cloud Penetration Test
Manual cloud penetration test covering IAM, storage, compute, network, and CI/CD. Delivered in 2 weeks with executive summary and developer-actionable findings.
See Cloud Pentest Service →5. Network Segmentation and Zero Trust
Cloud networks should be designed assuming compromise. Public-facing services live in one subnet behind a WAF and load balancer. Application services live in private subnets reachable only from the load balancer. Databases live in isolated subnets reachable only from application services. Management access (SSH, RDP) goes through a bastion or, better, Session Manager / Azure Bastion / IAP, never directly from the internet.
Security groups and NSGs are not firewalls, they are stateful packet filters. Treat every rule as a security boundary that should be justified and reviewed. "0.0.0.0/0 on port 22" should never exist in production. Use AWS Network Firewall, Azure Firewall, or GCP Cloud NGFW for actual stateful inspection and egress filtering.
Egress filtering matters more than most startups realize. The infamous Capital One breach exfiltrated data because the compromised EC2 could reach the internet freely. Restrict egress to known destinations, your container registries, package managers, monitoring providers, and you make data theft significantly harder.
6. Patching, Vulnerability Management and Container Security
Cloud doesn't eliminate patching, it changes who patches what. The shared responsibility model means you still patch operating systems, application runtimes, container images and application code. Run a vulnerability scanner against your AMIs, container images and live workloads weekly. Inspector, Defender Vulnerability Management, and Container Analysis are built-in starting points; layer Trivy or Snyk for deeper container scanning in CI.
Patch SLAs: critical CVEs within 7 days, high within 30 days, everything else within 90. Track patch compliance as a metric the engineering team owns. For containers, rebuild and redeploy weekly even when there are no code changes, base image updates pick up library CVEs automatically.
7. DPDP Act and Data Residency Considerations
Indian startups handling personal data must consider the DPDP Act 2023. Cross-border transfers to certain jurisdictions may be restricted by future notifications. Practical guidance: keep Indian customer data in ap-south-1 (Mumbai) or ap-south-2 (Hyderabad) regions; if you operate globally, build the architecture to support regional data residency from day one. Retrofitting region-locked storage at series C is expensive.
Beyond residency: maintain a Record of Processing Activities, build delete-on-request APIs, implement breach notification runbooks (72-hour clock for material breaches), and ensure your cloud provider is configured to support data deletion when a customer exercises their rights.
Frequently Asked Questions
How much does cloud security cost for an early-stage startup?
For a 20-50 person startup running on AWS, Azure or GCP, expect INR 3-8 lakh per year for a foundational cloud security program, that covers an initial cloud penetration test (INR 2-4 lakh), continuous posture monitoring tools (INR 1-2 lakh), and a quarterly review by an external consultant (INR 1-2 lakh). This is roughly 0.5-1% of typical series A burn rate, and it prevents the kind of breach that ends a company.
Is AWS more secure than Azure or GCP?
All three hyperscalers offer roughly equivalent security capabilities, the differences are in tooling, defaults, and ecosystem maturity. AWS has the largest set of native security services. Azure integrates best with Microsoft identity and Office 365 environments. GCP has the strongest default encryption posture. The real question is not which cloud is more secure; it is whether your team has the depth to configure any of them properly.
Do we need a SOC if we are only 30 people?
You need detection and response, but not necessarily a 24x7 in-house SOC. For startups under 50 employees, managed SOC services or SOC-as-a-Service typically deliver better coverage at lower cost than hiring. Once you reach 100+ engineers or handle regulated data (financial, health, payment) at scale, an in-house SOC starts making economic sense.
How often should we do cloud penetration testing?
At minimum once per year, plus after any major architectural change (new region, new tenant model, major IAM redesign). For startups handling sensitive data, twice-yearly is industry standard. Cloud configurations drift constantly, a one-time pentest catches issues at a single point in time and gives no guarantee about state 3 months later. Combine pentests with continuous posture monitoring.
Will ISO 27001 force me to redesign my cloud architecture?
Usually not. A reasonably well-configured AWS, Azure or GCP environment already covers 60-70% of ISO 27001 Annex A controls. The gaps are typically documentation (you have controls but not policies), logging (you have logs but not centralized), and process (you do things but cannot evidence them). A well-run ISO 27001 implementation wraps governance around your existing cloud setup rather than tearing it down.
What is the most common cloud security mistake you see in Indian startups?
Long-lived IAM access keys committed to private GitHub repositories. Private does not mean safe, an ex-employee with cached credentials, a leaked PAT token, or a compromised laptop turns into immediate cloud access. The fix is roles instead of keys, secret scanning in CI, and short-lived credentials via SSO. We see this in roughly 70% of first-time cloud assessments.
Can a small startup realistically implement zero trust?
Yes, and small startups have an advantage, there is less legacy to retrofit. Practical zero trust for a startup means: SSO with MFA for every system, device posture checks via MDM, application-layer authentication (no "VPN gives you the network"), and network microsegmentation in cloud. You do not need a six-figure zero trust platform; you need to design new systems with no implicit trust.
Lock Down Your Cloud Before You Scale
Codesecure is an ISO/IEC 27001:2022 certified cybersecurity firm. We help Indian startups secure AWS, Azure and GCP environments through cloud penetration testing, posture assessments, and ongoing managed security. Fixed-price engagements, OSCP-certified consultants, deliverables you can show to your enterprise customers and investors.
