Security Is Not a Series B Problem
Indian startups move fast. Cloud infrastructure gets spun up quickly, permissions are granted liberally, and security is deferred to "after we hit product-market fit." The problem: by the time you have revenue and customers, you also have a security debt that is expensive and painful to fix.
Here are the 10 most common cloud security mistakes we see in Indian startups -- and how to avoid them from day one.
1. Overly Permissive IAM Policies
The mistake: Granting AdministratorAccess or full-access policies to developers, CI/CD pipelines, and application roles because "we will tighten it later."
The fix: Start with least privilege from day one. Create role-specific policies: - Developers: Read access to production, write access to their team's dev account - CI/CD: Only the permissions needed to deploy to the target environment - Applications: Only the specific services they call (S3 bucket, DynamoDB table)
2. Root Account Usage
The mistake: Using the AWS root account or equivalent for daily operations.
The fix: - Enable MFA on the root account immediately - Create IAM users or SSO roles for all human access - Lock the root credentials in a secure location - Never create access keys for the root account
3. Secrets in Code Repositories
The mistake: Committing database passwords, API keys, and credentials directly in application code or configuration files.
The fix: - Use environment variables or secret managers (AWS Secrets Manager, Azure Key Vault) - Add pre-commit hooks that scan for secrets (use tools like gitleaks or trufflehog) - Rotate any secrets that have ever been committed to Git (assume they are compromised) - Enable GitHub secret scanning alerts
4. No Encryption at Rest
The mistake: Leaving S3 buckets, databases, and EBS volumes unencrypted.
The fix: - Enable encryption by default for all new resources using organizational policies - Use cloud-native KMS for key management with automatic rotation - Audit existing resources and encrypt any unencrypted stores containing customer data - Read our encryption strategies guide for a comprehensive approach
5. Public S3 Buckets and Storage
The mistake: Accidentally making storage buckets publicly accessible, exposing customer data to the internet.
The fix: - Enable "Block Public Access" at the account level for S3 - Use bucket policies that explicitly deny public access - Run periodic scans for publicly accessible storage (AWS Access Analyzer, Azure Advisor) - Never use S3 for serving static content without CloudFront in front
6. Missing VPC Configuration
The mistake: Running application workloads in the default VPC with default security groups that allow all inbound traffic.
The fix: - Create custom VPCs with proper subnet design (public, private, database tiers) - Use private subnets for databases and application servers - Default-deny inbound traffic on all security groups - Explicitly allow only the ports and sources needed
7. No Logging or Monitoring
The mistake: Running cloud infrastructure without audit logging, making it impossible to detect or investigate security incidents.
The fix: - Enable CloudTrail (AWS), Activity Log (Azure), or Audit Log (GCP) from day one - Ship logs to a centralized location (S3 bucket, Log Analytics, Cloud Logging) - Enable VPC Flow Logs for network traffic visibility - Set up basic alerts for root account usage, IAM changes, and security group modifications
8. Neglecting Security Group Hygiene
The mistake: Security groups with 0.0.0.0/0 (all traffic) inbound rules, SSH access open to the internet, and unused rules accumulated over months.
The fix: - Never allow 0.0.0.0/0 inbound except for load balancers on ports 80/443 - Use bastion hosts or SSM Session Manager for SSH access (no direct SSH from internet) - Audit security groups monthly and remove unused rules - Tag security groups with their purpose for easier management
9. No Backup and Recovery Plan
The mistake: No automated backups, untested restore procedures, and no disaster recovery plan.
The fix: - Enable automated backups for all databases (daily minimum, with point-in-time recovery) - Test restore procedures monthly (an untested backup is not a backup) - Store backups in a separate region for disaster recovery - Document recovery procedures and RTO/RPO targets
10. Ignoring DPDPA Requirements
The mistake: Assuming data protection regulations do not apply to startups or deferring compliance indefinitely.
The fix: - Map what personal data you collect and where it is stored - Implement basic consent management (clear consent at signup, ability to delete accounts) - Enable encryption and access controls for personal data - Document your data processing practices - Plan for compliance before you reach significant scale
The Startup Security Starter Kit
If you do nothing else, implement these five controls today:
- MFA everywhere: Root accounts, IAM users, email, code repositories
- Least privilege IAM: No AdministratorAccess for anyone
- Encryption at rest: All databases and storage buckets
- Audit logging: CloudTrail enabled in all accounts
- No secrets in code: Use secret managers and pre-commit scanning
These five controls take less than a day to implement and prevent the majority of cloud security incidents.
At Optivulnix, we offer a startup security accelerator that gets your cloud security fundamentals in place in one week. Contact us for a free security assessment.
