Information security objectives are the results an organisation sets out to achieve through its information security management system (ISMS). ISO 27001:2022 Clause 6.2 requires them to be set at relevant functions and levels, consistent with the security policy, measurable if practicable, informed by risk results, monitored, communicated, updated and documented.
What does ISO 27001 Clause 6.2 require?
Clause 6.2, “Information security objectives and planning to achieve them”, has two parts: what the objectives must be like, and what the plan to achieve them must say.
What must the objectives be like?
Under ISO/IEC 27001:2022 Clause 6.2, items a) to g), each information security objective must:
- be consistent with your information security policy;
- be measurable, where that is practicable;
- take into account the information security requirements that apply to you, and the results of your risk assessment and risk treatment;
- be monitored;
- be communicated;
- be updated as appropriate;
- be available as documented information.
The organisation must also keep documented information on its information security objectives.
What must the plan to achieve them state?
Items h) to l) of the clause say that, when you plan how to achieve each objective, you must decide:
- the actions to take;
- the resources required;
- the person accountable;
- the deadline;
- how you will judge the results.
Two items are new compared with the 2013 edition: objectives must now be monitored, and they must be available as documented information.
Clause 6.2 also connects to other parts of the standard. Under Clause 5.1, top management makes sure the objectives are set and fit the organisation’s strategic direction. Under Clause 5.2, the information security policy either includes the objectives or gives the framework for setting them. Under Clause 9.3, management review considers how far the objectives have been met. For a step-by-step walkthrough of putting this in place, see our guide on how to implement ISO 27001 Clause 6.2.
What are examples of information security objectives?
The examples below show how each objective can name a measure, an owner, a deadline and a source of evidence. The figures are illustrative targets, not values set by the standard; set your own from your risk assessment and the requirements that apply to you.
| Objective | Measure | Owner (example) | Due date | Evidence source |
|---|---|---|---|---|
| Phishing resilience | Phishing simulation click rate below 7% | Security awareness lead | Within 12 months, checked each quarter | Quarterly simulation results stored in the learning management system |
| Patch management | All high-risk server patches applied within five days of release | IT operations manager | Ongoing, reported monthly | Patch logs generated by the patching tool |
| Identity and access | Privileged access reviewed every quarter, with actions, dates and owners recorded | IT security lead | End of each quarter | Signed-off access review records |
| Incident response | Root cause review completed and filed within 48 hours of any critical security incident | Incident manager | 48 hours after each critical incident | Ticketing system exports |
| Training | All new employees complete security onboarding within five working days of starting | HR manager | Five working days from each start date | HR system training records |
| Data handling | Full backup restore test completed and results reported | Operations manager, signed off by compliance | Once a year | Backup test report with sign-off |
Each row covers what the clause asks the plan to state: what will be done, who is responsible, when it will be completed and how the result will be evaluated. The resources needed should be recorded alongside.
An objective with a name, a number and a link to a risk gives your team a clear next step and gives leadership a visible result.
How do you set a measurable information security objective?
These five steps follow the order of Clause 6.2:
- Start from your risks and requirements. Use your risk assessment and risk treatment results, plus the legal, contractual and business requirements that apply, to choose what matters most.
- Check it fits your policy. Make sure the objective is consistent with your information security policy and supports the organisation’s direction.
- Write the outcome as a measure. State the target, the timeframe and the data source, for example “phishing simulation click rate below 7% within 12 months, checked each quarter”.
- Plan the delivery. Record what will be done, the resources needed, the named person responsible, the completion date and how the result will be evaluated.
- Monitor, communicate and update. Track progress, tell the people involved, update the objective when circumstances change, and keep it as documented information.
Common weaknesses and how to fix them
| Objective flaw | Example | How to fix it |
|---|---|---|
| Too vague | “Improve awareness across the organisation” | “Achieve 96% completion of staff phishing training” |
| No owner | “Reduce data incidents” | “IT security lead reduces data incidents by 25% in 12 months” |
| Unmeasurable | “Maintain robust controls” | “No severity 1 vulnerabilities open in Q4, per scan report” |
ISO 27001 made easy
An 81% Headstart from day one
We’ve done the hard work for you, giving you an 81% Headstart from the moment you log on. All you have to do is fill in the blanks.
What does “measurable” mean under Clause 6.2?
ISO/IEC 27001:2022 Clause 6.2 b) says objectives shall be “measurable (if practicable)”. It does not require every objective to be a number. Where an objective cannot sensibly be measured, the plan must still say how its results will be evaluated (item l). Either way, you need evidence, not optimism: “increase awareness” gives you nothing to check, while “97% of staff pass the security quiz within 90 days of onboarding, tracked in the platform log” does.
What does a measurable objective include?
- Timeframe: A clear deadline, such as “by financial year end”, not “ongoing”.
- Data source: The log, dashboard or record the result will come from. If you cannot retrieve a result, rethink the objective.
- Criteria for success: For culture-driven targets, use observable benchmarks. “Post-incident reviews show lessons were acted on at the next similar event” is easier to evaluate than “improve learning from incidents”.
Clause 9.1 sets the wider rules for monitoring, measurement, analysis and evaluation in the ISMS. ISO/IEC 27004 gives further guidance on information security measurement.
If your team cannot point to the evidence for an objective, you cannot show that the objective has been met.
How should objectives link to business risks and goals?
In practice, the useful question for leadership is not “did we set objectives?” but “how did they reduce risk, protect revenue or support customer trust?”
Linking objectives to business value
- Risk anchoring: Base objectives on your risk assessment, not on ideas formed in isolation. Tackle the biggest risks first.
- KPI alignment: Tie security objectives to business measures. Audit log integrity, for example, supports fraud prevention and revenue assurance, not just IT.
- Transparent ownership: ISMS.online lets you assign every metric to a visible owner and map it to live dashboards, so progress updates for the board come from one place.
How often should you review information security objectives?
Clause 6.2 does not set a review frequency. It requires objectives to be monitored and updated as appropriate, and Clause 9.3 requires management review, at planned intervals, to consider how far the objectives have been met. You decide the rhythm.
A practical approach is to:
- review objectives quarterly in your ISMS steering group or risk committee;
- review them between scheduled meetings when something significant changes (see the questions below);
- use dashboards to spot drift early, rather than shortly before an audit.
ISMS.online automates review cycles and sends reminders, so every owner and executive sponsor can see what is due. For the related term, see our review objective definition.
Who should own information security objectives?
Clause 6.2 says objectives are set “at relevant functions and levels”, so they should not sit with the security team alone. For example, HR can own onboarding training, operations can own access management, and finance can own fraud signals, each with its own measurable objective.
How to build engagement across the organisation
- Translate objectives so every team knows its part (“HR flags any missed training within 48 hours”).
- Give each department a named metric and make sure its leader tracks actual performance.
- Make sure owners have the skills to deliver (see ISO 27001 Clause 7.2 competence) and understand how their work contributes to the ISMS (see ISO 27001 Clause 7.3 awareness).
- Show progress for every department in one place with ISMS.online dashboards.
The wider your objectives travel, the faster your culture moves from passive compliance to active defence.
Manage all your compliance, all in one place
ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.
What are the risks of weak information security objectives?
Weak objectives let risk build up unnoticed.
What weak objectives cost
- Objectives without an owner rarely get action, because everyone assumes someone else is watching.
- Objectives without evidence are hard to defend when an auditor or a customer doing due diligence asks how they were met.
- Measurable objectives, by contrast, focus budget and effort where the risks are greatest.
Why choose ISMS.online for Clause 6.2 objectives?
ISMS.online is a compliance platform that helps you set, track and evidence your information security objectives:
- Objective mapping: Design, assign and cascade objectives to each department leader and function.
- Visible owners: Assign every metric to a named owner and show progress for every department on live dashboards.
- Evidence linking: Link every metric to its evidence, such as logs, dashboard figures and audit trails, so it is ready when asked.
- Automated review: Schedule regular check-ins or trigger reviews when business needs or threats change, with reminders so every owner can see what is due.
- Board reporting: Produce at-a-glance progress updates for risk committees and executive briefings.
- Shared reports: Share metrics from the platform during a remote session.
Objectives that are tracked, owned and reviewed give leadership evidence of progress, not just a list of intentions. To see how ISMS.online can help you manage your Clause 6.2 objectives, book a demo.
Frequently Asked Questions
What is the difference between an information security objective and a control?
An objective is a result you want to achieve, such as a lower phishing click rate. A control is a measure you put in place to treat a risk, such as security awareness training or email filtering. Controls are chosen through risk treatment under Clause 6.1.3, using Annex A as a check that nothing necessary has been missed. Unlike the 2013 edition, the 2022 Annex A does not state a separate objective for each group of controls, so your Clause 6.2 objectives are where you say what your ISMS is trying to achieve.
How many information security objectives should an organisation set?
ISO 27001 does not set a number. Objectives are set at relevant functions and levels, so a small organisation may have a handful while a larger one has objectives for several departments. Fewer objectives that are owned, resourced and tracked are easier to deliver than a long list nobody monitors.
Where should information security objectives be recorded?
Under Clause 5.2, they can sit in the information security policy itself, or the policy can set the framework and the objectives can be recorded separately, for example in an objectives register that also holds the plan for each one.
What evidence shows an objective is being met?
An auditor or a customer doing due diligence may ask for evidence of progress. Useful types of evidence include:
- System data: security monitoring logs, HR completion records or platform screenshots.
- Written sign-off: signed or time-stamped confirmation, digital or on paper, that an objective has been completed.
- Shared reports: metrics shared from ISMS.online during a remote session.
- Traceable qualitative outcomes: for objectives that are not number-driven, a linked incident ticket or documented decision.
Keeping objectives and their evidence side by side means you do not have to gather proof by hand before each review.
What mistakes stop objectives from working?
Beyond vague wording and missing owners, three habits often undermine objectives:
- Copying templates instead of using your own risks: review your live incidents and threat trends, and build objectives that reflect this year’s situation.
- No resources behind the goal: an objective without time, budget or tools is unlikely to be met. Clause 6.2 asks you to decide what resources will be needed.
- Set once and forgotten: an annual check alone can let slippage go unnoticed for months; regular monitoring catches it earlier.
What events should prompt an update to your objectives?
Common reasons to revisit them between scheduled reviews include:
- Incidents: a breach or near miss is a reason to check whether your objectives target the right risks.
- Operational changes: a new product, system or market can change your risks and so your objectives.
- New requirements: new laws, contracts or frameworks that apply to you may need new or changed objectives.
- Warning signs in your data: missed deadlines, growing exceptions or drifting metrics.
