In this blog, we will discuss what a CERT-In security audit should check when production data moves between multiple cloud environments. We will cover audit scope, data transfers, access controls, cloud storage, databases, APIs, and network connections to help businesses understand the security checks needed in a multi-cloud setup.
What Should Be Included in the Multi-Cloud Audit Scope?
1. Production Cloud Accounts and Subscriptions
A CERT-In security audit should cover the cloud accounts and subscriptions that support production workloads. This includes the environments where applications, databases, storage, and other business services are hosted.
2. Cloud-Based Applications and APIs
Applications and APIs running across different cloud providers should be included in the scope. The audit should identify how these components communicate and what access they provide.
3. Databases and Storage Services
Production databases, object storage, backups, and replicated data stores should be reviewed. Their access permissions and exposure should match the intended business use.
4. Network and Connectivity Components
The audit should cover the network paths connecting different cloud environments, including private connections, VPNs, firewalls, security groups, and internet-facing services.
5. Identity and Access Management Systems
Cloud users, service accounts, roles, privileged accounts, and access policies should be reviewed to identify excessive or unnecessary permissions.
6. Cloud Security Services
Security monitoring, logging, key management, threat detection, and other cloud security services should also be considered where they support the production environment.
CERT-In’s 2025 Comprehensive Cyber Security Audit Policy Guidelines state that the audit scope should cover the organisation’s cyber infrastructure, including cloud architecture, APIs, databases, applications, hosting infrastructure, and data security. The scope should be based on an updated asset inventory.
How Should Data Movement Between Clouds Be Tested?
1. Mapping Data Flows Between Cloud Environments
The audit should identify what production data moves between cloud providers and which systems send or receive it.
2. Identifying Cloud-to-Cloud Connections
Each connection between cloud environments should be documented, including APIs, private networks, storage transfers, and service-to-service connections.
3. Checking Data Transfer Protocols
The security of the protocols used to move data should be reviewed to identify weak or incorrectly configured transfer methods.
4. Reviewing Encryption During Data Transfer
Sensitive production data should be protected while moving between cloud environments. Encryption settings should be checked along the transfer path.
5. Checking Data Destinations
The audit should verify that data is sent only to approved cloud accounts, services, storage locations, and databases.
6. Testing Unauthorized Data Transfers
Testing should determine whether a user, service, or application can send production data to a location outside its permitted scope.
What Access Controls Should Be Checked Across Multiple Clouds?
1. Cloud IAM Permissions
User and service permissions should be reviewed across each cloud provider to identify access that is broader than required.
2. Cross-Cloud User Access
Accounts with access to more than one cloud environment should be checked carefully, particularly when they can access production data.
3. Service Accounts and Roles
Service accounts should have only the permissions required for their assigned functions.
4. Privileged Cloud Accounts
Administrative accounts should receive additional review because they may have access to production systems, databases, and security settings.
5. Temporary Access Permissions
Temporary or emergency access should have clear limits and should not remain active after the required task is complete.
6. Least-Privilege Configuration
Access should be limited to the resources and actions required for each role or service. CERT-In guidance also highlights authorised asset inventories and least-privilege access as part of security management.
How Should Cloud Storage and Databases Be Assessed?
1. Public Storage Exposure
Storage services should be checked for unintended public access or permissions that allow unauthorised users to retrieve production data.
2. Database Access Permissions
Database accounts, application connections, and administrative access should be reviewed.
3. Cross-Cloud Database Connections
Connections between databases and applications hosted in different clouds should be checked for proper authentication and authorization.
4. Backup and Replication Access
Backup copies and replicated databases should receive the same access review as primary production data.
5. Encryption of Stored Data
The audit should check whether sensitive production information is protected while stored in databases, object storage, backups, and other services.
6. Unused Storage Resources
Unused storage resources should be identified because old databases, backups, and storage buckets may still contain sensitive information.
What Should Be Checked in Multi-Cloud API Connections?
1. API Authentication
APIs connecting different cloud environments should verify the identity of the calling application or service.
2. API Authorization
Authentication alone is not enough. The audit should check whether each API allows only the required users and services to access specific functions and data.
3. Cross-Cloud API Access
API connections between cloud providers should be reviewed for unnecessary access and weak authorization controls.
4. Sensitive Data in API Responses
API responses should be checked to ensure they do not expose unnecessary customer, financial, authentication, or internal information.
5. API Keys and Secrets
API keys, tokens, certificates, and other credentials used for cloud-to-cloud communication should be properly protected.
6. API Logging and Monitoring
API activity should be recorded so that unusual or unauthorised access between cloud environments can be identified.
CERT-In’s audit scope guidance includes APIs and data security along with cloud architecture, applications, databases, and hosting infrastructure.
How Should Network Connections Between Clouds Be Audited?
1. VPN and Private Connections
Private connections and VPNs should be reviewed to confirm that only approved networks and systems can communicate.
2. Firewall Rules
Firewall rules should allow only required traffic between cloud environments.
3. Security Groups
Cloud security groups and similar controls should be checked for unnecessary inbound and outbound access.
4. Network Segmentation
Production databases, applications, and sensitive services should be separated according to their security requirements.
5. Internet-Facing Services
The audit should identify services that are directly reachable from the internet and verify that their exposure is required.
6. Unnecessary Network Access
Unused ports, services, and network routes should be identified and reviewed.
7. Cross-Cloud Traffic Monitoring
Traffic moving between cloud environments should be monitored so unusual connections and unexpected data transfers can be investigated.
What Security Evidence Should Be Collected from Multiple Clouds?
1. Cloud Configuration Records
Relevant cloud configuration information should be maintained to show how production environments are set up.
2. IAM Policies and Permissions
Current IAM policies, roles, and permissions can help demonstrate how access to production resources is controlled.
3. Network Configuration
Network diagrams, firewall rules, security groups, and connectivity details should be available for review.
4. Access and Activity Logs
Logs can provide evidence of access to cloud resources and help support security findings.
5. Vulnerability Assessment Results
Current vulnerability assessment results should be maintained for systems covered by the audit.
6. Data Flow Documentation
Documentation should show where production data originates, where it moves, and which systems process it.
7. Security Monitoring Records
Relevant security alerts, monitoring records, and incident information should be available where applicable.
CERT-In audit guidance states that audit reports should document areas such as scope, methodology, findings, evidence, limitations, exemptions, and other audit constraints.
How Should Cloud Changes Affect the CERT-In Audit?
1. Adding a New Cloud Provider
Adding another cloud provider can introduce new accounts, networks, APIs, storage systems, and access controls that may need to be included in the audit scope.
2. Moving Production Workloads
Moving an application or database to another cloud can change its hosting, network, IAM, and data security controls.
3. Creating New Cloud Accounts
New production or supporting accounts should be added to the asset inventory and reviewed for their security configuration.
4. Changing Data Storage Locations
Moving production data to a different cloud or storage service can create new access and data protection requirements.
5. Adding New Cloud APIs
New APIs can introduce additional entry points and connections between applications and cloud services.
6. Changing IAM or Network Architecture
Major changes to permissions, network routes, security groups, or authentication can affect the existing security assessment.
7. Moving From Single-Cloud to Multi-Cloud
A move from one cloud provider to multiple providers changes the overall architecture and may require the audit scope to be reviewed.
CERT-In guidance recommends audits after changes in infrastructure and applications, with periodic audits based on the criticality of cyber assets.
Why Should Multi-Cloud Production Data Be Included in CERT-In VAPT?
1. Data Can Move Across Multiple Security Boundaries
Production information may pass through several cloud services, APIs, networks, and storage systems.
2. Cloud Configurations Can Differ Between Providers
Each cloud environment can have different IAM, networking, storage, and security settings that need separate review.
3. Cross-Cloud APIs Can Create New Access Paths
An API connecting two environments can become an additional route to production systems or data.
4. IAM Permissions Can Become Complex
Users and services may receive permissions across several cloud environments, making access review more important.
5. Storage and Database Exposure Can Change
Moving or replicating production data can create additional copies that require access and security checks.
6. Production Changes Can Make Earlier Audit Evidence Outdated
If the cloud architecture changes after an audit, older evidence may no longer represent the current production environment.
7. Full Cloud Coverage Helps Keep the Audit Scope Accurate
Including all relevant cloud environments, applications, APIs, data stores, and connections helps the audit reflect the current production setup.
Secure Your Multi-Cloud Environment with Peneto Labs
Managing production data across multiple cloud environments can make security assessments more complex. From cloud configurations and IAM permissions to APIs, databases, network connections, and data transfers, every component can introduce potential security risks.
At Peneto Labs, we help organisations assess their cloud and application security posture through high-quality VAPT and security assessments aligned with applicable security and compliance requirements. Peneto Labs has been empanelled by CERT-In to perform information security services.
Our assessments can help you:
- Identify vulnerabilities across multi-cloud environments
- Review cloud IAM and access controls
- Assess APIs and cloud-to-cloud integrations
- Identify exposed storage, databases, and services
- Review network security and segmentation
- Assess security controls around production data
- Validate security configurations and identify misconfigurations
- Provide actionable findings and remediation guidance
If your production environment spans multiple cloud providers, make sure your security assessment covers the complete architecture, not just individual cloud accounts.
Conclusion
A CERT-In security audit for a multi-cloud production environment should go beyond reviewing individual cloud platforms. It should assess how production data, applications, identities, APIs, storage, databases, and network connections work together across the entire cloud architecture.
Organisations should maintain an accurate asset inventory, map production data flows, review cross-cloud access, validate encryption and authentication controls, assess network exposure, and collect sufficient evidence to support audit findings. Any significant changes to cloud infrastructure, applications, data locations, IAM, or network architecture should also trigger a review of the existing audit scope.
A well-defined multi-cloud audit helps organisations identify security gaps that may not be visible when each cloud environment is assessed separately. It also helps ensure that the security assessment reflects the organisation’s current production architecture and supports stronger protection of sensitive business and customer data.
Talk to our team today to assess your multi-cloud security posture and secure your production environment.