Most financial institutions do not operate in a single environment. Core banking systems run on-premises. Customer-facing applications run on public cloud. Data warehouses and analytics workloads sit somewhere in between. That distributed model — commonly called a hybrid cloud architecture — is now the operational baseline for the sector, and it creates security challenges that neither purely on-premises nor purely cloud-native security programmes were designed to handle. This guide covers the main security risks of hybrid cloud environments and the practical controls that address them, with particular attention to the regulatory obligations that apply to financial institutions operating in the EU.
What Is Hybrid Cloud Security?
Hybrid cloud security refers to the set of policies, controls, and technologies used to protect data, applications, and infrastructure across an environment that spans both private infrastructure (on-premises data centres or private cloud) and public cloud platforms such as AWS, Azure, or Google Cloud.
The defining characteristic of a hybrid environment is that workloads and data move between these environments — sometimes continuously. That movement is where most security risk concentrates: in the connections between environments, in the inconsistencies between security policies applied in each environment, and in the gaps in visibility that arise when no single tool has a complete picture of the whole.
The Core Security Challenges in Hybrid Cloud Environments
Securing a hybrid cloud environment requires a unified strategy across on-premises and public cloud systems. Fragmented visibility. In a purely on-premises environment, a single security team with access to network logs and endpoint data can monitor the full estate. In a hybrid cloud model, public cloud providers generate their own logs in their own formats, on-premises systems generate separate logs, and the connections between them generate yet more data. Without deliberate effort to centralise and correlate that data, security teams are working with partial views — which is where attackers operate. Centralised visibility is critical in hybrid cloud deployments because 67% of organisations report network blind spots as a significant challenge in protecting their data.
Inconsistent access controls. On-premises systems typically use Active Directory or LDAP-based identity management. Cloud platforms use their own Identity and Access Management (IAM) systems. When users access resources in both environments, maintaining consistent access policies — who can access what, under what conditions, and with what level of authentication — requires explicit integration work. Organisations that do not do this integration end up with duplicate identity systems that drift apart over time, creating accounts that exist in one environment but not the other, or privileges that were revoked on-premises but remain active in the cloud.
Data classification and sovereignty. Financial institutions handle data at varying sensitivity levels, and regulatory requirements often dictate where certain categories of data can reside. Personal data subject to GDPR must remain within the European Economic Area unless specific transfer mechanisms are in place. Under DORA — the Digital Operational Resilience Act — institutions must document and monitor all ICT service providers, including cloud providers, and maintain an accurate register of information. A hybrid environment that lacks a clear data classification policy makes both requirements significantly harder to satisfy, especially given the unique security challenges of moving sensitive data between environments.
Misconfiguration risk. Cloud misconfigurations — storage buckets set to public access, overly permissive IAM policies, security groups with open inbound rules — are among the most common causes of cloud security incidents. The risk is heightened in hybrid environments because teams managing on-premises infrastructure and teams managing cloud infrastructure often operate with different processes, tools, and levels of cloud-specific expertise. That also expands the attack surface and adds to the hybrid cloud security challenges organisations already face. Enforcing consistent standards across private and public cloud environments, using baselines such as CIS Benchmarks or the NIST Cybersecurity Framework, helps reduce those gaps.
Shared responsibility ambiguity. Public cloud providers operate under a shared responsibility model: the provider secures the underlying infrastructure, and the customer is responsible for securing everything built on top of it. That boundary is well-defined in principle but frequently misunderstood in practice. Financial institutions that assume their cloud provider handles data encryption, access logging, or network segmentation — when those responsibilities sit with the customer — will have gaps in their security posture that may only become visible during an audit or an incident.
Hybrid Cloud Security Best Practices
Establish Unified Visibility Across Environments
The first requirement is being able to see what is happening across your entire estate from a single point. In practice, this means using centralized log management to aggregate telemetry from all environments into a single dashboard for monitoring and incident response, feeding a SIEM that supports unified visibility across a hybrid cloud security architecture, reduces blind spots in hybrid cloud infrastructure, and helps surface security gaps across multiple environments with detection rules that operate across environment boundaries.
Cloud providers offer native logging services — AWS CloudTrail, Azure Monitor, Google Cloud Audit Logs — but these must be actively enabled, retained for a sufficient period, and fed into your central monitoring stack across different cloud environments. Under DORA, financial institutions are required to maintain capability for ICT-related incident detection and response across all ICT systems, which includes cloud-hosted systems in multiple cloud environments. Under ISO/IEC 27001:2022, control A.8.15 (logging) and A.8.16 (monitoring activities) apply to all systems within the ISMS scope, regardless of where they run.
Centralise Identity and Access Management
Managing identity consistently across a hybrid environment requires a single authoritative source for user identities that both on-premises systems and cloud platforms can query. The practical implementation typically involves federating on-premises Active Directory with cloud IAM systems through a standards-based protocol such as SAML or OIDC, so that users authenticate once and that authentication is trusted across both environments.
Beyond single sign-on, centralised IAM enables consistent enforcement of key access controls: multi-factor authentication (MFA) required across all environments to protect all accounts, with phishing-resistant MFA prioritised for high-risk administrative accounts, role-based access control (RBAC) policies defined once and applied consistently, and access reviews that cover the full estate rather than each environment in isolation. RBAC limits access to cloud resources based on role, helping prevent unauthorised access or accidental changes. Define roles such as admin, developer, or analyst, and align permissions to each role’s responsibilities. Apply least privilege to both users and machine workloads. This is especially important in multiple cloud environments and for protecting sensitive customer data. Access reviews — documented, timestamped, and completed at least quarterly — are a standard audit requirement under both ISO 27001 (control A.5.18) and SOC 2 (Common Criteria CC6), and should include reviewing access permissions across the full estate.
Apply Zero Trust Principles to Cross-Environment Traffic
The traditional network perimeter — trusted inside, untrusted outside — does not map onto a hybrid cloud architecture where workloads communicate across environment boundaries continuously in hybrid cloud settings. Zero Trust replaces the perimeter model with a principle of verifying every access request regardless of origin: users must continually verify their identity to gain access, and only approved users or systems should reach the infrastructure, even if they originate from within the corporate network.
In a hybrid cloud context, Zero Trust typically means: requiring authentication and authorisation for every API call between on-premises and cloud systems; applying micro-segmentation, which divides networks into isolated zones to limit lateral movement during breaches, so that a compromised workload in one environment cannot move laterally into another; and validating device health and user context before granting access to sensitive resources and maintaining secure systems. Zero Trust is not a single product — it is a design principle that must be applied systematically across the architecture to reduce security threats. As workloads and data move from on-premises systems to public cloud environments, Zero Trust adds controls to protect sensitive information from unauthorized access.
Enforce Consistent Data Classification and Encryption
Data that flows between on-premises and cloud environments should be classified before it is placed in either. Classification determines the protection requirements: what can be stored in public cloud, what must remain on-premises, and what must be encrypted at rest or in transit to support protecting sensitive data with specific protocol standards. DLP tools can monitor classification and prevent unauthorized data transfers between environments in hybrid cloud systems.
Encryption of data in transit between environments should be treated as non-negotiable. All communication between on-premises systems and public cloud should traverse encrypted channels — TLS 1.2 or higher for API calls, IPSec or equivalent for network-level connections. Encryption at rest should be applied to all sensitive data stored in cloud environments, and teams should encrypt data with encryption keys managed by the customer through a centralized Key Management Service (KMS) rather than delegated entirely to the cloud provider where regulatory requirements demand it. Under DORA’s ICT risk management requirements, financial institutions must implement protective measures that include encryption of data at rest and in transit. Automatic backups should cover both public and private cloud environments to support recovery from cyberattacks, hardware failures, or accidental deletions as part of business continuity.
Implement Cloud Security Posture Management
Cloud Security Posture Management (CSPM) tools continuously scan cloud environments for misconfigurations against defined security baselines and compliance frameworks, supporting configuration management in fast-moving estates. In a hybrid environment, CSPM addresses the misconfiguration risk that manual processes cannot keep pace with — cloud infrastructure changes too quickly for periodic manual reviews to be reliable. Automated compliance verification tools can continuously check architectures against frameworks such as GDPR or PCI DSS, helping enforce consistent security and validate security settings.
A CSPM implementation should be configured against the security baseline appropriate for your environment: the Centre for Internet Security (CIS) Benchmarks for each cloud platform are a well-established starting point. For financial institutions with ISO 27001 certification, CSPM findings should feed into the organisation’s risk register and be tracked through to remediation as part of the standard risk treatment process. Used well, hybrid cloud security tools support consistent security policies across systems. Security automation tools can detect anomalies and respond to potential threats in real time, reducing reliance on manual processes and lowering the risk of human error.
Build a Unified Incident Response Capability
An incident that originates in the cloud and propagates to on-premises systems — or vice versa — requires a response capability that can operate across both environments simultaneously. Incident response plans that were written when the organisation operated purely on-premises will have gaps when applied to hybrid environments: different escalation contacts, different forensic collection procedures, different recovery procedures.
Hybrid-ready incident response planning means: documenting the specific steps for containment, eradication, and recovery in each environment; establishing clear ownership for cloud-specific response actions; and testing the plan with exercises that specifically simulate cross-environment scenarios. This should also align with a documented business continuity plan and wider business continuity requirements, with automated policy enforcement helping reduce human error during cross-environment response. Under ISO/IEC 27001:2022, control A.5.26 requires that responses to information security incidents be implemented in accordance with documented procedures. DORA adds further specificity for financial institutions, including requirements for ICT-related incident classification, escalation timelines, and regulatory notification.
Manage Third-Party and Cloud Provider Risk
Public cloud providers are ICT third-party service providers within the meaning of DORA. Financial institutions subject to DORA must include cloud providers in their ICT third-party register, assess their concentration risk (particularly where a single provider hosts multiple critical functions), and ensure that contracts with cloud providers include the mandatory clauses required under DORA Article 30.
Beyond DORA, cloud provider assessments should address: the provider’s own security certifications (ISO 27001, SOC 2 Type 2, ISO 27017 for cloud-specific controls); the contractual provisions for data deletion, audit rights, and exit; and the security controls the provider applies to the shared infrastructure that underpins your workloads. The shared responsibility model should be documented explicitly — for each cloud service in use, your organisation should have a written record of which security responsibilities belong to the provider and which belong to you.
How Hybrid Cloud Security Maps to Regulatory Requirements
For EU financial institutions, hybrid cloud security is not purely a technical discipline — it connects directly to regulatory obligations under DORA, NIS2, GDPR, and ISO 27001. The table below maps the key security practices to the frameworks that require them:
- Centralised logging and monitoring — ISO 27001 A.8.15/A.8.16, DORA Article 10 (ICT-related incident detection)
- Identity and access management — ISO 27001 A.5.15–A.5.18, SOC 2 CC6
- Encryption at rest and in transit — ISO 27001 A.8.24, DORA ICT risk management guidelines, GDPR Article 32
- Cloud provider risk management — DORA Article 28–30, ISO 27001 A.5.19–A.5.23
- Incident response — ISO 27001 A.5.26, DORA Article 17–23, NIS2 Article 23
The practical implication is that a well-implemented hybrid cloud security programme does not duplicate effort across frameworks — it satisfies requirements across multiple frameworks simultaneously, provided the controls are documented and evidenced correctly.
Frequently Asked Questions
What is the biggest security risk in a hybrid cloud environment?
Fragmented visibility is the most consequential risk. When security teams cannot monitor all environments from a single point, attackers can move between environments undetected. Misconfigurations — particularly overly permissive access policies or unencrypted data in cloud storage — are the most common individual cause of incidents.
Does DORA apply to cloud services used by financial institutions?
Yes. Public cloud providers that financial institutions use for ICT services are third-party ICT service providers under DORA. They must be included in the institution’s ICT third-party register, assessed for concentration risk, and contracted with mandatory clauses as specified in DORA Article 30.
What is the shared responsibility model in cloud security?
The shared responsibility model defines the division of security responsibilities between a cloud provider and its customer. The provider is responsible for the security of the underlying infrastructure; the customer is responsible for securing everything built on that infrastructure — including access controls, data encryption, network configuration, and application security. The precise boundary varies by service type (IaaS, PaaS, SaaS).
Hybrid cloud security is not a problem that resolves itself at a point in time. The environment changes continuously — new services are provisioned, configurations drift, personnel change — and the security programme must keep pace with those changes through monitoring, access reviews, and regular assessment of the posture across both environments. Organisations that treat it as a one-time architecture project rather than an ongoing programme will accumulate risk faster than they can detect it.
How Copla Supports Hybrid Cloud Security Programmes
We work with financial institutions to build security and compliance programmes that cover the full hybrid environment — not just the on-premises estate or the cloud workloads in isolation. The engagement starts with a scoping workshop that maps your hybrid architecture, identifies where sensitive data flows between environments, and assesses your current controls against the applicable frameworks: ISO 27001, DORA, NIS2, or SOC 2.
From there, we support control implementation across the key areas: identity and access management policy, cloud configuration baselines, logging and monitoring architecture, incident response planning, and third-party risk assessments for your cloud providers. The Copla platform tracks evidence of controls operating across both environments, so that when an audit comes — whether an ISO 27001 Stage 2 or a DORA supervisory review — the documentation is already organised.
Schedule a call with Copla to walk through how this would look for your environment.
