Do You Really Need to Certify Everything? The Scoping Guide for SOC 2 and ISO 27001

What scope means within SOC 2 and ISO 27001

Scope is the hard boundary of what your auditor does and doesn't assess. It makes the difference between an audit of 3 months and one of 9 months, and between documenting 10 systems or 50. Scope is the lever that determines whether certification is feasible with your current team.

Your organisational scope is everything your business does. Your audit scope is the part of that which comes under scrutiny. A SaaS company with five products can choose to only certify the product that enterprise clients use. Both standards explicitly permit this.

Auditors check whether your scope boundaries are realistic. If you claim your payment function runs completely isolated but it uses your central database and identity provider, you'll get questions. Scope must technically stack up. An auditor with five minutes of infrastructure knowledge sees through poor delineation.

Why organisations limit their scope

Speed is the most common reason. A startup with three months to achieve certification can realise this by limiting scope to the core product that enterprise clients use. This is one of the levers behind the fastest way to get ISO 27001 certified as a startup.

Internal workload saves more than auditor costs. Each system in scope requires documentation, configuration reviews, evidence collection, and training. For a team of ten people, the difference between twenty and fifty systems in scope can be the difference between feasible and unfeasible.

Organisations with legacy systems or hybrid infrastructure begin with a clearly delineated scope to first build expertise. Expansion can always come later, when the foundation is in place.

Scoping for SOC 2 and ISO 27001: the fundamental difference

SOC 2 and ISO 27001 approach scoping in fundamentally different ways. Understand this difference and you understand how to deploy both effectively.

SOC 2: start with what you promise clients

SOC 2 works from outside in. You start with your service commitments: what do you promise clients? A CRM provider promises that customer data remains available, secure, and confidential. These promises determine which Trust Service Criteria you must address. If you're unsure what your buyers are actually asking for, what customers really mean when they ask for SOC 2 breaks it down.

Next you define the system boundary: all systems, processes, and people needed to make those promises good. The strength of this approach is that your scope automatically aligns with what clients want to see. If you only make a security commitment, you don't need to implement privacy or availability controls (unless needed for security).

ISO 27001: start with the information that needs protection

ISO 27001 works from inside out. You begin with: which information must I protect? For each asset you determine:

• Confidentiality: how bad is it if this information is leaked?
• Integrity: how bad is it if this information proves incorrect?
• Availability: how bad is it if this information is unreachable?

This business impact analysis determines your scope. A startup with only public content has few confidentiality concerns but possibly major availability risks. A fintech with transaction data has enormous confidentiality and integrity risks instead.

From your information assets you work outwards: which IT systems process this data? Which people have access? This automatically creates the boundaries of your Information Security Management System. The advantage is that you stay focused on real risks instead of implementing all possible controls. If you're still deciding whether to begin at all, ISO 27001: what is it and when to start? covers the basics.

When which approach works best

SOC 2 works excellently for one clear product to enterprise clients. ISO 27001 shines with more complex organisations with multiple products or different risk profiles. The information-centric approach helps you prioritise.

For startups wanting both: begin with ISO 27001 logic. Define your critical information assets and work out your scope from there. Then map these to SOC 2 service commitments. This sequence gives you the strategic clarity of ISO with the client-facing presentation of SOC 2.

Privacy in ISO 27001: what you cannot scope out

Here lies a crucial difference: you can scope out privacy in SOC 2 by not selecting the Privacy criterion, but ISO 27001 requires you to comply with applicable laws and regulations, including GDPR. Annex A.5.34 on privacy and protection of personal data is difficult to scope out in practice, unless you can demonstrably show you do not process personal data. But you don't need to bring your entire organisation into scope for this.

Treat privacy as a separate topic, just as SOC 2 does. For assets already in scope, such as your production database with customer data, you often need to do little extra. Your encryption, access controls, and logging cover both security and privacy. Only add specific privacy elements such as retention periods and a process for data subject requests.

For assets only relevant due to privacy, such as your website with tracking or your CRM with prospect emails, you create a separate risk analysis. These often receive a low risk assessment because you're not collecting sensitive information. Implement targeted controls: a privacy notice on your website, consent tracking for cookies, and MFA login on your CRM. Done. These systems don't need the full ISO 27001 treatment with all Annex A controls, only the privacy-specific requirements.

What typically falls within scope

The core application is always in scope. This is what clients use and where their data flows through. Any attempt to keep this out of scope is directly rejected by auditors.

Underlying infrastructure follows automatically: servers, databases, load balancers, CDNs, and backup systems. CI/CD pipelines are crucial because a compromise here directly leads to compromised production code. Your GitHub repository, CI system, and deployment pipeline are in scope.

People with access to production systems or customer data are in scope. This means their access, training, and onboarding/offboarding processes are assessed.

What can (and sometimes must) remain out of scope

Corporate websites without customer data processing can stay out of scope. Internal tooling without production connection often remains out of scope: HR systems, internal wikis, or marketing Slack workspaces. The question is: does compromise of this system impact customer data security? If no, it can stay out.

But you cannot exclude what's fundamentally connected. Your identity provider managing access to in-scope systems must be included. Your monitoring system collecting production metrics must be included. Your incident response process must be included.

The biggest scoping pitfalls that delay implementation

Making scope too broad from fear doubles your work without added value. Auditors respect a well-justified, limited scope more than a broad but sloppy implementation.

Forgetting critical components costs weeks of delay. Teams often forget their deployment pipeline, monitoring stack, or incident response tool. Halfway through the audit, this still needs documenting.

Changing scope during the audit is almost never successful. Invest two days in thorough scope definition upfront, save six weeks of delay later.

Unclear scope boundaries lead to endless follow-up questions. "Marketing falls outside scope" isn't enough. Explain technically why: no access to production systems, data in separate database, no code deployment.

These are not the only traps. The 7 biggest ISO 27001 pitfalls covers the rest.

Impact of scope choices on your timeline and costs

A smart scope can halve your implementation time. A SaaS startup with one core product and around 25 employees can achieve ISO 27001 in twelve weeks with the right scope.

Direct auditor costs differ little: a broader scope adds one to two days. But internal costs are enormous. Each extra system means writing documentation, reviewing configuration, conducting interviews, and collecting evidence. For a full breakdown of what certification actually costs, see ISO 27001 costs: what does certification really cost your organisation?.

How to determine an effective scope in practice

Start with your client promise and work backwards. What exactly do you promise clients? That their data is secure? That your product is 99.9% available? These promises determine which information assets you must protect.

Create a business impact analysis: per critical asset, assess what happens if it's hacked, leaked, or destroyed. Only assets with significant business impact belong in scope.

Trace dataflows from client interaction to storage. Where does data enter? Which systems touch it? This visualisation shows which systems truly need to be in scope.

Document why things remain out of scope as carefully as what's in. "Marketing website falls outside scope because (1) no customer data is processed, (2) no connection to production infrastructure, (3) no access to sensitive systems."

Practical examples of effective scoping

Startup with one core SaaS product

An analytics platform with 200 clients and a team of 12 certifies their full stack. In scope: Next.js web application, API layer, PostgreSQL database, AWS infrastructure (EC2, RDS, S3), GitHub repository, GitHub Actions, Datadog monitoring, 1Password, and Google Workspace as identity provider.

Out of scope: Framer marketing website (only static content), LinkedIn company page, and Notion (no production data). Total scope: 9 systems, 12 people. Certification achieved in 14 weeks.

Hybrid infrastructure with multiple products

A fintech with 3 products certifies only the payment API. In scope: API layer, transaction database, on-premise HSM, AWS, Kubernetes, GitLab, Jenkins, and Splunk. Teams: backend engineering (6), security (2), infrastructure (3).

Out of scope: client dashboard (read-only replica), mobile app (only uses API), marketing site. Scope: 8 systems plus HSM hardware, 11 people. Certification in 22 weeks due to hybrid complexity.

How Tidal Control helps with scope determination

The platform begins with asset inventory where you directly conduct a business impact analysis. For each asset you answer five questions about confidentiality, integrity, availability, and business impact. Tidal takes the highest of the three scores as the impact level of the asset.

Per asset you conduct a risk analysis where Tidal suggests appropriate controls. These are directly linked to ISO 27001 and SOC 2 requirements. You see per control which Annex A controls or Trust Service Criteria it covers. Tidal's built-in tests flag incomplete risk assessments and unassigned asset owners.

Tests can be linked to controls, and to assets. This will count your in-scope systems. Tests read out security relevant info and evidence automatically from your cloud and IT systems. Besides that, Tidal has tests within the platform to keep track of your general compliance posture. This all saves tens of hours of manual screenshot and search work.

Frequently asked questions

Can you exclude your marketing website from scope? Yes, if it doesn't process customer data and has no connection to production infrastructure. Document the reasoning explicitly: no data processing, no shared credentials, no code deployment path.

Is privacy scopable out of ISO 27001? Not in the same way as SOC 2. ISO 27001 requires compliance with applicable laws including GDPR, so Annex A.5.34 is difficult to exclude unless you can demonstrably show you process no personal data.

Can you scope out privacy in SOC 2? Yes. Privacy is one of the five Trust Service Criteria, and you simply don't select it if you haven't made a privacy commitment to clients.

Can you change your scope mid-audit? Almost never successfully. Invest time in thorough scope definition upfront rather than adjusting boundaries once the audit has started, since this typically causes weeks of delay.

Your next steps

Begin with one question: which information would endanger your business if it were leaked, destroyed, or manipulated? The answer determines 80% of your scope decisions.

Then literally draw your dataflows. From client input to database storage, from API calls to analytics. Each system that touches data is a scope candidate. Each system without data connection can probably stay out of scope.

Once your boundaries are clear, planning your ISO 27001 journey walks through the timeline from kick-off to certificate.

Want to see how your scope compares to standard implementations in your sector? Book an introductory call with our compliance team, or take the free quick scan first.