A larger customer likes your product, procurement sends a security questionnaire, and somewhere around question forty it asks for your SOC 2 report. Without one, the deal stalls or moves forward with conditions attached. This playbook is for that moment, written for a European startup selling to companies bigger than itself.
SOC 2 or ISO 27001 First
The two produce different documents. A SOC 2 report is an attestation: an independent auditor describes your system, tests your controls against the Trust Services Criteria and gives an opinion, including any exceptions found. There is no certificate; buyers read the report. ISO 27001 certifies an information security management system (ISMS). An accredited certification body audits it and issues a certificate valid for three years, with surveillance audits in between.
Decide from your buyers. Pull the last ten questionnaires, RFPs and contract drafts you received and note what each one names:
- SOC 2 named explicitly, often as "SOC 2 Type II": start with SOC 2. It is a US-origin framework, and North American buyers tend to ask for it by name.
- An ISO 27001 certificate requested, typical of European enterprise and public-sector procurement: start with ISO 27001.
- Neither named: either works, so pick the one your largest open deal will accept.
- Customers in scope of NIS2 or DORA: they must manage their suppliers' security, so expect clauses on incident notification and audit rights on top of any report.
The overlap is large. Both expect access control, change management, logging, incident response, vendor management and risk assessment, so one set of engineering controls serves both. ISO 27001 adds a management system (risk treatment, Statement of Applicability, internal audit, management review); a SOC 2 Type II adds proof that each control operated throughout a period. Build the controls once and map them to both. For how this sits alongside GDPR and NIS2, see our guide to cybersecurity compliance across jurisdictions.
Scoping: Systems, People and Criteria
Scope is the boundary the auditor tests. Draw it around the service your customers buy:
- The production environment: compute, data stores, queues and the networks between them.
- The pipeline that builds and deploys it, and the Git repositories behind it.
- Your identity provider and every tool that grants access to production.
- The people with production or customer-data access, and the HR process that adds and removes them.
Leave out what does not touch the service or its data: the marketing site, the internal wiki, the design tools. Your cloud provider is a subservice organization: under the commonly used carve-out method its controls stay outside your report, and you review its own SOC 2 report instead.
Then choose the Trust Services Criteria. Security (the common criteria) is always included. The other four are optional, and each adds criteria the auditor tests:
- Availability: add it if your contracts carry uptime commitments.
- Confidentiality: add it if contracts define confidential information you must protect and dispose of.
- Processing Integrity: add it if correct processing is the product, as in payments or payroll.
- Privacy: overlaps heavily with what GDPR already requires of you; add it only when a buyer asks.
Type I versus Type II
A Type I report covers a single date: is your system described fairly, and are the controls suitably designed? A Type II report adds whether those controls operated effectively throughout an observation period, tested by sampling evidence from across it.
The length of the period is agreed with your auditor, and some buyers state a minimum, so ask both before you pick a start date. A Type I helps when a deal needs a document now; otherwise go straight to Type II. Between reports, buyers often ask for a bridge letter: your own statement that nothing material has changed since the last period ended.
The Controls as Engineering Tasks
For most controls a Type II auditor asks for a population, such as every leaver in the period or every change merged to production, and tests a sample from it. So each control must leave a record by default, and you must be able to produce the complete list for the whole window.
SSO and MFA everywhere
Put every in-scope system behind your identity provider and enforce MFA there: cloud console, Git platform, CI, database tools. Keep one or two documented break-glass accounts, with an alert on every use.
Evidence: the in-scope application list with each login method, the MFA enforcement setting, a user export showing enrollment, and break-glass usage logs.
Joiners, movers and leavers
Trigger access changes from the HR record: one ticket per joiner, role change and leaver, listing the grants. Set an offboarding deadline you can meet every time, for example the leaver's last working day. Disable the identity-provider account first, then revoke keys and tokens that live outside SSO.
Evidence: the HR list of joiners and leavers, and for each sampled person the ticket and when access was granted or removed.
Periodic access reviews
On the cadence your policy sets, for example quarterly, each production system's owner reviews who has access and signs off. Every removal becomes a ticket.
Evidence: the exported access list, the dated sign-off, and the closed removal tickets.
Change management
Protect the default branch of every production repository: no direct pushes, admins included; an approval from someone other than the author; required CI checks; deployment only from the pipeline. Define an emergency path that is reviewed after the fact. This is the pipeline our DevSecOps practice builds.
Evidence: the branch-protection settings, and for each sampled change the pull request with its approver and passing pipeline.
Logging and alerting
Centralize application, infrastructure and cloud audit logs with the retention your policy states, and route security alerts (bursts of failed logins, privilege changes, logging switched off) to on-call.
Evidence: alert rules, retention settings, and sampled alerts with the ticket each one produced.
Backups with a tested restore
Automate backups, keep them separate from production, and restore one on a schedule:
dropdb --if-exists restore_test
createdb restore_test
pg_restore --exit-on-error -d restore_test /backups/app-latest.dump
psql -d restore_test -c "SELECT count(*), max(created_at) FROM orders;"Evidence: backup job history, and a restore record: date, duration, what was checked, who ran it.
Vulnerability management
Scan dependencies, container images and hosts, and set fix deadlines by severity, for example critical within 7 days, high within 30, medium within 90. Choose numbers you will meet every time: the auditor tests against your policy, and every miss needs an approved exception.
Evidence: scan results, tickets with opened and closed dates, and the exception register.
Encryption in transit and at rest
TLS on every endpoint that carries customer data, internal ones included; encryption on every data store and backup; keys in a managed key service with restricted access. If your infrastructure is in Terraform, the code is evidence.
Evidence: configuration exports or infrastructure code, plus a TLS scan of public endpoints.
Vendor inventory
List every vendor that touches customer data or production: what data, what access, a risk rating, and when you last reviewed its security report or certificate. Your GDPR subprocessor list is the starting point.
Evidence: the inventory and the dated reviews.
Incident response plan and tabletop exercise
Write a short plan: severity levels, who leads, how customers and authorities are notified, how evidence is preserved. Then rehearse it on a realistic scenario, such as a leaked deploy key, and ticket the gaps.
Evidence: the plan, the exercise record (date, attendees, scenario, findings) and the follow-up tickets.
Policies people actually read
Write policies that describe what you do, a few pages each, and have everyone acknowledge them at hiring and annually, alongside security awareness training.
Evidence: each policy with its owner and review date, and acknowledgment records per person.
Not sure which of these you already meet? Request a free SOC 2 readiness assessment: we walk through your identity provider, repositories, pipeline and backups against the criteria and hand you a gap list ranked by audit risk.
Collect Evidence From Systems You Already Run
Screenshots taken the week before fieldwork are the weakest evidence you can offer. Export it on a schedule, with a timestamp, and store it where nobody can quietly edit it. A weekly job like this produces the populations auditors ask for:
#!/usr/bin/env bash
set -euo pipefail
SINCE="2026-01-01"
UNTIL="2026-06-30"
OUT="evidence/$(date +%F)"
mkdir -p "$OUT"
# Every change that reached the default branch in the window
git -C /srv/repos/app log main --first-parent --since="$SINCE" --until="$UNTIL" --format='%H|%an|%cI|%s' > "$OUT/changes-main.txt"
# Who holds which role in the production cluster
kubectl get rolebindings,clusterrolebindings -A -o wide > "$OUT/k8s-bindings.txt"
# Database logins and superusers
psql -d app -At -c "SELECT rolname, rolsuper, rolvaliduntil FROM pg_roles WHERE rolcanlogin;" > "$OUT/db-roles.txt"
# Fingerprint the snapshot
(cd "$OUT" && sha256sum ./*.txt > SHA256SUMS)The Git log is the population of changes. Hosted Git platforms expose branch-protection rules, pull request approvals and pipeline results through their REST APIs: join each commit to its pull request and you have the author, approver and pipeline status per change, which is exactly what gets sampled. Add your identity provider's user and MFA export, and write everything to object storage with versioning or a retention lock. Compliance automation platforms do the same through integrations; whether that beats a few scripts depends on how many systems you run. For the cluster side, see automating Kubernetes compliance evidence.
A 12-Week Readiness Plan
Weeks 1-2: decide and scope
- A framework decision note, based on the questionnaires you pulled.
- A system boundary diagram and an inventory of in-scope systems, data stores and people.
- The criteria selection and a gap register, one row per control.
- An auditor shortlist and a first talk about period length and dates.
Weeks 3-4: identity
- SSO and enforced MFA on every in-scope system, break-glass accounts documented.
- HR-triggered joiner and leaver tickets, and an offboarding runbook.
- The first access review, completed and signed.
Weeks 5-6: change and build
- Branch protection on every production repository, admins included.
- Deploys only from CI, and a written emergency change procedure.
Weeks 7-8: operations
- Central logging, with security alerts routed to on-call.
- Vulnerability scanning live, with severity deadlines in the tracker.
- Encryption verified, backups running, the first restore test recorded.
Weeks 9-10: policies, vendors and risk
- A policy set that matches what you now do, acknowledged by everyone.
- The vendor inventory, a risk assessment and the incident response plan.
Weeks 11-12: rehearse
- The tabletop exercise held, evidence jobs running on schedule.
- An internal readiness review: pick samples the way an auditor would and fix whatever you cannot produce.
- The observation period start date agreed with the auditor.
Then the observation window opens: nothing new to build, only controls to run on time. Put every recurring control in a shared calendar with an owner (access reviews, restore tests, vendor reviews) and check the evidence folder monthly, so you find a missed review before the auditor does.
What It Costs, and How to Estimate It
First-year cost is the sum of four lines, and you can estimate each one from your own numbers:
- Auditor fee: request quotes against the same written scope, criteria, report type and period, so they compare like with like.
- Tooling: a compliance automation platform or your own scripts, plus what people forget: the higher plan tier some tools require before they offer SSO, device management for laptops, and scanners.
- Gap-closing work: estimate each row of your gap register in hours, add the evidence automation, and multiply by a loaded hourly rate.
- Upkeep: weekly hours for the recurring controls and auditor interviews, multiplied by the weeks in the observation period and the same rate.
Traps That Slow a First Audit
Policies written for an imaginary company. Downloaded templates describe a security team and a change board you don't have. The auditor tests what the policy says, so every sentence you can't evidence becomes an exception. Write down what you actually do, then improve it.
Controls that only exist the week before the audit. A Type II tests the whole period. An access review done once, the day before fieldwork, is one sample out of the several the window required. Start the clock only when controls run on their own.
Scoping everything. Every in-scope system needs access reviews, logging and change evidence. Adding systems no buyer cares about multiplies the work.
Get a Free SOC 2 Readiness Assessment
If a customer has asked for a SOC 2 report or an ISO 27001 certificate, our cybersecurity team will look at where you stand at no cost. The assessment covers:
- Framework and scope: which report your buyers need, and the smallest boundary that satisfies them.
- A control-by-control gap list across identity, change management, logging, backups and vulnerability management, with the evidence each control produces today.
- A readiness plan sized to your team, including which evidence can be collected automatically.
Request your free SOC 2 readiness assessment and get a written list of gaps and next steps, with no obligation attached.