What Is Security Architecture? How to Design a Resilient Cyber Framework

Security architecture is the structured discipline of designing security controls, policies, and technology so that every decision traces back to a documented business requirement, rather than accumulating tools and controls independently of any shared business justification.

Cyber security architecture specifically applies this discipline to digital systems and networks, but the underlying logic stays the same regardless of scope: architecture exists to prevent exactly the failure mode most businesses fall into, a security stack assembled tool by tool, vendor by vendor, with no single person able to explain why each piece exists or what business outcome it actually protects.

Why security architecture needs to start with business goals, not tools

Security architecture built correctly starts with business requirements, what the organization actually needs to protect and why, before any technology gets selected, since a technology chosen first inevitably gets justified backward rather than genuinely matched to real risk.

SABSA, Sherwood Applied Business Security Architecture, developed by John Sherwood, Andrew Clark, and David Lynas, embodies this principle directly through its core philosophy: security functions as an enabler of business opportunity, not merely a set of restrictions imposed on operations. This reframing matters practically, not just philosophically, since a security team positioned as an enabler gets invited into business planning conversations early, while one positioned purely as a restriction gets consulted only after decisions are already made, precisely when it’s too late to architect protection in rather than bolt it on afterward.

The SABSA six-layer matrix, explained

The SABSA six-layer matrix structures every security decision across six layers, Contextual, Conceptual, Logical, Physical, Component, and Operational, with each layer answering the same six questions, what, why, how, who, where, and when, from a progressively more technical stakeholder perspective.

Layer	Stakeholder View	Core Question Focus
Contextual	Business owner	What needs protecting, and why
Conceptual	Strategic architect	Which principles guide decisions
Logical	Security architect	What services deliver the strategy
Physical	Designer/builder	What specific mechanisms implement services
Component	Engineer	What exact products and standards
Operational	Operations/facilities	How it runs day to day

The intersection of six layers and six questions creates a 36-cell matrix, giving architects a systematic way to trace every security decision down from business context to specific technical component, and back up again when justifying any single control’s existence. This structure directly borrows from the Zachman Framework’s approach to enterprise architecture, applying the same layered, stakeholder-specific logic specifically to the security domain.

Business Attributes Profile: translating boardroom language into controls

The Business Attributes Profile is SABSA’s starting technique, identifying and prioritizing the specific properties, availability, confidentiality, integrity, that the business genuinely needs a system to deliver, rather than starting the architecture process from a list of known threats.

This inversion matters significantly for how security conversations actually happen. Rather than opening with “here are the threats we’re worried about,” a Business Attributes Profile opens with “here’s what the business needs this system to reliably provide,” giving security teams, IT, and senior leadership a shared vocabulary none of them previously had. A Chief Risk Officer doesn’t need to understand firewall rule syntax to engage meaningfully with an attribute like “customer transaction data must remain confidential during the entire settlement window,” and that shared language is precisely what closes the communication gap most security architecture efforts never manage to bridge.

Bidirectional traceability: connecting every control back to a business objective

Bidirectional traceability means every technical control can be traced upward to the specific business requirement that justifies it, and every business requirement can be traced downward to the specific controls implementing it, closing the gap where technical teams and business leadership speak entirely different languages about the same system.

In practice, this means an engineer should be able to trace every line of infrastructure-as-code back to a specific asset, control, and business justification across an entire hybrid, multi-cloud environment, not just at initial design but continuously as the environment evolves. This bidirectional property is what separates SABSA from a one-time compliance exercise: a control that no longer traces back to any current business requirement becomes a flagged candidate for removal, and a business requirement with no corresponding control becomes an immediately visible gap, rather than either sitting undiscovered until an audit or incident forces the question.

SABSA vs TOGAF: how the two frameworks work together

SABSA vs TOGAF isn’t really a competitive comparison, the two frameworks answer genuinely different questions and were never designed to replace each other: SABSA is a domain architecture framework optimized specifically for security, while TOGAF is the broader enterprise architecture framework governing an organization’s entire technology planning process.

Enterprise architecture consultants increasingly frame this relationship as “TOGAF and SABSA,” not “TOGAF versus SABSA,” specifically because SABSA’s security-specific techniques, the Business Attributes Profile, the six-layer matrix, the Risk and Domain Models, plug directly into TOGAF’s broader Architecture Development Method rather than competing with it for the same role. A business running TOGAF for overall enterprise architecture planning genuinely benefits from adopting SABSA specifically for the security domain within that broader structure, rather than treating the choice between them as either-or.

From framework to practice: NIST, CIS, and OWASP inside a SABSA structure

SABSA’s layers provide the traceability structure; established frameworks like NIST, CIS Controls, and OWASP provide the actual technical content populating that structure, meaning SABSA doesn’t replace these frameworks, it gives them a documented business justification they otherwise lack standing alone.

NIST CSF’s six functions and OWASP’s vulnerability categories both answer valuable, well-established technical questions, but neither one inherently connects back to why a specific business decided a specific control mattered enough to implement. Slotting NIST guidance into SABSA’s Logical and Component layers, and OWASP findings into the same structure, gives a business the best of both: proven, widely adopted technical content, wrapped inside a traceability structure that survives an audit asking “why does this specific control exist” with a documented answer rather than an assumption.

Why boards struggle to see how security investment reduces risk, and how this fixes it

Boards struggle to evaluate security investment because technical metrics, patch counts, vulnerability scores, detection rates, don’t translate into the business-risk language boards actually use to make decisions, and SABSA’s Business Attributes Profile exists specifically to close that translation gap.

A security architect explaining “we improved our vulnerability scan pass rate” gives a board nothing to weigh against other capital requests. A security architect explaining “we strengthened the confidentiality attribute protecting customer settlement data, directly reducing exposure under our regulatory reporting obligations” gives the board a business-risk statement they can genuinely evaluate against alternatives. This is precisely the gap a Principal Security Architect is trained to close, sitting in a room with a Head of Trading, a Chief Risk Officer, and a VP of Engineering simultaneously, translating between their genuinely different vocabularies using Business Attributes as the shared reference point none of them had before.

How does this connect to your security posture and broader cyber security strategy?

Security architecture and what is security posture address genuinely different questions: architecture defines the structured, traceable design connecting business goals to technical controls, while posture measures your current, point-in-time readiness against that design, and cyber security strategy sits above both, setting the overall direction architecture is built to serve.

A business can have a well-documented architecture and still show a weak current posture if implementation lags behind the design, exactly the gap continuous posture monitoring is meant to surface. Strategy determines which business attributes matter most given the organization’s specific risk appetite and market position, architecture translates that strategic direction into a traceable, six-layer structure, and posture measures how well that structure is actually holding up in practice right now. All three need to work together, since strategy without architecture produces intent nobody implements consistently, and architecture without posture measurement produces a beautiful design nobody verifies against reality.

A practical starting point for building this without a dedicated enterprise architect

A practical starting point is a simplified Business Attributes Profile for your single most critical system, naming three to five specific properties the business genuinely needs it to deliver, then tracing your existing controls against those attributes to find the gaps.

This scaled-down exercise delivers real SABSA value without requiring formal certification or a dedicated architect role, the discipline of starting from business need rather than available tooling transfers cleanly to any organization size. Cyber Security Solutions Ltd helps clients build exactly this simplified, attribute-first starting structure, since businesses that begin with a documented “why” for their most critical system consistently make better security investment decisions than those working backward from whatever tools a vendor happened to pitch first.