Applying TOGAF for security architecture design

Why TOGAF is useful for security architecture

TOGAF is an enterprise architecture method, not a security framework. That distinction matters. If you try to use TOGAF as if it were a control catalogue, you will end up with a lot of diagrams and not much practical security. Used well, though, TOGAF gives security teams a structured way to influence design decisions early, keep architecture aligned to business goals, and make trade-offs visible.

For UK SMEs, that structure is often the missing piece. Security decisions are frequently made in response to a project deadline, a supplier requirement, or a recent incident. TOGAF helps move those decisions into a repeatable architecture process. It gives you a common language for business stakeholders, solution architects, infrastructure teams, and security practitioners.

Where TOGAF fits alongside security architecture practice

Security architecture is about designing systems so they are resilient to attack and operational failure. TOGAF supports that by providing the Architecture Development Method, usually called the ADM, which is the step-by-step process for developing architecture. Security can be embedded into each phase rather than bolted on at the end.

In practice, TOGAF works best when paired with other security methods. Threat modelling, for example, helps identify what can go wrong. Zero Trust principles help shape trust boundaries and access decisions. Defence in depth helps ensure that one failed control does not expose the whole environment. TOGAF then provides the governance and structure to make those ideas part of the design process.

What TOGAF does and does not give you for security design

TOGAF will help you define architecture principles, capture requirements, document target states, and manage change across domains. It will not tell you which specific security control to deploy in every case. That is where your risk assessment, threat model, and technical standards come in.

Think of TOGAF as the operating model for architecture decisions. It helps answer questions such as:

• What security outcomes does the business need?
• Which architecture decisions reduce risk most effectively?
• Who approves exceptions?
• How do we keep security requirements consistent across projects?

If you keep that boundary clear, TOGAF becomes useful rather than bureaucratic.

Start with business drivers and architecture principles

Security architecture should start with business context, not with tools. A UK SME may be trying to protect customer data, support remote working, meet supplier assurance requirements, or reduce the impact of ransomware. Those drivers should shape the architecture from the outset.

Translating business goals into security requirements

In TOGAF terms, business drivers feed architecture vision and requirements. For security, that means translating business objectives into measurable security outcomes. For example:

• Protect customer records from unauthorised access
• Ensure critical services remain available during a denial-of-service event
• Detect suspicious identity activity quickly enough to contain it
• Recover essential systems within a defined recovery time objective

These are more useful than generic statements such as “improve security”. They can be traced into architecture decisions, control selection, and operational monitoring.

A practical technique is to write security requirements in the same language as the business. If a service outage would stop orders being processed, then availability becomes a business requirement, not just a technical preference. If a supplier integration handles personal data, then encryption, logging, and access control become design constraints.

Defining security principles that architects can actually use

Architecture principles are one of the most valuable TOGAF outputs for security. They provide stable decision rules that teams can apply across projects. Good security principles are short, testable, and specific enough to guide design.

Examples include:

• All access must be explicitly authorised and logged
• External input is untrusted until validated
• Administrative access must be separated from standard user access
• Critical services must have a defined recovery path
• Security exceptions must be time-bound and approved

These principles are not controls in themselves. They are design rules. They help architects avoid inconsistent decisions, especially in organisations where multiple teams build or buy systems independently.

Map security concerns into the TOGAF ADM

The ADM is where TOGAF becomes operational. Security should appear in every phase, but the depth of involvement changes depending on the maturity of the organisation and the risk profile of the system.

Security inputs for the Preliminary and Architecture Vision phases

The Preliminary Phase is where you establish architecture capability, governance, and principles. For security, this is where you define the minimum architecture standards that all projects must follow. That may include identity standards, logging requirements, approved cryptographic patterns, and rules for exception handling.

The Architecture Vision phase is where you define the scope and value proposition of the change. Security should be part of the vision statement, especially if the new system changes trust boundaries, processes sensitive data, or introduces third-party dependencies. At this stage, you do not need a full control design, but you do need to identify the major security risks and assumptions.

Useful artefacts in these early phases include:

• Security architecture principles
• High-level risk statements
• Trust boundary sketch
• Initial non-functional requirements for confidentiality, integrity, availability, and recoverability

Embedding security in Business, Data, Application, and Technology Architecture

TOGAF separates architecture into domains. Security should be visible in each one.

Business Architecture: define who can do what, under which conditions, and with what approvals. This is where role separation, privileged access, and business process controls should be captured.

Data Architecture: classify data, define retention and protection requirements, and specify where encryption, tokenisation, or pseudonymisation is needed. Also identify where data may cross organisational or geographic boundaries.

Application Architecture: define authentication, authorisation, session handling, input validation, API security, and secure integration patterns. This is also where you decide whether a service should use central identity, local accounts, or federated access.

Technology Architecture: define network segmentation, endpoint hardening, logging pipelines, key management, backup architecture, and platform security baselines. If you use cloud services, include tenant configuration, workload identity, and monitoring integration.

The key is traceability. A security requirement should be visible in the architecture artefacts, not hidden in a separate spreadsheet that no delivery team reads.

Use threat modelling to shape architecture decisions

Threat modelling is the bridge between abstract security principles and concrete design choices. Within TOGAF, it helps you test whether the target architecture actually reduces risk or simply redistributes it.

Applying STRIDE and data-flow diagrams within the ADM

STRIDE is a practical way to structure threat analysis: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Data-flow diagrams help you show where data moves, where trust changes, and where controls are needed.

In an ADM cycle, threat modelling is most useful during architecture definition and solution design. Start with the key business processes and map the assets, entry points, identities, and dependencies. Then ask what could go wrong at each trust boundary.

For example, if a customer portal calls an internal API, the architecture should answer:

• How is the portal authenticated?
• How does the API verify the caller?
• What happens if tokens are stolen?
• How are requests rate limited?
• How are logs correlated across tiers?

This is not about exhaustive analysis. It is about identifying the threats that materially affect the design.

Turning threats into controls, patterns, and constraints

Once threats are identified, translate them into architecture decisions. A spoofing threat may lead to mutual authentication or stronger workload identity. A tampering threat may lead to signed artefacts, integrity checks, or stricter change control. A denial-of-service threat may lead to rate limiting, autoscaling, caching, or upstream protection.

Where possible, capture the response as a reusable pattern rather than a one-off fix. For example, a standard API pattern might require:

• Central identity provider integration
• Short-lived tokens
• Input validation at the edge and in the service
• Structured logging with correlation IDs
• Explicit timeout and retry behaviour

That makes the architecture easier to reuse and easier to govern.

Design security architecture building blocks

Security architecture becomes much easier to manage when you define a small set of approved building blocks. This is especially important for SMEs with hybrid estates, SaaS-heavy environments, and limited engineering capacity.

Identity, access, segmentation, logging, and cryptographic services

Most security architectures rely on a core set of services:

• Identity: central identity provider, strong authentication, lifecycle management, and conditional access
• Access: role-based access control, privileged access workflows, and just-in-time elevation where appropriate
• Segmentation: network and workload boundaries that limit lateral movement
• Logging: centralised collection, normalisation, retention, and alerting
• Cryptography: TLS for transport, key management, and encryption at rest where needed

When these services are designed as shared architecture components, projects do not need to invent their own security model every time. That reduces inconsistency and lowers operational overhead.

Reusable patterns for cloud, hybrid, and SaaS-heavy environments

In cloud environments, security architecture often centres on identity, policy, and telemetry rather than perimeter controls. In hybrid environments, you need to connect on-premises systems, cloud workloads, and SaaS applications without creating blind spots. In SaaS-heavy estates, the main challenge is often governance of identity, data sharing, and logging rather than infrastructure hardening.

Useful patterns include:

• Single sign-on with strong multi-factor authentication
• Privileged access separated from standard user accounts
• Microsegmentation or at least tiered network zoning
• Central log forwarding into a SIEM
• Immutable or offline backup copies for recovery

Choose patterns that fit the operating model. A small team does not need maximum complexity. It needs consistency, visibility, and manageable support costs.

Define governance, standards, and decision rights

TOGAF is particularly useful for governance because it makes architecture decisions explicit. That matters in security, where exceptions can quietly become the norm if nobody owns the decision.

Architecture review checkpoints and exception handling

Security review should happen at defined checkpoints, not only at the end of delivery. A practical model is to review:

• Architecture vision and scope
• Target architecture and key risks
• Solution design before build or procurement
• Go-live readiness and operational handover

Exception handling should be formal but lightweight. If a project cannot meet a standard, record the risk, compensating controls, owner, and review date. Time-boxed exceptions are much safer than informal waivers that never get revisited.

How to keep security standards consistent across delivery teams

Consistency comes from a small number of approved standards, reference architectures, and patterns. If every team writes its own security requirements, governance becomes unmanageable. Instead, publish a short set of architecture standards covering identity, logging, encryption, segmentation, and recovery.

Where possible, make the standards easy to consume. A one-page pattern is often more effective than a long policy document. Include examples, not just rules. Delivery teams are more likely to follow guidance that shows what “good” looks like in their environment.

Align TOGAF outputs with operational security needs

A common weakness in architecture work is that it stops at design. Security architecture only adds value if the operational teams can use it.

Making sure detection, response, and recovery are designed in

Detection and response should be part of the architecture, not an afterthought. That means specifying what must be logged, where alerts should be generated, and how incidents will be investigated. It also means designing for recovery, not just prevention.

Ask practical questions during design:

• Can the SOC see the events needed to detect abuse?
• Are logs tamper-resistant and retained long enough?
• Can privileged actions be traced to individuals?
• Are backups isolated from the primary environment?
• Can the service be restored without rebuilding everything manually?

These questions help ensure the architecture supports real operations, not just compliance narratives.

Handing off architecture decisions to engineering and SOC teams

Good handover is specific. The architecture pack should tell engineering what to build, tell operations what to monitor, and tell the SOC what signals matter. Include assumptions, dependencies, and known residual risks. If a control depends on a managed service or a third-party platform, make that explicit.

For technical teams, the most useful handover artefacts are usually:

• Architecture diagrams with trust boundaries
• Security requirements and standards references
• Threat model summary
• Logging and monitoring requirements
• Recovery and exception notes

Common mistakes when using TOGAF for security

Treating security as a late-stage review activity

The biggest mistake is to let security appear only at the end of the project. By then, the major design decisions are already fixed. You can still improve the solution, but the cost of change is much higher. Security needs to be present from the vision stage through to operational handover.

Over-documenting architecture without improving control effectiveness

Another common problem is producing detailed documents that do not change behaviour. If the architecture artefacts do not influence procurement, build standards, or operational monitoring, they are not doing useful work. Keep the focus on decisions, not paperwork.

A concise architecture with clear standards is usually better than a comprehensive but unused repository of diagrams.

A practical starter approach for UK SMEs

If you are applying TOGAF for security architecture design in a smaller organisation, start with a minimum viable approach. You do not need a full enterprise architecture function to get value from the method.

Minimum viable artefacts to produce in the first iteration

Begin with five artefacts:

• Security architecture principles
• A simple architecture vision statement for the change
• A high-level data-flow or trust boundary diagram
• A short threat model using STRIDE or a similar method
• A list of required security standards and exceptions

That set is enough to improve decision-making without creating unnecessary overhead.

How to scale the approach without creating process overhead

Scale by reusing patterns, not by adding layers of approval. Create standard templates for common systems such as SaaS integrations, internal business applications, and internet-facing services. Use the same review questions each time. Keep governance proportional to risk, so low-risk changes move quickly while higher-risk designs receive deeper review.

For many UK SMEs, the goal is not to become a large enterprise architecture shop. The goal is to make security design repeatable, visible, and easier to operate.

Applied in that way, TOGAF can be a practical framework for security architecture design. It helps you connect business drivers to technical controls, keep architecture decisions consistent, and make security part of normal delivery rather than a separate activity.

If you want support turning architecture principles, threat models, and governance into a workable security design approach, speak to a consultant.

Frequently asked questions

How does TOGAF differ from SABSA when designing security architecture?

TOGAF is an enterprise architecture method that structures how architecture is developed and governed. SABSA is a security architecture framework that is more explicitly risk-driven and security-specific. In practice, TOGAF can provide the process and governance, while SABSA can provide a deeper security architecture lens. Many teams use them together rather than treating them as alternatives.

What security artefacts should a small team produce first when using TOGAF?

Start with security architecture principles, a high-level trust boundary or data-flow diagram, a short threat model, and a small set of approved security standards. Those artefacts give you enough structure to make better design decisions without creating too much process for a small team.