Why Your Audit Program is Lying to You

Ayoub Fandi is the creator of the GRC Engineering Movement and the author of the GRC Engineering Newsletter, read by over 2,300 security and compliance practitioners. He built GitLab's GRC program from scratch, taking an engineering-first approach that became the basis for the ideas he now publishes and speaks on — including a keynote slot at RSA 2026. He also built Corsair, an open-source project aimed at creating a cryptographically verifiable trust infrastructure for third-party risk. This conversation is about why the compliance function that most security organizations run today is structurally incapable of producing the risk signal it claims to produce — and what a rebuilt version looks like.

The anchor data point is stark: the standard SOC 2 audit samples 25 items from a population that can number in the thousands, then issues an attestation that reads as company-wide. That gap between sample and claim is not a bug in how auditors behave — it's inherited from financial auditing methodology developed decades before modern software delivery existed. Ayoub's argument is that this breaks the entire downstream trust chain: TPRM teams make vendor decisions on the back of it, boards hear it summarized as assurance, and nobody says the quiet part out loud. The episode is for security leaders who run or inherit a GRC function, practitioners who want to move from periodic audit cycles toward continuous assurance, and anyone evaluating whether their compliance program is actually telling them something true. 

Hampton North is the premier US based cybersecurity search firm. Start building your security team with Hampton North. 

Sysdig is the leader in AI-powered real-time cloud defense; stop watching and start defending.

The 25-sample problem did not originate in security. It comes from financial auditing, where statisticians developed sampling methodology to detect fraudulent transactions — the idea being that if you pull from enough different parts of the ledger, patterns of falsification will surface. That logic has been carried forward, largely unchanged, into SOC 2, ISO 27001, and the rest of the modern compliance stack. The number 25 is still in use because it was deemed sufficient in a different era for a different problem.

Applied to a software company's pull request history, it produces results that are close to meaningless. A codebase generating 2,400 pull requests a year gets 25 sampled. An infrastructure with tens of thousands of nodes gets a handful checked. The auditor then issues a report that says the control passed — and the company's name goes on the attestation without any disclosure of the coverage rate.

The downstream effect is that third-party risk management teams — the primary consumers of these attestations — are making vendor onboarding decisions on signals that are structurally low-assurance. A TPRM analyst reviewing a SOC 2 has no way of knowing which 25 events were reviewed, whether the weeks surrounding the audit period looked different, or whether controls that passed on the sample were inconsistently applied elsewhere. Ayoub's phrase for what happens as a result: an abuse of the trust factor. 

Ayoub's read on why CISOs have accepted this arrangement is that compliance has quietly become a sales function. SOC 2 means you can sell to mid-market. ISMAP means you can sell in Korea. IRAP means you can sell in Australia. The certification is really a market access credential, and as long as it's understood that way, the incentive to demand more rigor out of the underlying methodology is low.

The problem is that this framing bleeds into how security leaders talk about their programs — to boards, to auditors, to themselves. When the primary objective of the compliance function is to produce certs, the compliance calendar becomes the organizing structure of the entire year. Audit prep, walkthroughs, evidence collection, remediation cycles on audit findings — by the time those are mapped out, there is very little room left for anything else. Ayoub invokes Parkinson's Law: if audit is defined as the work, the team will expand every audit-related activity to fill the available time.

The alternative he argues for is treating compliance outputs as a by-product of a security program that is organized around threats. If a control appears in ISO 27001 and is also genuinely relevant to the risk posture of the company, then invest in understanding its actual effectiveness. If it is purely a checkbox with no operational meaning, treat it that way — take the screenshot, do not waste engineering cycles on it. The distinction only becomes legible when the GRC team has a clear view of which risks actually matter to the business, which requires building toward risk rather than toward the audit calendar. 

The State of GRC 2026 report found that 86% of GRC teams still run primarily on spreadsheets. For teams of five or fewer, that number reaches 100%. Ayoub's take is that the spreadsheet is not the root cause — it is a diagnostic.

A spreadsheet is a relational database without intelligence. It can hold a list of controls, a status column, a column for evidence links. It can absolutely pass an audit — auditors often receive and review evidence in spreadsheet form. The ceiling only becomes visible when you try to do something more demanding: correlate findings across control domains, track control effectiveness at runtime rather than at audit time, or surface the fact that the same identity risk is showing up simultaneously in the compliance team's control testing, the risk register, and the TPRM assessment of your identity provider. That kind of correlation requires a data model that a spreadsheet cannot represent. 

At GitLab, Ayoub built the GRC function's own internal platform from scratch, starting with the data model — asking what the data layer should look like before asking what reports it needed to produce. One thing that surfaced: the compliance sub-team, the risk sub-team, and the TPRM sub-team were all generating data about identity controls independently, with no mechanism to share or correlate it. Three separate data points that could have compounded into stronger signal were living in three separate spreadsheets. 

The hiring picture is shifting. Ayoub notes that new GRC job postings are materially more technical than they were five years ago — often asking for Python proficiency as a baseline — and that GRC leaders at large B2B SaaS companies are actively working through whether to upskill existing staff, hire through attrition, or rebuild teams from scratch with engineering-first profiles.

The trust center — a vendor's webpage listing their certifications, subprocessors, and security posture — is a marketing page. It is static, unverified in any cryptographic sense, and tells a TPRM analyst roughly what a company wants them to believe at the moment the page was last updated. Questionnaires are worse: they are self-reported, they are slow, and at scale the analyst reviewing them is doing so because the process requires it, not because the signal is high quality. 

Ayoub's open-source project Corsair is an attempt to build the layer underneath — a trust infrastructure where control evidence can be cryptographically signed, shared with granular access controls depending on the relationship, and consumed by an automated process rather than a human reviewer manually comparing a PDF against a checklist.

The mechanics currently center on integrations with open-source CSPM tools like Prowler, which run locally and generate reports that can be signed with a company's private key and published to a trust.txt page. A consuming TPRM team — or eventually, an agent running on behalf of that team — can verify the signature, inspect the control test results, and make a risk-tiered decision based on actual tool output rather than a consultant's narrative summary. 

The access control layer matters because not every vendor relationship warrants full disclosure. Ayoub's model allows companies to nest what they share: more to enterprise buyers with leverage, less to smaller parties where the trust relationship is not yet established. The legal barrier he acknowledges is real — continuous sharing of control status creates contractual exposure if something lapses — but the direction of travel is toward real-time, machine-readable trust signals rather than annual PDF artifacts.

Ayoub's prediction from the State of GRC 2026 report: spreadsheets are number one this year, but next year something like Claude Projects or Notion AI will likely function as the primary GRC platform for a meaningful share of teams. The logic is not that purpose-built GRC SaaS is going away, but that the intelligence layer — the thing that used to require either a specialized tool or a human analyst — is now available on tap through any frontier model with the right context.

What changes is not the data itself but the depth of analysis accessible to a GRC team member who is, by the nature of the function, a generalist. A GRC analyst covering identity controls, cloud infrastructure, and vendor risk simultaneously can now interrogate each domain at a depth that previously required a specialist. The breadth was always there; the depth was the constraint. LLMs invert that constraint.

For GRC SaaS vendors, the honest question is what their moat is once the intelligence layer is commoditized. Ayoub points to network effects — a platform running across a hundred thousand companies with similar risk profiles can surface benchmarks and anomalies that no single company's internal tooling can generate. That is a real defensible advantage. Pure workflow automation built on top of a model that every practitioner can now access directly is harder to defend.

For practitioners at Fortune 500 companies, Ayoub's projection is that GRC teams contract slightly in headcount, get materially more technical in composition, and start to look less like a team of auditors and more like a small product team: a compliance subject matter expert functioning like a product manager, engineers building and maintaining the control telemetry infrastructure, and someone focused on the experience of the internal stakeholders who consume GRC outputs. The auditor profile — deep Excel fluency, strong documentation instincts, trained in CPA firm methodology — becomes less central. The engineering profile becomes more so. 

Guests — Ayoub Fandi, creator of the GRC Engineering Movement; author of the GRC Engineering Newsletter (2,300+ subscribers); speaker at RSA 2026; former GRC Engineering lead at GitLab; founder of the open-source Corsair project.

 Books mentioned — None named in the conversation.

Frameworks / models / tools named — SOC 2; ISO 27001; PCI DSS; ISMAP; IRAP; Prowler (open-source CSPM); Corsair (open-source third-party risk trust infrastructure); MCP (Model Context Protocol); Datadog; Salesforce; Ramp; Stripe; Cursor; Vim; Vercel; NPM; Homebrew (Brew); Merkle Tree; IETF protocols; Microsoft Office 365 / Google Workspace; Parkinson's Law.

Other people / shows / resources referenced — Christina Cacioppo (CEO, Vanta); GRC Engineering Newsletter; State of GRC 2026 report (800+ practitioners surveyed); deathbyclaude.com.