A compliance consultant I was talking to about AEGIS flipped through the threat brief I showed her, set it down, and said "this is nice, but it’s not evidence." That was a useful afternoon. This is what I learned.
The first version of the AEGIS report was a threat brief. A weekly PDF with new KEVs, noteworthy breaches, a coverage snapshot, and some recommendations. It was pretty. I was proud of it. I was convinced it was a selling point.
Then I ran it past a SOC 2 and HIPAA consultant who looks at these things all day, and she spent maybe two minutes on it before she explained, kindly, that I had built a newsletter and labeled it a report.
What she meant
Compliance frameworks don’t ask for "a threat intelligence report." They ask for evidence of three things, and it took me a while to hear them correctly:
One — that you know which threats apply to this specific organization. Not global headlines. Not "here’s what we saw in the wild this week." The actual environment being audited: its sector, its vendor stack, its geography. The auditor wants to see that your threat awareness is calibrated to the org, not copy-pasted across a client list.
Two — that every claim traces back to an authoritative source. "Elevated risk in healthcare" is an opinion. "CISA advisory AA24-xxx names ALPHV/BlackCat targeting healthcare via Exchange, technique T1190, see attached mapping" is a citation. Opinions don’t pass controls. Citations do.
Three — that awareness actually drove action, and you can show the action. This one is where most briefs (including mine, originally) fall apart. Awareness without documented response is, in the auditor’s read, almost worse than no awareness — because it suggests you knew the problem and didn’t act.
When she put it like that, I went home and tore up the report format.
Why generic briefs exist anyway
This format exists because it’s cheap to produce. One analyst writes the newsletter, it blasts to every client, the effort is amortized. The content is technically correct. It feels like you’re delivering value. And if no one is auditing the auditor, nobody notices that the same report is going to a healthcare client and an industrial client.
I’m not blaming anyone. When I tried to write a truly client-specific version by hand for a hypothetical AEGIS MSSP managing 10 clients, I calculated it would consume roughly a full work week per cycle. That’s not sustainable without tooling. So generic newsletters it is, and then people are surprised when an audit gets flagged.
What I rewrote
The AEGIS report now has four sections, in this order:
Environment snapshot. Sector, deployed tools, relevant regulatory frameworks, pulled straight from the tenant’s profile. This is the "specific to this org" proof.
Threats applicable to this environment. Only threats that match the tenant’s sector and tool stack. Each one cites its source — CISA KEV, MITRE Groups, vendor advisory, or a named news report from an authoritative outlet. If I can’t cite it, it doesn’t go in.
Coverage and gaps. For each threat, a mapping to MITRE technique IDs and whether the tenant’s stack covers those techniques. This is the "what’s our posture against this specific thing" part, not a hand-wavy "we have good EDR."
Actions and status. For every gap or KEV in scope: what the action was, who it’s assigned to, and its current state — in-flight, remediated inside deadline, or accepted with a documented justification. This is the part auditors actually read first. I had it last in v1, which was a mistake.
What I’m still figuring out
Different frameworks want different evidence formats. SOC 2’s appetite for narrative evidence is very different from CMMC’s appetite for structured artifacts, which is different again from HIPAA’s comfort with mid-technical writeups. The report today has a framework selector that tweaks the emphasis and the terminology, but it’s rough. Beta users are pointing out the edges, and I keep patching.
I also haven’t cracked how to handle negative findings elegantly. If a KEV matched the tenant’s stack and was remediated before the CISA deadline, that’s a positive. But if a KEV matched and the tenant intentionally did not remediate because the system is isolated on an air-gapped network, that’s also fine — it just needs a risk-acceptance artifact stapled to it. Right now that’s a checkbox plus a 500-character text field. It’s under-designed and I know it.
Why I’m writing this
Two reasons. One, if you’re an MSSP selling into regulated sectors, your generic threat brief is probably costing you retention conversations you don’t know about, and I want to save you the afternoon I had. Two, if you’re a compliance consultant and you’ve seen threat reports done really well, I want to learn from your examples.
I can’t replicate my early-Ritchy afternoon for everyone, but I can offer the next best thing: request beta access and I’ll walk you through the current report against your actual environment. If the format looks wrong for your framework, tell me and I’ll probably ship a fix within a few days.
Written while building AEGIS. Subscribe below for the next one.