ISO 27001 certification: build an ISMS that lasts

A customer asks for your ISO 27001 certificate. The commercial deadline is clear; the implementation work may not be. The first leadership decision is whether to build a security management system the business can sustain, or organize a temporary project around an audit date.

A useful certification plan starts by defining the system you need to operate, then arranging the evidence that demonstrates it. That means deciding which services the certificate should cover, who can authorize risk decisions, what resources control owners need, and how management will know whether the controls work.

The certificate is an important deliverable. The lasting business asset is an information security management system, or ISMS, that remains useful when employees leave, suppliers change, new products launch, and customers ask harder questions.

What ISO 27001 certification actually establishes

ISO/IEC 27001 specifies requirements for establishing, implementing, maintaining, and continually improving an ISMS. Its purpose is to manage risks to information confidentiality, integrity, and availability in the context of the organization.

Confidentiality concerns inappropriate disclosure, such as customer records becoming accessible to unauthorized users. Integrity concerns inaccurate or unauthorized changes, such as someone altering payment instructions. Availability concerns access when needed, such as restoring an important service after an infrastructure failure.

Certification concerns that management system within its stated scope. It does not guarantee that every product is vulnerability-free, that incidents cannot occur, or that every business unit has been assessed. A certificate covering one managed service should not be presented as assurance for an unrelated product.

ISO and IEC publish the standard; they do not certify your organization. An independent certification body performs the assessment and makes the certification decision. For customer assurance, a practical recommendation is to select a body accredited for the relevant ISMS certification activity and confirm that its certification will meet buyer requirements.

The distinction between conformity and certification also matters. An organization can implement an ISMS that meets the standard without seeking external certification. Certification adds independent assessment and a formal certificate. Buying software, employing a qualified implementer, or completing a training course does not confer organizational certification.

Decide whether certification solves the business problem

Certification is particularly relevant when procurement requirements, contractual commitments, sensitive information, or operational dependencies justify independent assurance. It is not a universal legal obligation for every business.

Before committing, ask sales and account teams to identify the actual requirement. Does the buyer require a certificate before contract signature, before production access, or at renewal? Must it cover a named service or legal entity? Will the buyer still require a security questionnaire, testing reports, or additional contractual controls?

These answers affect investment priorities. A certificate may support procurement, but it does not eliminate all due diligence. Avoid forecasting revenue on the assumption that certification automatically completes every customer's security review.

Separate certification from regulatory analysis. An ISMS can support evidence and governance relevant to other obligations, but certification does not establish compliance with GDPR or NIS2. Those regimes have their own applicability rules and duties. NIS2 is implemented through national law; GDPR duties depend on processing activities and organizational roles.

The leadership case should therefore identify three things: the assurance customers need, the information risks the business must manage, and the ongoing operating cost. Approve the program on that basis, rather than on a promise of a certificate by an arbitrary date.

Draw a scope customers can understand

Scope describes the boundaries and applicability of the ISMS. It should identify the relevant services, organizational units, locations, people, information, systems, and dependencies. It also needs to account for interfaces with activities outside those boundaries.

A narrow scope can be appropriate, especially for an initial implementation. It must still reflect what customers expect the certificate to cover. Excluding the team that administers production access does not remove its influence on a scoped customer service.

For a hosted application, examine the whole service chain: development, deployment, production operations, support access, identity administration, backups, and significant external providers. Shared HR or IT processes may affect security even when the scope centers on a product rather than the entire company.

A practical scope record should answer:

• Which legal entity operates the service?
• Which customer-facing services and information are covered?
• Which locations and remote-working arrangements matter?
• Which teams and shared processes affect those services?
• Which suppliers provide infrastructure or handle relevant information?
• What sits outside the boundary, and how are its interfaces managed?

Test the proposed wording with a buyer-facing colleague. If they cannot explain whether the customer's service is covered, the wording needs work.

Do not optimize scope solely to reduce audit fees. A smaller boundary may create complicated interfaces and leave the commercial requirement unanswered. Conversely, including every group company immediately may create unnecessary coordination. The right boundary is defensible, understandable, and operationally manageable.

Record the rationale and triggers for reconsidering it, such as acquiring a business, moving infrastructure, or launching a materially different service. Scope should remain a management decision, not a forgotten paragraph.

Give the program authority, not just an owner

Assign an implementation lead and an accountable management sponsor. They have different responsibilities. The lead coordinates work and maintains visibility; the sponsor resolves priorities, authorizes resources, and ensures security objectives fit business decisions.

Control ownership should follow operational authority. HR may own employment-related procedures, IT may own device management, engineering may own development practices, and procurement may coordinate supplier assessment. The compliance lead should not become nominally responsible for processes they cannot change.

Define who can accept residual risk and at what level. A service owner may recommend accepting a limited operational exposure, while a risk affecting important customer commitments may require executive approval. Record the decision, reasoning, conditions, and review date.

Leadership also needs to protect implementation capacity. Assigning work without making room for it creates predictable delays. Ask owners for the effort required, dependencies, and trade-offs; then approve a realistic plan.

Management review is where leadership evaluates the system and makes decisions about improvement, changes, and resources. A signed meeting record with no meaningful decisions provides little practical value. The review should expose unresolved choices, not merely endorse a green dashboard.

Understand the requirements before buying a checklist

The requirements in clauses 4–10 of ISO/IEC 27001 form the management-system core. They cannot be excluded when claiming conformity. Their practical outputs are distinct from implementing individual security controls.

Annex A of the 2022 edition contains 93 reference controls: 37 organizational, eight people, 14 physical, and 34 technological controls. Applicability is risk-based; there is no universal number that every company should implement.

Determine the controls necessary for risk treatment, then compare them with Annex A to check that necessary controls have not been overlooked. Controls can also come from contractual requirements, other sources, or your own design. Annex A is neither a substitute for risk assessment nor an exhaustive catalogue of every possible security measure.

The Statement of Applicability, or SoA, records necessary controls, the reasons for including them, their implementation status, and justification for excluding Annex A controls. Maintain enough traceability to explain how those decisions relate to risk treatment and other requirements.

ISO 27002 provides guidance on information security controls; ISO 27001 supplies the certifiable management-system requirements. Use the guidance to understand implementation options, but tailor procedures to your organization rather than importing an operating model you cannot sustain.

Build risk treatment before assembling evidence

Start with a repeatable risk assessment method. Define how risks are identified, how likelihood and consequences are assessed, how results are compared, and which criteria determine acceptability. Consistent interpretation matters more than a complicated scoring formula.

Describe risks as scenarios. “Cloud risk” is too vague to support a decision. “An administrator account is compromised and used to export customer records” identifies an event, affected information, and a business consequence.

Involve people who understand the service. They can explain existing safeguards, support access, supplier dependencies, recovery constraints, and workarounds that a generic risk library may miss. For a practical record structure, see our guide to an operational risk register.

For each significant risk, record the owner, assessment, current controls, treatment decision, target outcome, and residual-risk assessment. Possible treatment approaches include reducing exposure, avoiding an activity, sharing aspects of risk, or accepting it under defined criteria. Insurance or outsourcing does not remove every consequence or responsibility.

Translate treatment into accountable work. “Improve access security” is not an executable plan. Specify the systems affected, the change required, the owner, the completion criteria, and how effectiveness will be evaluated.

Keep these records distinct:

They should agree without becoming copies of one another. If a treatment depends on supplier monitoring but the related control is excluded without explanation, resolve the inconsistency before audit preparation.

Review risks at planned intervals and when significant changes occur. A new support provider, expanded data collection, incident, or major architecture change can make an earlier decision obsolete.

Make controls part of ordinary operations

A policy states expectations; a procedure explains how work happens; operating records demonstrate what actually occurred. Certification preparation needs all three where relevant.

For example, an access policy should connect to an implemented joiner-and-leaver process, sampled access changes, and a review of exceptions. A policy document alone leaves most of that story unproven.

Build the process around actual responsibilities. Identify who requests access, who approves it, who provisions it, what happens when someone's role changes, and how accounts are removed. Include service accounts and external users where they affect the scope.

Apply the same thinking across other important processes:

• Supplier assessment should connect service criticality, information access, contractual expectations, review outcomes, and unresolved concerns.
• Incident management should connect reporting routes, response responsibilities, escalation, recovery, and lessons learned.
• Backup and recovery should connect business needs, protected systems, restoration procedures, test results, and follow-up work.
• Change management should connect approval, testing, deployment records, emergency changes, and exceptions.

Physical and people controls still matter in a cloud-based organization. Remote work, device protection, confidential conversations, employment changes, and awareness cannot be dismissed because servers are outsourced.

Set control frequencies according to risk and operating needs. Do not copy a quarterly review promise into a policy unless the owner can carry it out and retain records. A policy that describes a process nobody follows creates an avoidable gap between intention and implementation.

Design evidence for inspection, not volume

Good evidence answers a defined question about a requirement or control. A large folder of screenshots is not inherently stronger than a smaller, well-explained set of reliable records.

For each important control, specify the source system, owner, collection method, coverage, expected frequency, and reviewer. Distinguish evidence of design from evidence of operation. An identity configuration may show that multifactor authentication is enabled; approval records and access reviews demonstrate other aspects of access governance.

Evidence should make its meaning clear:

• What service, system, or population does it cover?
• When was it produced, and what period does it represent?
• Is it complete enough for the question being assessed?
• Who reviewed it, and what exceptions were identified?
• What follow-up resulted from those exceptions?

Retain unsuccessful outcomes too. A failed restore test with documented investigation, remediation, and a successful retest can demonstrate that monitoring and improvement work. Deleting inconvenient results damages the usefulness of the record.

Protect evidence as information in its own right. Exports may contain employee details, customer identifiers, or sensitive configurations. Limit access, minimize unnecessary content, and define retention based on relevant obligations and business needs. Arrange controlled access for auditors rather than distributing broad archives casually.

Use internal audit and management review to test readiness

Internal audit evaluates whether the ISMS conforms to applicable requirements and is effectively implemented and maintained. It should cover the management system, not merely check technical settings.

Plan audit scope, criteria, methods, and reporting. Select competent auditors and preserve objectivity and impartiality. A small organization may use external support or suitable cross-functional arrangements rather than asking one person to evaluate all their own work.

Useful audit testing follows a record through the process. Select an employee departure and check notification, account removal, equipment handling, and exceptions. Select a supplier and examine whether its risk assessment matches its actual access. Select a treatment action and verify whether the declared completion has operational support.

Record findings accurately, including the requirement, observed evidence, and gap. Do not reduce the audit to a percentage-complete score that conceals missing management processes.

Management review then considers the required inputs, including performance, audit results, changes, risk assessment and treatment status, and opportunities for improvement. Prepare a concise decision pack with supporting records available. Explain where leadership needs to choose between remediation, additional resources, changed objectives, or approved risk acceptance.

For nonconformities, separate immediate correction from corrective action. Disabling an overlooked account corrects the immediate issue. Repairing the notification process and checking subsequent departures addresses recurrence. Record the cause, action, owner, and effectiveness evaluation.

Understand Stage 1, Stage 2, and the certification decision

Initial certification normally involves two audit stages. Agree the arrangements, expected records, and readiness expectations with the certification body early enough to plan properly.

Stage 1 examines readiness, scope, and management-system documentation. It helps the body understand the organization and assess preparedness for Stage 2. Expect scrutiny of the relationship between scope, risk assessment, treatment, the SoA, and management processes. Resolve identified concerns rather than treating Stage 1 as an administrative booking step.

Stage 2 evaluates implementation and effectiveness. Auditors use interviews, observation, and sampled records to test whether the ISMS operates as described. Employees should be able to explain their actual responsibilities, not recite rehearsed answers.

Keep requests organized during the audit. Assign a coordinator, record requests, identify the right owner, and provide relevant evidence with context. If something is missing, explain the situation accurately. Do not create retrospective records that falsely imply a process occurred.

A nonconformity means a requirement has not been fulfilled. Major findings affect the management system's capability to achieve its intended results; minor findings do not have that effect. Classification depends on context, so a single missing record cannot be assigned a universal label in advance.

The certification body determines findings, required responses, verification arrangements, and the certification decision independently. Confirm its deadlines and follow-up requirements in advance. An auditor's recommendation is not itself an issued certificate, and unresolved findings can delay the decision.

After certification, a typical cycle includes surveillance in the intervening years and recertification before the three-year certificate expires. Confirm the specific audit program and conditions with your body. Surveillance is not permission to pause the ISMS between visits.

Plan the timeline and budget around dependencies

Duration depends on maturity, scope, unresolved risks, evidence availability, internal capacity, and auditor scheduling. There is no universal ISO 27001 operating-evidence period that makes every organization automatically ready.

Ask the certification body what it needs to sample for your circumstances. A process performed monthly produces records differently from an annual exercise. Do not wait until the audit booking to discover that an important control has never been exercised.

Separate work you can accelerate—collection, coordination, drafting, and review preparation—from work that requires implementation and demonstrated operation. Parallelize independent tasks, but preserve dependencies: an SoA cannot be finalized credibly without control-selection reasoning, and effectiveness cannot be evaluated solely from a proposed policy.

Use readiness gates rather than one optimistic finish date:

Budget for internal effort, remediation, tooling, training, optional advisory support, and external assessment. Include surveillance, recertification, and ongoing maintenance, not just the first audit invoice.

Ask certification bodies to explain their assumptions about personnel, sites, activities, complexity, and audit arrangements. Compare the full cycle and follow-up charges. Avoid treating a low initial quote as the complete cost of operating a certified ISMS.

Worked example: one service, one sustainable plan

Consider an illustrative 30-person company operating a hosted document-sharing service. Assume it already has identity management, deployment approvals, and backups, but supplier reviews and access-review records are inconsistent. Its prospective customer wants assurance for the hosted service, including support access.

Management scopes the service and supporting development, operations, and support processes. It records interfaces with HR and shared IT rather than excluding their security effects. The CEO sponsors the program; an implementation lead coordinates it; operational managers own controls.

The team identifies a scenario in which excessive support permissions expose customer documents. Treatment includes restricted support roles, approved temporary elevation, access reviews, and monitoring appropriate to the service. The SoA records the necessary controls and implementation status.

The access owner then collects a role configuration, sampled approval records, a completed review, and evidence that excessive permissions discovered during that review were removed. These records establish more than the existence of an access policy.

During internal audit, a departed contractor is found with an active account. The team disables it, investigates the missed HR-to-IT notification, adds an explicit contractor termination step, and checks later departures to evaluate effectiveness. Management review considers the finding, remaining risks, and resources needed for ongoing reviews.

For budget planning only, assume eight contributors each spend two hours weekly for twelve weeks. That is 192 internal hours, before specialist remediation and audit participation. This is an illustrative capacity calculation, not a market estimate or certification promise.

The lesson is managerial: assign work to people with authority, reserve capacity, and make readiness depend on evidence. Existing technical safeguards reduce some implementation work, but they do not replace risk decisions, internal audit, or management review.

Automate repeatable work while retaining judgment

Automation can support inventory updates, evidence collection, reminders, technical checks, and reporting. Prioritize recurring work with reliable source data and a clear reviewer, rather than automating an unclear process.

An automated check needs defined coverage and failure handling. If a connection stops collecting records, distinguish “no issue detected” from “no current data.” Confirm that the source covers the relevant systems, accounts, or locations before relying on the result.

Keep human judgment explicit for risk acceptance, control applicability, evidence conclusions, and leadership decisions. A configuration check may show encryption enabled; it does not establish that key access, recovery, and exceptional data paths are appropriately managed.

Likewise, workflow automation can organize internal-audit requests and findings, but it does not supply audit competence or independence. AI-generated summaries and mappings should remain drafts until a reviewer checks the sources and approves the conclusions.

Measure both efficiency and effectiveness: time spent preparing evidence, overdue corrective actions, incomplete coverage, repeated failures, and the time taken to resolve important exceptions. Our guide to ISMS metrics explains how to make measures useful for management decisions.

Keep ownership active after certification

Before the certificate arrives, establish the maintenance calendar. Practical recommendations include regular owner checks, risk reviews triggered by material changes, planned control evaluations, internal audits, management reviews, and preparation for external assessments. Choose frequencies according to the process and risk rather than making every activity monthly.

Reassign responsibilities when employees move or leave. Review scope and control applicability when the business changes. Track recurring exceptions: repeated late access removal suggests a process problem even if every individual case eventually closes.

Secani supports this workflow by connecting requirements, controls, evidence, owners, tasks, and review decisions in a shared workspace. Start with one representative service, model its systems and dependencies, attach existing evidence to what it proves, and turn gaps into assigned tasks. Review AI-assisted suggestions against their sources and preserve human approvals and decision history. This helps the team retain what it learns during certification as systems change; certification remains the independent body's decision.

Questions that change the implementation plan

Does ISO 27001 require a penetration test?

There is no universal ISO 27001 clause requiring every organization to conduct a penetration test. Necessary testing depends on risk treatment, applicable controls, service characteristics, and contractual requirements. Where testing is needed, define coverage, remediation, and retesting rather than retaining only a report.

Should we pursue SOC 2 instead?

Ask what customers require and what scope they expect. SOC 2 produces an attestation report; ISO 27001 produces management-system certification. Some operating evidence may be reusable, but neither automatically converts into the other. Evaluate the separate requirements before committing to both.

Do we need an external consultant?

Not necessarily. External help can address interpretation, capacity, or specialist needs. Retain internal ownership and ensure procedures remain usable after the engagement ends. A person's implementer or auditor credential does not certify their employer.

Start with a decision and an evidence trail

Approve a short implementation charter stating the commercial need, intended scope, sponsor, lead, control owners, capacity, and readiness gates. Then take one important service and follow a control from requirement to risk treatment, implementation, evidence, and review.

That first trace will expose unclear responsibilities and missing records before they multiply. Use our ISO 27001 checklist to organize the remaining work, while keeping the management-system requirements and control applicability distinct.

A lasting ISMS makes security decisions inspectable and repeatable. Certification recognizes the system within its scope; leadership keeps it operating after the audit team leaves.