SABSA: trace the purpose of each control

Traceability explains how a security decision addresses a business need. It prevents a product catalogue from becoming the architecture.

Ask about the outcome before the control

When I review a proposal, the business should be able to recognize its need in the design. If the aim is to integrate an acquisition, we need to clarify which services must keep working, which information will be shared and which activities require immediate integration. “Integrate everything” is not an operational requirement.

I would also ask who validates the outcome. Security can design a protection capability, but the process owner must explain what they need to work. That conversation separates essentials from preferences and records trade-offs. If we do not know the deadline or the impact of an interruption, we should record an open question that affects the architecture rather than silently inventing an assumption.

Start with context

Describe services, stakeholders and expected outcomes. Translate general statements such as “secure access” into attributes that can be discussed and assessed.

Turn attributes into testable conditions

Continuity, traceability and ease of onboarding are useful terms, but they need meaning within the service. For continuity, we must agree which activity is recovered and under what conditions. For traceability, which actions are attributable to an identity and how the evidence is retrieved. For onboarding, which steps a new team needs and how much effort they require.

I would not assign a number merely because it is easy to measure. First I would define which decision it supports. Availability may describe a component while excluding a dependency that stops people working. Onboarding metrics may count new accounts without checking their permissions. The attribute needs to retain its connection to the outcome the business wanted.

From need to evidence

Business needWhich activity we want to enable.
Attributes and requirementsWhat it means for the service to fulfil its purpose.
Capability and decisionWhich solution we choose and why.
Control and operationsHow it is applied and who maintains it.
EvidenceHow we verify the outcome.

Evidence and business changes help us revisit previous decisions.

An illustrative diagram of the article’s approach; not an official framework or supplier model.

Build an understandable chain

Link need, attribute, risk, capability, decision and evidence. One capability may serve several objectives; one objective may need several capabilities.

Explain a decision from end to end

Suppose we choose identity federation during an acquisition. I need to explain which activity it enables, which risks it changes and which conditions it requires. Federation can simplify access, but we must know who maintains the identity, how it is removed and what happens if the authentication provider fails.

I would document alternatives, dependencies and reasons for the choice. That information lets us revisit the decision when the context changes. If an option was rejected because technical support was missing, preserve that reason: it may no longer apply later. We should also distinguish a required capability from a particular product. Changing tools should not mean rediscovering the control’s purpose or losing the criteria used to evaluate it.

Example: integrating an acquisition

If the business needs to integrate a new company without interrupting services, architecture must express what that outcome means. Attributes such as continuity, traceability and ease of onboarding may be agreed. These lead to federation, segregation and recovery capabilities. Tool selection follows an understanding of those capabilities and their dependencies.

How I would run an architecture review

I would prepare a review around a few important decisions rather than starting with the entire control catalogue. For each, I would bring the need, agreed attributes, alternatives considered and evidence we expect. The business should confirm purpose; technical teams, dependencies; and operations, responsibilities.

If differences emerge, I would record them as issues affecting the design. A solution may offer sufficient component availability while requiring manual intervention the team cannot provide outside working hours. That operational requirement belongs in the decision. We cannot accept the capability solely on a supplier’s availability figure.

I would also ask which changes should trigger reconsideration. A new population, different data location or broader actions may alter requirements. Identifying these triggers makes maintenance easier than redesigning everything each time.

At the end, I would record decisions and open questions with owners. Design approval should distinguish validated elements from those still dependent on tests. Implementation must then return evidence to that record: which capabilities were actually configured, which differences emerged and which trade-offs remain open. This continuity makes traceability a working tool. It also gives future reviewers enough context to understand why a decision was made and whether its original conditions still apply, without relying on the architect’s memory or a presentation that was never updated.

Keep architecture alive

Record each decision owner, assumptions and review triggers. Business changes should be traceable to the affected capabilities.

Use traceability when things change

The benefit becomes clear when a new request arrives. If a service’s scope changes, we can follow the relationships and identify affected requirements. A new user population may change the identity model, support needs and conditions for data access.

Not every change requires a complete redesign. We need to determine which assumptions remain valid and which decisions require new evidence. I would keep a short record of the reason for the change, the owners consulted and the review outcome. That record should help the people operating the service, rather than remaining only in the architect’s repository. Documentation loses value when it describes a solution that no longer reflects actual operation or the current business purpose.

The limits of traceability

A large matrix may appear rigorous without helping anyone decide. Prefer relationships an accountable owner can explain and validate. When a decision depends on an assumption —for example, that a supplier will retain a critical function— record it alongside the decision, together with a review trigger.

Give the operating model equal weight

A capability needs owners able to maintain it. Who reviews permissions? Who changes policy? Who investigates unexpected behavior? Who decides that an exception is no longer justified? Those activities belong in the operating model and its RACI.

To check traceability, I would choose several important decisions and ask for an explanation in both directions: from need to control, and from control to purpose. I would also check what evidence exists and when it was reviewed. If we can only point to a cell in a matrix, the explanation is missing. My aim is for the design to support decisions, operations and adaptation as needs change, while keeping limitations and trade-offs visible to the people who depend on it.