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.
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.
An AWS security audit for Indian SaaS teams starts with IAM, then storage exposure, then network and workload configuration, then logging. The India specific items are the CERT-In six hour incident reporting clock and the 180 day log retention floor, which most global checklists omit entirely.
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.
S3 remains the fastest route from a small mistake to a public dataset.
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.
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.
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.
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.
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.
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.
Run it in this order. Each phase feeds the next.
| Phase | Focus | Typical duration |
|---|---|---|
| 1 | Account inventory, IAM and privileged access review | 3 to 5 days |
| 2 | Storage, encryption and data exposure | 2 to 3 days |
| 3 | Network, workload and container configuration | 3 to 4 days |
| 4 | Logging, monitoring and CERT-In alignment | 2 to 3 days |
| 5 | Framework mapping and evidence pack | 2 to 3 days |
| 6 | Remediation support and retest | Ongoing |
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.
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.
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.
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.
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.
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.
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.
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.
No obligation. Our senior consultants will walk through your environment and share where the gaps are. Whether you work with us or not.
Cybersecurity that helps enterprises worldwide move from “hope we’re safe” to “we’ve got this.”
Follow us
Copyright © 2026 Secureroot Risk Advisory LLP. All rights reserved.
