TRACETraceable Risk, Architecture, Capability and Economics

Preview · selected sections of TRACE Framework v1.0

Foreword

The TRACE Framework was developed by GreyHyphen Labs from the working method of security strategy engagements delivered across the Gulf and Europe, and is published by GreyHyphen Labs under a commercial licence. It exists because of a question that is asked in every board room and answered badly in most: how do you know?

Security spend is not short of frameworks. NIST CSF 2.0 says which functions must be covered. ISO/IEC 27001 says what a management system must contain. SABSA says that architecture must be driven by the business. FAIR says how loss should be quantified. Each answers its own question, and answers it well. None of them answers the board's question, which is not whether a control exists but whether the money being requested traces to something the business actually needs.

That gap is not a documentation problem. Governance, risk and compliance tooling records positions faithfully and at scale. What it does not do is reason across them: it holds the risk register and the control library and the project portfolio in the same database without ever being able to say which risk this project is treating, or what quality of the business would be lost if it were cancelled. The chain of reasoning that connects a business need to a line in a budget is assembled by hand, for one presentation, and then thrown away.

TRACE makes that chain the object under management. Its claim is narrow and testable: a strategy is not a document, it is a chain of evidence, and an initiative that cannot be traced to a business driver is an opinion, however competently it is argued.

The framework is deliberately thin. It defines ten object classes, ten links, five stages, seven domains and five grades — and then it stops. It supplies no control catalogue, no threat taxonomy, no capability model and no quantification method, because good ones already exist and a further one would help nobody. What it supplies is the connective discipline that makes the others add up to a decision.

Version 1.0 was released by GreyHyphen Labs in October 2026.

4 Framework overview

4.1 The three components

TRACE has three components, and they do three different jobs. A framework that supplies only one of them is a checklist.

The seven domains of Clause 7 are not a fourth component. They are the map of who holds what, and they exist to enforce a single rule: that no object class has two systems of record.

4.2 Principles

Seven principles underlie the requirements of this document. Where a requirement admits of interpretation, the principle governs.

P1 Traceability before completeness A complete inventory that traces to nothing is not a strategy. The framework measures whether the links hold before it measures how much has been catalogued.

P2 Measure the shape, not the score A capability is scored on people, process and technology separately, never blended. The shape of a gap decides what kind of work closes it; a single number hides exactly the thing the decision needs.

P3 Unassessed is not zero An absent measurement is a finding in its own right. It is recorded as unassessed and reported separately from a measured shortfall.

P4 Single custody Every object class has exactly one system of record. Other domains reference it. Two lists of the same thing is the defect, not the redundancy.

P5 Gates, not reports Coverage is a condition of leaving a stage, not a document produced at the end of one. A stage that cannot pass its gate is not finished, however much has been written.

P6 Declare the outside What the framework does not cover is recorded with a location and a named owner. A blank cell and an out-of-scope cell are different claims and are never rendered the same way.

P7 Economics is part of the chain Cost, sequence and outturn are links in the chain, not attachments to it. A control with no cost basis and no outturn is not traced, however well it is designed.

4.3 Conventions

This document uses the following verbal forms.

Requirements are set out in ruled panels through the body of this document, and are collected in Annex A and Annex B.

4.4 How to read this document

Clause 5 is the model and should be read first; the rest of the framework is an application of it. Clause 6 is the operating manual and is what a practitioner will use daily. Clause 7 is the organisational map. Clause 8 is what an assessor uses. Clause 10 is what a reader already invested in another framework will want, and can be read immediately after Clause 4.