Integrating risk and security into architecture

When security review arrives after the target architecture is mostly fixed, the conversation becomes narrow. Teams argue about controls, compensating actions, and exceptions because the structural decisions are already hard to reverse. Changing a trust boundary after services have been designed around it is expensive. Redesigning dependency chains after platforms have been selected is even more so.

The ADM's value here is to pull that thinking earlier. If the architecture is still forming, security and risk concerns can influence trust boundaries, dependency design, recovery posture, and choice of technology patterns before delivery cost makes those choices sticky.

The goal is not to make every architect a security specialist. The goal is to make sure the decisions that security cares about most are visible and open to challenge while the architecture is still being formed. That means identifying which decisions are security-relevant, involving security expertise at those specific points, and recording the structural reasoning alongside the architecture decisions it shaped.

Consider the cost difference. Changing a trust boundary during Phase D is a modelling exercise. Changing the same trust boundary after three delivery teams have built services across it is a multi-sprint rework programme. The same structural change costs ten to fifty times more when it arrives late. That is not a security argument. It is an economics argument.

G152, "Integrating Risk and Security within a TOGAF Enterprise Architecture," is the primary TOGAF Series Guide for this topic. It provides a structured approach to making risk and security part of the architecture process rather than an afterthought. Two things matter here: the guide's core principle, and a working set of risk categories to apply with it.

Core principle: security as an architecture concern, not a review gate

G152 positions security as a concern that should be addressed within each ADM phase, not as a separate review that happens after the architecture is complete. Security concerns should be captured alongside other stakeholder concerns in Phase A, addressed structurally in Phases B through D, and governed in Phase G.

Six risk categories for architecture work

G152 keeps the scope of risk deliberately broad: it describes enterprise risk management as covering business, system, information, project, privacy, compliance, and organisational change risk, among other categories. To make that scope workable, this course uses six categories that recur in architecture decisions. Each affects those decisions in different ways.

Strategic risk.Risks that affect the enterprise's ability to achieve its strategic objectives. A technology architecture that locks the enterprise into a single vendor for a critical capability creates strategic risk because the vendor's direction may diverge from the enterprise's needs. In London, strategic risk includes the possibility that the chosen OT platform vendor exits the UK market, leaving the enterprise dependent on a platform with declining support.

Operational risk. Risks arising from failures in processes, people, or systems. A shared identity provider serving both OT and IT creates operational risk because a failure in the identity service cascades across both domains. In London, operational risk includes the telecom dependency that connects SCADA telemetry, smart-meter collection, and fault reporting to a single carrier.

Technical risk. Risks arising from technology choices, complexity, or maturity. An architecture that depends on unproven technology without proven operational track record introduces technical risk. In London, technical risk includes the maturity of any proposed integration platform for combining OT and IT data streams.

Compliance and regulatory risk. Risks arising from failure to meet legal, regulatory, or contractual obligations. A technology architecture that cannot support timely LTDS publication creates regulatory risk. In London, compliance risk includes the NCSC Cyber Assessment Framework obligations for operators of essential services.

Information and data risk. Risks to the confidentiality, integrity, and availability of enterprise data. A data pipeline without audit trail creates information risk because the enterprise cannot prove that published data is accurate. In London, information risk includes the integrity of the data path from distribution management to LTDS publication.

Concentration and dependency risk. Risks arising from shared dependencies that could cause correlated failures across multiple business outcomes. This is often the most important category for enterprise architects because it is invisible to specialist teams working within a single domain. In London, concentration risk is the central theme: the single telecom carrier, the shared identity provider, and the common data pipeline all create dependencies that cross domain boundaries.

SABSAstands for Sherwood Applied Business Security Architecture. It is a layered framework for designing security architecture that starts from business requirements rather than from technical controls. The detailed integration of SABSA with TOGAF is documented in the joint Open Group and SABSA Institute white paper "TOGAF and SABSA Integration" (W117). G152 was prepared in collaboration with The SABSA Institute and includes excerpts from that white paper, but the layer-by-layer mapping below comes from W117.

The key insight from the white paper is that SABSA and TOGAF share a common structure. Both use layered models that move from business context to logical design to physical implementation. The integration works because both frameworks ask similar questions at each layer, but SABSA applies them specifically to security.

SABSA layers mapped to TOGAF

1. Contextual layer (business view).What does the business need from security? This maps to TOGAF's business architecture and Phase A stakeholder analysis. In London, the contextual layer asks: what level of resilience does a distribution network operator need? What are the consequences of a security failure in terms of public safety, regulatory penalty, and reputation?
2. Conceptual layer (architect's view).What security principles, policies, and risk appetite should guide design decisions? This maps to TOGAF's architecture principles and the Preliminary Phase. In London, the conceptual layer says: OT must recover independently of IT; trust boundaries between operational and enterprise domains must be explicit and enforced.
3. Logical layer (designer's view). What security services, trust zones, and access models does the architecture need? This maps to the logical models in Phases B, C, and D. In London, the logical layer defines the trust zones: OT control, OT data, enterprise IT, publication, and external regulatory interfaces.
4. Physical layer (builder's view). What specific products, configurations, and implementations will deliver the logical security services? This maps to the technology-specific content of Phase D and the Solution Building Blocks that follow. In London, the physical layer names the firewalls, identity services, network segmentation tools, and monitoring platforms.
5. Component layer (tradesman's view). How are the physical security elements configured, deployed, and maintained? This maps to implementation detail in Phase G.
6. Operational management layer. How is the security architecture operated, monitored, and improved over time? This maps to Phase H and ongoing governance.

The practical value of the SABSA integration is that it gives security architects a structured way to contribute to each TOGAF phase rather than producing a parallel security architecture that nobody connects to the enterprise design.

Not every architecture decision is security-sensitive. But four categories of decision almost always are, and they should be flagged for security input early. The practical rule this course applies: identify these decisions and make sure security expertise is in the room when they are being formed.

Boundary design. Which trust boundaries exist, where should they be explicit, and which interactions should be more tightly controlled or separated? A trust boundary that is assumed but never drawn is a security gap hiding in plain sight. In London, the OT/IT boundary, the telecom/enterprise-IT boundary, and the publication/governance boundary are all security-relevant. Each should be drawn, labelled, and the enforcement mechanism stated.

Dependency design. Which shared dependencies could create concentrated failure or compromise risk across several business outcomes? If three critical services share the same identity provider, the failure of that provider becomes an enterprise event, not a local one. In London, the single telecom carrier dependency is the most dangerous concentration risk because it affects SCADA telemetry, smart-meter collection, fault reporting, and LTDS publication simultaneously.

Recovery design. Which services need recovery-first thinking and what evidence must exist before those designs are accepted as resilient enough? Recovery is not just about backups. It is about how quickly the enterprise can restore service after a compromise, failure, or cascading disruption. In London, recovery design must specify the order in which services are restored after a telecom outage: control-room visibility first, then fault reporting, then publication.

Governance design. Which choices need Architecture Board visibility because local compromise could weaken enterprise resilience later? A team that quietly relaxes a trust boundary to meet a delivery deadline creates risk that the rest of the enterprise cannot see. The governance design should specify which boundary and dependency decisions require enterprise-level approval and which can be made locally.

Controls are necessary, but they are not the starting point. The starting point is structural: boundaries, dependencies, trust, and recovery. Controls then reinforce the structural decisions. G152's business-driven approach points the same way: business drivers set the context for risk assessment, and control frameworks follow from that context.

Risk appetite should influence which patterns are acceptable, not just how issues are logged after the fact. If the enterprise has low appetite for extended outage inoperational technology, the architecture should reflect that through separation, independent recovery paths, and explicit failover design rather than through a risk register entry that says "mitigate."

Governance should record where enterprise trade-offs were made consciously rather than by accident. When a trust boundary is relaxed to reduce integration cost, the Architecture Board should know, and the rationale should be recorded. When risk appetite is accepted rather than mitigated, the decision should be explicit, time-bounded, and reviewed at the next architecture cycle.

The distinction between acceptable risk and unacknowledged risk is critical. An enterprise that accepts a concentration risk because the mitigation cost exceeds the expected loss is making an informed decision. An enterprise that has a concentration risk because nobody looked for it has an unacknowledged exposure. The architecture should make the difference visible.

A common failure is to treat security as an expert lane that runs beside architecture rather than through it. That keeps local specialists busy, but it prevents the enterprise from seeing the dependency picture that matters most.

The symptoms are recognisable. The security team produces its own set of diagrams that do not align with the architecture views. Risk registers exist in separate systems with no traceability to architecture decisions. Controls are mapped to compliance frameworks but not to the boundaries and dependencies they are supposed to protect.

The result is that the enterprise has two parallel stories about the same estate: one told by the architecture team in capability and service language, and one told by the security team in threat and control language. Neither story is wrong, but neither is complete, and nobody has combined them into a single defensible view.

Two publications address this failure mode from two directions. G152 says: integrate security and risk concerns into each ADM phase. The TOGAF and SABSA Integration white paper adds: use SABSA's layered model to ensure security architects contribute at each level of the architecture, not just at the control level. Both push the same direction: security should be part of the architecture, not parallel to it.

G152 gives TOGAF practitioners the vocabulary for risk and security integration, and the W117 white paper carries the detailed SABSA alignment framework. The question practitioners face is when the additional SABSA layer is worth the effort and when G152 alone is sufficient.

TOGAF alone (G152 only) is sufficient when:

• The enterprise has a small security team or no dedicated security architects, and the architecture team can integrate risk categories directly into ADM phases.
• Security requirements are well understood, stable, and covered by established control frameworks (ISO 27001, NIST CSF) that the enterprise already operates.
• The architecture engagement is time-bounded and the additional layered analysis would delay delivery without proportionate security benefit.

The SABSA integration (W117) adds value when:

• The enterprise operates critical infrastructure, financial services, or other domains where security failures have public-safety or systemic consequences.
• A dedicated security architecture function exists and needs a structured way to contribute at every ADM phase rather than producing a parallel security document.
• The architecture involves complex trust boundaries across multiple domains (OT, IT, telecom, cloud) where business-driven security reasoning is needed at every layer, not just at the control level.
• Regulatory or contractual obligations require traceable security architecture from business requirements through to operational management.

What SABSA adds that TOGAF alone does not

TOGAF treats security as one of many concerns that flow through the ADM. SABSA treats security as a first-class architecture discipline with its own six-layer model. The practical difference is depth: SABSA forces security architects to answer business-level questions ("what does the enterprise need from security?") before moving to technical ones ("which firewall rules?"). That business-first discipline is what prevents security architecture from collapsing into a controls catalogue.

The six SABSA layers (contextual, conceptual, logical, physical, component, operational) provide a traceability chain that risk-category analysis alone does not. When regulators or auditors ask "how does your security architecture trace from business objectives to operational controls?", the SABSA layers provide a structured answer.

London Grid Distribution is a strong candidate for SABSA alongside TOGAF because it operates critical national infrastructure with complex trust boundaries across OT, IT, and telecom domains.

SABSA contextual layer. A London SABSA analysis would start by asking: what does a distribution network operator need to protect, and what are the consequences of failure? The answers involve public safety (loss of supply), regulatory penalty (Ofgem enforcement), data integrity (LTDS publication accuracy), and operational continuity (SCADA and DMS availability). These business-level security requirements would then cascade through every subsequent layer.

SABSA logical layer. The trust zones in London (OT control, OT data, enterprise IT, publication, external regulatory) would be formally defined as SABSA logical security domains with explicit trust relationships, access policies, and information-flow rules between each zone.

Traceability benefit. When the NCSC Cyber Assessment Framework assessors ask London to demonstrate that security architecture traces from business objectives to operational controls, the combined TOGAF and SABSA structure provides a clear answer at each layer. Without SABSA, that traceability depends on the architecture team maintaining it informally, which is less reliable under audit pressure.

The London case is built precisely to prevent cyber from being treated as an IT side topic. OT platforms, field and smart-meter communications, enterprise IT, publication flows, and governance evidence all interact. That means security and risk have to be architectural from the start.

The OT/IT boundary. This is the most security-sensitive boundary in the London architecture. SCADA, distribution management, and protection relay systems sit on the OT side. Enterprise workflow, analytics, and publication sit on the IT side. The boundary must be explicit, enforced, and governed. A failure to maintain this boundary does not just create a security incident. It creates a potential public-safety event.

The telecom dependency. Field communications carry SCADA telemetry, smart-meter data, and fault-reporting signals. If the telecom carrier fails, all three data streams degrade simultaneously. The architecture must make this concentration risk visible and either accept it with governance approval or mitigate it through carrier diversification or local fallback.

The publication pipeline. LTDS publication depends on data from analytical systems, which depend on telemetry from OT, which depends on telecom. A security compromise at any point in that chain could produce inaccurate published data. The architecture must include integrity verification at each boundary.

• Security in London is inseparable from architecture boundary decisions. The OT/IT boundary, the telecom/enterprise-IT boundary, and the publication/governance boundary are all security-relevant.
• A good Stage 5 security view must span OT, IT, telecom, exchange, and governance without collapsing them into a single control framework.
• The NCSC Cyber Assessment Framework and the enterprise's own resilience principles both feed into the structural security reasoning that Phase D must make explicit.
• The concentration and dependency risk category is the most important one for London because the most dangerous risks sit in the dependencies between domains, not within any single domain.