Embedding Security by Design: A Comprehensive Guide to the TOGAF® 10 Security Architecture Series

Introduction

For decades, enterprise architecture and cybersecurity operated in silos. Security was frequently treated as a parallel workstream or, worse, an afterthought applied only after business and technology architectures were finalized. This approach resulted in fragile systems, costly retrofits, and misaligned risk postures. The TOGAF® Standard, 10th Edition fundamentally shifts this paradigm.

In TOGAF 10, security is no longer a separate discipline; it is fully integrated into the Architecture Development Method (ADM) via the TOGAF® Series Guide: Security Architecture. This guide provides the specific skills, techniques, and integration points required to embed security risk management directly into every phase of enterprise architecture development.

TOGAF10: Fully Integrated Security Architecture - By visual Paradigm

This comprehensive guide explores how to operationalize the TOGAF 10 Security Architecture Series Guide, moving from theoretical risk appetite to tangible architectural controls. Whether you are an Enterprise Architect seeking to improve security alignment or a Security Architect looking to influence business strategy, this guide provides the roadmap for evidence-based, risk-driven security architecture.

Key Concepts

Before diving into the ADM phases, it is essential to understand three foundational concepts that distinguish the TOGAF 10 approach from traditional security frameworks:

Risk-Driven vs. Control-Driven: Traditional security often starts with a checklist (e.g., “Implement MFA”). TOGAF 10 starts with business risk. Controls are selected only as a response to quantified risk that exceeds the organization’s risk appetite.
Security as a Cross-Cutting Concern: Security is not a distinct ADM phase. It is a continuous thread woven through Preliminary, Phases A–H, and Requirements Management. Every architectural decision has a security implication.
Evidence-Based Architecture: Security decisions must be traceable. There must be a documented lineage from Business Driver → Risk Assessment → Security Requirement → Control Selection → Validation. This traceability is what satisfies auditors and justifies investment.

💡 Practical Tip: When applying this guide, start with Security Risk Assessment and Requirements Engineering in Phases A–D. Organizations that jump straight to control selection (Phase E) without documented risk rationale consistently fail audits and create misaligned security spend. The TOGAF 10 approach mandates evidence-based security architecture.

Core Philosophy: Risk-Driven & Integrated

The central tenet of the TOGAF 10 Security Architecture guide is that security architecture is not about selecting controls first; it is about understanding business risk.

Translating Risk Appetite into Architecture

Business stakeholders rarely articulate needs in terms of “encryption standards” or “firewall rules.” They speak in terms of market expansion, regulatory compliance, customer trust, and operational resilience. The security architect’s primary role is translation:

Business Statement	Risk Translation	Architectural Requirement	Potential Control
“We need to launch our fintech app in the EU market by Q3.”	Non-compliance with GDPR could result in fines up to 4% of global revenue and reputational damage.	All PII of EU residents must be processed lawfully with explicit consent and right-to-erasure capability.	Consent management platform; Data residency controls in cloud region eu-west-1; Automated data deletion workflows.
“Our manufacturing line cannot tolerate more than 2 hours of downtime per year.”	Ransomware targeting OT systems could cause $2M/hour in lost production and safety incidents.	OT network must be segmented from IT; Critical PLCs must have integrity verification.	Industrial DMZ; Network micro-segmentation; File integrity monitoring on engineering workstations.
“We want to enable partner API access to our inventory system.”	Third-party compromise could lead to supply chain manipulation and fraud.	Partner access must be least-privilege, time-bound, and continuously verified.	OAuth 2.0 with scoped tokens; API gateway rate limiting; Continuous authentication/behavioral analytics.

Example: From Abstract to Concrete

Consider a healthcare provider adopting telehealth. A control-driven approach might immediately prescribe HIPAA-compliant cloud hosting. A risk-driven TOGAF 10 approach would first assess: What data flows? Who accesses it? What is the impact of a breach vs. the impact of service unavailability during a pandemic? The resulting architecture might prioritize availability and secure video transport over exhaustive logging of non-PHI metadata, aligning spend with actual patient safety and privacy risks.

Key Techniques in Security Architecture

These techniques map directly to ADM phases and provide the “how-to” for security architects. They transform abstract principles into actionable deliverables.

Technique	Primary ADM Phase(s)	Description & Application	Real-World Example
Security Risk Assessment	Preliminary, A, B, C, D	Identifies assets, threats, vulnerabilities, and impacts. Uses frameworks like NIST SP 800-30 or ISO 27005 to quantify risk before designing solutions.	During Phase B (Business Architecture), assessing the risk of insider threat in a merger scenario where employee turnover is high, leading to enhanced DLP and access recertification requirements.
Security Requirements Engineering	A, B, C, D	Derives security requirements from business drivers, regulations, and risk assessments. Ensures requirements are testable and traceable.	Translating “Protect customer data” into: “All stored payment card data MUST be tokenized using FIPS 140-2 validated module; decryption keys MUST reside in HSM; access logged to SIEM within 60 seconds.”
Threat Modeling	B, C, D	Systematically identifies potential attack vectors and threat actors against proposed architectures (e.g., STRIDE, PASTA). Validates design resilience.	Applying STRIDE to a new microservices order-processing flow in Phase D, revealing missing authorization checks between services, leading to implementation of service mesh mTLS and RBAC.
Control Selection & Mapping	E, F	Selects appropriate security controls (technical, procedural, physical) based on risk treatment decisions. Maps controls to standards (NIST CSF, CIS, ISO 27001).	After identifying ransomware risk in Phase D, selecting CIS Control 10 (Malware Defenses), NIST PR.PT-4 (Resilience), and mapping to specific EDR vendor capabilities in Solution Building Blocks.
Security Architecture Review	G, H	Evaluates implemented solutions against security requirements and risk acceptance criteria. Includes penetration testing coordination and compliance audits.	In Phase G, reviewing the deployed zero-trust network against the approved architecture; validating that conditional access policies enforce device compliance before granting SaaS access.
Data Classification & Protection	C (Data Arch)	Categorizes data by sensitivity and regulatory impact. Drives encryption, DLP, access control, and retention policies.	Classifying R&D prototypes as “Confidential – IP Critical” in Phase C, triggering automatic encryption at rest/in-transit, restricted sharing labels, and 7-year retention with legal hold capability.
Identity & Access Management (IAM) Design	C, D	Designs authentication, authorization, federation, and privileged access management aligned with zero-trust principles.	Designing a unified identity fabric in Phase D that federates employee, contractor, and IoT identities; enforcing step-up auth for sensitive transactions; implementing just-in-time privileged access.
Security Governance Integration	Preliminary, G	Embeds security decision-making into EA governance boards, change advisory boards (CAB), and procurement processes.	Establishing a Security Architecture Review Board (SARB) charter in Preliminary Phase; mandating security sign-off as gate criterion in Phase G; integrating security scoring into vendor RFP evaluation.

Deep Dive Example: Threat Modeling in Phase D

When designing a cloud-native application in Phase D (Technology Architecture), threat modeling should not be a documentation exercise. Using the PASTA methodology:

Define Objectives: Protect user session integrity and prevent account takeover.
Define Technical Scope: React frontend, Node.js API, PostgreSQL DB, AWS Cognito.
Application Decomposition: Map data flows, trust boundaries, entry points.
Threat Analysis: Identify OWASP Top 10 + business-specific threats (e.g., credential stuffing via leaked databases).
Vulnerability Analysis: Review code/config for JWT misconfigurations, missing rate limits.
Attack Modeling: Simulate attack paths; validate mitigations.
Risk & Countermeasure Determination: Prioritize fixes based on exploitability × business impact. Output feeds directly into Phase E work packages.

Essential Skills for Security Architects

Executing these techniques requires a hybrid skill set bridging deep technical security expertise and enterprise architecture fluency.

Technical Security Skills

Risk Analysis Frameworks: Proficiency in FAIR (quantitative), NIST RMF, ISO 27005, or OCTAVE. Ability to choose the right framework for the context (e.g., FAIR for board-level ROI discussions, NIST for federal compliance).
Security Control Libraries: Deep knowledge of NIST SP 800-53, CIS Controls, CSA CCM, or industry-specific regulations (HIPAA, PCI-DSS, GDPR). Understanding control dependencies and compensating controls.
Secure Design Patterns: Microservices security (service mesh, sidecars), API gateways, zero-trust network architecture (ZTNA, SASE), cloud-native security (CSPM, CWPP, IaC scanning).
Cryptography & Data Protection: Key management lifecycle, PKI hierarchy design, tokenization, format-preserving encryption, privacy-enhancing technologies (differential privacy, homomorphic encryption).
Vulnerability & Threat Intelligence: Interpreting CVEs/CVSS in business context, consuming threat feeds, mapping adversary TTPs to MITRE ATT&CK, validating detection coverage.

Enterprise Architecture Integration Skills

Business-Risk Translation: Converting “Critical RCE vulnerability in Apache Log4j” into “Potential 72-hour outage of customer portal affecting $500K/day revenue and regulatory reporting deadline.” Speaking the language of CFOs and COOs.
ArchiMate Security Modeling: Using the ArchiMate language’s security extension to visualize risks, controls, and their relationships to business/application layers. Creating views that show why a control exists, not just what it is.
Regulatory Mapping: Translating legal/regulatory text into actionable architecture constraints. Building reusable compliance patterns that accelerate future certifications.
Supplier Security Assessment: Evaluating third-party/vendor security posture as part of Technology Architecture (Phase D) and procurement. Integrating SOC 2 review, SIG questionnaires, and continuous monitoring into vendor lifecycle.
Security Metrics & KPI Development: Defining measurable indicators aligned with business outcomes. Moving beyond “number of patches applied” to “mean time to contain critical incidents,” “% of high-risk data flows with approved controls,” or “reduction in phishing click rate post-training.”

Skill Development Example

A security architect transitioning to TOGAF 10 should pair technical training (e.g., CCSP, CISSP) with EA training (TOGAF Foundation/Certified, ArchiMate). Practical exercises should include: taking a real business initiative, performing a risk assessment, deriving requirements, modeling in ArchiMate, and presenting recommendations to a mock architecture board. Mentorship from experienced EA practitioners accelerates integration skill development.

Integration Points Across the ADM

Security activities are continuous, not phase-gated. Below is a detailed view of how security integrates into each ADM phase, with concrete deliverables.

Preliminary Phase: Foundation Setting

Activities: Define security principles aligned with business values; establish risk appetite statement; create security governance model; select risk/framework standards; define security architecture repository structure.
Deliverables: Security Principles Catalog, Risk Appetite Statement, Security Governance Charter, Tailored Security Framework Baseline.
Example: Establishing principle: “Security controls shall be proportionate to asset classification and business criticality; over-control is waste.“

Phase A: Architecture Vision

Activities: Identify stakeholder security concerns; capture high-level security objectives; perform initial risk screening; define security scope and constraints; obtain stakeholder buy-in on risk tolerance.
Deliverables: Stakeholder Map (with security concerns), High-Level Security Objectives, Initial Risk Register, Approved Security Scope.
Example: CEO expresses concern about brand reputation; translated to objective: “No public-facing breaches involving customer PII in next fiscal year.”

Phases B, C, D: BDAT Architectures

Activities: Perform domain-specific risk assessments; conduct threat modeling; derive detailed security requirements; classify data; design IAM; evaluate supplier security; validate designs against principles.
Deliverables: Domain Risk Assessments, Threat Models, Security Requirements Specification, Data Classification Matrix, IAM Architecture, Supplier Security Assessments.
Example: In Phase C (Data Architecture), classifying all datasets; in Phase D, designing network segmentation based on data flows and threat model outputs.

Phase E: Opportunities & Solutions

Activities: Prioritize security work packages; select controls and technologies; map controls to standards; identify gaps and compensating controls; integrate security into Solution Building Blocks.
Deliverables: Security Work Package Backlog, Control Selection Matrix, Gap Analysis Report, Security-Enhanced Solution Building Blocks.
Example: Bundling MFA rollout, SIEM tuning, and DLP policy updates into a single “Identity & Data Protection Enhancement” work package with clear dependencies.

Phase F: Migration Planning

Activities: Sequence security work packages; assess migration risks; define transition architectures with security controls; validate rollback plans include security state restoration.
Deliverables: Prioritized Security Migration Roadmap, Transition Security Architecture, Migration Risk Assessment.
Example: Sequencing firewall rule migration before application cutover; ensuring legacy system decommission includes secure data sanitization.

Phase G: Implementation Governance

Activities: Conduct security architecture reviews; validate control implementation; manage exceptions/risk acceptances; coordinate penetration testing; verify compliance evidence.
Deliverables: Security Review Reports, Exception/Risk Acceptance Records, Pen Test Results & Remediation Plans, Compliance Attestation Evidence.
Example: Reviewing deployed cloud infrastructure against approved architecture; documenting accepted risk for temporary use of legacy protocol with compensating monitoring.

Phase H: Architecture Change Management

Activities: Assess security impact of changes; update risk register; revise control baseline; re-evaluate threat landscape; trigger reassessment if thresholds exceeded.
Deliverables: Security Impact Assessment, Updated Risk Register, Revised Control Baseline, Change Request Security Sign-off.
Example: New feature adds external API endpoint; triggers threat model update, additional WAF rules, and revised monitoring alerts before approval.

Relationship to Other TOGAF Series Guides

Security Architecture does not exist in isolation. Effective integration requires alignment with complementary guides:

Risk Management Guide: Security risk is a subset of enterprise risk. Techniques must align with organizational risk taxonomy, heat maps, and escalation paths. Security risks should roll up into enterprise risk dashboards.
Business Capabilities Guide: Security capabilities (e.g., “Identity Verification,” “Data Loss Prevention”) should be modeled alongside business capabilities. This enables capability-based planning and investment prioritization.
Agile & DevOps Guides: Security must shift-left. Techniques adapt to sprint cycles (e.g., lightweight threat modeling per epic), CI/CD pipelines (automated SAST/DAST, policy-as-code), and product team ownership. Security architecture becomes enabling guardrails, not gates.
Content Framework: Security artifacts (risk registers, control matrices, threat models) are defined as standard deliverables within the Architecture Repository. This ensures consistency, reusability, and tool interoperability.

Integration Example: Agile + Security + Business Capabilities

An agile team building a payments feature references the “Payment Processing” business capability model, which includes embedded security sub-capabilities. Their sprint backlog includes security tasks derived from the capability model. Automated pipeline checks validate controls against the Content Framework’s security artifact templates. Risk posture updates feed back to the enterprise risk dashboard weekly.

Conclusion

The TOGAF® 10 Security Architecture Series Guide represents a maturation of both enterprise architecture and cybersecurity disciplines. By embedding security into the ADM through risk-driven techniques, cross-cutting integration, and hybrid skill sets, organizations can achieve:

Aligned Investment: Security spend directly addresses documented business risks, eliminating wasted controls and unfunded gaps.
Audit Readiness: Traceable evidence from business driver to implemented control satisfies regulators and reduces audit fatigue.
Resilient Design: Threat-informed architectures withstand evolving attacks because security was designed in, not bolted on.
Business Enablement: Security becomes a value enabler, accelerating safe innovation rather than blocking progress.

Success requires commitment from both EA and security leaders. Start small: pilot risk-driven requirements engineering on one high-value initiative. Document the lineage. Measure the outcome. Scale what works. The TOGAF 10 approach is not about perfection—it is about progressive, evidence-based alignment between security and business value.

Remember: Security architecture is not a destination. It is a continuous practice of translating business risk into resilient design. Embrace the integration, develop the hybrid skills, and let risk—not checklists—guide your architectural decisions.