All ISO 27001:2013 certificates expire at the end of this month. For organisations that are yet to update their ISMS (information security management system) to align with the 2022 iteration of the Standard, there are inevitably certain areas that demand their attention more than others.

One of these is the new Clause 6.

What’s changed in Clause 6?

ISO 27001:2013 emphasised:

  • Addressing risks and opportunities (6.1); and

  • Establishing information security objectives and planning to achieve them (6.2).

Related to this, Clause 8 dealt with planning, implementing and controlling processes to implement the actions and achieve the objectives determined by Clause 6.

ISO 27001:2022 introduces updates in this area:

  • Clause 6.2 now explicitly requires that information security objectives must be available as documented information, in addition to retaining documented information on them.

  • A new Clause 6.3 (“Planning of changes”) explicitly requires that when the organisation determines the need for changes to its ISMS, those changes must be carried out in a planned manner.

These may look like relatively minor changes, but in practice they change auditors’ expectations around how mature an ISMS needs to be.

For many organisations, adapting to the new requirements will merely require formalising practices that are already in use, but they might also expose gaps in how objectives and change are currently handled, which could lead to more work.

So what does this mean in practice for organisations adapting their ISMS to conform to the 2022 standard?

Clause 6.2 – information security objectives (and planning to achieve them)

What the new clause says

Clause 6.2 now states that the organisation shall:

  • Establish information security objectives at relevant functions and levels.

  • Ensure those objectives:

    • Are consistent with the information security policy.

    • Are measurable (if this is practicable).

    • Take account of applicable information security requirements, and risk assessment and risk treatment results.

    • Are monitored.

    • Are communicated.

    • Are updated as appropriate.

    • Are available as documented information.

    • Retain documented information on its information security objectives.

  • When planning how to achieve the objectives, determine:

    • What will be done.

    • What resources will be required.

    • Who will be responsible.

    • When it will be completed

    • How results will be evaluated.

Some of this obviously just rephrases what was in ISO 27001:2013. The entirely new additions are the explicit monitoring requirement and making the objectives themselves “documented information” (not only documentation about them).

Why this matters

From a practical standpoint, many organisations already gather metrics, track KPIs and produce reports so will already have some degree of objective monitoring in place. But by making it explicit, the Standard reduces ambiguity: auditors will expect to see clear links between objectives, metrics, measurement regimes and ongoing reporting

Similarly, requiring the objectives themselves to be documented rather than merely retaining records about them closes a subtle loophole. Under the older phrasing, an organisation might have argued that they had an informal objective and kept reports about the metrics – although auditors might have challenged whether the correct, authorised version of the objective had been used.

Requiring the objective to be documented information ensures clarity on version, ownership and traceability.

In effect, these changes push more discipline: every objective should be formal, version-controlled, visible and actively tracked.

How to implement 6.2 in practice

Here are some practical steps for organisations migrating from the 2013 to the 2022 version of ISO 27001:

  • Review existing objectives
    Examine whether each of your current information security objectives are (or can be) expressed so they are measurable (or at least plausibly measurable). If some objectives are too vague (e.g. “Improve security posture”), consider reworking them to be more specific (e.g. “Reduce average incident remediation time by 20% over 12 months”).

  • Add or refine monitoring mechanisms
    For each objective, establish how you will monitor progress (e.g. dashboards, periodic reports, data collection). Decide the frequency, metrics, thresholds, acceptable variance, etc., and document it as part of your planning to achieve them.

  • Document the objectives formally
    Create a formal document (e.g. an Objectives Register) with a versioned record of each objective. This should include metadata: the date, owner, version, link to the relevant policy and status. Ensure that the current valid objectives are clearly identifiable and accessible to all relevant stakeholders.

  • Link planning to execution
    Ensure every objective has a defined plan: tasks, resource allocation, timeline, responsible persons and evaluation approach. This is not new but is emphasised again in 2022.

  • Communicate and make visible
    Objectives should be communicated across relevant levels and functions. If different business units or teams have other objectives, ensure alignment with top-level objectives and visibility (e.g. via intranet, dashboards, team meetings).

  • Set review/update triggers
    Define how and when objectives will be reviewed and updated (e.g. annually, after major risk reassessment or following a significant incident). This helps ensure objectives remain current and meaningful.

  • Retain evidence
    Archive historical versions and records of measurement, review and changes to objectives. In surveillance or recertification audits, auditors may ask for prior versions and how changes were controlled.

If you already had a mature system under 2013, many of these items may map cleanly to what you already have. The transition is mostly a question of tightening discipline, filling potential gaps, and making implicit practices explicit.

Clause 6.3 – planning of changes

What the new clause says

The text of new Clause 6.3 is brief:

“When the organization determines the need for changes to the information security management system, the changes shall be carried out in a planned manner”.

This doesn’t demand a specific format of documentation or a full change management process. It simply insists that change cannot be ad hoc – there must be a plan.

Why this matters

The new Clause 6.3 formally signals that ISO/IEC consider change control as an essential activity within the ISMS itself. Under earlier versions of the Standard, change control tended to fall to IT operations or project governance functions. Now, auditors will expect to see that any change – especially to the ISMS scope, controls, processes, organisational structure or risk treatment activities – goes through a deliberate planning step that acknowledges the effect on the ISMS.

Without this clause, organisations risk blind spots: changes implemented piecemeal could unintentionally degrade the ISMS, break alignment between objectives, risks and controls, or result in inconsistent documentation.

How to implement 6.3 in practice

  • Define what constitutes a “change”
    Not every minor tweak needs full planning. Establish thresholds or categories (e.g. control changes, scope changes, process reengineering, new systems or outsourcing) that should fall under the planning process.

  • Establish a simple change plan template
    The template should capture a description of the change, the rationale behind it, its impact on the ISMS (e.g. objectives, controls, integration), risk assessment of the change, resource requirements, the responsible party, schedule, stakeholder communication, approval steps and post-implementation review.

  • Apply planning to changes
    Each identified change should be run through the process. Even small changes should at least show evidence of decision, risk consideration and review. As ever, documentation is an important way of keeping auditors informed – and therefore content.

  • Use existing governance bodies
    You can embed change approval into existing committees, such as management review, CAB (change advisory board) or security steering . What matters is that planning and control are enforceable and traceable.

  • Maintain change logs and records
    Archive change plans, decisions, reviews, versioned documents and communications. These records will serve as evidence in audits.

  • Review the outcome
    After implementing changes, evaluate whether they met the intended goals and whether there were side effects, and record the lessons that were learned.

If you already have a mature change management process, you can align or reuse it –just ensure that ISMS-specific impacts are assessed, recorded and traceable.

Common challenges and pitfalls

When organisations adapt to the new requirements in Clause 6, certain issues often arise:

  • Vague objectives
    Objectives that lack measurable elements are harder to monitor or evaluate. Auditors may challenge ambiguous wording.

  • Disconnected metrics and objectives
    It’s not enough to collect metrics; they must clearly relate to objectives. If you have dashboards that don’t reflect declared ISMS goals, it will be questioned.

  • Poor version control
    Without formal versioning, the “live” objective might evolve or get overwritten, undermining clarity about what was actually in effect.

  • Siloed change control
    If ISMS changes are handled in an ad hoc or separate team (IT ops, projects), you lose traceability and alignment.

  • Lack of documented evidence
    As ever, documentation is key to compliance. Even though 6.3 doesn’t demand a full procedure, auditors will expect to see evidence of planning (e.g. change records, approvals and reviews).

  • Failure to update objectives
    Some organisations treat objectives as static and never revisit them, even as the business, risk profile or technology shifts. That leads to stale, irrelevant goals.

Why the changes are beneficial

For some organisations, these changes might seem fussy and burdensome. However, they offer genuine benefits:

  • Greater audit confidence
    By formalising objective monitoring and change planning, you reduce the chance of auditor findings citing lack of traceability or weak evidence.

  • Stronger internal alignment
    When objectives are visible, documented and actively tracked, teams across IT, security, product and risk can better align their activities with shared goals.

  • Better governance discipline
    Even modest scope creep or undocumented tweaks can erode ISMS consistency over time. Clause 6.3 helps mitigate that risk.

  • Commercial credibility
    Clients and regulators increasingly ask for evidence, not just statements. Demonstrable, tracked objectives and change history serve as proof of ISMS maturity.

  • Easier continual improvement
    A system that actively tracks objective progress and captures change effects is far better positioned to evolve with business demands or threat landscapes.

Managing your ISO 27001 transition

Transitioning from ISO 27001:2013 to ISO 27001:2022 doesn’t require wholesale reinvention, but it does demand greater rigour and clarity. For organisations that already have a metric-driven ISMS, the bulk of the work is in tightening documentation, aligning monitoring schemes and embedding a bit more governance discipline around changes.

And if you need help with any of that, our experts are here to help.

Our ISO 27001 Transition Gap Analysis service gathers information to ensure a comprehensive understanding of your organisation’s current security posture. Next, we conduct a detailed comparison, assessing your ISMS against the requirements of ISO 27001:2022.

We then provide you with a clear roadmap for improvement and create a revised risk treatment plan, aligned with the updated Standard, offering a strategic approach to strengthen your information security framework.

Enquire now