AWS Cloud Security Audit Checklist for Indian SaaS Teams

Most AWS security checklists you will find were written for a US audience. They cover IAM hygiene and public S3 buckets well, and they say nothing about the two requirements that will actually appear in your next India audit: a six hour incident reporting clock and a 180 day log retention floor.

This checklist is built for SaaS teams running production workloads on AWS from India. It covers the standard cloud security ground, then the India-specific items that global guides leave out. Work through it in order. The early sections catch the failures that cause real breaches, and the later ones catch the failures that cause audit findings.

Start with identity, not with the perimeter

An audit of IAM policies across every account is the first checkpoint of any serious AWS review, and it is where most findings cluster. Cloud breaches rarely begin with a clever exploit. They begin with a credential that had more permission than the job needed.

IAM checklist

• Root account has MFA enabled and no active access keys
• No IAM users with console access lack MFA
• Access keys older than 90 days are rotated or removed
• No inline policies granting wildcard actions, and any that remain are justified in writing
• Service accounts use roles, not long lived user credentials
• Cross account trust relationships are enumerated and each one has a named owner
• IAM Access Analyzer is enabled in every region you use
• Permission boundaries applied to any role a CI pipeline can assume

The test that finds the most in practice: pick your three most privileged roles and ask which specific task each was created for. If nobody can answer, that role has drifted.

Storage and data exposure

S3 remains the fastest route from a small mistake to a public dataset.

• Block Public Access enabled at the account level, not only per bucket
• Every bucket has default encryption enabled
• Bucket policies reviewed for wildcard principals, including conditional grants
• Versioning enabled on buckets holding customer data
• Lifecycle rules exist and match your stated retention policy
• EBS volumes and RDS instances encrypted at rest
• RDS snapshots are not shared publicly
• Secrets live in Secrets Manager or Parameter Store, never in environment variables committed to a repository

For Indian SaaS teams the retention rule cuts both ways. Your DPDP Act obligations push you to delete personal data once its purpose ends. Your CERT-In obligations push you to retain security logs. These are different data classes and need different lifecycle rules. Applying one blanket policy to both is a common and expensive mistake.

Network and workload configuration

• Security groups audited for open access on any port other than 80 and 443
• SSH and RDP never open to the internet, access via SSM Session Manager or a bastion with MFA
• VPC Flow Logs enabled on production VPCs
• Default VPCs in unused regions removed or explicitly justified
• Load balancers enforce TLS 1.2 or higher
• EC2 instances use IMDSv2 only, IMDSv1 disabled
• Container images scanned before deployment and base images patched on a schedule

IMDSv1 deserves particular attention. It is the mechanism behind several well known cloud credential thefts via server side request forgery, and disabling it is a configuration change rather than a project.

Logging, and the India specific part

This is the section global checklists get wrong for an Indian audience.

The CERT-In Directions of 28 April 2022 require organisations to report specified cyber incidents within six hours of noticing them, and to retain security logs for 180 days with the logs held inside India. On AWS that translates into concrete settings rather than a policy statement.

• CloudTrail enabled in all regions, with log file validation on
• CloudTrail logs delivered to a dedicated account the application team cannot write to
• CloudWatch log group retention set to at least 180 days across every group, not left at the default of never expire or a shorter custom value
• Log data resides in an India region where residency is required by contract or policy
• GuardDuty enabled in every active region
• AWS Config recording enabled with conformance packs mapped to the frameworks you claim
• Alerting routes to somebody who is awake, not only to an inbox (this is what a managed SOC exists to solve)

That last item is where the six hour clock is won or lost. Six hours is not a reporting window you can satisfy by discovering an incident on Monday from Friday logs. It assumes continuous monitoring and somebody who can recognise a reportable event as it happens.

Check your CloudWatch retention today. In most accounts we assess, at least one log group is still set to the default, and it is usually an application group nobody remembered to configure.

Mapping the audit to the frameworks you claim

If you sell to enterprises, your AWS configuration is evidence in somebody else audit. AWS Audit Manager can collect evidence mapped to SOC 2, HIPAA and PCI DSS control frameworks automatically, and AWS Config conformance packs give you continuous monitoring against a named control set.

The efficiency here matters. A single well configured logging and Config baseline produces evidence for SOC 2 Common Criteria, ISO 27001 Annex A controls and your DPDP Act security safeguards position at the same time. Teams that run these as three separate exercises pay three times for one set of controls.

What this looks like in the NCR market

Gurgaon and Noida carry a dense concentration of SaaS and fintech companies selling into regulated buyers, and the pattern we see repeatedly is a strong product security posture sitting on an unreviewed cloud configuration. The application gets penetration tested every year because a customer asks for the report. The AWS account that hosts it has never been reviewed, because no customer asks for that one specifically.

The second pattern is scale related. A company that grew from three AWS accounts to fifteen through acquisitions or team autonomy usually has no consolidated view of who can access what. The audit finding is not any single misconfiguration, it is the absence of a place where the answer lives.

A practical audit sequence

Run it in this order. Each phase feeds the next.

An automated scan gives you phases 2 and 3 quickly. Phases 1 and 4 need a person, because the questions are about intent and ownership rather than configuration state.

Where SecureRoot fits

SecureRoot runs cloud penetration testing and configuration reviews across AWS, Azure and GCP for SaaS and fintech teams in Delhi NCR and across India. We review the configuration and then test what an attacker could actually reach from it, which is a different question from whether a setting matches a benchmark.

Because the same team handles ISO 27001, SOC 2 and DPDP Act work, the output feeds your compliance evidence rather than sitting in a separate report. Our full range is on the services page.

Frequently asked questions

How often should we run a cloud security audit?

Annually as a baseline, and after any material change: a new production account, a migration, an acquisition, or a significant architecture change. Continuous monitoring through AWS Config covers drift between audits, but it does not replace a review that asks whether the design still makes sense.

Is an AWS security audit the same as cloud penetration testing?

No. An audit compares your configuration against a control set and finds misconfigurations. Penetration testing attempts to exploit what is there and finds attack paths, including chains where two individually acceptable settings combine badly. Most teams need both, and the audit should come first.

What does the CERT-In 180 day log retention rule mean on AWS?

In practice it means CloudWatch log group retention set to at least 180 days across every group, CloudTrail enabled in all regions with logs stored where they cannot be altered by the application team, and log data held in India where residency applies. Default retention settings do not satisfy it.

Do we need an India region specifically?

It depends on your contractual and regulatory position rather than a blanket rule. Where log residency inside India is required, the storage location has to reflect that. Confirm the requirement with your legal team before redesigning your architecture around it.

Our AWS setup was reviewed by our cloud provider. Is that enough?

A provider review usually checks configuration against a benchmark and is a useful baseline. It is not independent, and it typically excludes the identity drift and access questions that produce the most serious findings. Buyers asking for assurance generally want an independent assessment.

Next step

If you are preparing for a SOC 2 audit, responding to a customer security questionnaire, or simply have not looked at your AWS accounts in a year, a scoped review will tell you where you stand.

Book a 30 minute scoping call with our cloud security team, or call +91 73071 48874.