How to Make Security a Selling Point: SOC 2, Trust Pages and AI Data-Use Answers

1. Blog
2. Demand & Channels

By Saroj Jha · October 4, 2026 · 16 min read

Write down where buyers’ data goes and whether it trains any model, publish that on a dated trust page, start a SOC 2 audit only when a real deal needs one and the controls already run, answer questionnaires from one reviewed library, and claim only what you can show.

The email usually arrives after the good call. A prospect likes your demo, then their security team sends a spreadsheet of questions, and the deal waits until you answer it. If your product sends their data to a language model, one question gets sharper: will our data be used to train it?

Most startups meet this moment unprepared. There is no trust page, no written answer on model training, no one who owns the spreadsheet, and sometimes a line in a sales deck about being “enterprise-grade secure” that nobody can back up. Security is engineering work. Selling it is a writing job, and the writing can start long before an audit. A data-use page, a trust page and an answer library will carry most reviews. One overstated sentence can lose the deal.

Below are five steps, in the order you build them, each followed by one thing to do this week. It is orientation and AAJ’s judgement, not legal or security advice, and not a guarantee of results. It does not cover sector law such as HIPAA, and it does not teach you to pass an audit. If your product touches regulated data, get counsel involved early.

Running case: Example Co. Fictional

Example Co. is a fictional AI assistant for support teams. It reads incoming support tickets, sends the ticket text to a language model run by an outside provider, and returns a suggested reply. It has eight people and no security hire. It is a different fictional company from the Example Co. in the developer marketing post. Example Co., its pages and every detail about it are illustrative.

Figure 1 shows a typical path. Your buyer may ask in a different order or skip a step, and the steps below follow the order you build things, not the order of the asks.

Step 1: Answer the three data questions first

Before a buyer reads anything else, they want three answers. Where does our data go? Is it used to train a model? Who can see it? If you can answer those in one page, the rest of the review gets easier, because you have shown you know your own system.

Example Co.’s one-line description already answers the first question: ticket text goes to an outside model provider. That is the catch for any AI startup: Example Co.’s promise about training can be no broader than its provider’s terms and its own contract with that provider.

So start by checking what your provider says, for the plan you actually use. Two examples, checked again on October 14, 2026: Anthropic’s privacy page^[4] (dated August 18, 2026) says inputs and outputs from its commercial products are not used to train its models by default, with feedback a user chooses to send, or data a customer opts to share, as the exceptions. OpenAI’s business data page^[5] says its business products and API platform do not use inputs or outputs for training by default, with an explicit opt-in. Both are vendor pages and both can change. One trap: these defaults cover business and API plans, and a consumer plan may differ. Date what you found and keep a copy.

Then check your own product, because the provider is only one of the places data can go. Do you log ticket text? Do your own thumbs-up and thumbs-down buttons send ticket text to a set your team uses to improve prompts? Do you use customer data to evaluate or fine-tune anything? Any “yes” belongs in the answer. The most common way to get this wrong is a flat “we never train on your data” that is true of the provider and untrue of your own logging.

Write the answer as a short page a buyer can forward. For Example Co., it would read like this (all details illustrative):

example.com/data-use Fictional

How Example Co. handles your data

• What data does Example Co. process? The text of support tickets that a customer connects.
• 1 Where does it go? To one language model provider, through that provider’s business API, and to our own database, hosted in [region].
• 2 Is it used to train models? Ticket text is not used to train the provider’s models under the terms of our agreement. We do not train our own models on it. Feedback buttons store the rating only, not the ticket text. [Edit this line to match what is true.]
• How long do we keep it? [30] days, then deleted. The provider’s retention is set out in its terms: [link].
• 3 Who can see it? [Role-based access, named staff roles.] Our staff can read ticket text only after a customer opens a support request, and that access is logged.

1 2 3 The three questions buyers ask first. Replace bracketed text with what is true.

Add a list of subprocessors, which are the outside companies that process your customers’ data on your behalf: the model provider, your cloud host, your help-desk integration and any logging service. Buyers ask for it because every name on it is one more place their data can go. Figure 2 shows the same flow for Example Co.; draw yours the same way, and the page writes itself.

When the data flow fits in one picture, the one-page answer is easy to write and easy to keep true. When it does not, that is a finding too.

Example Co., step 1 Fictional

The founders write the five-line page above, list two subprocessors (the model provider and the cloud host) and discover that their own feedback button has been storing ticket text alongside the rating. They change it to store the rating only, and the page stays true.

Do this

Write the five-line data-use page for your product, date it, and have your engineer confirm every line against a setting or a contract.

Step 2: Build a trust page

A trust page, sometimes called a trust center, is a public page where you publish your security and privacy facts. It does one job: it lets a buyer’s security team answer their first questions without waiting for you. A prospect who finds a clear page before the call arrives with fewer questions, and the questions that remain are the real ones.

You do not need special software. A single page on your own site works, and a page that is honest and dated beats a polished one with gaps. Figure 3 shows what Example Co. would put on it. Each block answers one buyer question, and only one needs a request.

Three choices matter more than the layout.

Publish only what you can stand behind. Every block should be something a person on your team can explain and show. If your encryption story is not clear to you, do not borrow words like “bank-grade” for it. Leave the block out until it is true and specific. Step 5 gives the wording rule in full.

Put the data-use answer from step 1 near the top. For an AI product, it is the block buyers look for first. Link it from your pricing page and from the signup flow too. A trial user who is evaluating you for their company is running a small security review of their own.

Gate what needs a confidentiality agreement, and say how to ask. Policies and audit reports are usually shared on request, under a confidentiality agreement; check the terms of any audit you commission. The page should say what you will send, who to write to, and how long you take to reply. Make the reply time one you can keep, which is the subject of step 4.

Put a “last updated” date at the top and change it only when something changes, and give the page one named owner so it does not drift after the first week.

Example Co., step 2 Fictional

The founders publish a single page on their own site with the seven blocks in Figure 3. The certifications block reads “None yet. Our model provider publishes its own reports; see the subprocessor list.” The page names a mailbox and a five-working-day reply time for document requests.

Do this

Publish the seven blocks you can fill today, leave out the ones you cannot, date the page and name its owner.

Step 3: Decide whether you need SOC 2 yet

SOC 2 is the question I am asked most, so start with what it is. The AICPA^[1], the professional body of US accountants that publishes the standard, describes SOC 2 as an examination of controls at a service organization that are relevant to security, availability, processing integrity, confidentiality or privacy. A CPA firm carries out the examination and writes a report. That is why I avoid the phrase “SOC 2 certified”: what exists is an auditor’s report on your controls, with a scope and a date or a period, not a certificate that you hold.

Three details change how you talk about it. First, the five areas are the menu, and a report can cover some of them. Always say which. Second, the use of a SOC 2 report is generally restricted^[6], while a SOC 3 report covers the same areas in less detail and can be freely distributed^[7]. That is why the full report sits behind a request in Figure 3. Third, there are two types: a Type 1 gives an opinion on the design of your controls as of a date, and a Type 2 adds whether they operated effectively throughout a period^[6]. Ask the buyer which type they expect before you commit.

If a buyer asks for ISO/IEC 27001 instead, that is a certificate, from an accredited certification body^[8], and since October 31, 2025 it must follow the 2022 edition^[2]. Figure 4 compares the four kinds of report.

Now the decision. I would not start an audit because a competitor has one, or because a template says startups should. I would start when a real deal needs it and the controls behind it are already running. Figure 5 turns that into three questions.

The second question matters most and gets skipped most. An auditor examines controls that exist: who can get into production, how changes are approved, how you review vendors, how you remove access when someone leaves. If those live in people’s heads, the first job is to write them down and run them, and the audit comes after.

I will not quote a cost, a timeline or a share of deals that ask for a report. The figures in circulation come from companies that sell compliance software, and your scope sets the price. Ask two or three auditors for quotes, what your scope and period would need to be, and how they tailor the work to you. In May 2026 the AICPA warned peer reviewers about SOC 2 engagements with identical reports, risk assessments, sample sizes and testing procedures, which are not performed in accordance with professional standards^[10].

Until the answer is yes, you still have plenty to offer: the data-use answer, the trust page, the subprocessor list, written policies you follow, and complete answers to the questionnaire. If your model provider publishes its own reports, you can say so. OpenAI’s business data page^[5], for example, says it aligns with the SOC 2 Type 2 Trust Services Criteria and points to a trust portal for verification; check the portal for scope and date. Be clear about whose report it is. Your buyer is asking about you, and a provider’s report covers the provider. “Our model provider publishes SOC 2 documentation, which we have checked; we do not hold a report yet, and here is what we do instead” is a strong sentence, but only if you have read the provider’s own page first.

Example Co., step 3 Fictional

A prospect’s procurement team asks for a SOC 2 report. The founders ask whether the deal is blocked without one, and the answer, in writing, is no: a completed questionnaire and the trust page will do for this year. They write down their access, change and offboarding controls anyway, so that the next time the answer is yes they are ready to start.

Do this

Answer the three questions in Figure 5 in writing. If any answer is no, write down what you will send the buyer instead and when you will revisit.

Step 4: Run questionnaires as a pipeline

A security questionnaire is a long spreadsheet or portal form that a buyer’s team asks you to complete. Some are standard, such as the Cloud Security Alliance’s CAIQ, a yes-or-no questionnaire on cloud security controls^[11]; you can complete it once and publish it free in CSA’s public STAR Registry^[3]. The first one is painful. By the tenth, most of it should be reuse, if you built the pipeline after the first. The goal is that every question is answered once, by the person who knows, and reused after that.

The heart of it is an answer library: one shared document where each approved answer has a short text, a link to the evidence behind it, an owner and a review date. AAJ’s Security Questionnaire Answer Library is that document as a free workbook, with the request log, subprocessor list and change log beside it. Example Co.’s library might start like this (all entries illustrative):

The evidence column does the work. If you cannot name a document, setting or record that proves an answer, it is not ready for the library.

Figure 6 shows the pipeline around it: log the request and its due date, match each question to the library, and send the gaps to the person who knows, usually an engineer. A different person then checks every claim against the evidence before you send it on time and add the new answers to the library.

Three rules keep it fast and true.

One owner for the process, another for the truth. In an early-stage company the founder or a marketer can own the process: the log, the deadline, the library. The engineer owns whether an answer is true. Sales should not answer security questions from memory in an email, and a simple rule that all of them go through the log prevents most of the damage.

Set a reply time you can keep. It is the same habit as a lead-response agreement: a named owner, a time limit, and someone who checks it. Publish the time on the trust page and measure yourself against it.

Say no when the answer is no. If you do not do something, say so, and say what you do instead or when you plan to. A “no, not yet, planned for [date]” is fair only if the plan is real. A yes you cannot prove can cost you the deal and the relationship.

Example Co., step 4 Fictional

The first questionnaire has 180 questions and takes the founders two weeks. They start the library with every answer they wrote, each with its evidence and owner. About two thirds of the second questionnaire, from a different buyer, comes straight from the library, and the new answers go into the library the same day it is sent.

Do this

Download the Security Questionnaire Answer Library and fill five rows, one per question you have already been asked, each with its evidence and its owner.

Free template

Start the answer library after your first questionnaire

The free Security Questionnaire Answer Library keeps the request log, one approved answer per question with its evidence and owner, the subprocessor list and a change log, with Example Co. filled in.

Step 5: Keep every claim true

Everything above fails if one sentence is wrong. Buyers read security claims closely. A buyer’s team may compare your page to your questionnaire, the questionnaire to the contract, and the contract to what your engineer says on a call. A mismatch can cost more than the missing feature would have.

I use one rule: say only what you can show, at the level you can show it. The table below sets out wording by the evidence you hold. The examples use Example Co. and are illustrative, not legal text.

Three habits support the table.

Make the paper match the page. What you promise on the trust page, in the questionnaire and in the contract has to be the same, and Figure 7 shows the check. If sales promises more in an email than the contract gives, the contract is what counts, and the buyer will notice the difference.

Do not change data practices quietly. In February 2024, staff in the US Federal Trade Commission’s Office of Technology and Division of Privacy and Identity Protection warned in a blog post^[12] that it may be unfair or deceptive for a company to adopt more permissive data practices and tell its customers only through a surreptitious, retroactive change to its terms. The post is aimed at AI companies, but it says any firm that reneges on its privacy commitments risks running afoul of the law. If you ever want to use customer data in a way your page rules out, such as training, do not edit the page and hope. Tell customers first, get the agreement your contract requires, and ask a lawyer how.

Keep a change log. Add a short dated note each time your answer to any of the three data questions changes: a new subprocessor, a new retention period, a new provider. It takes a minute, it feeds the “last updated” date on the trust page, and it gives you something to point to when a buyer asks what changed since last quarter. For customers covered by the GDPR, adding a subprocessor needs their written authorization and, under a general authorization, advance notice so they can object^[13],[14].

Example Co., step 5 Fictional

Before a contract review, the founders put the trust page, the questionnaire answers and the draft contract side by side. The questionnaire says data is kept for 30 days; the contract draft says 90. They fix the contract, add a line to the change log, and the review passes without a question.

Do this

Once a quarter, read your trust page, your questionnaire library and your standard contract together and fix every place they disagree.

What changes by stage?

• Pre-seed — The data-use page and the subprocessor list, written by the founder and checked by whoever runs production. Nothing else yet.
• Seed — A trust page on your own site, an answer library after the first questionnaire, and written access, change and offboarding controls you actually run.
• Series A and B — The audit decision in step 3, a named owner for security requests, and a quarterly check that the page, the library and the contract agree. Larger buyers run the approval path the ABM playbook describes; build the material before the first big deal needs it.

What mistakes should I avoid?

• Writing “SOC 2 certified” or “compliant” anywhere.
• A trust page that nobody dates or owns.
• Letting sales answer security questions from memory in an email.
• A “we never train on your data” line that is true of the provider and untrue of your own logs.
• Describing your provider’s audit report as if it were yours.
• Starting an audit before the controls exist.
• Changing a data practice and updating the page afterwards, quietly.

Example Co. is a fictional company. Its pages, answers and details are illustrative. This post is orientation, not legal or security advice.