Jordan: You build automations that handle ten thousand dollars a month in client revenue. You've got Make scenarios processing Stripe webhooks, n8n workflows routing support tickets, Zapier Zaps syncing CRMs — production systems, real money, real data. Enterprise-grade work.
And then a mid-market prospect sends you a vendor security questionnaire. Two hundred and sixty-one questions. CAIQ four-point-oh-three. They want to know your encryption policy, your subprocessor list, your incident response plan, your data retention schedule, your AI training opt-out status. And you're sitting there in your home office thinking... I don't have a security page. I don't have a DPA. I don't have a subprocessor list. I have a Notion workspace with fourteen hundred workflows and zero public-facing evidence that I take any of this seriously.
That was me. November. A forty-thousand-dollar annual contract — recurring, not project — sitting on the other side of a procurement review I couldn't pass. Not because my security was bad. My security was fine. MFA everywhere, secrets in a vault, least-privilege access, encrypted backups. The controls existed. But the artifacts didn't. I had nothing to hand a reviewer. No page to link. No document to sign. Just... me, on a call, saying "trust me, I do all that stuff."
They went with a four-person agency. The agency had a trust center page. I checked it after — it was thinner than what I actually do. But it existed. And mine didn't.
Jordan: If you're selling automation services to anyone bigger than a ten-person startup and you don't have a public trust surface — a security page, a subprocessor register, a signable DPA — you are losing deals you never hear about. Not deals that go to a competitor after a shootout. Deals that die in procurement before your champion can even make the case. The buyer's security team Googles your company, finds nothing, and flags you as unvetted. That's the end. No call. No rejection email. Just silence.
Today I'm building the entire trust surface that prevents that — a one-page Notion Trust Center, a living subprocessor list, a plain-language Data Processing Addendum, a canonical data-flow diagram, and a Make scenario that automates DPA signature and storage. One weekend. Zero legal fees if you already have counsel on retainer. And every artifact is reusable across every prospect from here on out.
Jordan: So let me back up and explain what you're actually facing when a buyer sends you one of these questionnaires. Because the volume of what they ask is part of the problem — and it's also the key to solving it efficiently.
The three questionnaire frameworks you'll see most often are the CAIQ — that's the Consensus Assessments Initiative Questionnaire from the Cloud Security Alliance — the SIG from Shared Assessments, and anything mapped to the SOC 2 Trust Services Criteria. The CAIQ version four-point-oh-three has two hundred and sixty-one questions. The SIG comes in two sizes — SIG Lite at a hundred and twenty-eight questions, SIG Core at six hundred and twenty-seven. And then Google maintains an open-source set called VSAQ with four modules: web application security, security and privacy program, infrastructure, and physical slash datacenter.
Sounds like a nightmare, right? Two hundred and sixty-one questions minimum. But here's what I realized after I actually sat down and mapped the overlap — they're all asking the same eight to ten things. Access control. Encryption. Incident response. Data location. Subprocessors. Privacy and DPA status. Business continuity. And now — increasingly — AI and LLM data handling. The frameworks organize these differently, they use different numbering, but the substance converges. Which means if you build one page that covers those eight areas clearly, you've pre-answered the majority of what any of these questionnaires will ask.
That's the Notion Trust Center. One page. One scroll. Here's how I structured mine.
Jordan: Top of the page — company name, version number, last-updated date, and a security contact email. This matters more than you think. Reviewers scan for freshness. A page that says "last updated January twenty twenty-four" is worse than no page at all because it signals you set it up and forgot about it.
Below that, a Security Overview section. This is where you state your access control policy — SSO, MFA, least privilege, quarterly access reviews. Your encryption posture — at rest and in transit, with the specifics. AES-256 via your cloud provider, TLS one-point-two or higher. Your secrets management — where you store API keys, how often you rotate them, how production access works. Logging and monitoring — where your logs go, how long you retain them, what triggers an alert. And change management — git-based, CI/CD with required review, emergency change procedure.
Now — I want to be honest about something. If you're a solo operator, some of these controls are simpler than they sound. Your "access control policy" might be: I'm the only person with access, I use MFA on everything, and I review my own access quarterly. That's fine. Write it down. The point is not to pretend you're a fifty-person security team. The point is to document what you actually do, clearly, so a reviewer can see it and check the box.
Next section — Data Location and Retention. Primary region, failover region if you have one, backup frequency, retention periods, and your RPO and RTO targets. If you don't know those acronyms — Recovery Point Objective is how much data you can afford to lose, Recovery Time Objective is how long you can be down. For most solo automation shops, honest numbers here are something like RPO of twenty-four hours, RTO of forty-eight hours. Don't over-promise. Write what's real.
Then Incident Response and Business Continuity. How you detect incidents, how fast you notify — the standard is seventy-two hours for material incidents — and your continuity plan. Can you operate in a reduced mode? For how long? When did you last test recovery?
Jordan: This is the section that didn't exist two years ago and now shows up in almost every questionnaire I receive. AI and LLM data handling. Buyers want to know three things. Which AI providers are you using? Is their data being used to train models? And how long are prompts and outputs retained?
Here's what I write — and you can adapt this nearly word for word. "When AI is used, prompts and outputs are processed via" — and then name your provider — "API with Zero Data Retention. Personally identifying fields are masked before transmission, and outputs are stored in our system under the client's workspace."
That sentence does a lot of work. It names the provider. It confirms Zero Data Retention — which OpenAI calls ZDR, and it's a real setting you can enable on their API. It confirms you're masking PII before it hits the model. And it tells the reviewer where outputs live.
If you want an external governance reference to point to, ISO/IEC 42001 is the first global standard for AI management systems. You don't need to be certified. But you can say "we align our AI governance practices with ISO/IEC 42001" and link to it. That gives a reviewer something to anchor on.
The EDPB — the European Data Protection Board — actually published a harmonized DPIA template on April fourteenth of this year. It's open for consultation through June ninth. Why does that matter to you? Because the section headings in that template are becoming the de facto structure that privacy reviewers expect to see. Reed Smith, the law firm, called it a milestone toward consistent GDPR practice. If your Trust Center mirrors those section headings — data processing details, categories of data subjects, retention, transfer mechanisms — you're speaking the reviewer's language before they even open the questionnaire.
Jordan: Below the Trust Center, you need a living subprocessor list. Not a static paragraph — a Notion database. Columns for vendor name, purpose, whether they touch customer data, data categories, region, transfer mechanism, DPA link, security page link, last reviewed date, and status.
Here's an example row. PandaDoc — purpose: e-signature. Customer data: yes. Data categories: contact, content, metadata. Region: US and EU. Transfer mechanism: Standard Contractual Clauses, twenty twenty-one slash nine fourteen. Status: active.
And here's the copy-safe answer you can paste into any questionnaire that asks about subprocessors: "We maintain a live subprocessor register listing each vendor, purpose, data categories, region, and change history. Customers are notified of material changes at least thirty days in advance."
That's one sentence. And it answers about fifteen questions across the CAIQ and SIG. Because the question isn't really "who are your subprocessors" — the question is "do you have a system for tracking and communicating changes to your subprocessors." The register is the system. The sentence is the proof.
Notion themselves publish a subprocessor list in exactly this format. Zapier's DPA incorporates their subprocessor list by reference. You're not inventing a pattern here — you're copying what the tools you already use are doing.
Jordan: The last visual artifact is a canonical data-flow diagram. One diagram that shows how client data moves through your stack. Client submits via form or email. Intake system receives it. Make scenario processes it. PII gets masked before it hits the AI provider. Documents get created in PandaDoc. Signed PDFs get stored in Google Drive. Records get written to Notion.
Notion doesn't render Mermaid diagrams natively, so you'll need to export this as a PNG from whatever diagramming tool you use and embed the image. Under the diagram, list your data categories — contact data, content, metadata — with the purpose and retention period for each. That's your data-flow section done.
Jordan: Now — the DPA. The Data Processing Addendum. This is where I need to say something clearly: I am not a lawyer. What I'm about to walk through is a starter template. You need counsel to review it before you send it to a client. Do not skip that step.
With that said — the structure of a DPA is not mysterious. It covers subject matter and duration, roles and instructions — you're the processor, they're the controller — confidentiality, security measures, subprocessors, data subject rights, incident notification, return and deletion, international transfers, and audit rights. The IAPP — the International Association of Privacy Professionals — publishes a sample DPA structure that you can adapt. The EU Standard Contractual Clauses from twenty twenty-one slash nine fourteen handle the international transfer piece.
What I did is take that structure, write it in plain language — not legalese — and turn it into a PandaDoc template with fill-in fields. Client name, effective date, company name, notice email. Variables that auto-populate when the scenario fires.
And that's where the automation comes in. Here's the Make scenario.
Trigger — a new row appears in my Client Ops database in Notion with the status "DPA: Send." That kicks off the scenario. First module: a throttle. This is important — PandaDoc's sandbox API limits you to ten requests per minute per endpoint. Production limits aren't publicly documented with exact numbers, so I stay conservative. Six calls per minute max.
Second module: PandaDoc creates the document from my template, populating the variables. Third module: PandaDoc sends it to the client's email for signature. Fourth: I upsert the document context — doc ID, client name, an idempotency key — into a Make data store. That prevents duplicate sends if the scenario retries.
Oh — and this is a gotcha I hit. PandaDoc sets an X-Frame-Options header to SAMEORIGIN on their app URLs. Which means if you try to embed a live PandaDoc document inside Notion using an iframe or Notion's embed block, it will fail. You'll get a "failed to load" error. Don't waste an hour debugging that like I did. Instead — link to the PandaDoc document, or wait for the signed PDF and embed that using Notion's PDF block.
So — the client signs. PandaDoc fires a webhook on document completion. PandaDoc retries failed webhook deliveries three times with exponential backoff, which is solid. Make catches the webhook — and Make can handle up to three hundred incoming webhook requests per ten-second interval, so you're not going to hit a bottleneck there unless you're somehow sending hundreds of DPAs simultaneously.
The scenario downloads the signed PDF, uploads it to a specific Google Drive folder — organized by client name — and then updates the Notion Client Ops row with the status "Signed," the Drive link, the PandaDoc doc ID, and the timestamp. Optionally, it appends a line to a changelog: "DPA signed by client name on date."
Total modules in the scenario: nine. Total time to set up once you have the PandaDoc template ready: roughly forty-five minutes. And from that point forward, every new client DPA is triggered by changing a status field in Notion. No email drafting. No attachment hunting. No "did they sign it yet" follow-ups.
Jordan: Now — I'd be lying if I told you this solves everything. It doesn't. And I want to be direct about the limits.
Some enterprises will still require a SOC 2 Type II report. Some will require a completed CAIQ or full SIG Core — all six hundred and twenty-seven questions. Some will want a pen test report from a third-party firm. A Notion page does not replace those things. If a Fortune 500 company's procurement team needs SOC 2 Type II, you either get the audit done or you walk away from that deal.
And there's a real risk with publishing a trust center that over-promises. If you claim you do quarterly access reviews and you don't actually do them, that page becomes a liability, not an asset. The changelog exists for a reason — it forces you to version your claims. When you change a subprocessor, you log it. When you update a control, you log it. The page stays honest because the changelog makes drift visible.
But here's what the Trust Center does do. It eliminates the first round of email ping-pong. Instead of a procurement analyst sending you fourteen questions by email and waiting three days for answers, they open your trust center, see that you've addressed their core concerns, and either check the box or send you a shorter, more targeted follow-up. For deals under a hundred thousand dollars — which is most of what solo operators are closing — that's often enough. The trust center is your first-response evidence shelf. It's not the whole case. It's the thing that gets you past the initial screen so you can make the case.
And for the AI questions specifically — name your providers, state your training and retention settings, link to their data policies. Concrete answers beat boilerplate every time. A reviewer who sees "we use OpenAI API with Zero Data Retention enabled, prompts are retained in our systems for seven days for support, provider-side retention is zero days" — that reviewer moves on. A reviewer who sees "we take data security seriously" — that reviewer sends you twelve follow-up questions.
Jordan: That forty-thousand-dollar deal I lost in November — the one where the four-person agency won because they had a trust center and I didn't? I went back and looked at their page again last month. Security overview, subprocessor list, a DPA link, a data-flow diagram. Four sections. One Notion page. That's what beat me. Not a SOC 2 audit. Not a hundred-page compliance binder. A single page that said "we thought about this and here's the evidence."
What I built after that — the trust center, the register, the DPA flow — took me a weekend. And it's been reused on every prospect since. Seven deals. Seven times I've sent a link instead of answering fourteen questions by email. Two of those deals closed in under a week because procurement had nothing left to ask.
So here's what I want you to do this week. Not all of it — just the trust center page. Open Notion, create the page, fill in the sections with what you actually do today. Don't aspirate. Don't write what you plan to do next quarter. Write what's true right now. Publish it. Link it in your proposal template. That one page changes how procurement sees you — from "unvetted solo operator" to "vendor with a documented security posture." Everything else — the subprocessor database, the DPA automation, the data-flow diagram — you can layer in over the next two weekends.
The Notion template, the DPA starter, and the Make scenario are all on the Resources page. Copy them, customize them, and get counsel to review the DPA before you send it. Not legal advice — a starting point.
I'm Jordan. This is Headcount Zero. Go ship your trust surface.