ISO 27001 and SOC 2 for startups: doing it once, on AWS

The question usually arrives in a sales call. A bigger customer's security team sends a questionnaire, and somewhere on page three it asks: "Do you have a SOC 2 report or ISO 27001 certificate?"

Both are achievable for a small team. The trick is to treat them as one security programme with two outputs, not two separate projects, and to build the controls so that evidence collects itself instead of being screenshotted the week before the audit.

What each one is

ISO/IEC 27001 is an international standard for an information security management system (ISMS): the way you decide on, run and improve your security. An accredited certification body audits you and, if you meet the standard, issues a certificate.

• The current edition is ISO/IEC 27001:2022, plus a 2024 amendment that adds climate change considerations. The transition from the 2013 edition ended on 31 October 2025, so 2013 certificates are no longer valid.
• Its Annex A lists 93 controls in four themes: organizational (37), people (8), physical (14) and technological (34). Eleven were new in 2022, including threat intelligence, security for cloud services, data leakage prevention and secure coding.
• The certificate lasts three years, with a surveillance audit every year in between.

SOC 2 is a report, not a certificate. A licensed CPA firm examines your controls against the AICPA's Trust Services Criteria and writes an opinion on them. There are five criteria categories: Security, Availability, Processing Integrity, Confidentiality and Privacy. Security is part of every SOC 2 report; the other four are optional, and most companies add them only when customers ask.

• A Type 1 report checks that your controls are well designed at one point in time.
• A Type 2 report also checks that they actually worked over an observation period, typically 3 to 12 months. This is the one most customers want.
• The report is normally shared with customers under NDA. A SOC 3 is a shorter version you can publish.

	ISO 27001	SOC 2
What you get	A certificate	An attestation report
Who issues it	Accredited certification body	Licensed CPA firm
What it covers	Your whole ISMS, plus the Annex A controls you choose	Your controls against the criteria you choose
Proves operation over time?	Through yearly surveillance audits	Type 2 covers a 3–12 month period
Typically asked for by	Customers in Europe and elsewhere outside the US	Customers in the US
Renewal	Recertify every 3 years, audited yearly	New report, usually every year

Which one first?

Ask your customers, not the internet: look at which one their security questionnaires actually ask for. As a rough pattern, US buyers tend to ask for SOC 2, while buyers in Europe and elsewhere more often ask for ISO 27001, but your own pipeline is the only data that matters. If it's both, pick one, and design the controls so the second one is mostly paperwork.

That's realistic because the two overlap heavily:

The shared middle column is where nearly all the engineering work is. The outer columns are mostly documents and process.

A realistic first year

Illustrative only. Your scope, your auditor and how much already exists set the real dates.

1. Gap assessment. Compare what you do today against the criteria or Annex A, and list what's missing.
2. Fix the gaps and write the policies. Short, honest policies that describe what you really do beat long templates nobody follows. Auditors test what you say you do.
3. Start collecting evidence early. A Type 2 period can't start until your controls are running, so every week you wait pushes the report back.
4. Get audited. For ISO 27001 that's a Stage 1 audit (are the documents in place?) followed by a Stage 2 audit (do you actually operate them?). For SOC 2, many teams get a Type 1 first so they have something to show customers, then a Type 2 once the observation period ends.

Building the controls on AWS

AWS is responsible for security of the cloud: its data centres, hardware and hypervisors. You can download its own SOC reports and ISO certificates from AWS Artifact and hand them to your auditor for that part. You're responsible for security in the cloud, and that's what your audit covers.

The goal is to turn each control into something a system records automatically:

Control	On AWS	Evidence it produces
Access is granted, reviewed and removed	IAM Identity Center with your identity provider (Okta, Entra ID), permission sets, MFA	Who has access to which account, and when it changed
Activity is logged and kept	An organization CloudTrail trail with log file integrity validation, stored in a separate log archive account	Who did what, when, and proof the logs weren't altered
Configuration is controlled	AWS Config recording in every account and Region	The settings of each resource over time
Security settings are checked continuously	Security Hub CSPM with AWS Foundational Security Best Practices and the CIS benchmark	A running list of failed checks and when they were fixed
Threats and vulnerabilities are found	GuardDuty, and Amazon Inspector for EC2, container images and Lambda	Findings, with time to fix
Data can be recovered	AWS Backup plans and Backup Audit Manager reports, plus restore tests	Backups taken, and proof a restore works
Changes are reviewed	Infrastructure as code, pull request reviews, approvals before production deploys	Who approved each change to production
Environments are separated	Separate AWS accounts per environment	Production access is limited and auditable

If you already deploy with short-lived OIDC credentials and keep infrastructure in Terraform, a good share of the change-management evidence already exists in your Git history.

Two things to know before you plan around AWS tooling

• There's no ready-made ISO 27001 or SOC 2 pack. AWS Config conformance packs and Security Hub standards cover benchmarks like CIS, NIST and PCI DSS, but neither has an ISO 27001 or SOC 2 version. (AWS's control catalog maps some controls to ISO 27001, but only the 2013 edition, and a mapping isn't audit evidence.) AWS itself says its compliance-related templates won't guarantee you pass an assessment. Use them as building blocks and map them to your controls yourself.
• AWS Audit Manager isn't an option for new setups. It stopped accepting new customers on 30 April 2026 and is in maintenance mode. Its ISO 27001 framework only ever covered the 2013 edition. AWS points customers to Config conformance packs or to compliance platforms instead.

Compliance platforms

Tools such as Vanta, Drata and Secureframe connect to AWS, your identity provider, HR system and Git host, check controls continuously, and keep the evidence in one place for your auditor. They support both SOC 2 and ISO 27001, which makes the "do it once" approach much easier. They don't replace the engineering work above. They tell you whether it's working.

The parts that aren't engineering

Auditors spend as much time on these as on your cloud setup, and they're where small teams most often slip:

• People: background checks where lawful, security training at hiring and yearly, and an offboarding checklist that really removes access on the last day.
• Vendors: a list of the services that touch customer data, with their own SOC 2 reports or ISO certificates reviewed every year.
• Incidents: a written response plan, and a record of each incident, even small ones.
• Risk: a risk register reviewed at least yearly, linking each risk to the control that treats it. ISO 27001 explicitly requires a risk treatment plan and a Statement of Applicability.

Keeping it cheap and sane

• Keep the scope tight. Put only the production system that handles customer data in scope. Separate AWS accounts make that boundary easy to draw and defend.
• Automate before you document. A control that runs by itself produces evidence forever. A control that relies on someone remembering produces a finding.
• Write down what you actually do. Then do what you wrote. Most audit exceptions come from policies promising more than the team delivers.
• Treat it as ongoing. Both frameworks are audited every year. The real win isn't passing the first audit. It's when the second one is boring.