Enterprise Security Architecture Repository Structure

⏱ 6 min read

In mature organizations, security architecture is not a slide deck. It is not a SharePoint folder. It is not a collection of policies in PDF form. It is a structured, governed, traceable repository. Without a proper repository structure, controls become inconsistent, risks are disconnected from architecture, audit becomes painful, transformation creates chaos, and cloud and API adoption multiply complexity. enterprise cloud architecture patterns

High-level repository structure

Figure 1: Enterprise Security Architecture Repository — ten major sections from Governance through Assurance
Figure 1: Enterprise Security Architecture Repository — ten major sections from Governance through Assurance

The repository organizes security architecture into ten interconnected sections: Governance (principles, policies, regulatory mappings, strategy, ADRs), Risk Model (threats, vulnerabilities, risk assessments), Control Framework (controls mapped to policies and risks), Security Capabilities (what the organization must be able to do), Reference Architectures (reusable patterns), Solution Architectures (project-specific designs), Standards and Patterns (approved implementation approaches), Technology Catalog (approved security tools), Traceability Model (connecting all elements), and Assurance and Audit (evidence and compliance reporting). EA governance checklist

Governance structure

Figure 2: Governance section — Principles, Policies, Regulatory Mappings, Strategy, and ADRs
Figure 2: Governance section — Principles, Policies, Regulatory Mappings, Strategy, and ADRs

Governance defines what must be true enterprise-wide. Security Principles are strategic commitments ("least privilege by default," "encrypt everything in transit"). Policies translate principles into enforceable rules. Regulatory Mappings connect policies to external requirements (GDPR, NIS2, DORA, PCI-DSS, ISO 27001). Security Strategy defines the multi-year direction. Architecture Decision Records document significant security decisions with rationale and alternatives considered. ArchiMate modeling standards

Risk meta-model

Figure 3: Risk meta-model — Asset to Threat to Vulnerability to Risk to Control to Residual Risk chain
Figure 3: Risk meta-model — Asset to Threat to Vulnerability to Risk to Control to Residual Risk chain

The risk meta-model connects assets (what we protect) to threats (what can go wrong), vulnerabilities (weaknesses that threats exploit), risks (the combination of threat, vulnerability, and impact), controls (what we do to mitigate), and residual risk (what remains after controls). Every element in this chain must be modeled as a first-class architecture element in the repository — not as text in a spreadsheet. When modeled properly, a change to any element propagates through the chain: if a new vulnerability is discovered in a technology asset, the repository reveals which risks increase and which controls need strengthening.

Control trace model

Figure 4: Control trace model — from Policy and Risk through Control, Standard, Capability, to Technology
Figure 4: Control trace model — from Policy and Risk through Control, Standard, Capability, to Technology

Controls form the backbone of security enforcement. Each control traces upward to the policies and risks it addresses and downward to the standards, capabilities, and technologies that implement it. This bi-directional traceability is essential for two use cases: top-down (given a regulation, what controls implement it and what technologies enforce those controls?) and bottom-up (given a technology vulnerability, what controls are affected and what policies are at risk?).

Security capability hierarchy

Figure 5: Security capabilities — Identity and Access, Data Security, Network Security, Application Security, Cloud Security, Security Operations
Figure 5: Security capabilities — Identity and Access, Data Security, Network Security, Application Security, Cloud Security, Security Operations

Capabilities describe what the organization must be able to do, independent of how it does it. Identity and Access Management encompasses authentication, authorization, directory services, and privilege management. Data Security covers encryption, tokenization, data classification, and DLP. Network Security includes segmentation, firewalling, intrusion detection, and DDoS protection. Application Security covers SAST, DAST, dependency scanning, and API security. Cloud Security addresses CSPM, workload protection, and cloud IAM. Security Operations encompasses SIEM, SOAR, incident response, and threat intelligence. Each capability is assessed for maturity and investment priority. hybrid cloud architecture

Solution relationship model

Figure 6: Solution relationships — Project to Solution Architecture to Reference Architecture to Control Implementation to Evidence
Figure 6: Solution relationships — Project to Solution Architecture to Reference Architecture to Control Implementation to Evidence

Every project produces a solution architecture that must inherit from approved reference architectures and implement required controls. Control implementations produce evidence (configuration artifacts, test results, monitoring data) that feeds the assurance process. This chain ensures that projects do not invent security from scratch — they adopt patterns, implement controls, and produce audit evidence as a natural consequence of following the architecture.

Full traceability chain

Figure 7: Complete traceability — Regulation to Policy to Control to Capability to Technology to System to Evidence to Audit Report
Figure 7: Complete traceability — Regulation to Policy to Control to Capability to Technology to System to Evidence to Audit Report

The full trace chain connects external regulations through internal policies, controls, capabilities, and technologies to specific systems and their operational evidence, culminating in audit reports. This is the single most valuable structure in the repository. When a regulator asks "how do you comply with DORA Article 6?", the answer traces from the regulation through the policy it informs, the controls that implement the policy, the capabilities that deliver the controls, the technologies that enable the capabilities, the systems that run the technologies, and the evidence that proves it all works. This trace takes minutes with a well-structured repository and weeks without one.

Meta-model layering and governance workflow

Figure 8: Meta-model layers — Conceptual (principles/policies), Logical (controls/standards), Physical (technologies/systems), Evidence (audit/monitoring)
Figure 8: Meta-model layers — Conceptual (principles/policies), Logical (controls/standards), Physical (technologies/systems), Evidence (audit/monitoring)

The repository is organized in four meta-model layers. The Conceptual layer contains principles and policies — what must be true. The Logical layer contains controls and standards — how requirements are structured. The Physical layer contains technologies and systems — what actually runs. The Evidence layer contains audit artifacts and monitoring data — proof that everything works. Each layer has different governance cadence: conceptual elements change annually, logical elements change quarterly, physical elements change with deployments, and evidence is generated continuously. Sparx EA governance best practices

Figure 9: Governance workflow — Draft, Review, Approve, Publish, Monitor, Update lifecycle
Figure 9: Governance workflow — Draft, Review, Approve, Publish, Monitor, Update lifecycle

Repository content follows a governed lifecycle: Draft (author creates or modifies content), Review (peers and stakeholders validate), Approve (governance board confirms), Publish (content becomes authoritative), Monitor (operational data validates effectiveness), Update (cycle repeats when conditions change). This workflow applies to every repository artifact — from high-level security principles to individual control implementations. Without this lifecycle, the repository degrades from a governed knowledge base into a documentation graveyard.

Frequently Asked Questions

What is enterprise architecture?

Enterprise architecture is a discipline that aligns an organisation's strategy, business operations, information systems, and technology infrastructure. It provides a structured framework for understanding how an enterprise works today, where it needs to go, and how to manage the transition.

How is ArchiMate used in enterprise architecture practice?

ArchiMate is used as the standard modeling language in enterprise architecture practice. It enables architects to create consistent, layered models covering business capabilities, application services, data flows, and technology infrastructure — all traceable from strategic goals to implementation.

What tools are used for enterprise architecture modeling?

Common enterprise architecture modeling tools include Sparx Enterprise Architect (Sparx EA), Archi, BiZZdesign Enterprise Studio, LeanIX, and Orbus iServer. Sparx EA is widely used for its ArchiMate, UML, BPMN and SysML support combined with powerful automation and scripting capabilities.