ISO 27001 vs SOC 2: which customers will ask for which, and why

TL;DR — If your customers are mainly in North America, especially B2B SaaS buyers, they are more likely to ask for SOC 2 first. If your customers are in Europe, enterprise procurement-heavy, or you need a broader security management system that works across the whole company, ISO 27001 is more likely to matter; many growing software companies eventually do SOC 2 first for sales speed, then add ISO 27001 when international or enterprise demand justifies it. Reading time: ~7 min

What it is and where it sits

ISO 27001 and SOC 2 are both ways to prove to customers that your company handles security in a disciplined, auditable way. They are not security tools like a firewall or password manager. They sit one level above your app and infrastructure: in the layer of policies, controls, evidence, audits, and customer trust.

The simplest mental model is:

• Your product processes customer data.
• Your security controls protect that product and data.
• ISO 27001 or SOC 2 are external ways to show those controls exist and are actually being followed.

What each one is

• ISO 27001 is an international standard for an ISMS (Information Security Management System — the documented way your company manages security risks, controls, reviews, and improvement). You get certified by an accredited certification body.
• SOC 2 is an attestation report issued by a licensed CPA firm against the Trust Services Criteria (security rules defined by the AICPA). You are not "SOC 2 certified" in the formal sense; you receive a report.

Where they sit in a customer deal

Customers usually do not ask for ISO 27001 or SOC 2 during product setup. They ask during:

• vendor onboarding
• security review questionnaires
• procurement review
• legal/data protection review
• annual vendor reassessment

In other words, these frameworks live in your sales and governance flow, but they depend on your real technical and operational controls.

[Prospect Customer]
      |
      | 1. security questionnaire / RFP
      v
[Sales + Procurement] ---- 2. ask for proof ----> [Trust Docs]
                                                   |
                                                   | 3. provide report/cert
                                                   v
                                              [SOC 2 or ISO 27001]
                                                   |
                                                   | 4. evidence comes from
                                                   v
[Policies] ----> [People Processes] ----> [Cloud/App/Data Controls]
                                                   |
                                                   | 5. protect customer data
                                                   v
                                             [Your Product Service]

What they replace, and what they do not replace

They partly replace the painful version of trust-building where every prospect asks 200 custom security questions and you answer from scratch each time. A current SOC 2 report or ISO 27001 certificate often shortens that conversation.

They do not replace:

• actual security engineering
• legal agreements like a DPA (data processing addendum)
• customer-specific requirements such as data residency, encryption key ownership, or HIPAA controls
• product features customers may still need, like SSO (single sign-on), audit logs, or role-based access

How it actually works

Let’s walk one realistic example: a 40-person software company selling a workflow SaaS product to mid-market customers in the US and UK.

A prospect’s procurement team asks: "Please provide your latest SOC 2 Type II report or ISO 27001 certificate."

Step 1: The customer asks for evidence

This usually arrives as:

• a spreadsheet questionnaire
• a procurement portal upload request
• an email from security or legal
• an RFP (request for proposal)

At this point, the customer is not asking whether your app uses a specific library. They are asking whether your company can show a repeatable control system.

Step 2: You map the request to the right proof

Your team decides what to send:

• If the customer is a US SaaS buyer, they will often accept a SOC 2 Type II report.
• If the customer is a European enterprise or public-sector-adjacent buyer, they may prefer or require ISO 27001 certification.
• Some customers accept either.
• Large enterprises may ask for both, plus a CAIQ (standard cloud security questionnaire), pen test summary, and policy excerpts.

Step 3: The auditor looked at your controls before you sent anything

This is the important part: the report or certificate only exists because an outside auditor already examined your system.

For a software company, that usually includes evidence such as:

• access reviews for Google Workspace, Microsoft 365, GitHub, cloud accounts, and production databases
• MFA (multi-factor authentication) settings for admin systems
• onboarding and offboarding checklists
• vulnerability scanning and patching records
• incident response process and test results
• backup and restore evidence
• change management records for production deployments
• risk assessment documents
• vendor management reviews

For SOC 2 Type I, the auditor checks whether controls are designed appropriately at a point in time. For SOC 2 Type II, the auditor checks whether those controls operated over a period, commonly several months. For ISO 27001, the auditor checks whether your ISMS is defined, implemented, maintained, and improved, and whether required processes like internal audit and management review are happening.

Step 4: You share the artifact with the customer

Usually this happens through one of these paths:

• your trust center or document portal
• a secure file-sharing link
• the customer’s procurement portal
• email under NDA (non-disclosure agreement)

The customer reviews the document, often alongside a questionnaire.

Step 5: The customer uses it to reduce perceived vendor risk

A SOC 2 report or ISO 27001 certificate helps them answer questions like:

• Is this vendor mature enough for our data?
• Do they have controlled access to production?
• Is there a documented security process beyond ad hoc habits?
• Can we justify approval to internal audit, legal, and procurement?

That is why these frameworks matter commercially: they reduce friction in the buying process.

When to use it (and when not to)

The short version: choose based on who is buying from you, where they are, and how formal their procurement process is.

You probably want SOC 2 first if...

• your target buyers are in the US or Canada
• you are selling a hosted software product, not just project work
• deals are being slowed by security reviews right now
• customers literally ask "Do you have SOC 2?"
• you need the fastest path to a commonly accepted trust document in North American SaaS sales

You probably want ISO 27001 first if...

• your customers are in Europe, the UK, or multinational enterprises
• you want a formal management system spanning the whole organization
• leadership wants security governance embedded into company operations, not only a report for deals
• customers ask for an ISO certificate specifically
• you expect procurement teams to care about internationally recognized standards

You probably do not need either yet if...

• you are still pre-product-market-fit
• your customers are small and do not run vendor security reviews
• you do not yet have basic controls like MFA, asset inventory, access review, backups, and incident response
• your budget is better spent fixing obvious security gaps first

A useful rule: if fewer than about 20-30% of serious deals ask for one of these, you may not need to rush. If a missing report is blocking multiple qualified deals, it becomes a business priority.

Trade-offs

Neither option is free money. Each benefit comes with a cost.

Honest differences in operational burden

• SOC 2 often feels more directly tied to customer due diligence in US SaaS. It can be commercially efficient, but evidence collection can become a recurring scramble if your operations are not already tidy.
• ISO 27001 pushes you toward a more systematic governance model. That is powerful, but heavier: risk treatment, internal audit, management review, statement of applicability, and continual improvement are real work.

Lock-in and ecosystem effects

There is no hard technical lock-in in either standard, but there is process lock-in:

• once you promise annual reports or certification maintenance, customers expect continuity
• your team starts building workflows around the chosen framework
• changing auditors or control tooling later is possible, but disruptive

In practice

These examples are not the audit itself. They are the kinds of concrete controls auditors expect to see behind the report or certificate.

Example 1: Enforce security headers in nginx for your app

server {
    listen 443 ssl http2;
    server_name app.example.com;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "DENY" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Content-Security-Policy "default-src 'self'; frame-ancestors 'none'; object-src 'none'" always;

    location / {
        proxy_pass http://app_backend;
    }
}

This adds common browser-side protections that support secure application delivery. The gotcha: a strict Content-Security-Policy can break third-party scripts or embedded widgets, so test it in staging before production.

If you use a managed platform, set equivalent headers in your provider dashboard or app framework settings rather than editing nginx directly.

Example 2: Turn on PostgreSQL connection logging for audit evidence

ALTER SYSTEM SET log_connections = 'on';
ALTER SYSTEM SET log_disconnections = 'on';
ALTER SYSTEM SET log_line_prefix = '%m [%p] %u@%d %r ';
SELECT pg_reload_conf();

This records who connected, when, and from where, which helps support access monitoring and incident investigation. The gotcha: logs can contain personal data like usernames and IP addresses, so keep retention and access permissions aligned with your privacy and security policies.

⚠️ If you change database or web server settings directly in production, you can cause downtime or break application behavior. Apply the change in staging first, then use your normal change-management process to promote it.

Example 3: A simple access review checklist you can run monthly

{
  "review_name": "Monthly production access review",
  "systems": ["Cloud account", "GitHub", "Database", "CI/CD", "Password manager"],
  "checks": [
    "List all users with admin or production access",
    "Confirm each user still needs access for current role",
    "Remove departed staff and contractors",
    "Verify MFA is enabled for all privileged users",
    "Record reviewer name, date, and actions taken"
  ],
  "evidence": "Export user lists and save approved review notes in your compliance folder"
}

This is the kind of repeatable process auditors want to see: not just access control, but evidence that you review it regularly. The gotcha: if you cannot produce dated records of the review, many auditors will treat the control as not operating effectively.

In a typical provider dashboard, the action path is usually something like: Admin Console → Users or Organization Settings → Members, then export or screenshot the current access list and record the review outcome.

Further reading

• ISO/IEC 27001 — Clauses 4 through 10 and Annex A
• AICPA Trust Services Criteria
• SOC 2 Guide from the AICPA
• NIST Cybersecurity Framework 2.0
• The "Security" documentation sections for your cloud provider and identity provider

This article was written by an AI system and published pending human review. Verify anything you intend to act on.