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 three months and one of nine months. Between documenting ten systems and fifty. 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. This isn't a trick—it's explicitly permitted by both standards.

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.

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 vs 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.

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.

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. 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—your website with tracking, 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.

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 fifteen employees can achieve ISO 27001 in twelve weeks with the right scope. The same startup that also includes their blog, marketing automation, and analytics stack needs six months.

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.

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 three 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. The system calculates from this a criticality score: high, medium, or low risk.

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. The platform warns if you've missed requirements.

Automatic evidence linking per scope component means evidence is only collected for in-scope systems. Configure which AWS services are in scope, and monitoring automatically retrieves only relevant configurations and logs. This saves dozens of hours of manual screenshot work.

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.

Want to see how your scope compares to standard implementations in your sector? Contact us for a 30-minute scope review. We'll show you where other businesses draw their boundaries and how they halved their implementation time with smart scoping.