A policy template is a starting point, not a destination. Most teams download one, fill in the company name, and assume the work is done. It is not. The template describes a generic company. Your company is not generic. Until the policy reflects what your team actually does, it is decorative paperwork, and a certification auditor will see through it quickly.
Tailoring a policy template is not about rewriting it from scratch. It is about making it accurate. That distinction matters, because accuracy is what an auditor reviews. A policy that describes a practice your team does not follow is worse than no policy at all. It creates a gap with a label on it.
This guide walks through the steps we recommend for AI and B2B software startups preparing for their first ISO 27001 requirement, particularly teams without a dedicated GRC (Governance, Risk and Compliance) lead.
Start With the Customer Requirement, Not the Template
Before you open a policy document, read what your customer actually asked for. This sounds obvious, but most teams skip it. They treat "ISO 27001" as a uniform requirement and immediately begin writing policies across the whole company.
The customer requirement usually contains more detail than the headline standard. It may specify which systems must be in scope, which data types are covered, whether a specific Annex A control matters to them, or when they expect evidence. That detail shapes everything that follows. Reading it carefully is the first practical step.
Once you understand the requirement, confirm the scope of your own business that it covers. Which product, which team, which locations, which data flows. ISO 27001 certification applies to a defined scope, not your entire company by default. Defining that scope narrowly and accurately is how small teams avoid the preparation trap we have written about before: over-scoping your ISMS framework turns a manageable preparation effort into one that nobody can close before the deal deadline.
Identify What Your Team Actually Does Before Adapting Anything
This is the step that determines whether your policies are real or fictional.
Before you change a single line in a template, describe your actual practices. How does your team manage access to production systems? Who approves a new vendor? Where does customer data live, and who can reach it? What happens when an engineer leaves? How do you handle a suspected security incident today, even if the process is informal?
Write down what happens, not what should happen. The distance between those two descriptions is your evidence gap. Policies close that gap only when they describe the real practice and a record supports the description.
Use guided interviews to gather this information across your team. Structured questions work better than open-ended ones, because they surface specifics: names, systems, dates, file locations. A guided interview approach is central to how Sinope is built, because unstructured conversations tend to stay at the level of intention rather than evidence. Intention does not satisfy an auditor.
When you have a clear picture of your current practices, you are ready to open the template.
Adapt the Template to Reflect Reality
A good policy template covers the right territory. Your job is to make it accurate for your context.
Work through each section and ask three questions. Does this describe what we actually do? Is there a record that supports this description? Who owns the next action if this is not yet true?
Where the template describes a practice you follow, confirm the language matches your environment. If the template refers to "the IT department" and your startup has no IT department, replace that phrase with whoever actually owns the function. Precision here is not pedantry. An auditor reading a policy that references roles or systems that do not exist in your company will ask why.
Where the template describes a practice you do not yet follow, do not delete the section. Mark it as a gap. Assign an owner and a target date. An honest gap with a clear next step is more useful than a polished policy that describes something fictional.
Where the template includes controls that are irrelevant to your scope, note that explicitly. An Information Security Management System (ISMS) includes a Statement of Applicability (SoA), which is the document that records which ISO 27001 Annex A controls apply to your organisation and why. If a control does not apply, state that and give a reason. "Not applicable because we do not operate physical server infrastructure" is a complete and acceptable answer. Silence is not.
Keep Ownership Clear and Testable
A policy without an owner is an intention. Assign a named person to each policy. That person is responsible for the practice the policy describes, the evidence that supports it, and the next review date.
The review date matters more than most teams expect. Policies go stale quickly in early-stage startups. The team structure changes. The product changes. The infrastructure changes. A policy written for a twelve-person team may be inaccurate six months later when the team reaches thirty.
Set a review cadence that matches your rate of change. For most pre-seed teams we work with, quarterly is more realistic than annual. The review does not need to be a formal exercise. It needs to confirm that the policy still describes reality, that the supporting evidence exists, and that the owner is still the right person.
Testability is the other requirement. For each policy, ask whether you could demonstrate the practice to an external reviewer. If you cannot show dated records, logs, approvals, or another form of evidence, the policy cannot be verified. An uploaded document is not evidence of a practice. A dated record of the practice is.
This connects directly to what Sinope's guided preparation process is designed to do: move teams from described intentions to organised, auditable evidence.
Avoid Unnecessary Complexity
The pressure to cover everything is understandable. A customer asked for ISO 27001. The standard has 93 Annex A controls. The instinct is to address all of them.
Resist it. The standard requires you to assess which controls are relevant to your scope and justify the ones you exclude. It does not require you to implement every control regardless of relevance. A small SaaS team with no physical offices, no on-premise servers, and a tightly defined product scope will have a shorter, more accurate SoA than a large enterprise. That is correct, not incomplete.
Complexity that does not serve your actual risk environment creates two problems. It generates evidence requirements your team cannot meet before the deadline. And it produces an ISMS that nobody owns in practice, because the scope is too broad for the team that needs to maintain it.
Practical preparation means starting with the controls that are clearly relevant, documenting them accurately, and closing genuine gaps. Add controls when the risk or the customer requirement justifies them, not to signal effort.
Review as the Company Changes
Policy work does not end at certification. Your ISMS is a description of how your company manages information security right now. As the company changes, the description must change with it.
New systems, new team members, new customer data types, new vendors, new markets all affect the accuracy of your existing policies. Build the habit of treating a policy review as part of the same rhythm as a product retrospective. Brief, specific, and focused on what changed.
This is especially relevant for AI and B2B software startups. The operational environment changes faster than most traditional compliance frameworks assume. A policy reviewed annually in a company that ships weekly will drift out of accuracy quickly.
Treat the review as a check on reality, not a compliance ritual. If the policy still describes what you do, confirm it and move on. If it does not, update it and make sure the evidence follows.
Policy templates are tools. The work is making them accurate. Start with what your customer requires, describe what your team actually does, close the gaps with evidence, and keep ownership visible. That is what preparation looks like in practice.
If you are working through your first ISO 27001 customer requirement and want to understand what preparation would cost for your scope, request a cost breakdown at sino.pe. We review every request before we reply.