From AI Policy to Proof: The 6 Pieces of Evidence Buyers Accept

There’s a moment in almost every AI security review now that I’ve come to recognize. The startup sends its AI policy. It’s a good one. It says the company doesn’t train on customer data, that a person reviews high-impact outputs, that the models are tested for misuse and monitored for drift. The reviewer reads it, writes a polite thank-you, and adds one line at the bottom.

“Could you share the evidence for these?”

That line is where a lot of deals go quiet. Not because the startup was lying. Usually every sentence in the policy was meant sincerely. But a policy describes what you intend, and the reviewer’s job is to find out what happens. Those are different documents, and only one of them was attached.

Justin Kavalir, an attorney and certified public accountant who founded the Judgment Assurance Institute, put the problem in the title of an essay at the end of the summer: “A Policy Is Not Evidence.” His point is that the statements in an AI policy “are assertions, but they are only the beginning of governance,” and that the real test is a single question: “If asked tomorrow to prove it, what would there be to produce?” (Corporate Compliance Insights)

The buyer’s side of that question is more human than founders expect. Rune Kvist, who runs the Artificial Intelligence Underwriting Company, said on the Latent Space podcast in September that there’s little confusion about what the big AI risks are, and a lot of demand for something else: the specific evidence to ask for. As he put it, a risk leader at a big bank wants to know, “What can you ask for without sounding stupid?” Reviewers often know something is missing before they know what to request. The founder who arrives with the right evidence spares them that awkwardness, and sets the terms of the review in the process.

So this post is about the evidence. My brother Jon and I help founders get through these reviews, and in our experience six pieces of evidence answer almost every AI question a buyer asks: a map of your AI, provider terms that match your settings, an independent test, an attestation with AI in scope, records that show the controls running, and a rehearsal with a name on it. For each one I’ll explain why buyers accept it, what it looks like at a twenty-person company, how fresh it has to be, and what to send while it’s still in progress. At the end there’s a builder that turns your AI policy into an evidence pack, line by line.

The short answer

An AI policy is a promise. Enterprise buyers accept proof, and in practice they accept six kinds:

1. A map of your AI. An inventory of every AI feature and internal AI use, with an AI bill of materials and data flows: which models and versions, from which providers, in which regions, touching which data, kept for how long.
2. Provider terms that match your settings. The contract language about training and retention, for you and for each model provider, together with the settings and screenshots that keep it true.
3. An independent test of the AI features. A dated report from someone outside your company who tried to break them, with the scope, the method, the findings, the fix dates and a retest.
4. An attestation with AI in scope. A SOC 2 report, an ISO/IEC 42001 certificate, an AIUC-1 certificate or a HITRUST AI assessment whose scope sentence actually names your AI.
5. Operating records. Logs, approval records, evaluation results and change notices from the last few months, which show the controls running rather than written down.
6. A rehearsal with a name on it. A dated incident drill in which you stopped an agent or rolled back a model, and the named person who owns the response.

Each one is specific, current and checkable, which is why it works where a policy doesn’t. You don’t need all six on day one. A dated “not yet” with an owner, for the ones still in progress, is something buyers accept every week.

Why a policy stopped being enough

Two years ago, an AI policy was a sign that a startup had thought about the subject. Now everyone has one, many of them drafted with the help of the same AI tools they govern, and reviewers have read enough of them to know they mostly say the same things. A document that’s cheap to write is weak evidence of anything except the ability to write it.

Three things in 2026 turned that intuition into a standard expectation.

Paper got caught. In March, an anonymous investigation alleged that Delve, a compliance automation startup, had produced near-identical SOC 2 reports for hundreds of customers. Delve denies fabricating evidence, and Jon covered how to check a report and its auditor in Is Your SOC 2 Real?, so I won’t relitigate it. What changed afterward is that reviewers started reading past the badge. The Cloud Security Alliance, in an August research note on AI and SOC 2, described the problem precisely: “two AI companies can each hold a clean SOC 2 Type II report while having tested entirely different control sets” (Cloud Security Alliance). The same note points out that the Peer Review Board of the American Institute of Certified Public Accountants (AICPA) started directing peer reviewers to apply added scrutiny to SOC 2 practices on June 1.

The rule-writers started naming evidence. Colorado’s SB 26-189, which takes effect on January 1, 2027, requires developers of covered automated decision tools to give the companies that deploy them technical documentation about intended uses, training data categories, known limitations and human review, to tell them about material changes, and to keep compliance records for at least three years (Arent Fox Schiff). The EU AI Act’s Article 12 says “High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system” (EU AI Act). In June, the Cybersecurity and Infrastructure Security Agency (CISA) and its G7 partners published voluntary minimum elements for an AI bill of materials, and a Morgan Lewis alert summed up the practical effect: “Companies that sell or deploy AI-enabled software should expect AI SBOM requests to become more common in enterprise and government-facing transactions” (Morgan Lewis).

The auditors moved. In September the AICPA issued technical guidance on how a service organization’s use of AI affects SOC 1 and SOC 2 examinations, which in short says AI doesn’t get its own kind of examination, but AI that’s part of the services belongs in the system description (Schneider Downs). Then on October 28 it proposed new SOC 2 criteria whose “new points of focus address issues such as AI governance, model monitoring, prompt manipulation, data poisoning,” as well as the “transparency of AI-generated outputs, training data management, and the risks associated with automated decision-making.” Comments are due January 15, and if adopted the criteria apply to engagements beginning on or after December 31, 2027 (AICPA).

Under all three is something simpler, and it’s the reason I’d act on this even if none of the rules existed. Buyers are frustrated by how little they can see. In IDC’s September 2026 survey of executives, “lack of model and data transparency” was one of the top complaints about AI vendors, cited by 34 percent (IDC). Abhi Sharma, the co-founder and chief executive of Relyance AI, gave us the cleanest way to think about why on episode 70:

Listen · Episode 70 with Abhi Sharma

If trust is a product of transparency, security and value, then a startup with a great product and no visible evidence is multiplying by something close to zero. The same episode has a line about policy engines that applies just as well to policy documents: “The problem is they’re only as good as the amount of policies you write.” Evidence is what makes the policy count.

How buyers weigh evidence

It helps to know how the person reading your evidence is thinking, because it isn’t arbitrary. A security reviewer who approves you is putting their name next to yours. They need evidence they could defend to their own boss, their auditor or, on a bad day, their regulator. So they weigh it the way auditors have been taught to for decades.

The rules are written down. The auditing standard that governs public company audits in the United States, the Public Company Accounting Oversight Board’s AS 1105, lists what makes evidence reliable, and it reads like a guide to AI security reviews. “Evidence obtained from a knowledgeable source that is independent of the company is more reliable than evidence obtained only from internal company sources.” “The reliability of information generated internally by the company is increased when the company’s controls over that information are effective.” “Evidence obtained directly by the auditor is more reliable than evidence obtained indirectly.” And original documents beat copies whose reliability “depends on the controls over the conversion and maintenance of those documents” (PCAOB).

Translated for a founder:

• Independent beats self-made. A tester’s report beats your summary of it. A provider’s terms beat your description of them.
• System-made beats hand-made. An exported log beats a screenshot of a log, and a screenshot beats a sentence saying the log exists.
• Checkable beats described. If the buyer can verify it themselves, in a certificate registry, a trust center or a live demo, it counts for more.
• Original beats copied. Send the report, not a slide about the report.

Buyers add two tests auditors care about less. The first is scope: does this evidence cover the thing I’m actually buying? The second is freshness: is it about the model you run today? One of the first comments under Anthropic’s ISO/IEC 42001 announcement on Hacker News asked exactly that:

"Noob question: do they need to re-certify for each new model release?"

qxfys, commenting on Anthropic achieves ISO 42001 certification for responsible AI, January 2025

A few comments later, another reader asked the question every buyer asks about every badge:

"Don't they need to show some proofs that their model indeed "responsible"? Why not everyone can get that certificate?"

transformi, commenting on Anthropic achieves ISO 42001 certification for responsible AI, January 2025

The honest answers are “no, the certificate covers the management system, not each model,” and “the proof is in the audit report, the tests and the records behind the badge.” That’s why no single piece of evidence carries a review on its own, and why the six pieces below work as a set.

Dirk Meister, a founding engineer at Augment Code when we recorded, described the principle behind all of it in a sentence I keep coming back to. He was talking about customer-managed encryption keys on episode 77:

Listen · Episode 77 with Dirk Meister

Good evidence works the same way. It gives the buyer the ability to not take your word for it.

1. A map of your AI

What it is. A dated inventory of every place AI touches your product and your company, with enough detail that someone outside could draw the data flow. For each AI feature: the model and version, the provider and region, the data categories it sees, how long anything is retained and where, whether anything is used for training, and who owns it. Add your internal AI use too: the coding assistants, meeting notetakers and support tools your team uses with customer data. The machine-readable version is an AI bill of materials, and CISA’s June guidance groups its minimum elements into seven clusters: metadata, system-level properties, models, datasets, infrastructure, security properties and key performance indicators (Morgan Lewis).

Why buyers accept it. Because it’s specific and they can check it against everything else you send. A reviewer who sees “Anthropic, Claude, US region, 30-day retention, no training” in your map can compare it with your sub-processor page, your provider’s terms and your data processing agreement. A vague answer can’t be compared with anything. It’s also the first thing the rules ask for, from Colorado’s developer documentation to the EU’s technical documentation for high-risk systems. When we took Augment Code through ISO/IEC 42001, the gaps the first assessment found clustered around four things, and the first was model provenance, which is where the map starts (YSecurity case study).

What it looks like at a twenty-person company. One table, one data-flow diagram and a change log. Here’s the shape, for a made-up company:

Ged Ossman, the founder of Interf, made the case on episode 99 for going one step further and making this machine-readable: “If like vendor agents need something from enterprise, it should be specified in a machine-readable form, in a way where compliance security teams can quickly assess the risk.” The buyers who ask for an AI bill of materials in a standard format, like CycloneDX or SPDX, are still a minority. They won’t be for long.

How fresh. It has to change when the product changes: every new model, version, provider or data flow. Date every version, keep the old ones, and note when you told customers about a change, because “will you warn us before the model changes?” is one of the most common AI questions there is.

The common mistake. Listing a provider instead of a model. “We use OpenAI” tells a buyer almost nothing. Which model, which version, through which API or cloud, in which region, with which retention setting, for which feature: that’s the map.

If it isn’t done yet: “We’ll send our AI inventory and data-flow diagram by [date], and until then here’s the list of AI providers on our sub-processor page.”

2. Provider terms that match your settings

What it is. Two halves that only work together. The first half is paper: your own contract language about training on customer data, retention and AI use, and each model provider’s terms for the plan you’re actually on. The second half is the settings that keep the paper true: the retention configuration, the training opt-out, the zero-data-retention approval if you have one, the region pinning, the logging switches, and screenshots or exports that show them, dated.

Why buyers accept it. Because it closes the gap between a promise and the thing that keeps it. The notes for episode 75, our conversation with Jonathan Mortensen of Confident Security, open with three words that say it: “Contracts aren’t controls.” A contract tells the buyer what you agreed to. The setting shows them it’s being done. Send both, and the reviewer can tick the box without a follow-up call.

What it looks like. A short folder: your data processing agreement with its AI clause highlighted, each provider’s enterprise terms for your plan with the relevant sections marked, and one dated screenshot per setting, named so a reviewer can find it (“2026-10-31 provider console, data retention: zero”). If you route through a cloud provider’s AI service rather than the model maker directly, include that service’s terms and settings too, because that’s where the data actually goes.

How fresh. Quarterly, and every time you add a provider or change a plan. Providers change their defaults and their terms, and a screenshot from last year proves last year.

The common mistake. A free or personal account somewhere in the stack. It happens most with internal tools: an engineer’s personal subscription, a meeting notetaker someone installed for one call. Our episode with Michael Moore, Glean’s general counsel, has the principle in its title, How Free AI Tools Become Expensive Mistakes, and the evidence pack is where it gets caught: if you can’t produce the enterprise terms for a tool that touches customer data, the tool shouldn’t touch customer data.

If it isn’t done yet: “Our contract says we don’t train on customer data, and by [date] we’ll send each provider’s terms for our plan and the settings that enforce it.”

3. An independent test of the AI features

What it is. A dated report from someone outside your company who tried to make your AI features do what they shouldn’t: leak one customer’s data to another, follow instructions hidden in a document, take an action a user couldn’t, spend money, or reach systems it shouldn’t reach. A good report names the scope (which features and agents), the method (the OWASP Top 10 lists for large language model applications and for agentic applications, MITRE ATLAS), how many attempts were made and how they adapted, success rates by scenario, what an injected agent could actually reach, each finding with its fix date, and a retest letter.

Why buyers accept it. It’s independent, it’s about behavior rather than intent, and it answers the question underneath every AI section: what happens when someone tries? Rune Kvist said on Latent Space that “a lot of companies have not done a serious stress test,” and that startups in particular spend most of their time on how the product works in normal use. Buyers know that, which is why an independent test moves a review faster than any other single document.

What it looks like. For an AI feature inside a product, a focused test of two to three weeks is typical, with prompt injection, data separation between customers and output handling at the center. For an agent that takes actions, add the permission boundaries: what it can do on its own, with whose credentials, and whether a hostile document can make it do more. Jon wrote about what separates a test buyers trust from a PDF they file in Pentest Once a Year?, and it applies doubly to AI: the attempts, the attacker, the rates and the reach. If you hold AIUC-1, the standard builds this in, with adversarial testing of the production agent at least every quarter.

How fresh. At least once a year, and after any major change: a new model, a new agent capability, a new tool connection. For agents, quarterly is becoming normal.

The common mistake. Testing the web app and calling it an AI test. A traditional penetration test is still worth doing, but the questions the AI section asks need a tester who goes after the model’s inputs, outputs and permissions. Our AI red teaming team does exactly that, and we’d tell you so even if we didn’t.

If it isn’t done yet: “Our first independent test of the AI features is booked for [month], and we’ll share the letter and the fixes within two weeks of the retest.”

4. An attestation with AI in scope

What it is. An outside auditor’s or certifier’s report on the system around your AI. The common ones:

• A SOC 2 Type 2 report whose system description includes your AI components. The AICPA’s September guidance says AI that’s part of the services should be described there. Ask your auditor which AI components and controls are in scope, and get them named.
• An ISO/IEC 42001 certificate for your AI management system, from an accredited certification body, with a scope statement that covers the product the buyer is buying and a Statement of Applicability showing which controls you apply.
• An AIUC-1 certificate for AI agents. AIUC-1 has 51 requirements across data and privacy, security, safety, reliability, accountability and society; certification pairs an independent audit with adversarial technical tests of the production agent, repeated quarterly, and a certificate lasts 12 months (ElevenLabs).
• A HITRUST AI security assessment, which health systems increasingly recognize, or the Cloud Security Alliance’s STAR for AI, launched in October 2025 around its AI Controls Matrix of 247 control objectives.

Why buyers accept it. It’s independent, it covers the management system that keeps everything else true, and it’s checkable: a buyer can look up a certificate or read the auditor’s opinion. Scott Dietzen, Augment Code’s chief executive at the time and now a board member, said on episode 74 the thing I’d want every founder to hear before they chase a badge: “I see the certifications as recognition of work that’s been going on for a very long time.” The certificate is the receipt. The work is what the buyer is really buying.

When we ran Augment Code’s ISO/IEC 42001 program, that’s how it went. The week-one gap assessment cross-walked the existing SOC 2 controls and found nine major and ten minor gaps, clustered around model provenance, bias stress testing, adversarial exercises and human-in-the-loop checkpoints. The certificate came on day 93, and the case study records a seven-figure enterprise deal closing within days of certification and weekly security-review calls dropping from six to two (YSecurity case study). Notice that the gaps are the other five pieces of this post. The attestation was the receipt for building them.

Not everyone agrees on which badge matters, and you should know that before you pick one. AIUC-1 is a good example. Its supporters point to insurance:

Our agents - and their actions - can now be insured. Backed by AIUC-1 certification, we’re the first company to secure insurance for AI voice agents.

ElevenLabs (@ElevenLabs) · February 18, 2026

And it has sharp critics:

Everyone involved in this should be embarrassed. AIUC-1, a compliance standard for AI agent security, is a massive grift. Everyone who isn't on AIUC's cap table should oppose this.

Zack Korman (@ZackKorman) · April 13, 2026

My view is the practical one. Pick the attestation your buyers ask for, read its scope sentence before you pay for it, and never let it stand alone. ISO’s own explainer is a good ten minutes if ISO/IEC 42001 is new to you:

How fresh. Annually, with a bridge letter between reports if a buyer’s timeline falls in the gap. ISO/IEC 42001 certificates have surveillance audits in between.

The common mistake. An attestation whose scope quietly leaves out the AI, often by treating the model providers as carved-out subservice organizations without describing the controls you run over them. The buyer will read that paragraph. Read it first. Our ISO 42001 and SOC 2 teams spend a surprising amount of time on that one sentence.

If it isn’t done yet: “Our SOC 2 Type 2 audit period runs through [date] with our AI features named in scope, and here’s the auditor’s engagement letter.” Jon’s post on SOC 2 in progress has more sentences like that one.

5. Operating records: logs, approvals and evaluations

What it is. The evidence that your controls ran last month, not just that they exist. For an AI product that usually means four things:

• Action logs. For each AI action, who asked, which model and version ran, what tools it called, what it touched and the outcome. The Cloud Security Alliance note lists “per-inference logging that captures model version, a redacted prompt or prompt hash, tool calls, and outcome” among the evidence auditors already request informally.
• Approval records. If your policy says a person approves certain actions, the record of each approval: who, when, what they approved.
• Evaluation results over time. If you claim to monitor accuracy, safety, bias or drift, the results of your evaluation runs across model versions, with the thresholds you set and what happened when one was missed.
• Change notices. The record of telling customers about model and provider changes, which is your map’s change log made visible.

Why buyers accept it. System-generated records are high on the ladder, and they’re the only evidence that shows time. Kavalir’s essay names this capability “Record,” and makes the point sharply: a general policy or protocol isn’t evidence that it was followed. And it’s what regulation is converging on: the EU AI Act’s logging duty for high-risk systems, Colorado’s three-year recordkeeping.

Kayne McGladrey, then field chief information security officer at Hyperproof, put a name to what this piece prevents when he talked with Jon about public companies’ cybersecurity disclosures on episode 56: “the thing you don’t want to get caught out in is running a paper tiger where it works that way on paper, but it doesn’t actually exist in reality.” An AI policy without records is the same animal, and his fix carries over word for word: “You need to prove that you’re actually collecting evidence on an hourly or a daily basis associated with the control operation.”

What it looks like. A redacted sample from the last thirty days, a one-page field list for your logs with the retention period and export options, a chart of your evaluation results across the last three model versions, and the approval records for one week. You don’t send the whole database. You show that it exists, that it’s complete and that you can produce more on request.

Daniel Marashlian, co-founder and chief technology officer of Drata, described the work of producing records like these honestly on episode 64:

Listen · Episode 64 with Daniel Marashlian

He’s right, and it’s the best argument for setting this up once and letting it run. The logs your engineers need for debugging are most of the logs a buyer wants to see. Add the model version and the tool calls, keep them somewhere the application can’t edit, and the evidence collects itself.

How fresh. Continuous, with a sample from the last month ready to share.

The common mistake. Logging prompts and responses in full, with customer data in them, and then having to explain that to the same buyer. Log the metadata and a hash or redacted version, and say so.

If it isn’t done yet: “We log every AI action internally today, and by [date] we’ll be able to export a redacted sample and give your admins access to their own logs.”

6. A rehearsal with a name on it

What it is. Two things that belong together: an AI incident plan that’s been practiced, and the named person who owns it. The plan covers the AI scenarios that matter for your product: a prompt injection that leaks data, one customer’s data showing up in another’s output, an agent that takes an action nobody approved, a model update that makes outputs worse, a runaway bill. The rehearsal is a dated record of a tabletop or game day where you actually did the hard parts: stopped the agent and timed it, rolled back the model, drafted the customer notice.

Why buyers accept it. It answers the question a reviewer is too polite to ask: when something goes wrong at two in the morning, will anyone at this company know what to do? A dated drill is direct evidence. A name is accountability. Kavalir calls these “Own” and “Guard,” and Jon wrote a whole post on the “Own” part, Who Signs for the Agent?, because buyers increasingly ask for a person, not a team.

What it looks like. A two-page plan with the AI scenarios, a one-page record of the last drill (date, scenario, who attended, how long it took to stop the agent, what you changed afterward), and a line naming the owner, a backup and how a customer reaches them. If you’ve never run a drill, run one this month. It takes an afternoon, and it’s the cheapest evidence on this list.

How fresh. At least twice a year, and after any real incident.

The common mistake. A plan nobody has opened since it was written, with an owner who left. The rehearsal is what keeps both true.

If it isn’t done yet: “Our AI incident plan names [name] as owner, and we’ll run our first drill by [date] and send you the record.”

From policy line to proof

Here’s the part that ties it together. Take your AI policy and, for every sentence in it, name the evidence that proves it. Most policies use the same dozen lines, and each one maps to one or two of the six pieces:

When you do this exercise, two things happen. You find the lines that have no evidence behind them yet, and you can either build the evidence or soften the line until it’s true. And you end up with an index: one page that lists each claim, the evidence that proves it, the date of that evidence and who owns it. That index is the single most useful document you can send a reviewer, because it answers their unasked question before they ask it.

Build your evidence pack

Pick what you sell and who’s buying, tick the lines your AI policy actually contains, and set the honest status of each piece of evidence. The builder shows which claims are proven, which rest on stale evidence and which have nothing behind them yet, then writes the pack index with the artifacts to attach and the dated not-yet line for anything still in progress.

Interactive · 10 minutes · Runs in your browser

The AI evidence pack builder

Start with the context, then the policy lines, then the evidence. Everything updates as you go.

What your AI policy says

The builder needs JavaScript. The twelve policy lines and the evidence for each are in the table above.

The evidence you have today

Load an example startup Start over

…where you stand

…policy lines with current proof

…evidence pieces current

…lines with no proof yet

Copy the pack index Download (.md) Download (.csv) Print

Everything here runs in your browser and is saved only in this browser. The freshness windows reflect what buyers ask for in our experience and in the standards cited above. Send only what's true for your company, and replace every bracket before you send it.

Have an operator review your pack →

We get your email, the context you picked and the status of each policy line and evidence piece, never your company details. Jon or I reply to set up a review of your real pack. No sequence.

How to send it

The evidence does most of the work. How you send it does the rest.

Lead with the index. One page: each claim, the evidence, its date, its owner. Then the six pieces behind it. A reviewer who can see the whole shape in a minute reads the rest with goodwill.

Put it where buyers already look. A trust center with your current evidence, gated behind a simple request or a nondisclosure agreement for the sensitive pieces, saves you from rebuilding the pack for every buyer and shows that it’s kept current. Sensitive doesn’t mean secret: the map and the attestation can usually be shared under a nondisclosure agreement; the raw logs and the full test report usually go to the buyer’s security team on request.

Be transparent about what’s missing. Ged Ossman’s formula from episode 99 is the best advice I know about how to present an incomplete pack:

Listen · Episode 99 with Ged Ossman

A dated “not yet” is transparency. A vague “yes” is self-interest, and reviewers can feel the difference. In my experience, buyers accept open items with dates and owners from vendors of every size. What costs deals is evidence that turns out to say less than the answer it was attached to.

Keep it alive. Put the freshness dates on a calendar. When the map changes, tell the customers who received the old one. That one habit answers the most common follow-up question in AI reviews before anyone asks it.

Connect it to the rest of your review. The same principle runs through the people side of security. Jon wrote this week about hiring as an attack surface, and the evidence there has the same shape: identity verified before credentials, recorded, owned and refreshed. If you’re still writing the answers themselves, start with The 10 AI Security Questions Your First Enterprise Buyer Will Ask in 2027, where each one-sentence answer lists what to attach, and if the request came as a due diligence questionnaire rather than a security one, What Is a DDQ? explains the difference.

What it costs a startup

Less than founders fear, and more than a policy. Here’s the honest range from our work with startups, assuming one person who owns it and a few hours a week from engineering:

• The map: a day to build, an hour per change to keep current.
• The provider paper trail: a week of collecting terms and screenshots, then an hour a quarter.
• The independent test: two to three weeks for a focused AI test, plus the time to fix and retest.
• The attestation: months, which is why the dated not-yet matters so much. Augment Code went from gap assessment to an ISO/IEC 42001 certificate in 93 days, and that was a team that had already done the hard engineering.
• The records: a week of engineering to log the right fields and make them exportable, then they collect themselves.
• The rehearsal: an afternoon, twice a year.

That’s a quarter of steady work, not a year, and most of it compounds: the map, the records and the rehearsal make every later review and every attestation cheaper. If you’d rather not do it alone, it’s what our sales support team does with founders every week, and startups can claim their first 8 hours free.

We’re taking this subject to MicroConf US in Austin next April, where YSecurity is a sponsor and our talk is “How Founders Turn Security Commitments Into Revenue.” It’s on our events page, along with field notes from the stages and booths we’ve been at this year.

An AI policy was never the problem. It’s the right first page. It just can’t be the only page. The founders who move fastest through these reviews don’t have better policies than everyone else. They have the evidence behind each line, dated, owned and easy to check, and a reviewer who can approve them without taking anyone’s word for it.

Sasha