CyberSilo Security Architecture Review: Building Defence-in-Depth for Europe

What Is Defence-in-Depth Security Architecture?

Defence-in-depth is a layered security strategy where multiple overlapping controls protect assets so that if one layer fails, another compensates. In a European regulatory context, this directly maps to NIS2's requirement for proportionate technical and organisational measures under Article 21(2)—including policies on risk analysis, incident handling, business continuity, supply chain security, and access control. Unlike a flat perimeter model, defence-in-depth creates friction for attackers at every stage of the kill chain, from initial compromise to lateral movement and data exfiltration.

Key Layers in a Modern Architecture

A robust European enterprise architecture typically includes at least six layers: physical security (data centre access controls), network segmentation (VLANs, micro-segmentation, Zero Trust network access), endpoint protection (EDR, application control), identity and access management (MFA, privileged access management), data protection (encryption at rest and in transit, DLP), and monitoring/logging (SIEM, SOC, threat intelligence). The review must validate that each layer is both correctly configured and actually integrated with adjacent layers.

Why a Security Architecture Review Is Critical Under NIS2 and DORA

European regulators increasingly expect evidence of systematic architecture assurance, not ad hoc patch management. NIS2 Article 21 demands that essential and important entities implement measures that are "appropriate and proportionate" to the risk—this implies a documented architecture baseline and periodic review cycle. DORA goes further for financial entities, requiring regular threat-led penetration testing (TLPT) and a clear mapping of ICT assets, dependencies, and controls under Articles 24-26. Without a security architecture review, organisations cannot produce the evidence required by competent authorities during an audit or incident investigation.

Links to GDPR Data Protection by Design

GDPR Article 25 mandates data protection by design and by default. A security architecture review operationalises this principle by verifying that pseudonymisation, encryption, access controls, and logging are architected into systems—not bolted on after deployment. The review should explicitly map controls to the data flows in your processing register, identifying gaps where personal data could be exposed due to architectural weaknesses.

The CyberSilo Framework for Conducting an Architecture Review

We recommend a four-phase approach aligned with NIS2 risk management requirements: scoping and discovery, control mapping and gap analysis, remediation prioritisation, and continuous verification. Each phase produces specific deliverables that satisfy regulatory record-keeping obligations.

Key Architectural Controls to Evaluate for European Enterprises

Based on our work with regulated European organisations, the following controls consistently appear as weak points in architecture reviews. Prioritise these during your assessment.

Network Segmentation and Zero Trust

Flat networks still dominate in many legacy European enterprises, especially in manufacturing, logistics, and healthcare. Verify that segmentation enforces least-privilege communication between zones—not just VLANs with no access control lists. For OT/ICS environments, the Purdue model should be implemented with strict unidirectional gateways between Levels 3 and 4. NIS2 Article 21(2)(d) specifically requires “security in network and information systems” which includes segmentation as a core measure.

Identity and Access Management (IAM)

IAM is the most critical single control layer. Review whether MFA is enforced for all administrative and remote access, whether privileged access management (PAM) covers service accounts and break-glass accounts, and whether identity governance reviews (certifications) occur at least quarterly under SOX or internal policy. DORA Article 9 requires strong authentication for ICT staff accessing operational systems—architecture reviews must validate this at design level, not just policy level.

Detection and Response Capabilities

Your detection architecture must correlate across endpoints, network, cloud, and identity sources without silos. Evaluate whether your SIEM ingestion covers all critical log sources, whether detection rules are tested against frameworks like MITRE ATT&CK, and whether the SOC has documented runbooks for common attack patterns. For organisations using ThreatHawk SIEM, we recommend validating that correlation rules map to NIS2 Annex II incident categories for accurate reporting.

How to Ensure Ongoing Architecture Compliance

Architecture reviews are not a point-in-time box-ticking exercise. European regulators increasingly expect a continuous improvement cycle. We recommend three operational practices to maintain architectural integrity between formal reviews.

Integrate Architecture Changes into Change Management

Every network change, cloud deployment, or major application update should trigger a pre-defined security architecture impact assessment. This does not mean a full review each time, but a lightweight checklist—does this change add a new egress path? Does it expose a new attack surface? Does it require a new log source for the SIEM? This practice satisfies NIS2 Article 21's requirement for security in system acquisition and development.

Automate Control Verification Where Possible

Manual architecture validation does not scale. Use infrastructure-as-code scanning tools (e.g., Terrascan, Checkov for cloud), continuous compliance monitoring (CIS benchmarks, custom policies), and automated network mapping solutions. For SIEM-centric detection chains, automate the testing of detection coverage using platforms like Atomic Red Team or Caldera. Our Compliance Standards Automation tool can continuously map your control posture to NIS2, ISO 27001, and DORA frameworks.

Align with Threat Intelligence by Sector

Architecture controls degrade in relevance as the threat landscape shifts. Subscribe to ENISA's threat landscape reports, your sector-specific ISAC (financial, energy, healthcare), and feed this intelligence into your architecture review scope. For example, if ransomware groups are increasingly exploiting managed file transfer appliances, your review should specifically evaluate segmentation and monitoring of those assets. Threat intelligence services can provide curated feeds tailored to European sectors and regulatory priorities.

Common Pitfalls in European Architecture Reviews

We see these mistakes repeatedly across European enterprises, particularly those new to structured architecture assurance:

• Treating the review as a documentation exercise: A document that describes the desired architecture is not the same as evidence that the architecture actually exists. Require live verification: config dumps, network scans, SIEM coverage reports.
• Ignoring supply chain and third-party architecture: NIS2 Article 22 mandates supply chain security measures. Your architecture review must extend to the interfaces, data flows, and access rights of third-party providers—not just your own perimeter.
• Over-reliance on a single control layer: A robust SIEM is useless if network logs are incomplete. Endpoint protection is worthless if attackers can move laterally using compromised credentials. Defence-in-depth means every layer is independently strong and mutually reinforcing.
• Forgotten the people and process layers: Architecture is not just about technology. Review whether the SOC has shift coverage, whether on-call escalation works, whether runbooks are current, and whether staff have completed security awareness training relevant to their role (required under NIS2 Article 21(2)(g)).