Security teams in Germany and across DACH are being asked to protect estates that no longer have a single centre. A user may sign in from a managed device to a cloud application, query data in another environment, and trigger an AI service hosted by a third party. Each control may work in isolation, yet a gap between them can still expose the business. The European Union Agency for Cybersecurity’s latest threat landscape report describes how growing cyber dependencies are expanding the attack surface. For organisations in scope, the NIS2 Directive also brings cybersecurity risk management and senior accountability closer to board-level oversight. The practical challenge is to build layered protection that follows the request, the data, and the workload without adding friction to every legitimate action. 

Why Layered Security Matters 

Layered security is not a stack of unrelated tools. It is a set of controls that share context and cover different failure points. Identity can prevent an unauthorised user from reaching an application, but it cannot alone detect a compromised workload. Network segmentation can limit movement, but it does not tell an organisation whether sensitive data is leaving through a permitted channel. Effective design connects the layers so that signals from one improve decisions in another. 

Zero trust provides a useful principle for this approach. Access decisions should be made for each request using available context, rather than relying on a trusted network location. The CISA Zero Trust Maturity Model describes this as reducing uncertainty when organisations enforce accurate, least-privilege access decisions. 

Build The Layers Around Business Dependencies 

 Start With Identity and Access 

Identity is the first decision point for most digital activity. The relevant question is not justwhether a user has an account. It is whether the user, device, workload, or service identity should access a particular resource at this moment and under these conditions. Organisations should map privileged accounts, service identities, device posture, and high-value resources before adding more controls. Multifactor authentication and least privilege should protect sensitive access, while risk and context can determine when additional verification is needed. 

Microsoft Entra Conditional Access illustrates this model. Its policies combine signals such as user, device, location, and resource to decide whether access should be granted, restricted, or blocked. The wider lesson is to apply stronger controls when risk changes rather than subjecting every employee to the same level of friction. 

 Protect Cloud and Infrastructure Together 

Cloud security cannot be separated from the infrastructure that supports it. A practical review should cover workloads, APIs, operating systems, networks, secrets, and management planes, as well as the provider and third-party services behind them. Teams should map the dependencies between a production application, its data stores, identity provider, and external services. That map shows where a misconfiguration or compromised credential could travel. Segmentation, secure configuration, and controlled administrative access then create meaningful boundaries instead of isolated settings. 

 Treat Data and AI as Connected Assets 

Data controls should follow information as it moves through storage, applications, analytics pipelines, and models. That requires clear classification, rules for permitted use, and monitoring that can identify unusual access or extraction. AI adds further points to govern, including models, prompts, training data, tool permissions, and generated outputs. The NIST AI Risk Management Framework organises risk management around Govern, Map, Measure, and Manage. Used alongside an organisation’s security processes, it can help assign ownership across the AI lifecycle rather than leaving review until deployment is complete. 

 Join Monitoring to Response 

Monitoring is the connective tissue between prevention and recovery. Collecting more logs is not the same as creating better visibility. Teams should focus on events that change risk: a new privileged role, an unusual sign-in, a service identity accessing a new system, a large data transfer, or a model calling an unexpected tool. Each important alert needs an owner, a response playbook, and a way to test whether containment and recovery work. A control that creates noise without a clear action can slow the business without reducing exposure. 

 A Practical Framework for Prioritising Gaps 

The NIST Cybersecurity Framework 2.0 offers a broad way to understand, assess, and prioritise cybersecurity risk. For a connected environment, organisations can turn that principle into four practical questions: 

• Map. Identify the services that matter most, the data they use, the identities that reach them, and the third parties they depend on. Ask what must remain available and what would be most damaging if exposed. 

• Connect. Check that every critical path has preventive, detective, and recovery controls. Confirm that the relevant teams share signals and know who owns the decision when controls disagree. 

• Prioritise. Rank gaps by business impact, likely exposure, and concentration of risk. Apply the strongest controls to the highest-risk paths, while allowing lower-risk work to follow a simpler route. 

• Test. Run realistic scenarios such as stolen credentials, misconfigured cloud storage, a compromised API key, or an unsafe model output. Measure time to detect, contain, and recover, then remove controls that create repeated false positives. 

Security That Supports Operations 

Good controls are visible when risk changes and quiet when it does not. Google BeyondCorp and Microsoft Entra Conditional Access are examples of policy approaches that use identity and context instead of treating network location as a sufficient trust signal. They are product examples, not universal architectures. The principle is to make access decisions precise, explainabl,e and proportionate. Teams should monitor false positives, blocked work, exception requests, and the time required to complete secure workflows. Those measures show whether security is reducing risk while allowing the business to operate. 

Layered security works when it reflects the real route of work. For DACH organisations, the point to watch is whether governance, infrastructure, data, and AI teams own the connections between the layers. A checklist of tools is easy to produce. A tested model of dependencies, decisions, and recovery is more useful. Start with the services that matter most, make their dependencies visible and improve controls where a gap can change business risk. 

Sources And Further Reading 

• ENISA Threat Landscape 2026 — EU threat landscape and cyber dependencies. 

• NIS2 Directive — EU cybersecurity risk management and accountability for entities in scope. 

• NIST Cybersecurity Framework 2.0 — Risk assessment and prioritisation framework. 

• CISA Zero Trust Maturity Model — Guidance on context-based access decisions. 

• NIST AI Risk Management Framework — AI lifecycle risk-management framework. 

• Microsoft Entra Conditional Access — Example of context-aware access policies. 

• Google BeyondCorp — Example of identity- and context-aware access.