DISC InfoSec blogA signed two-page policy beats a fifty-page draft. Every time...

Sep 08 2026

A signed two-page policy beats a fifty-page draft. Every time…

Category: AI Governance,CISO,Data Governance,Information Security,IT Governance,Security policy,vCISO — disc7 @ 9:41 am

Startups at Seed or Series A Don’t Need a CISO to Pontificate. They Still Need Governance.

A viral take says early-stage startups need operators, not CISOs. Mostly right — but three of the four things it says startups need are governance work. What actually blocks the audit and the deal.

A take went around recently that I mostly agree with, which is why I want to argue with it.

The argument: a Seed or Series A company hires a security engineer at a healthy base salary, and within two weeks they’re drafting fifty-page governance policies and pitching board decks instead of fixing IAM roles. Meanwhile the AWS permissions are still a mess and the SOC 2 is dead in the water. Startups don’t need someone pontificating about corporate risk frameworks. They need operators who lock down the cloud, automate evidence collection, get enterprise procurement off the founder’s back, and let engineering ship.

Every word of the diagnosis is correct. Role clarity is a real failure mode, and if you hired for hands-on infrastructure work and got a risk committee, that’s a mis-hire no matter how good the risk committee is.

But read that list of what startups supposedly need instead. Lock down the cloud. Automate the evidence collection. Get procurement off your back. Unblock the SOC 2.

Three of those four are governance work described in operator vocabulary.

“SOC 2 dead in the water” is almost never a cloud configuration problem

This is the load-bearing claim, so it’s worth being specific. When a SOC 2 stalls at an early-stage company, here’s what’s actually blocking it, in rough order of frequency:

Policies undocumented, or documented and never reviewed — which hits CC1, CC2 and CC5 simultaneously
No formal risk assessment process (CC3)
Access reviews never performed (CC6) — note: not access misconfigured, access reviews not performed and signed
Incident response plan never tested (CC7)
Change management applied inconsistently (CC8)
No vendor risk program — no inventory, no tiering, no due diligence (CC9)
Data classification undefined (C1)

Now look at what’s on that list that Terraform fixes. Almost nothing. Your IAM roles can be immaculate and every one of those gaps remains open.

And there’s a structural fact founders consistently learn too late: a Type 2 report tests operating effectiveness over an observation period, typically six to twelve months. You cannot compress it, you cannot backfill it, and the clock starts when the controls are actually operating — not when you decide to get serious. Evidence has to be contemporaneous, created at the time the control operated. An access review reconstructed in a panic the week before fieldwork is not evidence; it’s a document about the past.

Which means the highest-leverage early action isn’t hardening. It’s starting the clock — getting a minimal, real control set operating so the window begins, and so that six months from now you have records rather than intentions.

This is the same argument I made about ISO 42001 Stage 2, and it generalises: controls are rarely why organisations fail. Evidence is. A programme built in the eight weeks before an audit gets found out, because records have dates.

“Getting procurement off your back” is governance by definition

The second item on the operator list is the one that funds the company, so it deserves precision about what it actually involves.

An enterprise security review is not a technical assessment. It’s a document request. The questionnaire asks for your information security policy, your named security owner, your subprocessor list, your access review cadence, your incident response procedure, your business continuity test, your data retention schedule — and, in every substantive questionnaire I’ve seen since mid-2026, an AI governance block: what AI do you use, do you or your vendors train on customer data, who’s accountable for your AI systems, are you ISO 42001 certified or implementing it.

You cannot answer any of that with cloud configuration. And the answers are representations — a completed questionnaire is a contractual statement to a customer. Claiming a control you can’t evidence converts a security problem into a misrepresentation problem, which is a materially worse category to be in.

So “get procurement off my back” decodes to: produce a coherent, defensible, evidenced document set that matches what you actually do. That is governance. Calling it operations doesn’t change the work.

The real distinction: fitness, not volume

Here’s where I think the original take mistargets. Its villain looks like the CISO mindset. The actual villain is governance theatre — and the tell is not that a policy exists, it’s that the policy is unsigned, undated, unowned, and unmatched to scope.

The test I’d apply to any governance artifact at an early-stage company is the same one an auditor applies:

Does it exist?
Is it operating? — is there a record showing it ran
Who owns it? — a name, not a team
Show me a specific instance, on a date

A two-page acceptable use policy that a founder signed, dated, and circulated passes all four and unblocks a procurement question. A fifty-page policy suite in draft passes exactly one. The fifty-page version isn’t wrong because it’s governance; it’s wrong because it’s optimised for the appearance of a programme rather than for producing artifacts.

So the correct instruction to your first security hire is not “stop writing policies.” It’s: write the shortest thing that will survive question four, get it signed, and go fix the cloud.

I’d also offer a more charitable reading of the engineer in that story than the original does. Very often the person drafting policies at week two is doing it because a customer is asking, nobody else will, and no one was named accountable. That’s not pretension. That’s a missing owner, and the founder is the one who left the seat empty.

What the first security hire should actually be

The useful frame isn’t seniority. It’s build versus attest, and they’re genuinely different jobs:

	Build	Attest
Output	Working controls	Evidence that controls work
Typical week	IAM, network, CI/CD, secrets, logging pipeline	Policies, risk assessment, vendor tiering, access review records, questionnaire responses
Failure mode	Hardened environment, no audit trail	Beautiful binder, nothing implemented
Unblocks	Incidents	Deals

The overlap zone — automating evidence collection so the build work generates the attest artifacts as a by-product — is the highest-value thing either role does, and it’s where the two disciplines actually meet. Access reviews that emit signed records. Change management that produces approval trails. Logging designed so it answers who authorised this, what did the system have, what did it decide, was that consistent with policy rather than requiring reconstruction.

At Seed and Series A, the pragmatic answer is usually: hire the builder full-time, buy the attest work fractionally. A strong infrastructure security engineer is a full-time job at that stage. Producing a defensible ISMS or AIMS is not — it’s a burst of work followed by a maintenance cadence, and it doesn’t need a full-time salary attached.

I should disclose the obvious: fractional governance is what my practice sells, so treat that recommendation with appropriate suspicion. The honest test of whether you need it: if you can already answer the four questions above for the controls a customer is asking about, you don’t. Go hire the builder and spend nothing on me.

The AI turn, where “just build” stops working

Here’s the part of the original argument that I think dates fastest, and it’s why this matters more in 2026 than it did in 2022.

The advice “operators build, governance pontificates” assumes governance decisions are made in documents. With AI systems, they’re made in architecture — usually by an engineer, at speed, without anyone recognising a governance decision has been taken. Four examples from earlier posts in this series:

Where the human sits relative to execution. Whether the system informs a human decision or makes it. That single design choice determines whether California’s ADMT rules apply — advisory tools are excluded provided there’s genuine human involvement in the final decision — and whether you can satisfy EU AI Act Article 14. It looks like a UX decision in the sprint.
Agent authority. An agent shipped with a broad tool and a standing service account has been granted ambient authority nobody approved. Authority must be bound to a specific action, not held generally by a component. That’s a code decision with liability attached.
Whether the logs will answer the audit. Agent action volume makes evidence architecture impractical to retrofit. If the decision log doesn’t record the policy version in force, no amount of later governance work recovers it.
What the model provider’s terms actually say about training on your customers’ data — which becomes your representation the moment you answer a questionnaire.

None of these get fixed by a policy written afterwards. All of them are cheap to get right at design time and expensive to unwind. So the modern version of the operator argument has to be: the builder needs enough governance literacy to recognise which of their design choices are governance choices — and someone accountable to check.

That’s not pontification. It’s the difference between an AI feature you can sell into an enterprise and one you have to re-architect after the security review.

A 90-day plan for a Seed / Series A first hire

Inventory first. Systems, data, vendors, and — the one most people skip — AI systems and agents, including embedded vendor AI and anything in CI. You can’t scope, tier, or answer a questionnaire without it.
Fix the two things that would actually hurt you. Usually identity and secrets. Time-boxed, not a programme.
Write the short policy set and get it signed. Information security, acceptable use, access control, incident response, AI acceptable use. Two to four pages each. Signed and dated beats comprehensive and draft, every time.
Name owners. One person per policy area. In a twenty-person company this is a fifteen-minute conversation that resolves a recurring audit finding.
Start the clock. Run the first access review, log it. Run one incident tabletop, log it. These are the records the Type 2 window will sample.
Automate evidence at the point of work — reviews, approvals, and deployments that emit artifacts without anyone assembling them later.
Build the questionnaire answer library from what’s now true, and re-read anything you answered before your architecture changed.

Note the sequencing. Nothing in there is a board deck, and nothing in there is a fifty-page policy. But five of the seven are governance, and they’re what closes the deal that funds the next engineering hire.

Where I’d land

The original take is right that a Seed-stage company doesn’t need someone theorising about enterprise risk frameworks. It’s wrong that the alternative is pure engineering, because it lists governance outcomes as the goal — evidence automation, procurement unblocked, SOC 2 moving — and then argues against the discipline that produces them.

The dichotomy that actually matters isn’t operator versus CISO. It’s artifacts that survive question four versus artifacts that don’t. Someone has to produce the first kind. At twenty people that person probably shouldn’t be full-time, and definitely shouldn’t be presenting to a board you don’t have yet.

Work with DISC InfoSec

DISC InfoSec provides exactly the fractional half of that split for B2B SaaS and financial services startups — SOC 2 and ISO 27001 readiness, ISO 42001 AI management systems, AI and agent inventories, vendor questionnaire response, evidence architecture, and internal audit. No board decks unless you ask for one.

We led VDR organization through ISO 42001 Stage 2 certification on the first audit attempt as the internal practitioner, served as internal auditor, and authored their MCP Governance Standard.

Readiness path: free 15–20 minute readiness call → ISO 42001 gap assessment or ISO 27001 gap assessment → 7–10 day Quick-Start → full implementation and certification support.

DiscInfoSec — Principal Consultant, DISC InfoSec (Deura Information Security Consulting LLC), Petaluma, AICP, CISSP, CISM | ISO/IEC 42001 & ISO/IEC 27001 Lead Implementer | PECB Authorized Training Partner

📅 calendly.com/hd-deurainfosec 📧 info@deurainfosec.com 📞 (707) 998-5164 🌐 deurainfosec.com

References

AICPA Trust Services Criteria — CC1–CC9, plus Availability, Confidentiality, Processing Integrity and Privacy categories; SOC 2 Type 1 vs Type 2 report scope
ISO/IEC 27001:2022; ISO/IEC 42001:2023
Regulation (EU) 2024/1689 (EU AI Act), Arts. 14, 26
CPPA ADMT regulations under CCPA/CPRA — advisory-tool scope exclusion
OWASP Agentic Security Initiative; OWASP AI Agent Security Cheat Sheet

Nothing here is legal advice, and formal SOC 2 opinions require a licensed CPA firm.

Startup security hiring seed series, SOC 2 blocked, first security hire, fractional CISO, vendor security questionnaire, ISO 42001 startup, AI governance startup

Download the AI Governance & Cybersecurity pdf file

AI Attack Surface ScoreCard

MachineLearning & Artificial Intelligence

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative