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 again after any material change: a new production account, a migration, an acquisition, or an architecture change that moves where data lands. Treat that cadence as a floor. The trigger most teams miss is organisational rather than technical, because a team gains its own account, a contractor keeps access after the project ends, or a CI pipeline is handed a role nobody scoped. AWS Config recording and conformance packs will catch configuration drift between reviews, but drift detection tells you whether a setting changed, not whether the design still fits the business you have now. Use the annual review to re-ask the ownership questions: who holds each privileged role, which cross-account trust still has a named owner, and whether CloudWatch retention on every log group still clears the 180 day floor in the CERT-In Directions. SecureRoot scopes that review on a 30 minute call; scope, timeline and fees are set out in the signed engagement agreement before any work starts.

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

No, and the difference decides what you learn. An audit compares your configuration against a control set and returns a list of misconfigurations: a bucket without default encryption, a log group left at never expire, an IAM user without MFA. Penetration testing starts from what an attacker can reach and hunts the chain instead, such as an IMDSv1 endpoint reachable through server side request forgery, credentials lifted from an over-permissioned instance role, then lateral movement into an account the application team was never meant to touch. Every link in that chain can pass a benchmark on its own, which is exactly why a clean audit report is not evidence of a hard target. Most teams need both, and in that order, because exploiting a misconfiguration you already know about spends the testing budget badly. SecureRoot's testing is manual and exploit-driven, with a proof of concept for each finding and a retest included in the engagement.

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

It means CloudWatch log group retention set to at least 180 days on every group, CloudTrail enabled in all regions with log file validation on, delivery into a dedicated account the application team cannot write to, and log data held in India where residency applies. The CERT-In Directions of 28 April 2022 require specified cyber incidents to be reported within six hours of noticing them and security logs to be retained for 180 days within Indian jurisdiction. Two details catch teams out. Retention is configured per log group rather than per account, so one forgotten application group undoes the claim for the whole estate. And the six hour clock is a detection problem before it is a reporting problem, which is why GuardDuty and Config alerts need a route to somebody awake rather than a shared mailbox. SecureRoot is not CERT-In empanelled; we assess the configuration against these obligations and hand you the evidence your filing rests on.

Do we need an India region specifically?

It depends on your contracts and your regulatory position rather than a blanket rule. The CERT-In Directions of 28 April 2022 require security logs to be retained for 180 days within Indian jurisdiction, so the log estate is the clearest case for an India region. Beyond logs the picture is narrower than people assume: the DPDP Act restricts transfers only to countries the government notifies rather than imposing general localisation, while sector rules carry their own expectations, including the RBI's Cybersecurity, Technology Risk, Resilience and Assurance Framework Directions issued on 31 July 2026 and SEBI's CSCRF for regulated market entities. Enterprise customers often write residency into the contract regardless of any statute. Confirm the requirement with your legal team before redesigning around it, because a cross-region rebuild is expensive and rarely reversible. Where residency genuinely applies, move the logging and backup estate first and treat compute placement as a separate, later decision.

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

A provider or partner review is a useful baseline, but it is not assurance. It generally checks configuration against a benchmark, which finds the settings that are wrong today and says nothing about how they came to be wrong. It is also not independent, because the party that built your landing zone is reviewing its own work, and the questions it is least likely to ask are the ownership ones: which privileged role still maps to a real task, which cross-account trust has a named owner, which CI role can assume more than its pipeline needs. In our assessments those identity questions produce the most serious findings, and no benchmark flags them. Enterprise buyers and SOC 2 auditors normally want an assessment from someone with no stake in the build. A configuration assessment answers the benchmark question; cloud penetration testing answers the harder one, which is what an attacker reaches starting from whatever the benchmark allowed.

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.