A customer security requirement lands in your inbox. The contract depends on it. Your team is somewhere between 12 and 35 people, and nobody has a dedicated GRC (Governance, Risk and Compliance) lead to hand it to. The requirement is real. The deadline is real. The instinct to move fast is understandable.
The problem is that moving fast without a clear method usually produces one of two outcomes: you over-prepare and spend months on work the customer never required, or you under-prepare and arrive at an audit without the records to support your claims. Both outcomes cost more than the preparation itself.
This guide describes a practical sequence for AI and B2B software startups preparing for ISO 27001 without a dedicated GRC function. The steps follow the logic of the standard, not the logic of a checklist vendor. Each step builds on the one before it.
Step 1: Read the customer requirement before you do anything else
The first step is not a tool purchase or a policy download. It is a careful reading of what the customer actually asked for.
ISO/IEC 27001 is a formal standard for an Information Security Management System (ISMS), which is the documented set of policies, practices, and controls your organisation uses to manage information security risks. Certification to the standard requires an assessment by an independent certification body. The customer requirement may ask for full certification, or it may ask for evidence of preparation, or it may ask for a specific subset of controls. These are not the same thing, and the distinction shapes every decision that follows.
Confirm three things before you begin preparation work. First, which product, service, or part of your business does the requirement cover. Second, what locations and systems does it include. Third, what is the timeline, and does the customer require completed certification or documented progress toward it.
The answers define your scope. The scope defines your workload. Starting before you have those answers is how teams end up defining an ISMS boundary that is far wider than the customer's actual concern.
Step 2: Collect your company context through structured questions
Once you know what the requirement covers, the next task is to describe your actual environment with enough specificity to assess it. This is where most small teams stall. A blank policy template does not help. A long list of 93 Annex A controls is not a useful starting point either.
The approach that works for small teams is a structured set of questions about how your company actually operates. Not how you intend to operate, and not how a generic software company might operate. How your specific team works today.
The questions that matter most at this stage include the following.
- How does your team work, and where are team members located?
- What systems do you use to build, host, and operate your product?
- Where does customer data live, and who has access to it?
- What security practices does your team already follow, even informally?
- What third-party vendors or cloud providers sit inside the boundary of what the customer requires?
The answers to these questions form the context that the rest of your preparation depends on. They tell you which controls are genuinely relevant to your environment and which ones can be excluded with a clear justification. ISO 27001 requires you to assess relevance and document your reasoning in a Statement of Applicability (SoA), which is the formal record of which controls apply to your scope and why. A well-grounded context makes that document accurate. A generic one makes it decorative.
Sinope's guided interview flow is designed to collect this context in a structured way, asking questions that surface your actual environment rather than prompting you to describe an idealised version of it. The product is in development, with ISO 27001 as the first complete preparation path.
Step 3: Identify what you already do and record it properly
Many small teams assume ISO 27001 preparation means creating new practices from scratch. For most AI and B2B startups, that assumption is wrong. The practices often exist. The records do not.
Your engineers probably follow a change management process, even if it is informal. Access to production systems is probably restricted to a small group. Vendor agreements probably exist somewhere. These are practices that support your ISMS. The gap is that they are not documented as evidence.
The distinction matters because an auditor reviews evidence, not intention. A policy that describes a practice your team does not follow is not evidence. A policy that describes a practice your team does follow, supported by a dated record and an identifiable owner, is.
For each area that falls within your scope, the task is to describe what actually happens, identify the record that supports that description, and confirm who owns that process. This approach, focused on describing existing practices before writing new ones, is also what tailoring policy templates to your actual environment depends on. The template gives you the structure. Your context and your records give it meaning.
Keep this work grounded. An uploaded document does not prove a practice occurred. A dated record, linked to the claim it supports, with a named owner, is the unit of evidence that holds up under review.
Step 4: Make your gaps explicit and assign the next action
After you have documented existing practices and the records that support them, the remaining work becomes visible. Some controls will be well-evidenced. Others will have no record at all. A few will have a policy but no supporting evidence. This gap analysis is the foundation of your preparation plan.
The useful way to treat a gap is not to hide it behind a completion percentage or a traffic-light status. Name it plainly. Describe what is missing, who needs to act, and what a completed record would look like. Assign one owner. Set a realistic date.
This matters for two reasons. The first is operational: gaps without owners stay open. The second is practical for audit preparation: an auditor will find the same gaps you find, and arriving with a documented plan for each one is far more credible than arriving with unexplained blanks.
Sinope's evidence organisation is designed to make gaps visible in exactly this way. Rather than surfacing a percentage score, it shows you which claims are supported by records and which are not, so your team can act on the actual state of preparation rather than an abstraction of it.
A note on what gap analysis does not do: it does not close the gaps for you, and it does not substitute for the decisions your team must make. Evidence assessments support human review. The certification decision belongs to an independent certification body, not to any software tool.
Step 5: Keep preparation costs separate from audit fees
Preparation and certification are two separate processes with two separate cost structures, and conflating them is one of the most common sources of budget confusion for founders going through this for the first time.
Preparation covers the work of understanding your scope, documenting your practices, building your evidence base, and addressing your gaps. Sinope's target preparation fee is 5,000 EUR. Final scope and terms need confirmation.
Independent audit fees are separate. They are paid to an accredited certification body that conducts the external assessment. Implementation costs, such as new tooling, vendor agreements, or engineering time spent on controls work, are also separate.
Understanding this structure before you begin makes it easier to present a realistic cost to your board or co-founders, and it prevents the common mistake of treating a preparation quote as an all-in number.
If you want a breakdown that reflects your specific scope, locations, and current state of readiness, you can request a cost breakdown at sino.pe. We review each request before we reply.
A practical first step
The sequence above is not complex. Read the requirement, collect your context, describe what you already do, name your gaps, and keep your cost structure clear. What makes it hard for small teams is that each step requires time that founders and CTOs are already spending on product and customers.
That is the gap Sinope is designed to close: a guided process that collects your context, organises your evidence, and makes your gaps actionable, without requiring a dedicated GRC lead to operate it.
If you have a customer requirement in front of you and want to understand what preparation would involve for your specific environment, a 30-minute conversation with Jaimie is a practical next step. The call focuses on the requirement you have, not a generic readiness checklist.