A policy library gives you documents. It does not give you proof.
That distinction matters more than most founders realise when they receive a first ISO 27001 customer requirement. The instinct is to move fast: find a platform with a pre-built template library, download the policy pack, and feel further along on day one. The problem is that feeling further along is not the same thing as being further along.
Real customers doing real due diligence check both.
What a senior reviewer is actually looking for
When a customer's security team reviews your documentation, they are not skimming for familiar policy headings. They are checking whether what the document describes matches how your company actually operates. Fortune 100 procurement teams often include CISOs who review each vendor personally, because their professional reputation depends on every vendor decision they sign off on. A well-formatted policy document does not satisfy that review. Evidence that the policy is followed does.
The gap between those two things is where most first-time ISO 27001 preparation efforts stall.
A policy can say your team performs quarterly access reviews. The reviewer wants to see a dated record of the last review, the name of the person who owns it, and what changed as a result. If that record does not exist, the policy is a description of intent, not a demonstration of practice. Experienced reviewers know the difference quickly.
The template iteration problem
Pre-built policy libraries are built for a generalised company. Your company is not a generalised company. It has a specific tech stack, a specific set of devices, a specific way of handling customer data, and a specific geographic footprint. A template written for that generalised company needs to be reworked before it accurately describes your practices.
This is not a minor editing task. Atlas Cloud documented this experience in their ISO 27001 preparation work: even starting from a template, they had to iterate on their policies several times before the documentation actually fit how their organisation operated. That iteration is the real preparation work. The template is not a shortcut around it. It is just a starting point that still requires the same thinking.
When a generic policy ships with controls and language that do not match your actual scope, it creates a different problem. You now have documentation that makes claims your evidence cannot support. That is harder to fix than a blank page, because it creates the appearance of readiness without the substance.
Scope first, documentation second
The more useful starting point is understanding your actual scope before generating any documentation. That means describing how your company operates: the technology you use, the devices in play, the locations where work happens, and where risk genuinely sits.
This matters because ISO/IEC 27001, the formal name of the standard, includes 93 controls across its Annex A. A Statement of Applicability, or SoA, requires you to document which controls apply to your organisation and why. Not every control applies to every business. A small B2B software team with no physical product and a cloud-native infrastructure has a materially different scope than a managed services provider handling on-premise infrastructure for enterprise clients.
If you start from a pre-built library that assumes a scope before it knows yours, you risk generating policies for controls that simply do not apply. That over-builds your documentation in some areas and can leave real gaps in others, because the template was not designed around your actual risk profile.
Getting scope right first means you stop before you generate policies where there is no clear risk. It also means the policies you do produce are grounded in what your company actually does, which makes the evidence question answerable rather than embarrassing.
Evidence is the actual work
The clearest way to describe the preparation challenge is this: documentation describes what you do, and evidence demonstrates that you did it.
Reviewers need both. An uploaded policy satisfies the first requirement. A dated record, an owner, and a traceable action satisfy the second. Preparation that produces only the first is incomplete, regardless of how comprehensive the policy library looks.
This is why scope-first, interview-led preparation produces more useful output than starting from a template. When you describe your actual practices before generating documentation, the documentation is more likely to describe something you can support with real records. The gap between what the policy claims and what the evidence shows becomes smaller, because the two were developed in relation to each other rather than independently.
What Sinope is building
We are developing Sinope to help small B2B and AI startup teams prepare for ISO 27001 through guided interviews and organised evidence review. The interview process collects context about how the company operates before producing any documentation. The goal is to make sure the preparation work reflects your actual scope, not a generic assumption about what your scope might be.
Sinope supports human review and decision-making. An independent certification body makes the certification decision. We do not certify. We help you prepare in a way that is honest about what you have, explicit about what is missing, and clear about what needs to happen next.
Our target preparation fee is EUR 5,000. Independent audit fees and implementation costs are separate. Final scope and terms need confirmation.
A practical next step
If you have received a customer security requirement and you are trying to understand what preparation actually costs and what it involves, request a cost breakdown at sino.pe. We review every request before we reply, because the answer depends on your scope, your current practices, and how far along you already are.
If you want to talk through the requirement before filling in a form, Jaimie offers a 30-minute call for founders and CTOs who have a specific customer need in front of them. Bring the requirement and a short description of your current practices. That is a more useful starting point than a checklist.
The preparation question is not how many policies you have. It is whether the evidence supports what those policies describe.