The request usually arrives from outside. A large customer requires ISO 27001 certification within a year. A tender lists it as a condition. An investor asks for it during due diligence. The organisation, often between twenty and three hundred people, has never had a formal information security management system and needs one quickly.
What happens next determines whether the ISMS becomes a useful way of managing risk or a folder of documents that nobody reads until the next audit.
A familiar situation
A software company of eighty people buys a template package with forty policies and sixty procedures. A project manager spends three months adapting the documents, replacing the placeholder company name and adding a few details. The certification audit is passed, with some minor findings.
One year later, the surveillance audit approaches. Nobody remembers what half of the procedures say. The risk register has not been updated since it was created. Management review was held once, for the audit. The internal audit was outsourced and its findings are still open. The developers see the ISMS as something that belongs to "the compliance person". Preparing for the surveillance audit takes almost as much effort as the original certification.
The company has a certificate. It does not have a management system that works.
Why ISMS projects turn into bureaucracy
The root cause is rarely the standard itself. ISO 27001 is short and fairly flexible. It requires an organisation to understand its context, assess its risks, choose appropriate controls, assign responsibilities, monitor whether it works and improve. It does not prescribe forty policies.
Bureaucracy usually comes from one of these choices:
- The scope is too broad. Everything is included from the start, so every department, location and system has to be covered and evidenced.
- Documents are written before decisions are made. Policies are adapted from templates without first deciding who owns what and how the organisation actually works.
- The ISMS is a project, not a routine. It is built for the audit and has no regular rhythm afterwards.
- Ownership sits with one person. The security officer or quality manager writes, maintains and evidences everything, so the rest of the organisation never takes part.
A proportionate ISMS avoids each of these deliberately.
1. Scope: small, meaningful and certifiable
The scope is the most important decision in the whole project. It defines which parts of the organisation, which services, locations and systems are covered by the ISMS and the certificate.
A good scope for a first certification is narrow enough to manage and broad enough to be meaningful to the customers who asked for it. For a software company, that may be "the development, hosting and support of product X, delivered from the office in Utrecht". Excluding the service the customer cares about makes the certificate worthless to them. Including every internal activity makes the project unnecessarily heavy.
Write down the interfaces: which departments, suppliers and systems outside the scope does the scoped service depend on? These dependencies need to be managed, even if they are not fully inside the scope.
2. Context and interested parties
The standard asks organisations to identify internal and external issues and the requirements of interested parties. In practice, this can be a two-page document that lists customers and their contractual requirements, relevant laws (such as the GDPR and, where applicable, NIS2), key suppliers and the internal factors that affect security, such as growth, remote work or reliance on a single cloud platform.
Keep it specific. "Customers expect security" is not useful. "Three enterprise customers require annual evidence of penetration testing and incident notification within 24 hours" is.
3. A small set of core policies
An SME rarely needs more than a top-level information security policy and a handful of topic-specific policies. A typical set covers acceptable use, access control, supplier security, incident management, business continuity and secure development, if software is developed.
A good policy states what is required and why, and who is responsible. It does not describe every step. A policy of two pages that people have read is more valuable than a policy of fifteen pages that nobody has.
Procedures and work instructions are only needed where consistency matters and the steps are not obvious: onboarding and offboarding, access reviews, handling a reported incident, restoring a backup. Many of these already exist informally. Writing down how it is actually done is usually better than introducing a new process.
4. A risk method people can apply
The risk assessment is the core of the ISMS. Every control decision should be traceable to it. The method should be simple enough that the people who own the risks can take part.
A workable approach:
- Start from the services and information in scope, not from a list of threats.
- For each, ask what could go wrong for confidentiality, integrity and availability, and what the business impact would be.
- Use a small scale for likelihood and impact, with descriptions that mean something to managers. "Customer data of more than 100 clients exposed" is clearer than "impact level 4".
- Assign each risk to an owner in the business who can decide on treatment and accept the residual risk.
Thirty well-described risks with clear owners are more useful than three hundred generic ones copied from a catalogue.
5. The Statement of Applicability
The Statement of Applicability (SoA) lists the controls from Annex A of ISO 27001 and states, for each, whether it is applicable, why, and whether it is implemented. The 2022 version of the standard contains 93 controls grouped into organisational, people, physical and technological themes.
The SoA is often treated as an administrative table. It is more useful to see it as the link between risk and practice. For each applicable control, it should be possible to say which risks it addresses, how it is implemented and where the evidence can be found. For each excluded control, the justification should be specific. "Not applicable" without a reason invites questions from the auditor and usually means nobody has thought it through.
6. Evidence built into normal work
Auditors look for evidence that the ISMS operates, not only that it is documented. In a bureaucratic ISMS, evidence is collected in a rush before each audit. In a proportionate ISMS, it is produced as part of normal work.
Examples: access reviews recorded in the ticket system, onboarding checklists completed in the HR tool, incidents logged in a simple register, supplier assessments stored with the contract, backup restore tests noted with their outcome. Agree in advance where each type of evidence lives and who produces it. Then the audit becomes a matter of showing what already exists.
7. Internal audit
ISO 27001 requires an internal audit programme. For a small organisation, that can be one audit per year covering the whole ISMS, or a few shorter audits spread over the year. The internal auditor must be objective, which means they should not audit their own work. Smaller organisations often use an external party or a colleague from another department who has received some training.
The value of the internal audit lies in the findings and what is done with them. An audit that finds nothing in a young ISMS has probably not looked closely.
8. Management review
Top management must review the ISMS at planned intervals. This is not a formality. It is the moment when management sees whether the risks are under control, whether objectives are met and whether resources are sufficient, and makes decisions about them.
A management review of an hour, twice a year, with a short report covering risk status, incidents, audit results, supplier issues and open actions, is usually enough. What matters is that decisions are recorded and followed up.
9. Certification
Certification usually takes place in two stages. In Stage 1, the certification body reviews the documentation and checks whether the organisation is ready. In Stage 2, it assesses whether the ISMS is implemented and effective in practice. Most certification bodies expect the ISMS to have been operating for some time before Stage 2, typically with at least one internal audit and one management review completed.
For a clearly bounded scope with engaged management and a reasonable existing baseline, the path from start to readiness for certification often takes around three to five months. It takes longer when the scope is broad, when management is not available for decisions, or when technical gaps such as missing logging or weak access management have to be closed first.
10. After certification
The first certificate is the start of a three-year cycle, with surveillance audits in the first and second year and a recertification audit in the third. The ISMS that passes these audits easily is the one that has become routine. A simple annual calendar helps: risk review per quarter, access reviews at fixed moments, supplier reassessments based on their classification, internal audit in the spring, management review twice a year. When these activities are planned and assigned, evidence for the auditor is produced along the way.
This is also the moment to consider whether the scope should grow. Many organisations start with one service or location and extend the scope once the ISMS works. That is usually a better route than starting broad, because the second part benefits from everything learned in the first.
The role of management
The standard places clear responsibilities with top management: establishing the policy and objectives, providing resources, assigning roles and reviewing the ISMS. In smaller organisations, the director is often also the person who approves budgets, owns the most important risks and speaks to the customers who asked for the certificate. Their involvement is not a formality. An ISMS where management attends one meeting a year and signs documents prepared by others tends to drift. An ISMS where management takes risk decisions, asks about progress and follows up on audit findings tends to work, because the rest of the organisation sees that it matters.
This does not have to cost much time. A few hours per quarter is usually enough, as long as those hours are used for decisions rather than for presentations.
Common mistakes
- Choosing a scope based on what is easy to certify rather than on what customers need.
- Copying templates without adapting them to real roles and processes.
- Treating the risk assessment as a one-time exercise.
- Letting the security officer own all risks instead of advising the business owners.
- Planning internal audit and management review only just before the certification audit.
- Forgetting that suppliers inside the scope need to be assessed in proportion to their risk.
Three things to do before you start
- Write a one-paragraph scope and check it with the customer or tender that triggered the request. Make sure it covers what they care about.
- Name the risk owners for the services in scope. If nobody in management is willing to own them, solve that before writing any documents.
- List what already exists: processes, tools, logs and records that can serve as evidence. Build on these rather than replacing them.
Conclusion
ISO 27001 does not require bureaucracy. It requires a clear scope, an honest view of risk, controls that follow from that risk, people who own them and a regular rhythm to check whether it works. For smaller organisations, the most efficient route is to keep the scope controlled, document only what is needed and build evidence into normal work from the start.
FLODISQ offers an ISO 27001 Fast Track for SMEs built on exactly these principles. When the ISMS is in place, people need to know their part in it. Role-based training for risk owners and managers helps to make the system work outside the security team.