A customer sends a procurement questionnaire. It asks for ISO/IEC 27001 certification. Your first instinct is to move quickly, cover everything, and demonstrate that your company takes security seriously. That instinct, however understandable, is where most small teams go wrong.
The scope of your Information Security Management System, or ISMS, is not a formality. It is the single decision that determines how much preparation work you will carry, how much evidence you must produce, and how much the process will cost. Get it wrong at the start and you will pay for it twice: once in wasted preparation effort, and again when you discover the gaps you cannot close before the deal deadline.
This post is about how to get that decision right.
Start Where the Requirement Actually Starts
Before you open a policy template or assign a control owner, read the customer's requirement carefully. Not the ISO/IEC 27001 standard itself, and not a generic controls checklist. The requirement the customer sent you.
Ask three things about it. Which part of your business does it cover? Which product or service is the customer concerned about? And which locations or systems does that product touch?
A customer requirement for ISO 27001 certification on your core SaaS product does not automatically extend to your internal HR processes, your finance systems, or the side project your engineering team is prototyping. The standard requires you to define a scope that reflects your actual environment. It does not require that scope to be your entire company.
This is where over-scoping becomes expensive. Teams read the customer requirement, assume it means everything, and build an ISMS that spans far more than the customer's actual concern. The controls multiply. The evidence gaps multiply with them. The team runs out of time.
Start with the requirement. Confirm the product, the company boundary, and the locations it covers. Then work inward.
What a Well-Defined Scope Actually Looks Like
A well-defined scope is narrow enough to be manageable and accurate enough to satisfy the customer. Those two things are not in conflict. They reinforce each other.
For a pre-seed SaaS team of 15 to 30 people with a single cloud-hosted product, a realistic scope might cover the product itself, the infrastructure it runs on, the team members who access production systems, and the processes that govern how data is handled. That is a bounded, honest description of where information security risk actually lives.
The ISO/IEC 27001 standard requires you to assess which of its 93 Annex A controls are relevant to that scope and to justify the ones you exclude. This document is called the Statement of Applicability, or SoA. A small team with a narrow, accurate scope will produce a shorter SoA than a large enterprise. That is not a weakness. That is a correctly scoped system.
Tailoring your policies to that actual scope is how small teams keep their preparation manageable. A generic template applied to a poorly defined scope produces policies that describe nothing real and evidence gaps that nobody can close.
Evidence Gaps Are a Signal, Not a Problem to Hide
Once your scope is defined, the preparation work becomes concrete. You are no longer asking "what does ISO 27001 require?" in the abstract. You are asking what your team already does inside that scope, what records support those practices, and what is genuinely missing.
Those three questions produce a gap list. A well-scoped ISMS produces a gap list that a small team can work through. An over-scoped ISMS produces a gap list that nobody owns and nobody finishes.
The gap list is useful precisely because it is honest. An uploaded policy document does not prove that a practice occurred. A dated record, owned by a named person, linked to the claim it supports, does. When a gap appears in your evidence, the right response is to name it, assign it, and decide whether it falls inside your scope at all.
If a gap falls outside your defined scope, it is not your gap to close for this preparation. That is why scope definition comes first.
Use Guided Interviews to Surface What You Already Do
Most small teams have more relevant practices than they realise. Access controls, change management, incident response, backup routines: these often exist in some form, even in early-stage companies. The problem is that they live in people's heads, in Slack threads, or in informal conventions that nobody has written down.
Guided interviews are a practical way to surface this context. Rather than starting with a blank policy template or a 93-item controls list, structured questions about your actual environment draw out what your team already does: how you manage access, where your data lives, who can reach production, and how you handle a security incident when one occurs.
The answers to those questions build a picture of your current state. That picture sits alongside your scope definition and your gap list. Together, they show you where preparation effort is genuinely needed and where existing practice simply needs to be recorded and evidenced.
Sinope's guided preparation process is built around this approach. The product is in development, with ISO 27001 as the first complete preparation path. Structured questions collect your company context. Organised records show your evidence and your gaps. Your team makes the decisions. An independent certification body decides certification.
Preparation Costs and Audit Fees Are Separate
One of the most common points of confusion for founders approaching ISO 27001 for the first time is the cost structure. Preparation and independent certification are distinct processes with distinct costs, and conflating them leads to budget surprises that derail timelines.
Preparation covers the work of defining your scope, assessing your controls, closing your evidence gaps, and building the documentation your ISMS requires. This is the work that Sinope supports. Our target preparation fee is EUR 5,000. Final scope and terms need confirmation.
Independent audit fees are separate. A UKAS-accredited or equivalent certification body conducts a two-stage audit of your ISMS. Their fees depend on your scope, your team size, and the certification body you choose. Implementation costs, including any tools, infrastructure changes, or specialist time your team requires, are also separate.
Understanding this distinction before you begin means you can budget honestly and avoid the situation where a quote for the full process arrives and resets your planning from scratch. If you want a clear breakdown of what preparation will cost for your specific context, you can request one at sino.pe.
The Scope Decision Is the Preparation
Founders sometimes treat scope definition as a preliminary step, a form to fill before the real work starts. It is the opposite. The scope decision is the preparation. Everything that follows, the controls assessment, the SoA, the evidence collection, the gap list, the policy tailoring, depends on what you put in scope and what you leave out.
A scope that is wider than your customer requirement demands means more controls to assess, more evidence to produce, more gaps to close, and more audit time to fund. None of that additional work is required by the customer. It is carried by your team, at your cost, against your deal deadline.
A scope that accurately reflects the product, the systems, and the people the customer is concerned about gives your team a preparation effort they can actually complete. The gap list is manageable. The evidence is findable. The policies describe something real.
Start with the customer requirement. Confirm what it covers. Define your scope from there, and build inside it.
If you are facing a first ISO 27001 requirement and want to understand what preparation will involve for your specific context, a 30-minute conversation is a practical next step. Jaimie reviews these calls personally and focuses on the requirement in front of you, not a generic checklist.