Do we need SOC 2 or ISO 27001 before the first enterprise deal?

A startup usually does not need a SOC 2 report or an ISO 27001 certificate before its first enterprise deal. Most enterprise buyers send a security questionnaire first and ask for a report or a certificate later, often as a contract condition with a deadline. The questionnaire is answered from the policies, so the policies come first either way.

Can one document cover all eight policies a SaaS startup needs first?

One document can cover all eight policies a SaaS startup needs first, as long as each policy is a separate section with its own owner, control statements and revision history. Questionnaires and auditors ask for the documents by name, and a single file with eight clearly labelled parts answers that. One undifferentiated document does not.

What does an auditor look for in a policy?

An auditor looks for three things: that the policy exists and has been approved, that it names an owner and a control for each requirement, and that there is a record showing the control is followed. The document supplies the first two. The third is your operation, and the policy should say which record proves it.

Does a startup with twenty people need a records of processing register?

The small-organisation exemption in GDPR Article 30(5) rarely covers a SaaS startup, even one with twenty people. It exempts organisations employing fewer than 250 persons, but not where the processing is likely to result in a risk to people's rights and freedoms, is not occasional, or includes special categories of data or data on criminal convictions and offences. A SaaS product that processes customer data continuously will rarely qualify, and enterprise procurement teams ask for the register regardless.

When does a SaaS startup need an AI governance policy?

A SaaS startup needs an AI governance policy when the product uses a model to produce, rank, recommend or decide something a customer or their users see, or when staff use AI tools on customer data. Many enterprise questionnaires now carry an AI section that asks for the policy by name, and buyers in the EU ask whether the product is high-risk under Article 6 of the EU AI Act, Regulation (EU) 2024/1689.

Which policies does a SaaS startup need before its first enterprise deal?

Written by PolicyDrafters. Published 4 October 2026, updated 8 November 2026.

A SaaS startup needs eight policies before its first enterprise deal: information security, access control, acceptable use, incident response, business continuity and backup, vendor management, data retention and a privacy notice. Each answers a section of the buyer's security questionnaire and maps to ISO/IEC 27001:2022 Annex A and SOC 2. Where the product uses AI, add AI governance.

Why does the order matter?

The first enterprise deal arrives with a document attached. It is a security questionnaire, sent by the buyer's procurement or security team. An enterprise security questionnaire is a buyer's list of the controls a vendor must show before its product is allowed to hold the buyer's data.

The questionnaire asks much the same questions whoever sends it, because most questionnaires cover the same ground as two sources: ISO/IEC 27001:2022 Annex A [1] and the AICPA's SOC 2 Trust Services Criteria [2].

The order below is the order a typical questionnaire follows. A SOC 2 or ISO 27001 auditor later asks for the same documents, so a startup that writes them in this sequence meets each question with a document already written.

Each policy below does the same three jobs. It states the rule, it names the owner, and it says which record proves the rule is kept. A questionnaire reviewer reads for the first two and an auditor samples the third; a policy with only the first is a statement of intent, and reviewers can tell within a paragraph.

Why does the information security policy come first?

The questionnaire opens by asking whether you have an information security policy, who approved it, and when it was last reviewed. ISO/IEC 27001:2022 asks for exactly this in clause 5.2 and again in Annex A control 5.1, which calls for a set of topic-specific policies approved by management, published, and reviewed at planned intervals [1]. SOC 2 reaches the same document through its common criteria on communication, CC2.2 and CC2.3, which expect internal and external communication of security objectives and responsibilities.

An information security policy is the short, management-approved document that states the organisation's commitment to protecting information and from which every other security policy derives. It sets out the scope of systems and data it covers, the roles that own security and the review cycle. It is the parent of the rest of the set, and it is usually signed by the chief executive so that the commitment visibly comes from the top.

What does the access control policy say?

The second block of questions is about who can reach what. How is access requested and approved, how are privileges separated, is multi-factor authentication enforced, and how quickly is access removed when someone leaves? Annex A controls 5.15 to 5.18 cover access control, identity management, authentication information and access rights, and 8.2 covers privileged access rights. SOC 2 puts the same questions under CC6.1 to CC6.3, which are the criteria a startup most often has to write from scratch, because they describe a joiner, mover and leaver process that has been running informally in a chat channel [2].

The access control policy states who grants access, on what basis, how privileged accounts are separated and reviewed, and the deadline for revoking access at offboarding. The record it names is the access review: a periodic list of accounts, checked and signed. Reviewers ask for the last one.

Who is the acceptable use policy written for?

The questionnaire then asks what staff are allowed to do with company systems and customer data: which devices, which cloud tools, what may be shared, what must be encrypted. Annex A 5.10 calls for rules on acceptable use of information and other associated assets, 6.2 ties the rules to terms and conditions of employment, and 8.1 covers user endpoint devices. SOC 2 touches the same ground in CC6.7 and CC6.8 on restricting the movement of data and preventing unauthorised software.

The acceptable use policy is the one document every member of staff signs, so it is written for them rather than for the auditor: what they may install, what they may not, where customer data may be stored, and what happens on loss of a laptop. Its record is the signed acknowledgement, and the reviewer will ask what proportion of staff have signed it.

What does the incident response procedure set?

Every questionnaire has an incident section, and enterprise buyers read it closely because their own contracts pass notification deadlines down to vendors. The questions are concrete: who declares an incident, who is told and by when, what is recorded, how customers are notified. Annex A 5.24 to 5.28 cover incident management planning, assessment, response, learning and evidence, and 6.8 covers event reporting by staff. SOC 2 asks under CC7.2 to CC7.5, which run from detection through containment to post-incident review.

The incident response procedure is the first document in the set that is a procedure rather than a policy, because what the reviewer wants is the steps. It names the roles, the severity levels, the notification clock for each, the evidence to preserve, and who signs the post-incident review. Most security policy sets fall apart here, because the procedure was written for a team of three and nobody has updated the names.

What does the business continuity and backup policy set?

The next block asks how the service survives an outage: backup frequency, restore testing, recovery time and recovery point objectives, redundancy across regions. Annex A 5.29 and 5.30 cover information security during disruption and ICT readiness for business continuity, 8.13 covers information backup and 8.14 redundancy. SOC 2's availability criteria A1.2 and A1.3 ask for recovery infrastructure, backups and the testing of recovery plans, and CC7.5 asks how incidents are recovered from.

The business continuity and backup policy states what is backed up, how often, where, how restores are tested, and the recovery targets the organisation commits to. The record is the restore test log. A buyer who is relying on your product will want to see that a restore has been run, not only that backups are taken.

What does the vendor management policy cover?

Enterprise buyers know that their data will sit in your sub-processors, so the questionnaire asks for the list, how each vendor was assessed, and what the contracts say. Annex A 5.19 to 5.22 cover supplier relationships, from the policy through the agreements to monitoring and change. SOC 2 asks under CC9.2, which expects risks from vendors and business partners to be assessed and managed.

The vendor management policy sets the tiers of vendor, the due diligence each tier gets, the contract terms required, and the review cycle. Its record is the vendor register, with the assessment date against each name. For a SaaS startup the register doubles as the sub-processor list the privacy notice refers to.

What does the data retention policy contain?

The questionnaire's data section asks how long customer data is kept, how it is deleted on termination, and how deletion is proved. Annex A 5.33 covers protection of records, 5.34 covers privacy and protection of personal data, and 8.10 covers information deletion. SOC 2's confidentiality criteria C1.1 and C1.2 ask how confidential information is identified, retained and disposed of. For personal data, Article 5(1)(e) of the GDPR, Regulation (EU) 2016/679, states the storage limitation principle directly: personal data is kept no longer than the purpose requires [3].

The data retention policy carries a schedule: each category of data, the period it is kept, the trigger that starts the clock and the method of deletion. The record is the deletion log. Reviewers compare the schedule with the privacy notice and the contract's termination clause, and look for the three to agree.

Who asks to see the privacy notice?

A SaaS startup's privacy notice is the public document the buyer's legal team asks to see. That team usually brings its own questions:

where personal data is processed
under what lawful basis
which transfers leave the jurisdiction
whether the records of processing exist

The notice is drafted against the information duties in GDPR Articles 13 and 14 [4]. For Californian users, it is also drafted against the notice at collection that the CCPA requires in California Civil Code section 1798.100(a) [5].

Behind it sits the register that GDPR Article 30 requires each controller and processor to keep. It lists the purposes of processing, the categories of data and recipients, transfers and retention periods [6].

Article 30(5) exempts organisations employing fewer than 250 persons. The exemption does not apply where the processing is likely to result in a risk, is not occasional, or includes special categories of data or Article 10 data on criminal convictions and offences. A SaaS product processing customer data every day rarely fits the exemption.

A privacy policy pack covers both faces of the question. It contains the notice the public reads, and the internal data protection policy and request procedure that staff follow when a deletion or access request arrives, with the Article 30 register as a template.

When is AI governance the ninth policy?

Many questionnaires now carry an AI section, and it is asked whenever the product uses a model to generate, rank, recommend or decide something a user sees, or whenever staff use AI tools on customer data. The questions are: do you have an AI policy, which systems are in scope, who is responsible, how is human oversight arranged, and is the system high-risk under Article 6 of the EU AI Act, Regulation (EU) 2024/1689 [7].

ISO/IEC 42001:2023 supplies the management system structure most buyers expect [8], and the NIST AI Risk Management Framework (AI RMF 1.0, released in January 2023) supplies the vocabulary US buyers use [9].

An AI governance suite is the set of documents that answers this section: a governance policy, a risk management procedure, an acceptable use policy for AI, a system inventory, a human oversight procedure, an incident and complaint procedure, and a technical documentation template. For a startup whose product does not use AI, the section is answered with a sentence and the suite can wait.

Who asks for each policy?

The table maps each of the nine documents to the people who ask for it and the evidence they look for. Control numbers refer to ISO/IEC 27001:2022 Annex A and the 2017 SOC 2 Trust Services Criteria.

Scroll sideways for the other columns

Policy	Who asks for it	What they look for
Information security policy	Questionnaire, ISO/IEC 27001 clause 5.2 and Annex A 5.1, SOC 2 CC2.2 and CC2.3	Approval from the top, scope, owners, review cycle
Access control policy	Questionnaire, SOC 2 CC6.1 to CC6.3, Annex A 5.15 to 5.18 and 8.2	Joiner, mover and leaver steps; the last access review
Acceptable use policy	Questionnaire, Annex A 5.10, 6.2 and 8.1, SOC 2 CC6.7 and CC6.8	Rules staff can follow; signed acknowledgements
Incident response procedure	Questionnaire, SOC 2 CC7.2 to CC7.5, Annex A 5.24 to 5.28 and 6.8	Roles, severity levels, notification clock, post-incident review
Business continuity and backup policy	Questionnaire, SOC 2 A1.2 and A1.3, Annex A 5.29, 5.30, 8.13 and 8.14	Recovery targets; the last restore test
Vendor management policy	Questionnaire, SOC 2 CC9.2, Annex A 5.19 to 5.22	Vendor register with assessment dates; contract terms
Data retention policy	Questionnaire, SOC 2 C1.1 and C1.2, Annex A 5.33 and 8.10, GDPR Article 5(1)(e)	Retention schedule; deletion log; consistency with the notice
Privacy notice and Article 30 register	Buyer's legal team, GDPR Articles 13, 14 and 30, California Civil Code section 1798.100(a)	Lawful bases, recipients, transfers, retention, rights
AI governance policy	Questionnaire AI section, EU AI Act Article 6, ISO/IEC 42001:2023	System inventory, classification, human oversight, incident route

Which questionnaire sections ask for each policy?

The questionnaire arrives in one of a few shapes.

The Cloud Security Alliance publishes the CAIQ, a set of yes or no questions for documenting the security controls of IaaS, PaaS and SaaS services. Version 4.1 is combined with the Cloud Controls Matrix [10], whose 17 control domains give the CAIQ its sections [11].
Google published the Vendor Security Assessment Questionnaire (VSAQ) as open-source templates, among them a security and privacy programmes questionnaire and an infrastructure questionnaire. The repository was archived in November 2022 and the templates remain public [12].
Many enterprise buyers send their own spreadsheet instead, which usually asks the same questions in its own order.

The table shows where each of the eight policies is asked for in the two published formats: the CAIQ by Cloud Controls Matrix domain, and the VSAQ by template and section. A customer's own spreadsheet can be read the same way, by finding the section that asks about each control.

Where the CAIQ and the VSAQ ask for each of the eight policies
Policy	CAIQ v4.1 (Cloud Controls Matrix domain)	VSAQ (template and section)
Information security policy	GRC, Governance, Risk Management and Compliance	Security and privacy programmes: Security Controls, and Security and Privacy Policies
Access control policy	IAM, Identity and Access Management	Security and privacy programmes: Security and Privacy Policies, and Personnel Security; Infrastructure: Administrative Access
Acceptable use policy	HRS, Human Resources Security, and UEM, Universal Endpoint Management	Security and privacy programmes: Security and Privacy Policies, on acceptable use of information and IT devices
Incident response procedure	SEF, Security Incident Management, E-Discovery and Cloud Forensics	Security and privacy programmes: Security and Privacy Incident Response
Business continuity and backup policy	BCR, Business Continuity Management and Operational Resilience	Infrastructure: Backups
Vendor management policy	STA, Supply Chain Management, Transparency and Accountability	Security and privacy programmes: Partner Security Program
Data retention policy	DSP, Data Security and Privacy	Security and privacy programmes: Security and Privacy Policies, on retention and destruction of data
Privacy notice	DSP, Data Security and Privacy	Security and privacy programmes: Security Controls, which asks for a link to the public privacy policy

Where the CAIQ and the VSAQ ask for each of the eight policies

Information security policy: CAIQ v4.1 (Cloud Controls Matrix domain)GRC, Governance, Risk Management and Compliance; VSAQ (template and section)Security and privacy programmes: Security Controls, and Security and Privacy Policies

Access control policy: CAIQ v4.1 (Cloud Controls Matrix domain)IAM, Identity and Access Management; VSAQ (template and section)Security and privacy programmes: Security and Privacy Policies, and Personnel Security; Infrastructure: Administrative Access

Acceptable use policy: CAIQ v4.1 (Cloud Controls Matrix domain)HRS, Human Resources Security, and UEM, Universal Endpoint Management; VSAQ (template and section)Security and privacy programmes: Security and Privacy Policies, on acceptable use of information and IT devices

Incident response procedure: CAIQ v4.1 (Cloud Controls Matrix domain)SEF, Security Incident Management, E-Discovery and Cloud Forensics; VSAQ (template and section)Security and privacy programmes: Security and Privacy Incident Response

Business continuity and backup policy: CAIQ v4.1 (Cloud Controls Matrix domain)BCR, Business Continuity Management and Operational Resilience; VSAQ (template and section)Infrastructure: Backups

Vendor management policy: CAIQ v4.1 (Cloud Controls Matrix domain)STA, Supply Chain Management, Transparency and Accountability; VSAQ (template and section)Security and privacy programmes: Partner Security Program

Data retention policy: CAIQ v4.1 (Cloud Controls Matrix domain)DSP, Data Security and Privacy; VSAQ (template and section)Security and privacy programmes: Security and Privacy Policies, on retention and destruction of data

Privacy notice: CAIQ v4.1 (Cloud Controls Matrix domain)DSP, Data Security and Privacy; VSAQ (template and section)Security and privacy programmes: Security Controls, which asks for a link to the public privacy policy

A policy gives an answer something to point at; it does not make the answer true. Each answer should describe the controls your organisation actually runs and the evidence it actually holds, and a reviewer who reads "yes" will often ask for the record behind it. The guide to what to do when a customer sends a security questionnaire covers the response itself: the first day, answering honestly, what to say where a control is not yet in place, and the difference between a policy and the evidence of it.

What should a startup do with the list?

Write the policies in this order and stop when the questionnaire stops. The first six are the policy layer a security reviewer reads. An information security policy set drafts all six against Annex A and the SOC 2 criteria, with a control table in each document that lists the questions it answers.

The privacy notice and the register come from the privacy pack. The AI section, where it applies, comes from the governance suite.

Each is drafted from an intake, reviewed by our legal team and delivered in Word and PDF at a fixed price. Each is structured the way the reviewer expects to read it. Together, that is what a SaaS company with a deal waiting on the questionnaire needs: the right pages, in the right order, with a clause to point at for every question.

The documents do not make the audit pass; the audit also tests whether the controls are followed, and that part is your operation. What the documents do is put the policy, the owner and the record on the page before anyone asks.

Questions

Do we need SOC 2 or ISO 27001 before the first enterprise deal?: A startup usually does not need a SOC 2 report or an ISO 27001 certificate before its first enterprise deal. Most enterprise buyers send a security questionnaire first and ask for a report or a certificate later, often as a contract condition with a deadline. The questionnaire is answered from the policies, so the policies come first either way.
Can one document cover all eight policies a SaaS startup needs first?: One document can cover all eight policies a SaaS startup needs first, as long as each policy is a separate section with its own owner, control statements and revision history. Questionnaires and auditors ask for the documents by name, and a single file with eight clearly labelled parts answers that. One undifferentiated document does not.
What does an auditor look for in a policy?: An auditor looks for three things: that the policy exists and has been approved, that it names an owner and a control for each requirement, and that there is a record showing the control is followed. The document supplies the first two. The third is your operation, and the policy should say which record proves it.
Does a startup with twenty people need a records of processing register?: The small-organisation exemption in GDPR Article 30(5) rarely covers a SaaS startup, even one with twenty people. It exempts organisations employing fewer than 250 persons, but not where the processing is likely to result in a risk to people's rights and freedoms, is not occasional, or includes special categories of data or data on criminal convictions and offences. A SaaS product that processes customer data continuously will rarely qualify, and enterprise procurement teams ask for the register regardless.
When does a SaaS startup need an AI governance policy?: A SaaS startup needs an AI governance policy when the product uses a model to produce, rank, recommend or decide something a customer or their users see, or when staff use AI tools on customer data. Many enterprise questionnaires now carry an AI section that asks for the policy by name, and buyers in the EU ask whether the product is high-risk under Article 6 of the EU AI Act, Regulation (EU) 2024/1689.

Sources

ISO/IEC 27001:2022, Information security management systemsiso.org
AICPA, 2017 Trust Services Criteria (with revised points of focus, 2022)aicpa-cima.com
Regulation (EU) 2016/679, Article 5(1)(e)eur-lex.europa.eu
Regulation (EU) 2016/679, Articles 13 and 14eur-lex.europa.eu
California Civil Code section 1798.100(a)leginfo.legislature.ca.gov
Regulation (EU) 2016/679, Article 30eur-lex.europa.eu
Regulation (EU) 2024/1689, Article 6eur-lex.europa.eu
ISO/IEC 42001:2023, AI management systemsiso.org
NIST AI Risk Management Framework (AI RMF 1.0)nist.gov
Cloud Security Alliance, STAR Level 1: Security Questionnaire (CAIQ v4.1)cloudsecurityalliance.org
Cloud Security Alliance, Cloud Controls Matrixcloudsecurityalliance.org
google/vsaq on GitHub, Vendor Security Assessment Questionnairegithub.com

The documents this guide is about

Applies to

SaaS and technology

Information security policy set
An information security policy set is the group of written policies and procedures that states how a company protects its systems and data: who may access what, how staff may use company devices, how incidents and outages are handled, which vendors may hold the data, and who owns each control.
$1,200 to $2,500
12 working days
Privacy policy pack
A privacy policy pack is the set of public notices and internal documents that state what personal data an organisation collects, why, who receives it, how long it is kept and how people exercise their rights, drafted against each privacy law that applies, such as GDPR, the CCPA or the Nigeria Data Protection Act 2023.
$1,200 to $2,500
10 working days
AI governance suite
An AI governance documentation suite is the set of policies, procedures and record templates that sets out how an organisation approves, risk-assesses, oversees and monitors the AI systems it builds or uses, and keeps the evidence of each step in the form the EU AI Act, the NIST AI RMF and ISO/IEC 42001 describe.
$3,000 to $5,000
20 working days