A Practical Approach to Enterprise Security Architecture (ESA)

Enterprise Security Architecture (ESA) extends traditional Enterprise Architecture (EA) by adding explicit, risk-driven perspectives that EA historically lacked. Security must address risks, threats, and vulnerabilities without obstructing business objectives, and it operates under a “weakest link” dynamic: defenders must protect many interdependent components while attackers may succeed by compromising only one or a few. As a result, ESA must exist in parallel with EA across all architecture layers and integrate with governance, risk management, and audit needs rather than functioning as disconnected technical diagrams.

Industry alignment between EA and ESA is relatively new, and most enterprises still lack a unified ESA, instead maintaining fragmented artifacts that describe isolated protections. ESA provides a unifying, multi-layer framework—contextual, conceptual, logical, and physical/component/solution—that can incorporate existing materials (e.g., board-level security presentations, CIO/CTO logical models, network diagrams), rationalize overlaps, replace gaps, and align security decisions with business priorities.

The Open Group’s TOGAF community has chosen to improve EA–security alignment by referencing established ESA work rather than rebuilding security discipline inside TOGAF, notably leveraging SABSA. ESA can be lightweight for smaller organizations and expand for complex environments. It should align with existing EA practices, control frameworks, and risk programs to optimize security investments, reduce cost and complexity, and maximize control effectiveness—while avoiding excessive additional processes beyond those already required for audit, compliance, and EA.

Two practical adoption paths emerge: use NIST Cybersecurity Framework (CSF) for control prioritization and roadmapping, or adopt/distill SABSA concepts to build a more comprehensive, business-driven, risk-aligned ESA integrated with TOGAF processes.

• Security architecture must address risks, threats, and vulnerabilities without impeding the business it protects.
• Attackers may only need to compromise one or a few components, while defenders must protect many systems and components.
• EA disciplines were originally written without incorporating security or risk management drill-down.
• The Open Group has chosen to reference existing ESA works such as SABSA rather than developing extensive new security disciplines within TOGAF.
• EA and ESA alignment is a relatively new concept in the industry.
• Most enterprises do not have a complete ESA and instead have partial security architecture artifacts.
• ESA and EA modeling frameworks use contextual, conceptual, logical, and physical/component/solution layers.
• NIST CSF is divided into Core, Profile, and Tiers.
• NIST CSF defines five functions: Identify, Protect, Detect, Respond, and Recover.
• NIST CSF includes 22 categories and 98 subcategories, with subcategories mapping to NIST 800-53 or COBIT controls.

• “Security is also a weakest link problem; the defender must protect many different systems and components whereas the attacker need only compromise one – or a few – to break in.”
• “Therefore, security architecture must exist in parallel with all elements of EA.”
• “Rather than reinventing the wheel by developing extensive security disciplines within TOGAF, the Open Group has chosen to reference existing ESA works, such as the Sherwood Applied Business Security Architecture (SABSA).”
• “Fortunately, much of the typical customer’s prior work on security architecture can be reused.”
• “Through its unifying framework and its connection to EA, ESA can coexist with them; incorporating some, rationalizing others, perhaps replacing a few, and unifying all.”
• “An ESA spans organizational, conceptual, logical, and physical IT layers.”
• “It enables security services and components to achieve and maintain a state of managed risk throughout an enterprise.”
• “The ESA must not impose too many incremental processes or assessments on top of these already required for internal/external audits, compliance, and EA.”
• “No one reference architecture or similar framework provides the best tradeoff on breadth/depth of coverage, or the best fit for all types of customers.”
• “Using ESA, customers can better align IT, security, and risk processes and architecture.”