TOGAF And Zachman For Security Architecture

Security problems are often architecture problems wearing incident-response clothing.

A system has implicit trust. A business process bypasses review. A data flow nobody documented becomes the breach path. A vendor integration grows from "temporary" to critical without anyone updating the model.

Enterprise architecture frameworks will not fix that by themselves, but they can force better questions.

The two frameworks people usually ask about are TOGAF and Zachman. They are often discussed like rivals. I think that is the wrong framing.

TOGAF is a method. Zachman is a classification scheme.

Use TOGAF when you need a process for changing architecture. Use Zachman when you need to check whether your architecture description is complete.

TOGAF In Plain English

TOGAF's Architecture Development Method is a cycle for moving from principles and current state to target architecture, migration planning, governance, and change management.

For security teams, the value is not the vocabulary. It is the discipline:

• define the security principles before tool selection
• document current-state risk honestly
• design target-state controls with business context
• build a migration path instead of a wish list
• govern implementation so security requirements survive delivery pressure
• revisit the architecture as threats and systems change

That is useful work, even if you never say "ADM" in a meeting.

Where TOGAF Helps Security

Preliminary Phase

Set the ground rules:

• risk appetite
• control standards
• approved patterns
• cryptographic requirements
• threat modeling expectations
• exception process

This prevents every project from renegotiating security from scratch.

Architecture Vision

Do not write a vision that says "implement MFA" or "deploy Zero Trust." Write the business outcome:

• reduce standing privilege
• enable safer remote access
• make regulated data flows visible
• shorten incident containment time

The control comes later. The reason comes first.

Business, Data, Application, And Technology Architecture

Security shows up differently in each domain:

• business: roles, processes, continuity needs
• data: classification, retention, residency, encryption
• application: authentication, authorization, API controls
• technology: segmentation, logging, endpoint controls, identity boundaries

If one domain is missing, the security design is probably incomplete.

Migration And Governance

This is where plans either become real or turn into shelfware.

A useful roadmap ranks work by risk reduction and dependency order. A useful governance process catches security requirements that disappear during implementation. Neither needs to be dramatic. Both need to exist.

Zachman In Plain English

Zachman is a 6x6 matrix. The columns are the basic questions:

• What
• How
• Where
• Who
• When
• Why

The rows are perspectives, from planner to owner to designer to builder to implementer to functioning system.

That sounds abstract, but it is a good way to find missing security thinking.

A Security Reading Of Zachman

For a sensitive data platform:

Most security gaps come from missing one of those columns.

Examples:

• You know who can access data, but not when that access expires.
• You know where a system runs, but not why a third party can reach it.
• You know what data is sensitive, but not how it moves through reporting jobs.

Zachman is useful because it makes the blank spaces visible.

How I Would Use Them Together

Use TOGAF to run the work. Use Zachman to check coverage.

For example, during a Zero Trust program:

1. TOGAF sets the phases: current state, target state, roadmap, governance.
2. Zachman checks completeness: identity, devices, data, access timing, locations, business rules.
3. Security frameworks such as NIST CSF or SP 800-207 provide control language.

That combination is more practical than trying to make one framework do everything.

A Small Example

Suppose a company wants to reduce risk around contractor access.

TOGAF asks:

• What is the current access model?
• What should the target model be?
• Which applications move first?
• Who governs exceptions?
• How will the model change over time?

Zachman asks:

• What resources can contractors access?
• How do they request and use access?
• Where do they connect from?
• Who approves and reviews access?
• When does access expire?
• Why is access needed in the first place?

Together, the two views turn "fix contractor access" into a plan.

Failure Modes

Framework Theater

Teams produce artifacts because the framework says so, not because anyone uses them. This is how architecture becomes ceremony.

Tool Fixation

An enterprise architecture tool will not rescue unclear thinking. Start with the questions, then pick tooling that helps maintain answers.

Compliance-Only Use

Frameworks can support audit evidence, but audit evidence is not the same as security improvement. If the model does not help prioritize or govern change, it is not doing enough.

Too Much At Once

Do not implement every phase, cell, and artifact on day one. Pick a high-risk system or program and prove value there.

Where To Start

Start small:

1. Pick one system with real risk.
2. Map current-state data, identity, application, and technology architecture.
3. Use Zachman questions to find missing areas.
4. Define the target state in business terms.
5. Build a migration plan with owners and checkpoints.
6. Review progress after the first implementation, not at the end of the year.

Bottom Line

TOGAF helps structure change. Zachman helps catch blind spots.

Security teams do not need to become enterprise-architecture purists to use either one. They need enough structure to stop rediscovering the same gaps during incidents, audits, and migrations.

Use the frameworks as tools, not as identity.