6.2 — Information security objectives and planning to achieve them
Objectives turn your risk treatment decisions into a forward-looking commitment your organization can be held to — and that your auditor can track from one surveillance audit to the next.
In plain language
In plain language: sub-clause 6.2 requires you to set concrete, measurable information security objectives that flow from your policy and your risk work, and to plan — with resources, an owner, and a deadline — exactly how you intend to reach each one.
Position in the standard
Why this requirement exists
A policy that says "we take security seriously" means nothing without objectives that make it testable. This requirement forces that translation: from intent to a specific, dated commitment someone owns.
Scenario: an organization writes "reduce our attack surface" as an objective and considers the job done. A year later, at the surveillance audit, nobody can say whether that happened, because there was never a metric, an owner, or a deadline attached to it. A properly planned objective — "reduce internet-facing services from 40 to 15 by Q3, owned by the infrastructure lead, tracked monthly" — gives the auditor, and the organization, something to actually check.
What the standard expects
Objectives must be consistent with your information security policy, measurable wherever practicable, take into account applicable security requirements and the results of your risk assessment and treatment, be monitored, be communicated, be updated as needed, and be kept as documented information. On top of setting the objectives themselves, the standard requires a plan for reaching each one that spells out what will be done, what resources it will take, who is responsible, when it will be completed, and how the results will be evaluated.
In practice
- Derive objectives from your risk treatment plan (6.1.3) rather than inventing generic ones — every high-priority risk should have a corresponding objective or map to an existing one.
- Write each objective with a number and a deadline: "reduce X to Y by [date]," not "improve X."
- Assign one accountable owner per objective, with the resources they need actually allocated, not assumed.
- Review progress on a fixed cadence (quarterly is common) and feed the results into your management review (clause 9.3).
Evidence the auditor will ask for
- A documented list of current security objectives, each with a metric, an owner, and a deadline.
- The action plan for each objective, showing resources and planned steps.
- Progress tracking records or dashboards showing the objectives were actually monitored.
- Evidence objectives were communicated to relevant staff, not just filed.
Common pitfalls
- Vague objectives with no number attached — "improve awareness" instead of "achieve 95% completion of security training by Q2."
- Objectives set once at certification and never revisited — a snapshot rather than a living target.
- No traceable link between objectives and the risk assessment or the security policy.
Related requirements
6.1.3 Risk treatment
Treatment decisions are the most common source of new objectives.
6.3 Planning of changes
Pursuing an objective is itself often a change to plan for.
Parent link: Clause 6 · Planning
Frequently asked questions
How many security objectives should we have?
Can an objective be qualitative rather than numeric?
Set security objectives that survive the surveillance audit.
Sentrix links your objectives to your risk register and tracks progress automatically, so nothing goes stale between audits.