Most ISO 27001 projects that stall do not stall on the controls. They stall because the scope was wrong from the start, and every decision built on it inherited the problem.
Before scope, though, comes a simpler question that is skipped more often than any other: why are you doing this at all?
The answer shapes the scope. The scope determines which risks you assess. The risks determine which controls you need. The controls determine what you implement, document, audit and maintain for as long as you hold the certificate. Get the reason and the scope right and the rest of the standard becomes a series of logical steps. Get them wrong and you spend months implementing controls that do not fit the business, or discover at audit that the certificate does not cover the part of the organisation your customer actually cared about.
This guide follows that order: why, then scope, then everything they drive, then what it takes to keep the system working once you are certified.
What ISO 27001 actually is
ISO/IEC 27001 is an international standard for an information security management system: the policies, processes, responsibilities and controls an organisation uses to manage risks to the information it holds.
The distinction worth understanding early is that it is a management system standard, not a checklist. It does not tell you to install particular products or configure particular settings. It requires you to understand your risks, decide how to treat them, implement proportionate controls, and demonstrate that the whole arrangement is managed, measured and improved over time.
That is why two certified organisations can look quite different. A twelve person consultancy and a two hundred person manufacturer can both be fully compliant, with very different controls, because their scopes and risks are different.
The current version is ISO/IEC 27001:2022. Its structure has two parts: the main clauses, which describe what the management system must do, and Annex A, a reference set of 93 information security controls from which you select those relevant to your risks.
Step one: be clear about why you are implementing it
An information security management system is a significant commitment, and it goes considerably better when everyone involved understands what it is meant to achieve. Before anything else, write down the problem you are trying to solve.
For most organisations the reason is one of these, or a combination:
- A tender or contract requires it. A customer or framework has made ISO 27001 a condition of doing business. This is the most common trigger, and it is a perfectly good one.
- It helps you win work. Nobody has required it yet, but you are competing against organisations that hold it, or bidding for work where demonstrating how you manage information security is a differentiator.
- Your clients expect it. Existing customers are asking increasingly detailed security questions in their supplier assessments, and a certified management system answers most of them at once.
- You want genuine assurance. Leadership wants confidence that information security is being managed properly, independently of any external demand.
- Regulatory or contractual obligations make a structured, evidenced approach sensible even where certification is not strictly required.
It does not matter which of these applies. What matters is knowing, because the reason has direct consequences.
It shapes the scope. If a particular customer requires certification of a particular service, that service has to be inside the boundary. If the aim is winning a class of tenders, the scope needs to cover what those tenders will examine.
It sets the timeline. A tender deadline and a desire for better assurance produce very different project plans.
It keeps leadership engaged. The standard requires top management to be involved, not merely informed. Directors who understand the commercial or risk reason for the work support it; directors who see it as a compliance exercise tend to disengage once the certificate arrives.
It prevents a system nobody runs. An organisation that implements ISO 27001 purely to obtain a certificate, without a clear view of what it should achieve, often ends up with documents that describe an ideal nobody follows. The first surveillance audit usually finds that out.
Step two: define your scope properly
This is the step to spend time on, because it is the one that is hardest to change later.
The standard requires you to determine the boundaries and applicability of the management system, and to document the result. That scope has to take account of three things.
The issues that affect you. The internal and external factors relevant to your purpose and to information security: your market, your regulatory position, your technology, your size, the threats you face.
What interested parties require of you. Customers, regulators, suppliers, insurers, staff and anyone else whose requirements are relevant. A customer contract demanding certification of a particular service is exactly the kind of requirement that shapes scope.
Interfaces and dependencies. Where your activities meet those performed by other organisations: the cloud platform you host on, the managed service provider running your infrastructure, the outsourced payroll bureau. These are the edges of your scope, and they have to be understood rather than ignored.
What a scope statement should settle
A useful scope answers, in plain terms:
- Which parts of the organisation are included: the whole business, particular divisions, particular services or products
- Which locations are included, including remote and home working arrangements
- Which information and systems are within the boundary
- Which people are covered, including contractors
- What the exclusions are, and why they are justified
The three most common scope mistakes
Too broad, too soon. Certifying the entire organisation on the first attempt is admirable and frequently the reason projects run for eighteen months. A well-defined scope covering the services your customers care about can be certified first, then expanded.
Too narrow to be useful. The opposite error: a scope drawn so tightly that it excludes the systems your customers actually rely on. The certificate exists, but it does not answer the question the customer was asking. Anyone reading your certificate can see the scope statement, so a carve-out that removes the interesting part is visible.
Ignoring the dependencies. Outsourced services do not leave scope because someone else operates them. You remain responsible for managing the risk they introduce, which usually means supplier assessment, contractual security requirements and evidence that you monitor them.
Your reason defines your scope. Scope defines what you are protecting. What you are protecting defines your risks. Your risks define which controls you need. Every later decision inherits the first ones, which is why an hour spent on the reason and the scope saves weeks of implementing controls that do not fit.
Step three: assess your risks
With the scope defined, you assess the risks to the information inside it.
The standard requires a defined, repeatable risk assessment methodology, so that results are consistent and comparable over time. In practice that means agreeing in advance how you will identify risks, how you will judge their likelihood and impact, and what level of risk the organisation is prepared to accept.
The assessment then identifies risks to the confidentiality, integrity and availability of the information in scope, assigns an owner to each, and evaluates them against your criteria. The output is a risk register that becomes one of the central working documents of the whole system.
A common error here is producing an exhaustive generic list rather than an honest assessment of your risks. Forty carefully considered risks relevant to your business are worth more than four hundred copied from a template, and they are considerably easier to maintain.
Step four: select your controls
For each risk, you decide how to treat it: reduce it with controls, avoid it by changing what you do, transfer it (through insurance or contract, for example), or accept it within your defined appetite.
Where you choose to reduce risk, you select controls. The standard requires you to compare the controls you have chosen against Annex A to confirm you have not overlooked anything necessary.
The 2022 version organises its 93 controls into four themes:
| Theme | Controls | Examples |
|---|---|---|
| Organisational | 37 | Policies, roles, supplier relationships, incident management, threat intelligence |
| People | 8 | Screening, awareness and training, terms of employment, remote working |
| Physical | 14 | Secure areas, equipment protection, clear desk, physical security monitoring |
| Technological | 34 | Access control, secure configuration, logging, backup, secure development |
The Statement of Applicability
The result of that comparison is recorded in a Statement of Applicability: a document listing every Annex A control, whether it applies to you, whether it is implemented, and the justification for including or excluding it.
This is where scope and risk pay off. A control is included because a risk in your scope requires it, and excluded because no risk in your scope does. An auditor will read that justification closely, and “not applicable” without a reason is one of the most frequent findings at certification.
The Statement of Applicability is also the document your customers most often ask to see, because it shows exactly which controls you operate.
Step five: implement and document
Now you implement the controls you selected and document what the standard requires.
The documented information the standard asks for includes, among other things: the scope, the information security policy, the risk assessment and treatment process and their results, the Statement of Applicability, information security objectives, evidence of competence, the results of monitoring and measurement, the internal audit programme and results, management review results, and records of nonconformities and corrective actions.
Two principles keep this manageable.
Document what you actually do. A policy describing an ideal nobody follows is worse than no policy, because it becomes a nonconformity the moment anyone checks. Write to reflect reality, then improve the reality.
Keep the distinction between policy and procedure. A policy states what the organisation intends and why. A procedure states how, when and by whom it is done. Mixing the two produces documents that are too detailed to approve and too vague to follow.
Step six: prove it works before the auditor arrives
Two activities are required before certification, and both are genuinely useful rather than formalities.
An internal audit. An objective review of whether the management system meets the standard and your own requirements, and whether it is effectively implemented. It must be carried out by someone who does not audit their own work, which is one of the most common reasons organisations bring in external support at this point.
A management review. Top management reviewing the performance of the system, its risks, the audit results and the opportunities for improvement, and making decisions. The standard is explicit that leadership must be involved; an information security management system that the directors have never looked at will not certify.
Findings from both should be recorded and addressed through corrective action before you book the certification audit.
Step seven: the certification audit
Certification is carried out by an accredited certification body. In the UK, look for accreditation by UKAS, which is what gives the certificate its standing.
The audit is in two stages. Stage one reviews your documentation and readiness: whether the scope, risk assessment, Statement of Applicability and required documents are in place. Stage two assesses whether the system is actually implemented and effective, by examining evidence, interviewing people and sampling records.
Nonconformities raised at stage two need to be addressed, with evidence, before certification is granted.
Maintaining it afterwards
This is the part organisations underestimate. The certificate is not the finish line; it is the start of a three year cycle.
Annual surveillance audits. In each of the two years following certification, the certification body returns to confirm the system is still operating. Surveillance audits sample the system rather than repeating stage two in full, but they will look for evidence that the processes have continued, not just that they existed on the day of certification.
Recertification in year three. A fuller reassessment to renew the certificate for a further cycle.
In between, the system has to keep running. That means:
- Keeping the scope current. New services, new locations, new suppliers and acquisitions all change what is in scope. A scope statement written three years ago rarely still describes the business.
- Revisiting risks. At planned intervals, and whenever something significant changes. The risk register is a working document, not an archive.
- Running the internal audit programme across the cycle, so every part of the system is examined, not just the easy parts.
- Holding management reviews at planned intervals, with leadership genuinely engaged.
- Managing nonconformities and corrective actions as they arise, rather than saving them for the audit.
- Measuring whether controls work, against the objectives you set, so improvement is based on evidence.
Organisations that treat ISO 27001 as a project to finish tend to struggle at their first surveillance audit, because the system stopped running the week after certification. Organisations that treat it as the way they manage information security find the audits largely take care of themselves, because the evidence is being produced as a matter of course.
How long does it take?
It depends almost entirely on scope, and on how much already exists. An organisation with a clear, contained scope and reasonable existing practices can typically move from start to certification in a matter of months. A broad scope, an organisation starting from very little, or limited internal time for the work extends that considerably.
The factors that most influence the timeline are the breadth of the scope, the maturity of existing security practices, how much internal time is available, and how quickly decisions can be made and signed off by leadership.
Where ISO 27001 sits alongside Cyber Essentials
They answer different questions. Cyber Essentials certifies five technical controls across your organisation; ISO 27001 certifies how you manage information security as a whole. Many organisations hold both, and Cyber Essentials frequently provides useful evidence for several Annex A technological controls. We compare them properly in Cyber Essentials vs IASME Cyber Assurance vs ISO 27001.
How Malwise helps
We are not a certification body for ISO 27001, and we will not certify your management system. That independence is deliberate: the organisation that helps you build a system should not be the one that certifies it.
What we do is help you get there and stay there:
- Gap analysis against ISO 27001:2022, so you know where you stand before committing to a timeline
- Scoping support, starting with what you need the management system to achieve, which is where we would always recommend beginning
- Implementation support, from risk methodology and Statement of Applicability through to policies and procedures written to reflect how you actually work
- Independent internal audit, before certification and across the three year cycle, carried out by someone who has not audited their own work
- Ongoing support through surveillance and recertification
Our work is informed by building and operating these systems in practice, including in defence environments where scope, evidence and accountability are examined closely.
If you are considering ISO 27001, or already hold it and want an independent view before your next surveillance audit, get in touch or call 01722 445972. More detail is on our ISO 27001 consultancy page.