4.5.1. Enterprise Architecture and Security Integration
💡 First Principle: Changing a design on paper costs almost nothing, while changing it after it is built costs rework, downtime and political capital — so the cheapest point to add a security requirement is when the enterprise architecture is being decided, and every later point is more expensive.
Enterprise architecture (EA) describes the organization's current state, its desired future state, and the roadmap between them, across business processes, information, applications and technology. Its value to the business is coherence: without it, each department buys systems that solve its own problem and the organization accumulates duplicated platforms, inconsistent data and integrations nobody fully understands. Its value to security is the same coherence — a single view of where sensitive data flows, which systems depend on which, and where a single failure would cascade.
Two frameworks dominate EA discussions, and they answer different questions:
| Framework | What It Is | What It's Good For |
|---|---|---|
| TOGAF (The Open Group Architecture Framework) | A method: the Architecture Development Method (ADM), an iterative cycle from architecture vision through business, information systems and technology architectures to migration planning, implementation governance and change management | Running an architecture program — producing and governing architectures over time |
| Zachman Framework | A taxonomy: a matrix that classifies architecture descriptions by interrogative (what, how, where, who, when, why) and by stakeholder perspective (from executive and business owner down to builder and operator) | Checking completeness — making sure every perspective and question has been described |
TOGAF organizes architecture into four domains — business, data, application and technology — and its ADM places requirements management at the center of the cycle, which is exactly where security requirements need to enter. Zachman is not a process; it tells you what descriptions should exist, not how to produce them. A common exam distractor treats the two as interchangeable or claims Zachman prescribes implementation steps.
For a security manager, the practical mechanisms of integration matter more than framework trivia:
- Security participates in architecture governance. An architecture review board (or equivalent) that approves significant designs should include security, so security requirements are assessed when designs are proposed rather than discovered during a pre-launch penetration test.
- The EA's target state carries security principles. Principles such as "identity is verified for every access" or "sensitive data is classified before it is stored" become constraints every project inherits, instead of arguments re-fought project by project.
- Architecture records support risk decisions. Data-flow and dependency views from the EA tell the risk assessment (3.1.3) which assets are critical and where a compromise would spread, and they make the asset inventory (4.1.2) more complete.
- Deviations are governed, not ignored. A project that cannot follow an architecture standard goes through the exception process with a risk owner's sign-off, the same as a policy exception.
Technical debt is the architecture version of an unpatched vulnerability. Legacy platforms that no longer fit the target state still carry business processes, and the security manager's job is to make that residual risk visible to the decision-makers who own it, not to quietly absorb it. The EA roadmap is the right place to plan the retirement or isolation of systems that can't meet current security principles.
⚠️ Exam Trap: When a scenario describes a security weakness discovered late in a project — just before go-live — the tempting answer is a technical fix or a delay negotiated on the spot. The better answer often addresses the root cause: security was not involved in architecture review early enough. ISACA rewards fixing the process that let the gap through, after the immediate risk has been reported to the decision-maker.
Reflection Question: Two business units have each bought a customer database, and neither is in the enterprise architecture. One holds payment data. What does the absence of an enterprise view cost the security program, before any breach occurs?
