The Compliance Fire Drill I Refuse to Run Again: Building Trent’s GRC Program With Our Own AI Security Engineer

A few months ago I wrote about becoming the first security engineer at a startup, living the interview scenario I used on more than a hundred candidates. Here now is the sequel to that story; the moment that scenario stops being about the product and starts being about the paperwork. This is the story of how I used the Trent AI Security Engineer for GRC to build Trent’s own compliance program. Why the gaps it found were more valuable than the coverage it confirmed, and how a Senior Security Director at a bank turns the same output into budget.

Two Weeks to Produce a Year of Evidence

As a senior security engineer at one of the GAFAM, I lived through the seasonal pressure of “we need evidence for this compliance framework audit IN THE NEXT TWO WEEKS.” If you only ever respond to that time-bounded pressure, you end up permanently reactive: you sprint, you assemble screenshots and exports, you survive the audit, and you swear it will be different next year.

Once you’ve been through it once, you do prepare a bit more. You plan which tools you want to use to produce evidence of which security goals. But then a second problem shows up, you end up swamped in too many frameworks and too many tools with too many overlapping capabilities. Which of your fifteen tools proves which of your four hundred controls? Does anyone actually know? Usually the answer lives in one veteran’s head, in a spreadsheet last updated two audits ago or you end up spinning a whole dedicated team just for this.

The question every security org must answer is deceptively simple: Given the compliance frameworks I’m accountable for, do I have the right tools in place to cover every required capability?

Answering it properly means reading hundreds of pages of framework documents, translating each control into the capability it implies (SAST, DAST, CSPM, PAM, and the rest of the alphabet), and then checking whether the tools you own actually deliver that capability for the tech stack you actually run. Today most orgs do this manually, or pay consultants significant fees for a mapping that still takes weeks and multiple iteration rounds. And most startups don’t do it at all; the gaps go undetected until an auditor finds them, which triggers exactly the reactive scramble I just described.

The Tables Turned, Again

When I joined Trent as the first security engineer, I knew this moment was coming for us too. A security startup selling to security teams gets asked about its own security posture early and often, and rightly so. SOC 2 questionnaires, GDPR obligations, and customer security reviews, the GRC clock starts ticking the day you sign your first enterprise-shaped prospect.

In my interview role-play, this was the surprise card I loved dropping on candidates: “The CEO calls you at 6pm and asks if we can achieve SOC2 compliance by the end of the week.” Now I’m the one taking that call. 🙂

The difference is that this time I had a tool I only wished existed during my GAFAM years. We had just extended the Trent AI Security Engineer into GRC, starting with what we call the Security Program Mapper. So I did the obvious thing; I pointed it at Trent itself.

Three Lists In, One Map Out

The design principle behind the mapper is that the user should never need to know control IDs, sections, or subsections. You supply three plain lists:

Trent reads the frameworks, extracts and de-duplicates every capability they collectively require, maps your tools onto those capabilities against your specific stack, and produces a structured matrix. Every row carries:

• Category – logical grouping (“Application Security: Build”)
• Capability – the industry-standard term auditors and vendors use (SAST, DAST, CSPM, PAM…)
• Requirement – a plain-language explanation a non-practitioner can read
• Tool(s) In Place – which of your tools cover it, given your stack, with gaps called out explicitly
• Sources – the specific frameworks and control IDs driving the requirement
• Notes – why coverage is or isn’t complete, stack caveats, recommended actions

Two example rows, so you can see the shape of it:

An LLM does roughly 95% of this work in minutes instead of the weeks it takes manually or with consultants. The remaining 5% is you: reviewing, refining, re-framing. That’s deliberate.

The tech stack is not decorative

This is the detail that separates a useful mapping from a checkbox exercise. The question is never “Do you have SAST?” It’s “Does your SAST cover Apex?” A scanner that handles your JavaScript beautifully but has never heard of the Salesforce code sitting in your revenue path is a Partial, not a Full, even though the tool is technically “in place.” I have watched exactly this class of blind spot survive multiple audit cycles at very large companies, because nobody ever cross-referenced tool coverage against the stack inventory. The mapper does that cross-reference on every single row.

Citations, or it didn’t happen

Every capability maps back to specific control IDs: PCI 6.2.3, NIST 800-53 SA-11(1), CIS 16.12. This matters for two reasons. First, credibility: vague claims like “PCI requires this” die instantly in front of an experienced auditor or a GRC lead. Second, defensibility: when you later argue for budget (more on that below), you’re not presenting abstract risk, you’re presenting a named control deficiency with a paper trail.

What Came Back When I Ran It on Trent

I fed the mapper our frameworks, our tooling, and our stack, and got back a matrix of several dozen capability rows. Reviewing it took me an afternoon. Producing the equivalent by hand, and I have done this by hand, is a multi-week project you keep deprioritizing until an auditor forces the issue.

Three observations from dogfooding:

1. The gaps are the product. Confirmation that our SCA coverage is Full is nice, but the rows marked Gap and Partial are the ones that influence my roadmap. They became my prioritized backlog, each with a framework citation attached, before any auditor asked. That’s the shift from reactive to proactive I never managed with spreadsheets; I now plan in advance what coverage we have and what we need to fill, based on our list of frameworks, tools, and tech stacks. This is the tool I wished I had to organize and prepare for compliance audits.
2. The Notes column earns its keep. A verdict without a reason is just a color on a spreadsheet. “Tool X covers three of your four stack components; component Y needs a stack-native scanner or a config change on your current license tier” is something I can act on Monday morning.
3. It’s opinionated output, not automation. A couple of verdicts I overruled, because I know deployment details the input lists didn’t capture. Good. This is directionally-correct, practitioner-grade output that a human reviews and refines, not an audit-ready attestation, and we’re explicit about that framing. The human stays in control; the machine just eliminates the weeks of framework archaeology.

From Gap Table to Budget: How a Bank Reads the Same Matrix

I build programs, and my colleague, a senior cyber security leader who works in a financial institution, funds them. When we compared notes, he described the leadership side of exactly this exercise, and it’s worth quoting his logic at length, because it shows what the mapping output becomes one level up in the org chart.

Security leaders, in his words, secure budget by translating audit-identified maturity gaps into specific, defensible control deficiencies mapped to recognized frameworks like NIST CSF or the CIS Critical Security Controls. Instead of presenting abstract risk, they quantify the operational and financial impact by showing how current control performance deviates from defined targets: vulnerability management SLAs, patch timelines, asset coverage falling outside acceptable thresholds. Exposure windows made concrete, critical vulnerabilities unpatched beyond 7 to 15 days, incomplete asset inventories, inconsistent identity, and access enforcement.

Then comes the roadmap: remediation sequenced into achievable annual increments, each phase combining control-gap closure, enabling technology, and staffing or process maturity; each investment tied to a before-and-after state with real metrics. Two of his examples include:

1. Attack surface: an internal audit shows only 68% of internet-facing assets are in vulnerability scanning, and critical vulnerabilities average 32 days to remediate against a 15-day SLA. The exposure gap is undeniable. The funding request bundles an external attack surface management capability, process improvements, and one additional analyst, with a committed outcome: 95% asset coverage and sub-14-day critical remediation within 12 months.
2. Identity: privileged access reviews show excessive standing access and inconsistent MFA across cloud workloads. That maps cleanly to CIS Control 6 and the NIST AC control family. The roadmap initiative: just-in-time access, full MFA enforcement for privileged accounts, identity governance tooling. The measurable outcome: standing privileged access dramatically reduced, elevated activity fully audit-traceable.

“This shifts the conversation from general security spend to measurable risk reduction tied to business impact.”

Notice what his method requires as raw material: a defensible map of required capabilities, current coverage, named control deficiencies, and framework citations. That is, row for row, what the Trent Security Program Mapper produces. I use the matrix to build the program; a security leader uses the same matrix to sequence the roadmap and defend the spend. Same artifact, two audiences, which is exactly why the Requirement column is written in plain language and the Sources column is written in auditor.

What This Is Not

Let me be as blunt as I was in our ClawHub analyses: an LLM-generated mapping is not a certified compliance attestation, and anyone who sells you one as such is selling you a phantom implementation. Real coverage depends on configuration, license tiers, and deployment details that no list of tool names fully captures. The mapper’s job is to compress weeks of framework reading and cross-referencing into an afternoon of expert review, and to make sure no capability silently falls through the cracks between your frameworks, your tools, and your stack.

That’s the difference between finding your gaps in July on your own schedule, and finding them in November because an auditor did.

Try It on Your Own Program

The seasonal audit fire drill is optional. If you can write down three lists, your frameworks, your tools, your stack, the Trent AI Security Engineer can hand you back the map I spent years wishing someone would hand me: every required capability, what covers it, what doesn’t, and the control IDs to prove it.

Then the two weeks before your next audit become what they should have been all along: a walk in the park. 🙂