TCCE Framework: Threat, Control, Compliance, Evidence

TCCE (Threat, Control, Compliance, Evidence) is a sequential AI compliance pipeline that processes an AI system in four ordered stages: threat assessment → control mapping → compliance evaluation → evidence linking. Each stage consumes the previous stage's output and produces an auditable artifact of its own: threat assessment turns model metadata into a MITRE ATLAS-mapped threat profile, control mapping selects ISO/IEC 42001 controls that answer those threats, compliance evaluation runs gap analysis and posture scoring against the mapped controls, and evidence linking binds every conclusion to artifacts signed with CRYSTALS-Dilithium and anchored in a Merkle tree.

The term names both the methodology and its implementation, the TCCE Engine — the core pipeline inside SecureGRC, an early-stage, purpose-built quantum-safe AI compliance platform. TCCE is not an ISO or NIST standard; it is a pipeline architecture that composes existing standards (MITRE ATLAS, ISO/IEC 42001, FIPS 204) into a single traceable chain. This page defines the framework, explains why the stage ordering is load-bearing, walks through each stage's inputs and outputs, and compares TCCE against generic GRC workflows.

What is the TCCE framework?

TCCE is best understood as a data pipeline for compliance rather than a document workflow. A traditional compliance exercise produces documents — risk registers, control matrices, audit reports — whose relationships live in people's heads or in spreadsheet cross-references. TCCE instead treats compliance as a typed, ordered transformation: metadata goes in one end, and a signed, verifiable compliance posture comes out the other, with every intermediate artifact preserved and linked.

 model metadata in                                        signed evidence out
       │                                                            │
       ▼                                                            ▼
 ┌──────────┐      ┌──────────┐      ┌────────────┐      ┌──────────┐
 │  THREAT  │ ───▶ │ CONTROL  │ ───▶ │ COMPLIANCE │ ───▶ │ EVIDENCE │
 │  assess  │      │   map    │      │  evaluate  │      │   link   │
 └──────────┘      └──────────┘      └────────────┘      └──────────┘
  MITRE ATLAS       ISO 42001         gap analysis        Dilithium-signed,
  threat profile    control set       + posture score     Merkle-anchored

Three design decisions define the framework:

• Strict sequence. Stages run in a fixed order — Threat, then Control, then Compliance, then Evidence — because each stage's output is the next stage's justification. Nothing downstream can exist without an upstream reason.
• Metadata-only inputs. The pipeline operates exclusively on extracted metadata. Model weights, training data, and proprietary IP never enter the system — the property explained in depth in the metadata-only compliance model. This is what makes TCCE outputs shareable with auditors and regulators by construction.
• Independently testable stages. Each stage has a defined input contract and a defined output artifact, so it can be tested, replayed, and audited in isolation — the same way well-factored software pipelines are validated stage by stage.

Why does the order of the TCCE stages matter?

The sequence is the framework. Reversing or skipping stages produces the classic failure modes of AI governance, so it is worth being precise about what each ordering constraint prevents.

Threats ground controls. If control selection comes first — as it does in checklist-driven programs — you get controls chosen because a template listed them, not because they answer a threat the system actually faces. A retrieval-augmented chatbot and a credit-scoring model face very different adversarial surfaces; starting from an enumerated, MITRE ATLAS-mapped threat profile means the control set differs accordingly, and every selected control can point at the threat that justified it.

Controls ground compliance claims. A compliance score is only meaningful relative to a defined control set. Because TCCE evaluates posture against the controls mapped in stage two, a statement like "82% posture against the applicable ISO/IEC 42001 control set" is a claim about specific, threat-justified controls — not an impressionistic maturity rating.

Claims need evidence. The final constraint is the sharpest: no compliance claim leaves the pipeline without a link to a signed artifact that supports it. TCCE's design goal is the elimination of orphan paperwork — documentation that exists but cannot be traced to a reason, and claims that are asserted but cannot be proven. In a completed TCCE run, an auditor can pick any statement in the posture report and walk backwards: claim → evaluated control → mapped threat → source metadata, with each hop cryptographically verifiable.

What happens in the threat assessment stage?

Threat assessment is the entry point of the pipeline. It starts from extracted model metadata — model type and architecture family, dataset lineage, framework and library dependencies, deployment context, and interfaces — and never from the model itself. From that metadata, the stage enumerates the adversarial techniques relevant to the system and maps them to MITRE ATLAS, the adversarial-threat knowledge base for AI systems, producing a structured threat profile.

Mapping to ATLAS rather than an ad-hoc risk list matters for two reasons. First, ATLAS gives threats a shared, citable vocabulary — an auditor can look up a technique and see the documented attack pattern behind it. Second, it makes the crosswalk to governance frameworks tractable: how an operational threat catalog like ATLAS relates to a management-system standard like ISO/IEC 42001 is exactly the mapping problem examined in ISO 42001 vs MITRE ATLAS, and TCCE's first two stages are that crosswalk operationalized as a pipeline.

What happens in the control mapping stage?

Control mapping consumes the threat profile and answers one question per threat: which controls, if operating, would mitigate this? The stage draws from SecureGRC's ISO/IEC 42001 control library — the Annex A controls of the AI management system standard published in December 2023, covering themes such as AI system documentation, impact assessment, data provenance and quality, and lifecycle management. (For the standard itself, see ISO/IEC 42001 explained.)

The output is deliberately a mapping, not a list. A bare control list says "we selected these"; a mapping says "we selected these because of those." That distinction is what lets the later posture report defend its own scope: controls that were excluded were excluded because no profiled threat required them, and that reasoning is recorded rather than implied.

What happens in the compliance evaluation stage?

Compliance evaluation is where the pipeline turns a control set into a measured position. For each mapped control, the stage assesses implementation status, then aggregates the results into two artifacts: a gap analysis — the delta between required and actual, stated per control — and a compliance posture report that scores coverage across the applicable control set.

Because the evaluation runs against threat-justified controls, its outputs inherit the traceability of the earlier stages. A gap is never just "control X is missing"; it is "control X, mapped from threats Y and Z, is not yet operating" — which is also why TCCE gap analyses double as prioritization inputs: gaps that trace to more or nastier threats surface first. Posture scoring gives governance teams and the SecureGRC dashboard a longitudinal signal: re-running the pipeline after remediation shows the score moving for reasons the chain can explain.

What happens in the evidence linking stage?

Evidence linking is the stage that turns conclusions into proof. Every artifact the pipeline produced — the threat profile, the control mapping, the gap analysis, the posture report, and generated ML-BOMs aligned with CycloneDX (which has supported ML-BOMs since v1.5) and SPDX — is hashed with SHA-3, signed with CRYSTALS-Dilithium (ML-DSA, NIST FIPS 204, finalized August 2024), and anchored into a Merkle tree. Each compliance claim is then linked to the signed artifacts that support it, forming a verified audit trail.

Two properties of this stage deserve emphasis. First, verification requires only public keys: an auditor checks a Dilithium signature and a Merkle inclusion proof offline, against a public FIPS specification, without trusting or even contacting the platform. Second, the signatures are post-quantum: because compliance evidence must stay trustworthy for retention windows of many years, signing it with algorithms a future quantum computer could break would give it an expiry date. The full rationale — including why lattice signatures and SHA-3 were chosen — is covered in quantum-safe compliance.

Why does it matter that each TCCE stage is independently testable?

Monolithic compliance processes fail monolithically. When threat analysis, control selection, scoring, and evidence gathering happen as one undifferentiated exercise, an error found anywhere casts doubt everywhere — and the only remedy is redoing the whole assessment. TCCE's stage boundaries exist to prevent exactly that, and they pay off in four specific ways:

• Failures localize. If a threat mapping is wrong, the defect is in stage one; the control library, scoring logic, and signing machinery are unaffected and demonstrably so, because each stage's artifacts are separately signed and separately checkable.
• Stages are replayable. A defined input contract means an auditor — or SecureGRC's own test suite — can feed a stage known inputs and compare outputs against expectations, the way unit tests validate one function rather than an entire program. Each stage of the TCCE Engine is tested this way in isolation.
• Audits can be scoped. An auditor interested only in whether control selection follows from the threat profile can examine stage two alone: its input (the signed threat profile), its output (the signed mapping), and the linkage between them. No need to re-litigate the whole run.
• Partial re-runs stay cheap. When a model's metadata changes — a new dataset, a new dependency — the pipeline re-executes from the affected stage forward, and the audit trail records precisely which artifacts changed and why. Compliance keeps pace with retraining instead of restarting from zero.

This is an architectural claim, not a marketing one: the same reasoning that makes staged, contract-driven software pipelines more reliable than monoliths applies to compliance pipelines, and TCCE is simply that reasoning applied to governance.

How does TCCE compare to a generic GRC workflow?

Generic GRC platforms grew up around IT and financial controls, and their workflows reflect it: control checklists first, narrative evidence later, AI handled as one more questionnaire. The differences from TCCE are structural rather than cosmetic:

The honest trade-off runs the other way, too: incumbent suites cover breadth — privacy, third-party risk, ESG, dozens of frameworks — that a purpose-built AI compliance pipeline does not attempt. TCCE optimizes for depth and verifiability on one problem: AI systems, under AI-specific threats and AI-specific regulation such as the EU AI Act (in force since August 2024, with staged obligations). How that focus compares with a broad incumbent platform is examined in SecureGRC vs OneTrust.

Frequently asked questions

Definitions and boundaries of the TCCE framework. Broader product questions are covered in the SecureGRC FAQ.