Why Clause 6.2 Catches Organisations Off Guard
Information security objectives are one of those areas where organisations tend to write something down, tick the box, and move on. Then the certification auditor arrives, asks a few pointed questions, and the whole thing unravels. The objectives are vague, nobody owns them, there is no baseline to measure against, and progress has never been reviewed.
On this page
Clause 6.2 of ISO 27001:2022 is not asking for aspirational statements about wanting to be secure. It is asking for a structured, evidence-backed approach to setting targets that actually drive improvement in your information security management system. If you are responsible for implementing or auditing an ISMS, understanding what measurable information security objectives look like in practice is essential.
This article walks through what Clause 6.2 requires, why organisations consistently get it wrong, and how to set objectives that will hold up under scrutiny from an external auditor.
What Clause 6.2 Actually Requires
The clause sets out a clear list of criteria that every information security objective must satisfy. It is worth going through each one because they are not interchangeable. Failing to meet even one of them is enough for a nonconformity.
Consistent With the Information Security Policy
Your objectives must connect back to the commitments made in your information security policy. If your policy commits to protecting personal data and maintaining availability of critical systems, your objectives should reflect those priorities. An objective about reducing phishing susceptibility makes sense in that context. An objective about reducing printer paper use does not.
Auditors will trace the line from policy to objectives. If it is not there, expect a finding. For guidance on what a well-constructed policy looks like, see our article on writing an information security policy that meets Clause 5.2.
Measurable Where Practicable
ISO 27001 uses the phrase where practicable, which some organisations interpret as permission to avoid measurement altogether. That is not what it means. It means that if a reasonable measure exists, you must use it. For almost every information security objective, a reasonable measure does exist.
A target like improve security awareness is not measurable. A target like achieve a pass rate of 85 per cent or above in the annual phishing simulation by December is. The difference matters enormously when you are trying to demonstrate continual improvement.
Taking Into Account Applicable Requirements
Your objectives need to reflect the legal, regulatory, and contractual obligations your organisation has identified. In Australia, this includes obligations under the Privacy Act 1988, the Notifiable Data Breaches scheme, and any sector-specific requirements. If your risk assessment has flagged regulatory compliance as a significant risk, your objectives should address it directly.
Relevant to Information Security Risk and Opportunities
Objectives should emerge from your risk assessment and treatment process, not be invented independently of it. If your risk assessment identified that privileged access management is a high priority risk, and your objectives make no mention of it, something is wrong with either the objectives or the risk assessment. The two need to be coherent.
Monitored, Communicated, Updated, and Documented
Clause 6.2 also requires that objectives are monitored, communicated to relevant parties, updated as appropriate, and maintained as documented information. These are operational requirements, not just planning requirements. An objective that was set twelve months ago and never reviewed again is not being managed. It is being stored.
Exemplar Global Recognised Training ProviderRTP No. 310970
The Six Criteria That Make an Objective Auditable
When you sit down to write information security objectives, there is a practical framework that will help you produce something that survives audit scrutiny. Think of it as a checklist for each objective before you finalise it.
Specific
The objective must describe a precise outcome. Improve our patch management is not specific. Reduce the proportion of critical and high severity vulnerabilities remaining unpatched beyond 30 days to below five per cent is specific. The more precise the language, the easier it is to measure and the harder it is to argue about whether you achieved it.
Measurable
There must be a metric. Whether that is a percentage, a count, a time period, or a score, the objective needs a number attached to it. If you cannot put a number on it, you cannot demonstrate progress. And if you cannot demonstrate progress, a certification auditor will question whether the objective is genuine.
Achievable
Objectives should be challenging but realistic. An organisation that has never conducted security awareness training should not set an objective of achieving 100 per cent completion in the first month. The objective needs to be achievable within the resources and timeframe available. Unrealistic objectives are a red flag for auditors because they suggest the organisation is not serious about actually meeting them.
Relevant
The objective must connect to a real information security risk or opportunity. If you cannot explain why an objective matters in the context of your ISMS, it probably should not be there. Relevance also means the objective should matter to the people responsible for achieving it, not just to the person who wrote it.
Time-Bound
Every objective needs a deadline. Without a timeframe, there is no accountability. We will reduce the average time to respond to security incidents is an intention. We will reduce the average time to respond to security incidents from 48 hours to 24 hours by the end of the financial year is an objective.
Owned
This is the one that most templates leave out, but it is critical in practice. Every objective must have a named owner. Not a team, not a department, a person. The owner is accountable for monitoring progress, removing obstacles, and reporting on status. Without a named owner, objectives drift. Nobody feels responsible, nothing gets measured, and the management review meeting has nothing meaningful to discuss.
Real World Examples of Measurable Information Security Objectives
Theory is useful, but examples make it concrete. The following are the kinds of objectives that hold up under audit scrutiny. They are drawn from the types of organisations that commonly seek ISO 27001 certification in Australia.
Security Awareness Training
Objective: Achieve a completion rate of 90 per cent or above for the annual information security awareness training programme across all staff by 30 June.
Measure: Training completion records from the learning management system.
Owner: Information Security Manager.
This is measurable, time-bound, and directly linked to the risk of human error and social engineering. If your phishing simulation results show that click rates are high, this type of objective addresses the root cause.
Vulnerability Management
Objective: Reduce the proportion of critical vulnerabilities on internet-facing systems remaining unpatched beyond 14 days to zero by end of Q2.
Measure: Vulnerability scan reports reviewed monthly.
Owner: IT Infrastructure Manager.
This objective connects directly to the risk treatment plan, specifically to controls related to technical vulnerability management. An auditor reviewing this objective can trace it back to the risk register and forward to the monitoring records.
Access Control Reviews
Objective: Complete quarterly access rights reviews for all privileged accounts across production systems, with 100 per cent completion rate for each quarter.
Measure: Access review completion records, including sign-off by system owners.
Owner: IT Security Analyst.
Privileged access is a persistent risk in most organisations. An objective that targets the review process, rather than just the existence of a policy, shows the system is operating rather than just documented.
Incident Response
Objective: Reduce the average time from security incident detection to initial containment action to under four hours for all Priority 1 incidents by end of financial year.
Measure: Incident log with timestamps for detection and containment actions.
Owner: Security Operations Lead.
This objective is grounded in operational reality. It requires that incidents are being logged properly, which itself provides audit evidence. The metric is meaningful because detection-to-containment time directly affects the impact of a breach.
How to Connect Objectives to the Risk Assessment
One of the most common weaknesses auditors find is a disconnect between the risk assessment and the objectives. The risk assessment identifies a set of priority risks. The risk treatment plan maps those risks to controls. The objectives should then measure whether those controls are working.
If your risk assessment identifies unauthorised access to sensitive customer data as a high priority risk, and your risk treatment plan includes implementing multi-factor authentication and quarterly access reviews, your objectives should include measurable targets for both of those controls. The chain should be unbroken: risk to control to objective to measurement.
When you can show an auditor that chain, the objectives stop looking like a documentation exercise and start looking like genuine management. That is what certification auditors are looking for. For a detailed walkthrough of the risk assessment process that feeds into this, see our article on information security risk assessment: Clause 6.1.2 step by step.
Monitoring and Reviewing Objectives Throughout the Year
Setting objectives is only the first step. Clause 6.2 requires that they are monitored. This means someone needs to be checking progress at regular intervals, not just at the annual management review.
In practice, this looks like a monthly or quarterly review by the objective owner, with a brief status report that captures current performance against the target, any obstacles encountered, and whether the objective is on track. That status information then feeds into the management review, where top management can see whether the ISMS is performing as planned.
If an objective is clearly not going to be met, the organisation should document why and either adjust the target or escalate the issue. Auditors are not necessarily looking for perfect performance. They are looking for evidence that the organisation is paying attention, responding to what the data shows, and making informed decisions. An objective that was missed but thoroughly analysed and corrected is far better than an objective that was met on paper but never genuinely tracked.
Common Nonconformities Auditors Raise Against Clause 6.2
Having conducted hundreds of external audits, there are patterns in how organisations fall short against this clause. Knowing them in advance helps you avoid them.
Objectives That Cannot Be Measured
The most frequent issue. Statements like maintain a strong security culture or ensure our systems remain secure are not objectives in the ISO 27001 sense. They are intentions. Auditors will push back on these immediately.
No Evidence of Monitoring
The objective exists on paper, but there is no record of it ever being reviewed. No meeting minutes, no status reports, no data. This suggests the objective was created for the certification audit and then forgotten. Expect a nonconformity.
Objectives Not Updated After Risk Changes
The risk landscape changes. New systems are deployed, new threats emerge, regulatory requirements shift. If the objectives have not been reviewed and updated to reflect those changes, the clause requirement to update objectives as appropriate has not been met.
No Connection to the Risk Assessment
Objectives that appear to have been invented without reference to the risk assessment or treatment plan. This is a systemic issue because it suggests the planning processes are not integrated. An auditor finding this will likely look more carefully at both the risk assessment and the objectives to understand whether either is genuine.
Objectives Not Communicated
Clause 6.2 requires that objectives are communicated to relevant parties. If the people responsible for achieving the objectives do not know what they are, the system is not functioning. Auditors will ask objective owners what their targets are. If they cannot answer, that is a finding.
Linking Objectives to Management Review
Information security objectives feed directly into the management review process under Clause 9.3. The management review must consider the extent to which objectives have been achieved. This means the monitoring data you collect throughout the year has a specific destination. It is not just collected for its own sake. It informs a decision-making process at the highest level of the organisation.
If your management review minutes do not show a discussion of objective performance, supported by actual data, the connection between planning and review has broken down. Certification auditors check this link specifically because it is where they can see whether top management is genuinely engaged with the ISMS or just signing off on paperwork.
For a practical guide to what auditors look for when reviewing ISMS performance evaluation, see our article on how to audit performance evaluation in an ISMS.
Exemplar Global Recognised Training ProviderRTP No. 310970Practical Steps to Get Clause 6.2 Right
If you are building or reviewing your information security objectives, here is a practical sequence to follow.
- Start with the risk treatment plan. Identify the controls you have selected. For each significant control, ask what a measurable indicator of effectiveness looks like.
- Draft objectives using the six criteria. Specific, measurable, achievable, relevant, time-bound, and owned. For each objective, confirm you have a metric, a target, a deadline, and a named owner before you finalise it.
- Check alignment with the information security policy. Every objective should connect to a commitment in the policy. If it does not, either the objective is wrong or the policy needs updating.
- Document the objectives formally. Clause 6.2 requires documented information. A simple register with the objective, metric, target, deadline, owner, and current status is sufficient.
- Build a monitoring cadence. Decide how often each objective will be reviewed, who is responsible for collecting the data, and where that data will be recorded.
- Feed results into management review. Ensure the management review agenda includes a standing item on objective performance, supported by the monitoring data.
- Update objectives when circumstances change. After significant risk assessment updates, after incidents, after regulatory changes, review whether the current objectives remain appropriate.
Building Auditor Capability Around Clause 6.2
If you are an internal auditor or aspiring lead auditor, understanding how to audit information security objectives is a distinct skill. It requires you to trace the connection between the risk assessment, the treatment plan, and the objectives. It requires you to ask for monitoring records, not just the objectives document. And it requires you to test whether objective owners actually know what they are responsible for.
The questions that tend to be most productive in an audit of Clause 6.2 are practical ones. Ask the objective owner how they track progress. Ask them what the current performance is against the target. Ask them what they would do if the objective looked like it was going to be missed. The answers reveal whether the objectives are being actively managed or just stored in a folder.
If you are looking to build structured skills in auditing information security management systems, Audit Workshop offers ISO 27001 auditor training at both internal and lead auditor levels. The training is grounded in real audit practice, not just clause-by-clause theory, and is designed for practitioners who want to conduct audits that add genuine value. You can explore the available courses at auditworkshop.com.
