Know whether your cloud is set up safely — against a benchmark you can name.

• Recording switched off before a resource existed also gives a WARNING that evaluates nothing.
• The recommended CloudFormation template excludes IAM global resources from recording by default, and daily recording sends no data on a day without changes.
• With Security Hub CSPM and Security Hub both enabled, the Config.1 control always shows PASSED.

• IAM Access Analyzer trusts access from inside its zone of trust, the account or organization chosen at set-up. It reads external access only in its own Region, and covers fifteen resource types for external access and six for internal access.
• Last-accessed data misses iam:PassRole, data plane events, and access allowed by resource-based policies, access control lists, service control policies, permissions boundaries and session policies. It counts failed attempts too.
• Google's IAM recommender looks back at most 90 days and ignores access control lists and Kubernetes role-based access control.

• Defender for Cloud has two Secure Score models with different calculations. The classic one counts only built-in Microsoft cloud security benchmark (MCSB) recommendations, not Preview ones.
• Defender recalculates each control every eight hours per Azure subscription or per AWS or GCP connector. Microsoft's note of 30 June 2026 says over 200 new AWS and GCP recommendations began counting, so a score change there reflects wider scope, not a worse environment.
• MCSB mappings to CIS, NIST and PCI don't mean full compliance. Microsoft's SE:01 calls benchmarks a starting point for your own baseline.
• Security Health Analytics runs batch scans daily on one tier and every 48 hours on another; real-time detectors scan when a configuration changes.

NIST SP 800-115 (September 2008), Chapter 3, Review Techniques: reviews are passive and pose minimal risk. Section 3.4 compares settings with a checklist; automation is preferred, but some settings must be checked manually.

CERT-In's Comprehensive Cyber Security Audit Policy Guidelines, Version 1.0, 25.07.2025: section 6 defines Cloud Security Testing as evaluating and assessing security measures, configurations and vulnerabilities, so our scope names which one you are buying. Clause 13.1.1(a) puts cloud architecture in audit scope; 13.1.1(c) derives scope from the consolidated, updated asset inventory.

The Reserve Bank of India (Outsourcing of Information Technology Services) Directions, 2023, Appendix I: paragraph 3 makes cloud security a shared responsibility between the regulated entity (RE) and the cloud service provider (CSP). Paragraph 6(b) asks for role-based user and privileged access, segregation of duties, need-to-know, least privilege and multi-factor authentication; 6(c) for control objectives at least as high as on-premise; paragraph 9 for the RE's audit, periodic review or third-party certifications to cover, as per applicability and cloud usage, roles and responsibilities of RE and CSP in cloud governance, access and network controls and configurations. Clause 2(a) applies the Directions to commercial banks as defined there, Primary (Urban) Co-operative Banks in Tier 3 and Tier 4, NBFCs in the Top, Upper and Middle Layers, Credit Information Companies, and EXIM Bank, NABARD, NaBFID, NHB and SIDBI; clause 2(c) limits them to Material Outsourcing of Information Technology Services arrangements, as the Directions define that term.

SEBI's Frequently Asked Questions on CSCRF for SEBI REs and the Framework for Adoption of Cloud Services by SEBI REs, 11 June 2025: question 49 makes the RE solely accountable; question 43 cites clause 4(ii) of the SEBI Cloud Adoption Framework, which mandates an explicit and unambiguous delineation of responsibilities between the RE and the CSP; question 27 lets coverage stop at systems under SEBI's purview only if properly segregated, connected systems included. The FAQ says it is neither an interpretation of CSCRF nor a binding opinion.