Welcome back to Signal & Trust.

We've covered Trust Decay Rate and Vendor Trust Scores. Now the inevitable question: what happens when trust breaks?

Not "what's your incident response plan." Every org has one of those. The question is: how do you rebuild trust after a breach — internally, with customers, with partners, and with your board?

The best IR teams in the world treat the first 72 hours not as a technical exercise, but as a trust reconstruction operation.

---

Hour 0-8: Establish the Trust Perimeter

Most IR playbooks start with containment. Stop the bleeding. Isolate the affected systems. That's table stakes.

The best teams add a parallel workstream that almost nobody documents: mapping the blast radius of broken trust.

Ask immediately:

• Which identity systems are compromised? Not just "which accounts" — which systems that issue trust are affected? If your IdP is in scope, every authentication decision made since the compromise is suspect.

• Which data flows can we still trust? If an attacker had access to your CI/CD pipeline, can you trust your last three deployments? If they touched your logging infrastructure, can you trust your own forensic evidence?

• Who needs to know right now — not for compliance, but for operational trust? Your SOC 2 auditor can wait. Your cloud provider whose shared infrastructure might be affected cannot.

The output of this phase isn't a containment report. It's a Trust Perimeter Map — a real-time document showing which systems, relationships, and data flows are inside the "known-good" boundary and which are outside it.

Hour 8-24: The Silence Tax

Here's where most organizations make their most expensive mistake: they go quiet.

Legal counsel says don't disclose yet. PR wants to control the narrative. Leadership wants more information before saying anything.

Meanwhile:

• Your customers are hearing rumors

• Your partners are running their own threat models against your environment

• Your employees are speculating on Slack

• Journalists are making calls

Silence isn't caution. It's a trust tax that compounds by the hour.

The best IR teams deploy what we call Structured Transparency — a framework for communicating during uncertainty without creating legal liability:

The Three-Statement Framework

At any point during an active incident, you should be able to issue three statements:

1. What we know

"We detected unauthorized access to [system] on [date]. The investigation is ongoing."

Not speculation. Not attribution. Just confirmed facts.

2. What we're doing

"We have engaged [forensic firm], isolated affected systems, and are conducting a full review of [scope]."

This tells stakeholders you're acting, without revealing your defensive playbook.

3. What we don't know yet

"We have not yet determined the full scope of data accessed. We will provide an update within [timeframe]."

This is the statement most organizations are afraid to make. But acknowledging uncertainty is more trustworthy than projecting false confidence. People don't lose trust because you were breached. They lose trust because you pretended you weren't.

Hour 24-48: The Internal Trust Audit

By day two, your technical team is deep in forensics. Good. But who's auditing the trust decisions that led here?

This is the window for what we call the Pre-Mortem in Real-Time:

• Which trust assumptions failed? Did you trust a vendor's attestation that turned out to be stale? Did you trust a network segment that should have been segmented further?

• Which compensating controls didn't compensate? Every risk register has "mitigated" risks with compensating controls listed. How many of those actually fired during this incident?

• Where did trust concentration create fragility? Single points of trust failure — one admin account, one API key, one vendor integration — are the architectural equivalent of single points of failure. Map them now while the pain is fresh.

Document these findings in real-time, not after the incident. Post-incident reviews suffer from hindsight bias. The trust audit you run at hour 36 — while you're still uncertain and scared — is more honest than the one you run at day 30.

Hour 48-72: The Reconstruction Signal

By hour 48, you should be transitioning from "what happened" to "what trust looks like going forward."

This is where you build the Trust Reconstruction Roadmap:

1. Re-baseline your identity trust

Force credential rotation not as a panic response, but as a deliberate re-establishment of known-good identity state. Every privileged account. Every service account. Every API key that touched a compromised system.

2. Publish your Trust Recovery Timeline

Internally and — where appropriate — externally, communicate: "Here is when we expect to have re-established trust in each affected system, and here is how we'll verify it."

This is radically different from "here's our remediation plan." Remediation fixes the vulnerability. Trust recovery re-establishes the organizational confidence that your systems are operating as intended.

3. Update your Trust Decay Model

If you're tracking TDR (Edition #1), this incident just gave you real data. Update your decay curves. Adjust your vendor trust scores. Feed the learnings back into the measurement system so the board sees not just "we had a breach" but "here's how our trust model has been recalibrated."

The Signal

Incident response isn't a security function. It's a trust function.

The organizations that recover fastest from breaches aren't the ones with the best SIEM or the fastest forensic team. They're the ones who understand that every hour of silence, every unexamined trust assumption, and every delayed communication is eroding something far more valuable than data.

Trust is the asset. The breach is just the event that revealed how well you were maintaining it.

---

Next edition: The CISO's Trust Stack — Building a Personal Operating System for Risk Decisions

— Signal & Trust

Welcome back to Signal & Trust.

Last edition, we introduced Trust Decay Rate and argued that boards need to see trust as a depreciating asset. The single biggest source of that decay? Your vendors.

---

The Questionnaire Problem

Let's be honest about how most third-party risk management (TPRM) actually works:

1. You send a 200-question security questionnaire to a vendor

2. Someone on their side — often not even in security — fills it out

3. Your GRC team scores it against a rubric

4. The vendor gets a "risk rating" that lives in a spreadsheet until next year's review

You're not measuring their security posture. You're measuring their ability to fill out forms.

A vendor can answer "yes" to every control question on Tuesday and get breached on Wednesday. The questionnaire tells you nothing about the dynamic state of their environment. It's a point-in-time photograph of a self-reported narrative.

What a Vendor Trust Score Actually Requires

A meaningful Vendor Trust Score (VTS) needs to be continuous, observable, and falsifiable. Here's the framework:

1. Evidence Freshness Index

For every critical control a vendor claims to have, ask: when was the last independent evidence of it operating?

Not "when did they last attest to it." When was it last observed.

• SOC 2 report from 11 months ago? That's stale evidence.

• Real-time shared dashboard of uptime and incident response metrics? That's fresh evidence.

Score each control on evidence age. Anything over 90 days without fresh evidence gets a decay multiplier.

2. Incident Transparency Ratio

How many security incidents has the vendor disclosed in the last 12 months versus how many you'd statistically expect given their size and industry?

• Zero disclosed incidents from a 5,000-person SaaS company isn't a green flag. It's a red one. Either they're not detecting, or they're not disclosing.

• The honest vendors — the ones you should actually trust more — will have incident reports. Transparency is signal. Silence is noise.

3. Dependency Chain Depth

Your vendor has vendors. Their vendors have vendors. How deep does your trust chain actually go?

Most TPRM programs stop at Tier 1. But the breaches that destroy companies — SolarWinds, MOVEit, Codecov — all came from Tier 2 or deeper.

If you can't see at least two levels deep into your vendor's supply chain, you don't have a trust score. You have a trust assumption.

4. Contractual Trust Alignment

Does your contract with this vendor actually reflect your trust requirements?

Check for:

• Breach notification SLAs — is it 72 hours, 24 hours, or "reasonable time"?

• Right to audit — can you actually exercise it, or is it buried in language that makes it practically impossible?

• Subprocessor transparency — are they required to disclose when they add new subprocessors who touch your data?

Most vendor contracts are optimized for procurement speed, not trust verification. The gap between what your risk team assumes and what your legal team agreed to is often enormous.

Building the Score

A vendor with a VTS below 60 isn't necessarily a vendor you drop. It's a vendor where you need compensating controls on your side — because you can't trust their environment to protect your data the way your risk register assumes it does.

The Signal

The next generation of TPRM isn't about better questionnaires. It's about continuous trust telemetry — treating vendor relationships the way you treat your own network: monitored, measured, and never assumed to be secure.

Your board doesn't need to know every vendor's SOC 2 status. They need to know: how many of our critical vendors have a Trust Score below our threshold, and what's our exposure?

That's a conversation worth having.

---

Next edition: Trust Recovery Playbooks — What the Best Incident Response Teams Do in the First 72 Hours That Nobody Teaches

— Signal & Trust

Welcome back to Signal & Trust.

Last edition, we broke down why Zero Trust is itself a trust framework. Today, we're going one level up — to the boardroom.

---

"What's Our Risk Appetite?"

If you've sat through a board meeting on cybersecurity in the last five years, you've heard this question. And you've probably watched a CISO pull up a heat map, point to some colored squares, and say something like "We're within acceptable tolerance."

Here's the problem: risk appetite is a feeling, not a metric. It's a qualitative statement dressed up as governance. And boards are making multi-million dollar resource decisions based on it.

What Boards Actually Need: Trust Decay Rate

Instead of asking "what's our risk appetite," boards should be asking: "How fast is trust degrading across our critical systems, and what's the cost of restoration?"

This is what we call Trust Decay Rate (TDR) — the measurable erosion of trust relationships across an organization's systems over time.

How to Measure It

TDR is a composite of three observable signals:

1. Credential Drift

How many privileged accounts have exceeded their last access review cycle? In most enterprises, the answer is 15-30% at any given time. Each one is a trust assumption that hasn't been validated.

2. Control Attrition

What percentage of your compensating controls are still operating as designed? Not "are they turned on" — are they effective against current threat models? Most SOCs can't answer this honestly.

3. Vendor Trust Lag

How current is your third-party risk assessment relative to your vendors' actual security posture? If you assess vendors annually but breaches happen quarterly, you're operating on stale trust data 75% of the time.

Why This Changes the Conversation

When you present TDR to a board, you're not asking them to evaluate a feeling. You're showing them:

• A number that moves — trust is degrading at X% per quarter

• A cost to restore — re-establishing trust across these systems costs $Y

• A decision framework — invest now to slow decay, or pay more later to rebuild

This is the language boards already speak. They understand depreciation. They understand maintenance costs. Trust Decay Rate translates security into capital allocation.

The Signal

Stop asking your board to define "risk appetite." Start showing them how fast trust is eroding and what it costs to maintain. The CISOs who make this shift will stop being cost centers and start being strategic advisors.

That's the real board-level metric nobody's reporting.

---

Next edition: Vendor Trust Scores — Why Your Third-Party Risk Program Is Measuring the Wrong Things

— Signal & Trust

Every org measures uptime. Compliance scores. Patch velocity.

Almost nobody measures the trust failures that actually kill companies.

Here are three I've been tracking:

1. Decision Latency Under Ambiguity

When your CISO gets conflicting signals — a vendor says they're compliant, your pentest says otherwise — how long does it take to reach a decision? Most orgs don't track this. The best ones measure it in hours. The worst discover it in post-mortems.

2. Stewardship Drift

The gap between who should own a risk and who actually does. It widens silently. By the time you notice, three teams think someone else is responsible for a critical control.

3. Trust Assumption Decay

Every third-party integration starts with a trust assumption. How often do you re-validate? Most orgs set-and-forget. The ones that don't are the ones that catch the next SolarWinds before it catches them.

I write about these patterns weekly in Signal & Trust — built for CISOs and security leaders navigating complexity without the noise.

What's the trust failure your org isn't measuring?