ISO 27001 Clause 6.2: Security Objectives
Clause 6.2 requires your organization to set information security objectives that are measurable, aligned with your policy, and backed by a plan to achieve them. Without clear objectives, your ISMS has no way to demonstrate whether it is actually improving security or just generating documentation.
What the clause requires
ISO 27001:2022 Clause 6.2 specifies that information security objectives must:
- Be consistent with the information security policy
- Be measurable (or at minimum, capable of being evaluated)
- Take into account applicable security requirements and risk assessment results
- Be monitored, communicated, and updated as appropriate
- Be retained as documented information
When planning how to achieve each objective, you must also define:
- What will be done
- What resources are required
- Who is responsible
- When it will be completed
- How results will be evaluated
This is not a suggestion list - auditors check for all of these planning elements against each objective.
How to set practical objectives
The standard requires objectives but does not prescribe what they should be. Here is how to set objectives that satisfy auditors and actually drive security improvement:
Start from your risk assessment
Your objectives should address the most significant risks from your risk assessment. If your top risks relate to phishing and cloud misconfiguration, your objectives should target those areas - not generic goals about “improving security.”
For a 25-person SaaS company, a typical set of 4-6 objectives might include:
- Reduce phishing click rate from 12% to under 5% by end of Q2 through monthly security awareness training
- Achieve 100% MFA coverage across all production systems by end of Q1
- Reduce mean time to patch critical vulnerabilities from 14 days to 7 days
- Complete annual risk reassessment by end of Q3
- Pass surveillance audit with zero major nonconformities
Make them measurable
The standard says objectives must be measurable “where practicable.” In practice, auditors expect most objectives to have quantifiable targets. Vague objectives like “improve data security” or “strengthen our security posture” will get challenged.
Good measurable objectives have a baseline (where you are now), a target (where you want to be), and a deadline. “Reduce successful phishing attempts from 12% to under 5% by Q2” is measurable. “Improve phishing awareness” is not.
Some objectives are harder to quantify - “build a security-aware culture,” for example. For these, use proxy metrics: training completion rates, incident reporting frequency, or phishing simulation results. The goal is evaluation capability, even if the measurement is indirect.
Keep the number manageable
Organizations that set 15-20 objectives struggle to track them all and end up with a stale list that nobody monitors. Four to eight objectives is a practical range for most organizations. Each one should be meaningful enough to warrant dedicated resources and tracking.
Assign clear ownership
Every objective needs an owner - someone accountable for progress. This connects directly to your roles and responsibilities under Clause 5.3. The objective owner does not have to do all the work, but they must track progress and report during management review.
Document the plan
For each objective, document what actions are needed, who is responsible, the timeline, the resources required, and how you will evaluate success. This can be a simple table or a section in your ISMS manual. The format does not matter - the completeness does.
| Objective | Owner | Actions | Resources | Deadline | Evaluation |
|---|---|---|---|---|---|
| Reduce phishing click rate to under 5% | ISMS Manager | Monthly phishing simulations, targeted training for repeat clickers | Security awareness platform, 2 hours/month staff time | Q2 2026 | Monthly simulation reports |
| 100% MFA on production systems | CTO | Audit current MFA coverage, deploy to remaining systems | Identity provider license, 40 hours engineering time | Q1 2026 | System access audit |
Connecting 6.2 to the rest of your ISMS
Objectives sit between planning and execution - they translate risk findings into concrete targets.
Clause 5.2 connection. The information security policy sets the strategic direction. Objectives must be consistent with it. If your policy commits to protecting customer data, your objectives should include specific targets related to data protection.
Clause 6.1 connection. Risk assessment results are a direct input to your objectives. Risks above your acceptance threshold should be addressed either through risk treatment controls or through objectives that target specific improvements.
Clause 6.3 connection. Planning of changes applies when objectives require significant changes to the ISMS. Adding a new technology platform to meet an objective, for example, should go through change planning.
Clause 9.1 connection. Monitoring, measurement, analysis, and evaluation is where you track objective progress. Define what metrics to collect and how often before you start - not after.
Clause 9.3 connection. Management review must evaluate the status of objectives. This is where leadership reviews progress, decides whether objectives are still relevant, and approves changes to targets or timelines.
What auditors check
Objectives are one of the most commonly audited areas - and one of the most common sources of findings.
Documented objectives with planning elements. Auditors check that each objective has all the required planning elements: actions, resources, responsibility, timeline, and evaluation method. Missing any of these is a finding, even if the objective itself is well-defined.
Consistency with the policy. Auditors compare objectives against your information security policy. If the policy emphasizes availability but none of your objectives address uptime or recovery, they will note the gap.
Evidence of monitoring. Setting objectives is not enough - you must show evidence of tracking them. Auditors ask for progress reports, dashboard screenshots, or management review minutes that discuss objective status. If you set objectives 12 months ago and have no evidence of monitoring since, that is a nonconformity.
Risk-informed objectives. Auditors check whether objectives reflect your actual risk landscape. If your risk register highlights insider threats as a top risk but none of your objectives address access control or monitoring, they will question the connection between risk assessment and objective setting.
Updates over time. For surveillance audits, auditors look for evidence that objectives evolve. Completed objectives should be replaced with new ones. Objectives that missed their deadline should show evidence of review and adjustment - not just the same stale targets year after year.
Common mistakes to avoid
Setting objectives once and forgetting them. The most common mistake is defining objectives during implementation and never reviewing them. Clause 6.2 requires objectives to be “updated as appropriate.” If your objectives look identical at your second surveillance audit, auditors will question whether you are actually using them to drive improvement.
Objectives disconnected from risks. Generic objectives that do not trace back to your risk assessment or policy commitments add no value. Every objective should answer the question: why does this matter to our organization specifically?
No measurable targets. “Improve security awareness” is not an objective - it is an aspiration. Attach a metric: “Achieve 95% completion rate for annual security awareness training” or “Reduce phishing simulation click rate below 5%.” If you cannot measure it, you cannot evaluate it, and you cannot demonstrate improvement.
Too many objectives. An organization with 20 objectives is unlikely to track or achieve them all. Focus on the four to eight that matter most. Quality beats quantity, and auditors prefer a small set of well-tracked objectives over a long list with no evidence of progress.
Confusing objectives with controls. “Implement MFA” is a control, not an objective. The objective is the outcome: “Prevent unauthorized access to production systems.” MFA is one of the actions you take to achieve it. This distinction matters because auditors expect objectives to be outcome-focused, not task lists.
How 27kay can help
We help organizations define objectives that auditors accept and that actually drive security improvement - not generic statements that exist only for the certificate. As part of ISO 27001 implementation, we connect your risk assessment results to practical, measurable objectives and set up the tracking framework so management review has something meaningful to evaluate. For the full picture, see our ISO 27001 knowledge hub.
Need help setting security objectives that work? Get in touch - we will review your risk landscape and help you build objectives that make a real difference.