What Clause 6.2 Requires
Clause 6.2 requires the organization to establish information security objectives at the functions and levels where they are relevant — not one corporate statement, but targets that reach the teams doing the work. Each objective must line up with the information security policy, be measurable where that is practicable, and reflect both the applicable information security requirements (legal, contractual, interested-party) and the results of risk assessment and risk treatment. Objectives must then be actively managed: monitored over time, communicated to the people who have to deliver them, and updated when circumstances change. The objectives themselves must exist as documented information — one of the standard's explicitly mandatory documents.
The second half of the clause covers planning. For every objective, the organization must work out what will be done, which resources the work needs, who carries responsibility, when it will be completed, and how the result will be evaluated. The 2022 revision sharpened the clause in one notable way: objectives must now explicitly be monitored, closing the loophole where organizations wrote objectives once and looked at them again only when the next audit loomed.
Why This Clause Exists
To convert the broad commitments in the information security policy into specific, trackable targets — each backed by a real plan — so the ISMS demonstrably improves the organization's security posture instead of merely maintaining paperwork.
What This Really Means
Think of clause 6.2 as the OKR system for your ISMS. The information security policy (clause 5.2) sets direction — protect customer data, meet legal obligations, keep services available. Objectives turn that direction into commitments with numbers and dates attached, and the planning requirement forces you to budget the work instead of just wishing for the outcome.
The difference between a good and a bad objective decides whether this clause works for you or against you. "Improve security" and "strengthen our security culture" are not objectives — they cannot be measured, so they can never be achieved or missed. Compare: "close 95% of critical vulnerabilities within the SLA defined in our patching standard, measured quarterly", "reduce mean time to revoke leaver access to under 24 hours by Q3", or "reach 95% completion of role-based security training by year end". Each has a metric, a target, and an implied owner — an auditor can ask how it is going, and you can answer with data.
Objectives should also cascade. "At relevant functions and levels" means an organization-level objective (no repeat audit findings in access control) breaks down into function-level targets: IT operations completes quarterly access reviews on time, HR processes 100% of leavers through the offboarding checklist. A single list owned entirely by the CISO, invisible to the teams whose work actually moves the numbers, fails the spirit of the clause and usually the letter too.
What auditors treat as the heart of 6.2: documented objectives exist, each traces to the policy and the risk picture, each carries the five planning elements (what, resources, who, when, how evaluated), and — above all — there is evidence the objectives were monitored between audits. The classic failure is a list written the week before Stage 1 and untouched since; the monitoring trail is what separates a managed system from a stage prop.
Why It Matters
Objectives are how top management proves the ISMS is going somewhere. Risk treatment (clause 6.1) keeps bad things from happening; objectives make good things happen on purpose. Auditors lean on them because they are the single best indicator of whether the management system is alive: a living ISMS produces measurement data, status discussions, and course corrections, while a paper ISMS produces a list typed once.
The clause also anchors a chain the rest of the standard depends on. Objective progress is part of what clause 9.1 measures, objective fulfillment is a required input to the clause 9.3 management review, and missed objectives feed clause 10.1 improvement. Weak objectives quietly hollow out all three.
When objectives are missing, vague, or untracked:
- •Stage 1 documentation finding – documented objectives are mandatory; a missing or evidently decorative list is one of the quickest nonconformities an auditor can raise before Stage 2 even begins
- •No evidence of improvement – without measurable targets you cannot demonstrate the ISMS improves anything, which resurfaces as a clause 10.1 weakness
- •Management review without substance – clause 9.3 requires reviewing objective fulfillment; vague objectives reduce that agenda item to "all fine, moving on"
- •Surveillance audit exposure – objectives identical and unmeasured across two surveillance cycles signal a stalled system and invite escalation from minor to major findings
- •Lost budget leverage – objectives with costed plans are the strongest internal argument security has for resources; vague intentions win nothing
Regional Compliance Context
Organizations in India's regulated financial sector should align ISMS objectives with the security performance reporting their regulator already expects: RBI master directions keep boards engaged with the cyber risk posture of regulated entities, and SEBI's CSCRF expects market intermediaries to track and report security metrics. Running one set of objectives that satisfies both the ISMS and the regulator beats maintaining parallel scorecards — where the mandated metrics overlap with your risk picture, derive the ISMS objectives from them directly.
Documented Information Required
Information security objectives
MandatoryThe documented set of objectives — each measurable where practicable, with its metric, target, owner, and timeline. Version-controlled and approved by management; this is explicitly required documented information.
Objective achievement plan
RecommendedThe what / resources / who / when / how-evaluated plan for each objective. It can live inside the objectives document itself or in a project tracker — auditors care that the five elements exist, not where they live.
Objective monitoring records
RecommendedPeriodic measurements — a KPI dashboard export, quarterly status report, or management review extract — proving each objective is tracked at a defined frequency rather than rediscovered annually.
See the full ISO 27001 mandatory documents checklist for every document and record the standard requires.
How to Implement Clause 6.2
Derive Candidate Objectives from Policy, Risks, and Requirements
Pull threads from four sources: the commitments in your information security policy, the top risks and treatment priorities from clause 6.1, the interested-party requirements identified under clause 4.2, and recurring pain such as incident trends or prior audit findings. An objective that cannot be traced to one of these sources is decoration. The CISO or ISMS manager typically drafts; expect 3–7 strong candidates, not 20.
Make Each Objective Measurable
Give every objective a metric, a baseline, a target, and a measurement method. Transform vague intent into testable form: "improve patching" becomes "close 95% of critical vulnerabilities within the SLA in our patching standard." Where a number genuinely does not fit (for example, "implement a PAM solution"), define dated, binary completion criteria instead — the standard asks for measurable where practicable, and auditors accept milestone-based objectives when they are unambiguous.
Cascade Objectives to Functions and Levels
Break organization-level objectives into the function-level targets that actually move them: IT operations owns the access review completion rate, HR owns offboarding checklist execution, engineering owns secure-release criteria. Record the cascade so each function sees its slice — this is what "at relevant functions and levels" means in practice.
Plan the Five Elements for Each Objective
For every objective, record what will be done, the resources required (budget, tools, people-hours), the single accountable owner, the completion or review date, and how results will be evaluated. A table with five columns satisfies this; the discipline of filling it in is what exposes unresourced wishes early.
Approve and Communicate
Take the objectives through management approval — a leadership meeting or the management review both work — and record the decision. Then communicate each objective to its owner and the affected teams. An objective whose owner first hears about it in the audit interview is a finding waiting to happen.
Monitor at a Defined Frequency
Measure monthly or quarterly, whichever matches the metric, and record the readings. Reuse machinery you already have: a BI dashboard, a spreadsheet refreshed each quarter, or your GRC tool. Feed the status into management review as the clause 9.3 input on objective fulfillment.
Update Objectives When the World Changes
Refresh the set after the annual risk assessment, after significant incidents, and when scope or business priorities shift. Retire achieved objectives explicitly and replace them — a list that has not changed in two years tells auditors the system stopped thinking.
Audit Evidence
During Stage 1 and Stage 2 of your ISO 27001 certification audit, auditors will expect the following evidence to demonstrate conformity with Clause 6.2:
Documentation
- Documented information security objectives with metric, target, owner, and date for each
- Achievement plans showing the five planning elements (what, resources, who, when, evaluation method)
- Monitoring records — dashboard exports, quarterly status reports, or tracked KPI history
- Management review minutes showing objective fulfillment as an input and decisions taken on lagging objectives
- Version history of the objectives document showing updates after risk assessments or business change
Interviews
- CISO or ISMS manager on how objectives were derived from the policy and risk results, and how progress is tracked
- Objective owners in the functions (for example, the IT operations lead holding a patching or access-review target) on current status and the last measurement
- Top management on how objectives connect to business priorities and what was decided when an objective slipped
Observations
- The live tracking mechanism — dashboard, spreadsheet, or GRC tool — showing current readings rather than reconstructions
- A traceability walk-through from one objective back to the policy commitment or risk it addresses and forward to its latest measurement
- Evidence of communication: objectives visible where teams work (intranet page, team OKR tool, all-hands material)
Practitioner Insights
My standard probe for 6.2 is to pick one objective and ask for its most recent measurement. The failure pattern is consistent: a well-formatted objectives document created shortly before Stage 1, with no readings behind it. The second pattern is objectives that are really slogans — "achieve 100% security" cannot be measured, so it cannot be an objective. Three to five genuinely instrumented objectives will always audit better than twelve decorative ones, and they give the management review something real to decide about.
Smaller organizations sink time into building a separate objectives bureaucracy when the standard never asks for one. If your engineering team already runs OKRs in a tool, security objectives can live there, and the five planning elements are five columns in a sheet. The evidence mistake I see most is tracking the metric faithfully but never recording an evaluation of the result — add one line each quarter saying what the reading means and what you decided, and you have closed the loop the clause actually asks for.
Common Challenges & Solutions
Challenge
Objectives are written as aspirations ("strengthen security culture") that can never be measured or closed.
Solution
Rewrite each one with a metric, a target, and a date, even if the first baseline is a guess. "Strengthen security culture" becomes "reach 95% completion of role-based training and cut the phishing-simulation click rate below 5% by Q4." If an objective resists all measurement, make it milestone-based with dated, binary completion criteria.
Challenge
Objectives exist on paper but nobody measures them between certification audits.
Solution
Attach monitoring to a meeting that already happens — a quarterly ops review or the management review cycle — and name a metric owner for each objective. A 15-minute standing agenda item with a one-page dashboard is enough; the goal is a dated trail of readings, not a reporting program.
Challenge
Objectives float free of the risk assessment and the policy, and auditors flag the disconnect.
Solution
Add a traceability column: each objective cites the policy commitment or risk register entry it advances. Run the check in reverse too — if your top three risks have no corresponding objective or treatment action, either the objectives or the risk assessment needs revisiting.
Challenge
Every objective is owned by the CISO, and the functions whose work drives the numbers have never heard of them.
Solution
Cascade ownership deliberately: the organization-level objective stays with leadership, but each contributing target gets a named functional owner who reports status. Put the function-level targets into the team goal systems that already exist so they are managed as work, not as compliance.
Challenge
The same objectives roll forward year after year, including ones achieved long ago.
Solution
Make objective refresh an explicit management review output: retire what is achieved, restate what changed, and add what the new risk picture demands. Keep the version history — an evolving objectives document is itself evidence of a functioning ISMS.
