Introduction
Preparing for ISO/IEC 27001 is a management exercise, not simply a search for security policies. It requires understanding what information matters to the organization, who is accountable for protecting it, how risks are assessed, and how decisions are reviewed over time.
This guide is a practical starting point for discussing an information security management system (ISMS). It does not replace the official standard, professional interpretation of its requirements, or an independent certification audit.
Clarify the purpose and expected outcome
Start by asking why the organization wants an ISMS. The driver might be customer confidence, more consistent risk management, contractual expectations, operational resilience, or a formal certification goal. These motives overlap, but they influence priorities and timelines. A rush to collect documents without agreement about the objective often creates paperwork disconnected from real decisions.
Identify the senior leader who will sponsor the work, the person coordinating activities, and the teams that will contribute. Security may be coordinated by technology staff, but human resources, procurement, legal, operations, and business leadership often own important parts of the risk picture.
Define what the initial readiness review should produce: a proposed scope, a high-level gap register, named owners, approximate resources, and a decision about next steps. Treat certification as a separate outcome that requires assessment by an appropriate certification body.
Determine the scope and organizational context
An ISMS needs a clear boundary. Describe the organizational activities, locations, information, systems, people, and external dependencies that fall within that boundary. A scope that sounds elegant but omits important supporting services can conceal risks rather than manage them.
Map interested parties and their relevant expectations. These may include customers, employees, regulators, vendors, owners, and contractual partners. Record which obligations apply and which require specialist confirmation. The goal is not to create a maximal list of hypothetical rules; it is to understand the commitments that genuinely affect the organization.
Sketch major information flows. For instance, if customer support exports personal information from a SaaS platform into shared documents, both the application and the surrounding workflow matter. Review the scope when services, ownership, or outsourcing arrangements change.
Inventory assets and existing practices
Compile an initial inventory of important information and the systems that create, process, store, or transmit it. Include cloud services, endpoints, backups, physical records, service accounts, and third-party providers where relevant. Assign an owner responsible for accuracy and business importance rather than treating the inventory as an IT-only spreadsheet.
Gather current evidence: access reviews, incident records, onboarding procedures, supplier agreements, backup checks, change approvals, vulnerability handling, and awareness activities. A practice can exist without a polished policy, while a polished policy can exist without being followed. Verify actual operation by observing a sample of work.
Record uncertainties as you go. If nobody knows whether an old server holds customer information, that is a finding to investigate. Do not quietly mark it as low risk or assume that an inventory is complete because the most visible cloud resources are listed.
Establish a repeatable risk-assessment method
Choose a documented method for identifying, analyzing, and evaluating information-security risks. Decide how likelihood and impact will be described, who evaluates the risks, how decisions are approved, and when assessments are repeated. A simple consistent method is more useful than a complicated scoring system that different teams interpret differently.
Express risks as scenarios that connect a cause to a business consequence. For example: an overly broad administrator role might permit an unauthorized change to customer records, causing inaccurate information and service disruption. This is easier to address than the vague entry “access control risk.” Consider confidentiality, integrity, and availability as appropriate.
Record a risk owner and a treatment decision. Some risks can be reduced through controls; others may be accepted within defined criteria, avoided by changing the activity, or shared through contracts or insurance. Decisions should be made by authorized people with appropriate evidence, not hidden in technical documentation.
Select controls and explain their applicability
Review relevant controls against the risks and requirements identified. Consider identity and access management, supplier security, device protection, logging, vulnerability management, backup, continuity, physical security, and people-related practices. The choice should flow from the organization’s risks, not from a generic checklist copied into a folder.
A statement of applicability helps explain which controls are relevant, which are implemented, and the reasons behind inclusion or exclusion. It should be consistent with the risk treatment plan and supported by actual evidence. A control is not necessarily effective because a policy claims it exists.
Confirm interpretations and document expectations using the official ISO/IEC 27001:2022 text and applicable amendments. Related standards can provide guidance, but they should not be mistaken for a substitute for the requirements of ISO/IEC 27001 itself.
Build evidence into daily operations
Evidence should emerge from real work: approvals in a ticket system, periodic access reviews, onboarding records, tested recovery procedures, supplier evaluations, and incident exercises. Assign where evidence will be retained and how sensitive information will be protected. Avoid producing screenshots and signatures solely for an upcoming review.
For each key process, specify who performs it, when it happens, what a successful outcome looks like, and what record demonstrates completion. Sampling a recent account-removal event, for example, may reveal more than reading a lengthy access-control policy.
Review gaps in effectiveness as well as documentation. If backups run every night but restoration has never been tested, the missing activity is validation, not another document. If employees do not know how to report an incident, the response process needs practical reinforcement.
Prepare people, internal reviews, and improvement
Explain responsibilities in plain language. Managers need to understand risk ownership, system administrators need repeatable operating procedures, and employees need clear guidance for everyday decisions. Awareness training should match roles and likely situations, rather than simply requiring everyone to complete the same slideshow.
Plan for internal audits and management reviews as part of the continuing ISMS cycle. Reviews should surface findings, assess performance, consider changes, and lead to tracked corrective actions. Independence and competence matter when assigning internal audit activities.
Treat nonconformities as information that helps strengthen the system. Record what happened, identify underlying causes where warranted, choose corrective actions, and verify that the actions worked. A growing pile of unresolved findings should not be disguised by attractive status dashboards.
Create a realistic readiness roadmap
Translate the gap register into a sequenced plan. Address high-consequence risks and foundational governance first, then stabilize operational processes and evidence collection. Track each action’s owner, due date, dependency, and verification method. Separate quick documentation fixes from work that requires new infrastructure, vendor changes, or cultural adoption.
Before seeking formal certification, confirm the current standard and any applicable amendments, review the ISMS scope, complete necessary internal activities, and discuss assessment logistics with a qualified certification body. An external adviser may support preparation, but preparation services do not themselves constitute certification.
Continue improving whether or not formal certification is pursued. The long-term value comes from making information-security decisions deliberate, traceable, and responsive to changing risks—not from a one-time document collection exercise.
Worked example: preparing a focused ISMS scope
Consider a software company that runs customer applications in a managed cloud environment. Its initial scope could describe the people, information, services and supplier interfaces involved in delivering and supporting those applications. The scope needs explicit boundaries and justified exclusions; writing 'the whole company is secure' does not describe which activities the ISMS actually covers.
Create an asset and information-flow inventory, assign risk owners, and record how each risk is assessed and treated. Where an Annex A control is applicable, identify the implemented procedure and the evidence that it operates. A control described in a policy but never followed in practice is not yet dependable evidence.
Before seeking an external audit, rehearse management review, internal audit and corrective-action tracking. Certification decisions belong to an accredited independent certification body, not to a readiness consultant, and readiness activities cannot guarantee a certificate.
Practical takeaways
Further reading
These primary resources provide additional detail and guidance.
Related services
Explore the services behind these topics:
- ISO/IEC 27001 Preparation — Guidance on the policies, processes, and evidence needed to prepare your organization.
- Cybersecurity — Practical security, risk reduction, and stronger protection for your business and data.
Continuing the conversation
Use these steps as a starting point for your own context, risks, and priorities. We can help you assess the situation, plan practical improvements, and build toward your goals.
← Back to all insights