The argument of this article is straightforward: SABSA is an architectural method without a threat taxonomy and without a control catalogue. TLCTC is a threat ontology without an architectural method. Neither is complete alone. Together with NIST CSF as the verb set and external catalogues as control content, they form a four-way composition that enterprise security architecture actually needs.
What Each Framework Actually Is
Before any comparison, the categories must be clean. SABSA and TLCTC are not the same kind of object. Treating them as interchangeable produces the same confusion as comparing a grammar to a dictionary.
SABSA
Type: Enterprise security architecture method.
Provides: Six-layer model (Contextual → Operational), 6W matrix per layer, Business Attribute Profile, traceability from business need to security mechanism.
Answers: "How do we structure enterprise security thinking so it traces back to business need?"
TLCTC
Type: Threat classification ontology.
Provides: Ten non-overlapping cause clusters (Axiom III), Bow-Tie discipline with the SRE as universal pivot, cause-side vs consequence-side separation, deterministic attack-path notation.
Answers: "What is the threat — and what is not the threat?"
What SABSA Does Not Have
SABSA is deliberately content-light, method-heavy. It is a framework for designing security architecture, not a repository of content. The practitioner imports content from elsewhere.
Specifically, SABSA does not provide:
- A threat taxonomy. The Risk and Threat Assessment step expects a threat model — but SABSA does not prescribe one. Practitioners populate it with whatever vocabulary their organization uses: "ransomware," "data breach," "insider threat," "APT activity." This is precisely the conflation the Kreinz Thesis identifies.
- A control catalogue. SABSA does not enumerate controls. It expects the practitioner to import them from ISO/IEC 27002, NIST SP 800-53, CIS Controls, COBIT, or similar.
- Predefined control objectives. SABSA does not state, normatively, what objectives must exist.
What SABSA does provide that can look catalogue-adjacent:
| SABSA artefact | What it actually is |
|---|---|
| Business Attribute Profile | Taxonomy of ~85 business attributes (Available, Confidential, Accountable, Auditable, Compliant, …). A catalogue of consequence-side properties, not threats and not controls. |
| Logical Security Services | Reference set of service abstractions (authentication, authorization, cryptographic, audit, …). Placeholders for future implementation. |
| Security Mechanisms / Components | Architectural patterns for protocols, devices, technologies. Design choices, not controls. |
| Service Management catalogue | Inventory of operational processes (IR, vuln mgmt, change mgmt). Process inventory, not control inventory. |
The closest thing to a catalogue is the Business Attribute Profile — and it is a catalogue of what must be protected, not against what and not how.
Where SABSA Actually Operates: The Umbrella Layer
The TLCTC v2.0 white paper draws a distinction at Chapter 9: local controls protect a specific asset; umbrella controls protect across a wider scope (network zones, enterprise IAM, centralised monitoring, governance programmes). Almost every SABSA deliverable is an umbrella control.
| SABSA artefact | Operating scope |
|---|---|
| Business Attribute Profile | Enterprise scope (umbrella) |
| Security Services Catalogue | Shared services (umbrella) |
| Trust / Domain Model | Cross-organisational zones (umbrella) |
| Risk Model | Portfolio / business-process level (umbrella) |
| Service Management Architecture | SOC, IR, governance forums (umbrella) |
SABSA does not, in practice, prescribe how to harden a specific parser's input validation — that is local-control territory for the implementing team. It tells the enterprise to have an application-security capability with defined services and governance. The white paper's warning applies directly:
Umbrella controls are always scope-limited. They often cannot protect exposed patient-zero systems (or they become a target themselves).
This is SABSA's natural blind spot. The enterprise IAM service does not protect the exposed jump-host that sits outside the IAM scope. The SIEM does not detect the exploit that occurred before the agent was deployed. The umbrella ends where the umbrella ends.
The Third Archetype: Governance Umbrella
The binary "umbrella vs local" is insufficient, because most umbrella services are only effective when local systems actually participate. The binding mechanism is its own archetype.
| Archetype | Operates as | Example |
|---|---|---|
| Pure umbrella | Edge / shared backbone capability | Upstream DDoS scrubbing, off-site DR datacentre |
| Governance umbrella | Policy, standards, ARB, baselines, exception management, KCI accountability | Enterprise SDL standard, "must integrate with central IAM" policy, secure-by-design patterns |
| Local control | Per-asset implementation | Input validation in a specific parser, session-flag handling in an application |
Almost every operational umbrella service has a corresponding local conformance requirement:
- Enterprise IAM (umbrella) → application must consume SSO / federation, no local accounts (local). Binding = identity standard + ARB review.
- SIEM (umbrella) → system must forward logs in defined schema (local). Binding = logging standard + onboarding checklist.
- WAF / API gateway (umbrella) → traffic must be routed through it, no bypass paths (local design). Binding = network policy + design review.
- Central patch management (umbrella) → agent installed and reporting (local). Binding = vulnerability management standard + KCI.
- SBOM / SCA (umbrella) → development pipeline emits SBOM and consumes vetted dependencies (local CI/CD). Binding = SSDLC standard.
In each row, the umbrella delivers no risk reduction on the assets that do not participate. The governance umbrella is what closes that gap — not by adding a technical control, but by enforcing the integration as a baseline.
Sharpened Position
SABSA is primarily the architectural method for designing the governance umbrella, with secondary coverage of operational umbrella services. Its strength is producing the policies, standards, attribute profiles, and architecture patterns that bind local and operational-umbrella controls to enterprise intent.
This also explains where the GV column in the TLCTC × CSF matrix lives in practice. GV is not technical; it is the binding mechanism that ensures the ID/PR/DE/RS/RC controls are present and accountable for every cluster. The governance umbrella is the GV column expressed as concrete architectural artefacts.
Control Objectives Are Predefined, Not Authored
This is where the most common confusion sits. Control objectives are not free-form artefacts that SABSA practitioners synthesise. They are structurally predefined by the composition of two closed vocabularies.
From the white paper, §8.1.1:
NIST CSF functions provide a stable verb set for control objectives across operational risk […]. TLCTC provides a stable noun set for cyber causes […]. For each TLCTC cluster #X, define control objectives and controls under each CSF function.
Functions are verbs. Clusters are nouns. The control objective is the verb-noun composition.
The verb set is fixed: GV / ID / PR / DE / RS / RC (six). The noun set is fixed: #1 through #10 (ten), each with a normative generic-vulnerability definition. The Cartesian product is a closed enumeration of sixty legal control-objective statements. The v2.0 grammar (§7.5) extends this with lifecycle anchors:
[CSF Function] + [Lifecycle Point / Transition] + [TLCTC Cluster or Event Node] + [Objective qualifier]Examples:
| Verb | Noun (Lifecycle) | Legal control-objective statement |
|---|---|---|
| IDENTIFY | #2 | Identify weaknesses enabling #2 Exploiting Server on internet-facing services |
| PROTECT | #4 | Protect against credential acquisition and misuse in #4 Identity Theft |
| DETECT | #9 → #4 | Detect the transition from #9 to #4 before Loss of Control occurs |
| DETECT | #7 | Detect #7 Malware execution before Loss of Control |
| RESPOND | #10 | Respond to #10 Supply Chain trust-acceptance compromise |
| RECOVER | post-SRE / [DRE: Av] | Recover business capability after [DRE: Av] caused by a ransomware chain |
| GOVERN | #X (all) | Set ownership, risk appetite, and accountability for #X |
The implication for SABSA is precise. SABSA does not author control objectives — it architects their instantiation. Any control-objective statement in a SABSA artefact that does not reduce to [CSF verb] + [cluster #X] (+ optional lifecycle anchor) is semantically drifted. It is consequence-language ("prevent data breach"), actor-language ("defend against APTs"), or technology-language ("manage EDR") — none of which are valid threat nouns under Axioms III and IV.
The 10 × 6 Completeness Test
If SABSA functions as the governance umbrella, its artefact set must instantiate every cell of the TLCTC × CSF matrix. Anything less is governance with structural blind spots, and those blind spots propagate downward through standards, baselines, and KCIs into every local control owner's worksheet.
| #1 | #2 | #3 | #4 | #5 | #6 | #7 | #8 | #9 | #10 | |
|---|---|---|---|---|---|---|---|---|---|---|
| GV | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| ID | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| PR | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| DE | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| RS | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| RC | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
For every cell, the governance umbrella must either name a control objective with an owner and an enforcement mechanism, or record an explicit risk acceptance with a governance decision behind it. A blank cell is not "no risk" — it is uncontrolled exposure with no enterprise intent attached. Local control owners cannot compensate for missing GV; they do not have the mandate.
Mature SABSA shops tend to produce strong coverage for clusters aligned with traditional architecture domains and weak coverage for clusters that have been siloed elsewhere:
| Cluster | Typical SABSA strength | Common silo gap |
|---|---|---|
| #1 Abuse of Functions | Authorisation model, segregation of duties | Application-layer functional misuse |
| #2 / #3 Exploiting Server/Client | SDL standard, app-sec services | — |
| #4 Identity Theft | IAM model, PAM, MFA standards | — |
| #5 Man in the Middle | Cryptographic architecture, PKI | Internal east-west traffic protection |
| #6 Flooding | Often weak | Delegated to network team without architecture governance |
| #7 Malware | Endpoint architecture, execution control | EDR governance vs application-whitelisting standards |
| #8 Physical Attack | Often weak | Delegated to facilities / physical security |
| #9 Social Engineering | Often weak | Delegated to awareness / HR; rarely architected |
| #10 Supply Chain | Improving but uneven | Split between procurement, dev, and SecOps with no architectural binding |
The bolded clusters are the standard governance umbrella gaps. They are not necessarily technical gaps — the controls often exist somewhere in the organisation — but they are governance gaps, because SABSA artefacts do not bind them to enterprise intent through the same architectural method as the IT-native clusters.
The Four-Way Composition
With each framework correctly positioned, the composition becomes explicit:
| Layer | Source | What it provides |
|---|---|---|
| Threat noun (cause) | TLCTC | 10 clusters with generic-vulnerability definitions |
| Function verb | NIST CSF | 6 functions (GV / ID / PR / DE / RS / RC) |
| Control objective | TLCTC × CSF | Predefined: 60 verb-noun compositions |
| Lifecycle anchor | TLCTC Bow-Tie | Cause-side step / SRE / DRE / BRE |
| Consequence attribute | SABSA BAP | What business properties must survive the SRE |
| Architectural method | SABSA | How to instantiate, govern, trace, and bind controls at enterprise scope |
| Control content | ISO 27002 / NIST 800-53 / CIS / … | Actual control statements |
None of these is complete alone. The common industry failure is using a control catalogue (ISO 27002 Annex A) without a threat taxonomy, without a lifecycle anchor, and without a binding method. The result is the well-known "thousands of controls, no traceability" problem — and the symmetrical failure where SABSA artefacts are architecturally rigorous and threat-semantically incoherent at the same time.
Practical Posture for SABSA Practitioners
Adopting TLCTC alongside an existing SABSA practice does not require changing the SABSA method or its artefact structure. It requires fixing what goes into those artefacts. Concretely:
- Replace the heterogeneous threat list with the 10 clusters as the controlled vocabulary in every risk register, threat assessment, and policy document. "Ransomware," "data breach," and "APT" are not threats — they are outcomes, consequences, or actor labels.
- Split each risk-register row into cause-side (cluster + attack path) + SRE + DRE + BRE. The Bow-Tie discipline replaces the conflated "threat / risk / impact" column with a structured event chain.
- Map Business Attributes to the consequence side (DRE / BRE), not the cause side. The BAP is consequence-oriented by design; let it stay there.
- Re-tag every control as cause-side or consequence-side via Bow-Tie position. SABSA's traditional preventive / detective / corrective labelling masks this distinction; the Bow-Tie restores it. This step is usually where the most semantic drift surfaces in mature SABSA shops.
- Audit the artefact set against the 10 × 6 matrix. Every blank cell is either an uncovered predefined objective or an explicit risk acceptance. Make the choice visible.
- Rewrite every control-objective statement to the verb-noun form. If a statement does not reduce to
[CSF verb] + [cluster #X], it is drifted and must be restructured.
None of this requires abandoning SABSA. It requires recognising that SABSA's content-emptiness is structural, and filling that emptiness with the semantically disciplined sources the architectural method was designed to consume.
Closing
The question is not whether to use SABSA or TLCTC. The question is whether your enterprise security architecture can answer four orthogonal questions simultaneously, without conflating any of them:
- What is the threat? (TLCTC)
- What do we do about it? (NIST CSF)
- What business properties must be protected? (SABSA BAP)
- How is the architecture organised, governed, and bound across the enterprise? (SABSA method)
If any of these answers is missing — or semantically conflated with another — the architecture is incomplete, regardless of how elegantly it is documented. Most enterprise security architectures today fail on (1): they have governance, structure, and traceability, but the threat semantics underneath are pre-paradigmatic.
SABSA built the cathedral. TLCTC supplies the language the sermons must be preached in.
References: TLCTC v2.1 White Paper (Chapters 6–9), Why Exactly Ten? (Framework Architecture, Feb 2026), SABSA Institute architectural method documentation. All TLCTC framework materials licensed CC BY 4.0 — tlctc.net.
For comments or critique, contact via tlctc.net.