SOC 2 Type II or ISO 27001 First? A 20-Person Engineering Team's Decision Rule
If your enterprise pipeline is mostly North American, start with SOC 2 Type II; if it is European, Middle Eastern, APAC or public-sector, start with ISO 27001. Here is the decision rule, the real cost and timeline for a 20-person team, and why your setup on AWS, GCP, Azure, Scaleway or your own Kubernetes cluster decides how painful the audit gets.
Decide by buyer geography. North American pipeline: SOC 2 Type II first. European, Middle Eastern, APAC or public-sector pipeline: ISO 27001 first. Split pipeline: SOC 2 Type II first, because its 3-month observation window yields a usable artifact sooner.
Timeline: roughly 4-6 months for a first SOC 2 Type II, 6-12 months for a first ISO 27001 certification, which needs a working ISMS before the Stage 1 and Stage 2 audits.
Budget mid five figures all-in for either in year one. The hard costs are a compliance platform (Vanta, Drata, Sprinto or Secureframe), the auditor fee and a penetration test. Internal engineering time is the one nobody plans for.
SOC 2 Type I only earns its cost as a bridge while your Type II window is already running.
Sequence the two frameworks. Most control evidence is shared, but ISO/IEC 27001:2022 clauses 4-10, the management-system layer, are genuinely new work after SOC 2.
Infrastructure evidence causes most of the audit pain: production access, change approval, log retention, environment separation and restore tests.
The framework you should pursue first is already sitting in your inbox. Open the last ten security questionnaires your sales team received and count which name appears.
If your enterprise pipeline is mostly North American, pursue SOC 2 Type II first. If it is mostly European, Middle Eastern, APAC or public-sector, pursue ISO 27001 first. If it is split, start with SOC 2 Type II, because a 3-month observation window produces a usable report in roughly 4-6 months, against 6-12 months for a first ISO 27001 certification.
I have interviewed more than 200 CTOs, and the small teams that got stuck in procurement rarely picked the wrong framework on purpose. They picked the one their board mentioned instead of the one their buyers asked for.
Should a 20-person engineering team pursue SOC 2 Type II or ISO 27001 first?
Pursue SOC 2 Type II first if your enterprise pipeline is mostly North American, and ISO 27001 first if it is mostly European, Middle Eastern, APAC or public-sector. If the pipeline is split, SOC 2 Type II goes first because it reaches a usable artifact faster.
When the answer is not obvious, use three tie-breakers in strict order:
Where your signed and in-flight enterprise deals sit geographically, weighted by deal size.
Which framework the last 10 security questionnaires named by brand.
Which one your single largest prospect's vendor-risk team asked for in writing.
At 20 people you have no compliance hire, usually no security engineer, and one or two people who understand the infrastructure, so every evidence hour comes out of their shipping time. Neither artifact makes you secure, and neither unblocks a deal if your architecture cannot produce the same evidence every week for months.
Buyer profile
Framework to pursue first
Why
Typical time to first usable artifact
US/Canada enterprise SaaS buyers
SOC 2 Type II first
US questionnaires name SOC 2 by default
SOC 2 Type II: ~4-6 months
EU/UK enterprise buyers
ISO 27001 first
European procurement and ISO-certified parents ask for the certificate
ISO 27001: ~6-12 months
EU public tender
ISO 27001 first
Tenders often list ISO 27001 as an eligibility criterion
ISO 27001: ~6-12 months
Middle East/APAC enterprise buyers
ISO 27001 first
International standard, publicly verifiable certificate
ISO 27001: ~6-12 months
Split North America/EMEA pipeline
SOC 2 Type II first, ISO 27001 second
Faster first artifact, most evidence reused
SOC 2 Type II: ~4-6 months
US healthcare buyers
SOC 2 Type II first, plus HIPAA
SOC 2 is often mapped to HIPAA safeguards
SOC 2 Type II: ~4-6 months
US fintech buyers
SOC 2 Type II first, possibly SOC 1 or PCI DSS
Financial reporting and card data add overlays
SOC 2 Type II: ~4-6 months
EU financial-services buyers
ISO 27001 first, with DORA evidence
DORA pulls ICT vendors into contractual oversight
ISO 27001: ~6-12 months
The verdict, in one line: North American pipeline means SOC 2 Type II first, EMEA, APAC or public-sector pipeline means ISO 27001 first, and a split pipeline means SOC 2 Type II first.
What is the actual difference between SOC 2 Type II and ISO 27001:2022?
SOC 2 Type II is an attestation report issued by a licensed CPA firm proving your controls operated effectively across a defined window. ISO 27001 is a certification issued by an accredited certification body proving you run an information security management system, valid for three years with annual surveillance audits.
SOC 2 examinations follow AICPA attestation standards (AT-C sections 105 and 205) against the 2017 Trust Services Criteria: Security, which is mandatory, plus optional Availability, Processing Integrity, Confidentiality and Privacy. The AICPA describes SOC as a suite of services CPAs provide, so nobody is "SOC 2 certified". You receive a report, and sharp vendor-risk analysts notice the wrong phrasing.
ISO/IEC 27001:2022 has management-system requirements in clauses 4-10 plus Annex A, with 93 controls grouped into four themes: organizational, people, physical and technological. The transition period off the 2013 edition has closed, so every new certificate is issued against the 2022 revision.
Attribute
SOC 2 Type I
SOC 2 Type II
ISO/IEC 27001:2022
What the artifact is
SOC 2 Type I: attestation report on control design at a point in time
SOC 2 Type II: attestation report on operating effectiveness over a period
ISO 27001: certificate of conformity for your ISMS
Issuing body
SOC 2 Type I: licensed CPA firm
SOC 2 Type II: licensed CPA firm
ISO 27001: accredited certification body
How scope is defined
SOC 2 Type I: Trust Services Criteria categories you select
SOC 2 Type II: Trust Services Criteria categories you select
ISO 27001: ISMS scope plus Statement of Applicability
What the auditor inspects
SOC 2 Type I: whether controls are designed and in place on one date
SOC 2 Type II: samples of evidence across the whole window
ISO 27001: ISMS documents, risk treatment, internal audit, management review, Annex A controls
Time to first usable artifact (20 people)
SOC 2 Type I: ~2-3 months
SOC 2 Type II: ~4-6 months
ISO 27001: ~6-12 months
Validity and renewal
SOC 2 Type I: one-off, superseded by Type II
SOC 2 Type II: renewed annually on a continuous window
ISO 27001: certificate is public; SoA shared on request
Who asks for it
SOC 2 Type I: early US buyers as a stopgap
SOC 2 Type II: US and Canadian enterprise buyers
ISO 27001: EU, UK, Middle East, APAC and public-sector buyers
Which framework do enterprise buyers actually ask for in 2026?
Enterprise vendor-risk teams ask by name, and the name tracks geography and industry: US procurement names SOC 2 Type II, while European procurement, ISO-certified parent companies and public tenders name ISO 27001. Your own inbox is stronger evidence than any vendor benchmark, including this article.
Spend 20 minutes counting the framework named in your last 10 questionnaires, weighted by deal size, then layer on industry. US healthcare adds HIPAA. US fintech may add SOC 1 or PCI DSS v4.0.1. EU buyers cite ISO 27001 alongside GDPR Article 28 processor obligations, and EU financial-services buyers pull you into DORA (Regulation (EU) 2022/2554), which has applied since 17 January 2025.
A SOC 2 Type II report often satisfies an ISO-asking buyer, and the reverse, if you can hand over a control mapping within a day. Some procurement processes will not move without the exact artifact, and no mapping fixes that. When that happens, you lose the quarter, and you should forecast it honestly.
While the window runs, keep the deal alive with a completed CAIQ or SIG Lite, a public trust page from Vanta, Drata, Sprinto or Secureframe, a recent penetration test summary, a signed DPA, and your auditor's engagement letter with a target report date. None of these carries an independent opinion, so treat them as a bridge, never a substitute.
How long and how much does SOC 2 Type II vs ISO 27001 cost for a 20-person company?
Plan on roughly 4-6 months and mid five figures all-in for a first SOC 2 Type II, and 6-12 months with a similar or slightly higher all-in figure for a first ISO 27001 certification. The compliance platform, the auditor fee and a penetration test dominate the cash budget, and internal engineering time is the cost teams forget.
Vanta's SOC 2 cost guide (vendor-published) puts the audit fee at $10,000 to $50,000 and first-year all-in at $10,000 to $80,000 or more, with readiness taking one to five months and the Type II observation period usually three to twelve months. With a 3-month window and tight readiness, that lands at the 4-6 months I see most often. Secureframe's ISO 27001 guide (vendor-published) puts the certification audit at roughly $10,000 to $50,000, surveillance at about $10,000 a year, and penetration tests at an average of $8,000 to $10,000.
I could not find a credible, independent engineer-day figure, so I will not invent one. Name a single owner, usually the person who understands production best, and protect a fixed share of their week from readiness until the auditor signs. Running both audits at once at 20 people splits that same person in two, so finish one and start the second inside the next 12 months.
SOC 2 Type II: one named owner, a protected share of their week
ISO 27001: the same owner plus leadership time for management review
Ongoing cost
SOC 2 Type II: annual re-examination on a continuous window
ISO 27001: ~$10,000/year surveillance, recertification in year three (Secureframe)
Ship faster on infrastructure you control.
Qovery gives your team self-service deployments on your own AWS, GCP, Azure, or Scaleway account - or your existing Kubernetes cluster. Start deploying in under 10 minutes.
How much do SOC 2 and ISO 27001 overlap, and can you reuse the work?
The overlap is large enough that the second framework is an extension rather than a restart, because most technical control evidence is shared. What does not transfer from SOC 2 to ISO is the management-system layer in ISO/IEC 27001:2022 clauses 4-10, and that is real new work.
SOC 2 does not hand you an ISMS scope statement, a risk assessment methodology, a Statement of Applicability, an internal audit programme or a management review cadence. ISO does not hand you SOC 2's evidence of operating effectiveness across a window, or the extra Trust Services Criteria categories when a buyer asks for Availability or Confidentiality. I will not quote an overlap percentage, because I have not seen a published cross-walk that justifies one, so the table below describes the overlap by control domain.
Write policies once in framework-agnostic language and tag every control to both frameworks on day one. Vanta, Drata, Sprinto and Secureframe all map both, so you collect each piece of evidence once.
Control domain
SOC 2 Trust Services Criteria
ISO/IEC 27001:2022 Annex A
Still to build if SOC 2 first / ISO first
Access control and offboarding
SOC 2: covered (CC6)
ISO 27001: covered (organizational and technological controls)
Access control: mostly reusable both ways
Change management
SOC 2: covered (CC8)
ISO 27001: covered (technological controls)
Change management: reusable both ways
Encryption and key handling
SOC 2: covered (CC6)
ISO 27001: covered (use of cryptography)
Encryption: reusable both ways
Logging and monitoring
SOC 2: covered (CC7)
ISO 27001: covered (logging, monitoring)
Logging: reusable, but SOC 2 needs retention across the full window
Vendor risk
SOC 2: covered (CC9)
ISO 27001: covered (supplier relationships)
Vendor risk: reusable both ways
BCDR and backups
SOC 2: Availability category if selected
ISO 27001: covered (backup, ICT continuity)
BCDR: add Availability if SOC 2 comes second and buyers want it
HR and awareness
SOC 2: covered (CC1, CC2)
ISO 27001: covered (people controls)
HR and awareness: reusable both ways
Risk management
SOC 2: covered (CC3)
ISO 27001: clause 6 risk assessment and treatment
Risk management: ISO needs a formal methodology and treatment plan
ISMS governance
SOC 2: not required
ISO 27001: clauses 4-10, internal audit, management review
ISMS governance: new work if SOC 2 came first
For small teams the real remediation effort lands on production access, log retention, environment separation and backup restore proof. Policy templates take a week.
Does running on AWS, GCP, Azure or Scaleway make you SOC 2 or ISO 27001 compliant?
No. AWS, Google Cloud, Azure and Scaleway hold reports for the layers they own, such as data centres, hardware and the hypervisor, and those reports stop there. You still have to prove your IAM, deployment pipeline, environment separation, key handling and log retention.
Open the end of any provider SOC 2 report. Microsoft tells customers to search for "User Entity Responsibilities", the controls you must run for the system as a whole to meet the criteria. Your auditor will test those complementary user entity controls against your environment, and most small teams have never read that section.
For EU readers, Scaleway or an EU-region account makes data residency easier to argue in an ISO 27001 or GDPR Article 28 conversation. Scaleway publishes its own ISO 27001 certification there, which EU buyers like to see. Residency is still not a control.
Why does your infrastructure decide how painful the audit is?
For a 20-person team, the audit is won by proving that what you claim about production stayed true across every environment for months. Infrastructure that enforces controls automatically turns a multi-week evidence hunt into an export.
The failure modes auditors find repeat across teams: hand-rolled Terraform that diverges per environment, SSH access nobody can enumerate, staging drifted from production, deploy approvals living in Slack threads, and logs that rotate out before the window closes. Self-managed Kubernetes makes this worse. In Red Hat's 2024 State of Kubernetes Security report, 40% of respondents detected misconfigurations in their container or Kubernetes environments, and 26% said their organization failed an audit. Running across two clouds, or a cloud plus your own cluster, multiplies every one of those gaps when nothing enforces the same rule twice.
Auditors reward one control plane where access, approvals, deployments and environment configuration are enforced identically and logged automatically, so sampling any month returns the same answer. Without a dedicated DevOps engineer, the platform has to enforce the control, because under deadline pressure a human will skip it.
This is where Qovery fits. Qovery runs your apps inside your own AWS, GCP, Azure or Scaleway account, or on your existing Kubernetes cluster, so the cloud account and its compliance artifacts stay in your name. Git-push deployments, per-environment RBAC, preview environments per pull request, environment auto-stop and managed cluster upgrades give you a deployment and access trail that is standardised and recorded instead of reconstructed at audit time. Databases run on managed cloud services in your account.
Qovery is not a compliance product. It issues no reports and makes nobody compliant. Pair it with Vanta, Drata, Sprinto or Secureframe for policies, evidence collection and the auditor workflow, and passing the audit is still on you.
Auditor request
Hand-rolled Terraform plus raw Kubernetes
PaaS where the account is the vendor's (Heroku, Render)
Internal developer platform in your own cloud account (Qovery)
Production access list
Raw Kubernetes: possible, but spread across IAM, kubeconfigs and SSH
Heroku/Render: team list in the vendor dashboard; infrastructure access is the vendor's
Qovery: per-environment RBAC in one place, plus your cloud IAM
Change approval trail
Raw Kubernetes: only as good as your CI discipline
Heroku/Render: deploy history from git
Qovery: git-push deploys with recorded deployment history per environment
Environment separation proof
Raw Kubernetes: full control, nothing enforces it
Heroku/Render: separate apps or spaces, on vendor infrastructure
Qovery: separate environments with their own access rules in your account
Log retention
Raw Kubernetes: you build and prove it
Heroku/Render: vendor retention limits apply
Qovery: cloud audit trails stay in your own account under your retention settings
Backup restore evidence
Raw Kubernetes: you script and document restores
Heroku/Render: vendor-managed backups, restore evidence on their terms
Qovery: managed cloud databases in your account; you still run the restore test
Install the Qovery Agent Skills once, then ask your coding agent in plain language to stand up consistent environments in your own cloud account. Add the MCP Server when you want the agent to inspect what is already running.
Install the skills globally for Claude Code, Cursor, Codex, OpenCode and Gemini CLI. The script asks you to approve it before it runs:
Add the MCP Server to Claude Code. It logs in through OAuth in your browser and is read-only by default, so the agent can inspect but not change anything:
BASH
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242
Grant write access only when you explicitly want it, which also requires enabling write access in the Qovery Console:
BASH
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242
The skills (qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, qovery-terraform) deploy; the MCP Server operates what already exists. Then ask, for example: "deploy this app to my AWS account with Qovery and give me a separate staging environment with its own access rules". The walkthrough is in the AI agent quickstart and on the Claude Code integration page.
Frequently asked questions
Should a 20-person engineering team pursue SOC 2 Type II or ISO 27001 first when selling to enterprise buyers on a hyperscaler cloud?
If your enterprise pipeline is mostly North American, pursue SOC 2 Type II first. If it is mostly European, Middle Eastern, APAC or public-sector, pursue ISO 27001 first. If it is split, start with SOC 2 Type II, because a 3-month observation window produces a usable report in roughly 4-6 months, against 6-12 months for a first ISO 27001 certification.
Is SOC 2 Type I worth doing before SOC 2 Type II?
Only as a bridge. A SOC 2 Type I report covers control design on a single date, and many enterprise vendor-risk teams want a Type II report on operating effectiveness. Buy a Type I only if a live deal needs something during the weeks your Type II observation window is already running.
How long does a SOC 2 Type II observation window have to be?
The observation period for a SOC 2 Type II is usually three to twelve months, according to Vanta's SOC 2 cost guide (vendor-published). Most first reports use a 3-month window to get a usable artifact quickly, and later reports move to a continuous 12-month window renewed annually.
Can a SOC 2 Type II report satisfy an enterprise buyer who asked for ISO 27001?
Often, yes, if you can hand the buyer a control mapping between the AICPA Trust Services Criteria and ISO/IEC 27001:2022 Annex A within a day. Some procurement processes, especially EU public tenders, require the ISO 27001 certificate itself, and no mapping changes that.
Does running on AWS, GCP, Azure or Scaleway make us SOC 2 or ISO 27001 compliant?
No. The cloud provider's reports cover the layers it owns, such as physical security, hardware and the hypervisor. You still have to evidence your own IAM, change approval, environment separation, key handling, log retention and restore testing, including the user entity controls listed at the end of the provider's SOC 2 report.
How much does a first SOC 2 Type II or ISO 27001 cost, and how many engineer-days should a 20-person team budget?
Vendor-published figures put a SOC 2 audit fee at $10,000-$50,000 and first-year all-in at $10,000-$80,000 or more (Vanta), and an ISO 27001 certification audit at roughly $10,000-$50,000 plus about $10,000 a year for surveillance (Secureframe). Budget mid five figures all-in for either in year one. No independent engineer-day benchmark exists that I trust, so name one owner and protect a fixed share of their week from readiness until the report or certificate lands.
Can we pursue SOC 2 Type II and ISO 27001 at the same time, or should we sequence them?
Sequence them. At 20 people the same one or two engineers carry both audits, and running them in parallel halves their attention for both. Finish the first, then extend the shared control evidence to the second within the next 12 months, budgeting real time for ISO 27001 clauses 4-10 if SOC 2 came first.
Morgan co-founded Qovery and leads engineering. He writes about Kubernetes architecture, DevOps best practices, and building resilient infrastructure at scale.
Next step
Ship faster on infrastructure you control.
Qovery gives your team self-service deployments on your own AWS, GCP, Azure, or Scaleway account - or your existing Kubernetes cluster. Start deploying in under 10 minutes.
