Executive Summary
The most dangerous assumption in cloud migration projects is that security responsibility transfers to the provider along with the infrastructure. Gartner's widely cited prediction — "through 2025, 99% of cloud security failures will be the customer's fault" — has been borne out in the field: major cloud providers' infrastructure is rarely breached; what gets breached are the gaps customers leave in their own area of responsibility.[1]
The cost data points the same way. According to IBM's 2025 Cost of a Data Breach Report, the global average breach cost is $4.44 million, and breaches involving data spread across multiple environments run above that average.[2] A striking finding from IBM's 2023 report completes the picture: 82% of the breaches studied involved data stored in the cloud.[3] Flexera's research shows roughly 89% of organizations use more than one cloud — meaning this risk surface is not the problem of any single provider, but of inconsistency across environments.[4]
This report examines the most misunderstood layer of the shared responsibility model: application delivery and protection. It walks through the responsibility matrix layer by layer, lists the application-layer configuration errors we see most often in the field, and analyzes why policy drift is the least noticed gap in hybrid environments.
The Cloud Security Gap by the Numbers
Customer share of cloud security failures (Gartner prediction)
Global average (IBM 2025)
Share of breaches studied (IBM 2023)
Organizations using more than one cloud (Flexera)
The Model Is Simple — Its Interpretation Is Not
The shared responsibility model itself is not complicated: the provider is responsible for the security of the cloud, the customer for the security of what is in the cloud. The complexity comes from the boundary shifting as the service model changes — and from organizations assuming the boundary sits higher than it does. In IaaS, everything from the operating system up belongs to the customer; in PaaS, the platform moves to the provider but application configuration does not; even in SaaS, data classification, access policies, and identity configuration stay with the customer.
The critical point is this: whatever the model, control over the traffic reaching your application — who accesses it, which requests are legitimate, what data leaves — never transfers to the provider. The provider can give you tools; it does not take on the responsibility.
The Responsibility Matrix, Layer by Layer
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical infrastructure and hypervisor | Provider | Provider | Provider |
| Network controls | Shared | Shared | Provider |
| Operating system and middleware | Customer | Provider | Provider |
| Application and traffic policies | Customer | Customer | Shared |
| Data, identity, and access configuration | Customer | Customer | Customer |
The Application-Layer Errors We See Most in the Field
The errors that feed cloud breaches are not exotic; the same patterns repeat. Misconfiguration and inadequate change control have ranked near the top of the Cloud Security Alliance's threat lists for years.[5] What we see most often in the field:
WAF Left in Detection Mode
WAF policies switched to detection mode during migration — "let's monitor first" — never get switched to protection mode in the rush to go live. The organization believes it is protected; the WAF only produces logs.
Overly Permissive Network Rules
Broad NSG/security group rules opened for troubleshooting become permanent. "Temporary" 0.0.0.0/0 exceptions leave uninventoried management endpoints exposed to the internet.
Unencrypted Traffic After Termination
TLS is terminated at the load balancer, and traffic flows in plaintext across the internal network. In the cloud, the notion of an "internal network" is more porous than in the data center; leaving east-west traffic unencrypted is the quietest gap in your area of responsibility.
API Endpoints Missing from Inventory
Every microservice moved to the cloud produces new API endpoints. Undiscovered, schema-less endpoints fall outside WAF coverage; attackers like undocumented endpoints even more than documented ones.
Rule Drift Across Environments
A rule set fine-tuned on-prem over years is translated "approximately" to a different engine in the cloud. The two engines decide the same request differently — and nobody knows which environment is right.
Default Identity Configuration
Conditional access, MFA enforcement, and session policies are left at defaults "to be hardened later." In the cloud, identity has replaced the network perimeter; a default identity setting means a default perimeter wall.
The most common hybrid security gap is not a CVE but a process failure: mature in the data center, default in the cloud. While the on-prem copy of an application sits behind a tight WAF policy, the cloud copy runs on a basic signature set for months. Attackers scan both copies and enter through the weaker one. Policy drift does not correct itself over time; it grows unless it is measured.
The Real Cost of Hybrid Complexity
Running two separate WAF engines does not just mean two licenses. It means two rule languages, two exception lists, two testing processes, two sets of audit evidence, and two distinct bodies of expertise. The security team designs every change twice, tests it twice, and documents it twice. That cognitive load surfaces at precisely the most critical moments — during incident response — when answering which rule was active in which environment takes hours rather than minutes.
On the audit side, the cost is even more visible. PCI DSS, KVKK/GDPR, and sector regulations require audit evidence for every environment in scope. Proving the same protection in two different products in two different forms multiplies audit preparation time; inconsistency findings mostly arise from interpretation differences between the two products.
Multi-cloud grows this picture multiplicatively, not linearly. Flexera's data shows that the large majority of organizations use more than one cloud;[4] every new environment brings a new set of native security services and a new configuration language. As the number of environments grows, the claim of "the same protection in every environment" becomes indefensible unless it is built on policy rather than on tools.
Defensive Implications
Inventory Your Data Flows
Which application runs in which environment, which data does it touch, and who inspects its traffic? Without an inventory, the responsibility matrix stays on paper.
Put the Responsibility Matrix in Writing
Document the provider/customer boundary explicitly for every service model and leave no layer unowned. Verify the "the provider handles it" assumption against a written commitment.
Build a Single Policy Plane
Run the same control set — the same WAF engine, the same rule language, the same exception process — in every environment. When rule translation disappears, policy drift is structurally prevented.
Enforce End-to-End Encryption and Visibility
Enforce TLS not only at the edge but on east-west traffic as well; inspect encrypted traffic without leaving blind spots.
Validate Continuously
Test policy parity continuously, not in a yearly audit: the same request should get the same decision in every environment. Drift should be an alarm, not a finding.
The TR7 Approach: The Same Protection in Every Environment
TR7's answer to this picture is running the same platform in every environment:
The Same Image on Azure Marketplace
The TR7 virtual platform is available as a ready-to-run image on Azure Marketplace; the same engine that runs on hardware runs in the cloud.
Policy Portability
WAF rules, SSL/TLS profiles, and access policies move between environments without rule translation; one exception list, one set of audit evidence.
License Portability
Licenses are tied to the organization, not the platform; they move with the workload across Azure, GCP, and supported hypervisors.
Hybrid Traffic Management
GTM routes traffic between on-prem and cloud legs based on health, geography, and latency; it forms the backbone of a gradual migration.
References & Sources
Source of the prediction that "through 2025, 99% of cloud security failures will be the customer's fault." https://www.gartner.com/smarterwithgartner/is-the-cloud-secure
Primary source for the global average breach cost ($4.44 million) and per-environment cost breakdowns. https://www.ibm.com/reports/data-breach
Source of the finding that 82% of the breaches studied involved data stored in the cloud.
Annual research on multi-cloud adoption rates and enterprise cloud strategies. https://www.flexera.com/blog/cloud/cloud-computing-trends-flexera-state-of-the-cloud-report/
Threat ranking in which misconfiguration and inadequate change control hold top positions. https://cloudsecurityalliance.org/research/top-threats
Official documentation of provider/customer responsibility boundaries by service model. https://learn.microsoft.com/azure/security/fundamentals/shared-responsibility
The Same Protection in Every Environment
You don't have to rebuild your security layer when moving to the cloud. TR7 brings the protection and delivery policies from your data center to Azure on the same engine — one policy plane, one management console, one set of audit evidence.
Explore the WAAP Solution