ISO 27001 Clause 6.2: information security objectives that pass audit

The Stage 2 auditor asks you to trace one security objective from the risk register to the management review minutes. Yours live on a slide from the kick-off workshop, nobody owns them, and the green dashboard tile is fed by nothing.

This guide shows founders, heads of security and compliance leads at UK regulated firms and B2B SaaS companies how to set three to six information security objectives that survive that sampling. It covers what ISO 27001 Clause 6.2 requires, the delivery plan behind each objective, examples wired to live data, how to handle a missed target, and the evidence pack.

What does ISO 27001 Clause 6.2 require?

ISO 27001 Clause 6.2 requires leadership to set written information security objectives that fit the security policy under Clause 5.2 and answer the risks assessed under Clause 6.1. Each objective needs a delivery plan, and the standard expects objectives to be monitored, communicated, updated and documented, with measurement wherever practical.

Clause 6.2 is where the information security management system gets its targets. Leadership writes down a small number of objectives, backs each with a plan, and keeps checking whether the plan works. Results flow into the management review under Clause 9.3, and misses flow into corrective action under Clause 10.2.

Auditors test every objective against the standard's attribute checklist. Each objective should be:

• Consistent with the security policy set under Clause 5.2.
• Measurable wherever a metric is practical.
• Risk-informed, taking account of your security requirements, including legal and contractual ones, and the results of risk assessment and treatment.
• Monitored over time, with evidence that someone looked.
• Communicated to the people who deliver it.
• Updated when circumstances change.
• Documented as controlled information, with versions and approval.

Most of this is practice you already run. You patch, train staff and review access. Clause 6.2 asks you to pick the few that matter most for your risks, name an owner for each and keep the evidence together. The ISO/IEC 27001:2022 standard overview presents the standard as guidance for companies of any size and sector, so a 50-person firm's register should look nothing like a bank's.

Legal and contractual obligations belong in the register as drivers. A customer contract that promises timely patching is a reason to have a patching objective, and an auditor will accept it as one.

How many information security objectives should you set, and must they be numbers?

Set three to six information security objectives, derived from your Clause 4 context and the risk treatment decisions under Clause 6.1 rather than a template. Numbers are required only where practical: qualitative or maturity-based goals are legitimate if you can still evaluate them through structured review.

Fewer objectives get delivered. Each one needs an owner, resources, a metric and quarterly attention, so beyond six the register becomes a list nobody reads and the auditor's sample lands on the weakest entry. At 50 people, three objectives often cover vulnerability management, awareness and supplier risk.

Derive them in three moves:

1. Start from context. Take interested parties, obligations and scope from your Clause 4 work.
2. Read the treatment decisions. Pick the risks where you chose to reduce rather than accept.
3. Group and cut. Merge related treatments into one objective each, and drop any without an owner or a plausible metric.

Your biggest risks name your objectives. If the Clause 6.1 treatment plan puts unpatched internet-facing systems at the top, that is objective one.

Write each as an outcome with a boundary. "Critical vulnerabilities on internet-facing systems are remediated within 14 days" beats "improve vulnerability management".

A qualitative goal still needs a test. Security awareness among engineers, for example, can be evaluated through a maturity review or a structured leadership assessment, scored against criteria written down in advance. What matters is that a second reviewer, shown the same evidence, reaches the same conclusion.

Resist adding objectives to please stakeholders. Park the rest as projects in the treatment plan. They stay visible there without being audited as objectives, and they add no unowned entry for the sample to find.

Template sets are the usual trap. A copied list of ten objectives, disconnected from your own risk assessment, fails the auditor's first question: how does this trace back to your risk assessment?

What are the five planning questions every objective must answer?

Every objective needs a delivery plan answering five questions: what actions will be taken, what budget, people and tooling sit behind them, which single named individual owns the result, when it completes, and how success is evaluated. One page per objective is enough; 'the IT team' does not count as an owner.

The five questions turn an objective from a slogan into a plan, and they are the questions the auditor reads off the page:

1. Actions. What work will be done, broken into steps the owner can schedule.
2. Resources. The budget, hours and tooling behind those actions.
3. Owner. One named individual with the authority and access to deliver.
4. Completion date. A calendar date, not "ongoing".
5. Evaluation method. The metric, target and data source that will show success.

For a 50-person SaaS firm, the patching objective's plan might read:

• Actions: weekly authenticated scans and a triage rota for critical findings.
• Resources: the scanner licence and two engineer hours a week.
• Owner: the Head of Engineering.
• Completion: first full quarter of data by 30 June, then quarterly review.
• Evaluation: share of critical findings closed within 14 days, from the scanner export.

Ownership is where plans break. The NCSC guidance on cyber security governance notes that risk decisions can be delegated to the people best placed to understand the problem, and that good governance makes business goals and risk appetite clear. Delegation only works when a named person holds the authority to act on what they are given.

A goal assigned to a team gets delivered by no one. An owner can delegate tasks but not accountability, so list contributing groups beneath one accountable name on both the register and the plan.

Resourcing is part of the plan the standard spells out, and auditors check it. An objective with no budget, hours or tooling attached is a wish. Write the engineer days, the licence or the contractor cost beside each action, even as an estimate.

Keep each plan to one page, stored with the register under the same version control. The page doubles as the owner's briefing, and it gives the auditor a single document to follow.

What do good information security objectives look like when wired to live data?

Good information security objectives name a metric, a target and a live data source you can show an auditor: scanner output for patching SLAs, LMS completion for training, IdP reports for access reviews. If you cannot point at the data underneath, the objective is not genuinely monitored.

Three objectives cover most of a mid-market stack. Each pairs a metric and target with a data source and the evidence it leaves behind, as the table at the end of this section sets out:

• Patching. Critical vulnerabilities on internet-facing systems closed within the agreed SLA. The scanner holds the data.
• Training. New joiners complete security awareness training within 30 days, with an annual refresh. The LMS reports completion.
• Access reviews. Quarterly reviews of privileged access closed on time. The IdP report and review tickets show closure.

Targets come from your risk work, not this page. If 14 days is unrealistic given your release cadence, record a baseline first and tighten it over two quarters; the revision history then shows improvement.

Pull the figure from the source rather than retyping it. A scheduled scanner export saved to the evidence folder each month beats a screenshot taken the morning of the audit.

Aspirational wording is the first pitfall. "Strengthen our security culture" is a poster, not an objective, so rewrite it until a stranger could mark it met or missed.

Incident counts are the second pitfall. Teams set a target of no incidents because it sounds ambitious, and then the number becomes something to protect.

A zero-incident objective mostly teaches people not to report incidents.

Measure the response you want instead, such as time from report to triage, as the last row of the table does. A rising count of reports then reads as a sign the culture works, not a failure.

Dashboards are the third pitfall. A tile turns green when its query returns nothing, so a broken feed looks exactly like a clean result.

A dashboard tile nobody can trace to a data source is decoration, not a metric.

What should you do when an objective target is missed?

A missed target is not an audit failure by itself. Record the variance, find the root cause, and raise corrective action under Clause 10.2, then report it at the management review. What fails is quietly extending the deadline, which erases the evidence that the management system detects and corrects problems.

Check metrics quarterly at this scale and evaluate formally at the annual management review under Clause 9.3. Refresh objectives whenever the business or threat picture shifts materially.

When a target slips, run four steps:

1. Record the variance. Target, actual, date and data source.
2. Find the root cause. A vendor patch that broke a build is a cause; "people were busy" is not.
3. Raise corrective action under Clause 10.2, with an owner and a date.
4. Report it at the management review, and decide whether to resource, revise or escalate.

A missed target with a corrective action on file is stronger evidence than a hit target with nothing behind it.

Escalate early where the cause is resourcing. A target missed for lack of hours is a decision for leadership, not a reason to blame the owner, and the minutes should show that decision being made.

Re-dating a missed target is the commonest way to turn a miss into a finding. The new date erases the variance, so the auditor sees no sign the system noticed anything. If the target was wrong, revise it through a documented change that says why, and keep the old version.

Take a SaaS firm that misses its 14-day patching target because a vendor update broke a build. The variance, the cause and the fix to its test pipeline make a complete record, and that record is what the auditor hopes to find. The same habit carries over to privacy work: the ICO Data Protection Audit Framework offers organisations a way to record, track and report on progress.

What do auditors ask about Clause 6.2, and how are findings graded?

At Stage 2, auditors trace one objective end to end: register entry, delivery plan, metric source and management review minute. Missing or unplanned objectives grade as a major nonconformity; objectives never formally evaluated, or missed targets without corrective action, grade minor and can aggregate to major as a pattern.

Expect these questions in the room:

• "Show me your security objectives. Where do they live, and who approved them?"
• "How does this objective trace back to your risk assessment?"
• "Who owns it, what resources sit behind it, and when is it due?"
• "How do you monitor progress? Show me the data underneath the dashboard."
• "This target was missed. Walk me through what happened next."

Sampling goes deep rather than wide. Alongside the document trail, the auditor asks interviewees how their day-to-day work moves the objective forward. Evaluation gets particular attention, because monitoring has to be demonstrable, not asserted.

In certification-body practice, grading for this clause runs along these lines:

• Major nonconformity: no documented objectives, or objectives with nothing planned behind them. At Stage 2 that is the absence of a requirement.
• Minor nonconformity: objectives set but never formally evaluated, or a missed target with no corrective action.
• Aggregation: repeated minors on this clause can be raised as a major as a pattern.

Auditors vary in how they weigh a single gap, so read the grading as a guide to patterns rather than a guarantee.

Objectives are the auditor's test of whether the ISMS is steering anything or merely existing. Vague or absent targets read as a management system on autopilot, and that impression colours the rest of the assessment.

Prepare interviewees as well as paperwork. An engineer who can say the patching SLA is 14 days, and show the backlog report that proves it, closes the sampling trail faster than any document.

What evidence pack proves Clause 6.2 to an auditor?

The evidence pack you hand the auditor has six parts: the approved, versioned objectives register; a one-page delivery plan per objective; raw metric data such as scanner exports and LMS reports; management review minutes showing evaluation; a communication trail; and corrective action records for anything missed.

Credible means real data underneath and an approval trail. Check each item:

• Objectives register: approved by leadership, versioned, with the date of the last review.
• Delivery plans: one page per objective naming actions, resources, owner, date and evaluation method.
• Metric data: raw scanner exports, LMS reports and uptime records, not a screenshot of a tile.
• Management review minutes: showing objectives were evaluated, with decisions recorded, not merely listed.
• Communication trail: onboarding materials, briefing notes and intranet posts, each dated.
• Corrective action records: a ticket per missed target, with cause and closure.

Dates matter, and auditors read them on minutes and exports. Exports spread across the year show monitoring happened; a folder created the week before the audit shows a project. Four quarterly checks with short notes beat one polished pack.

Run a dry run before Stage 2. Pick one objective and walk it from risk register to review minute, timing how long each document takes to find. Gaps found in the dry run are cheap, and the same gaps found by the auditor are findings.

How do you automate Clause 6.2 monitoring and corrective action?

Treat the objectives register as data: each objective is a record with owner, metric, target and review date. Bind metrics to scanner, LMS and IdP sources, and let a drift past threshold open a ticket with the owner attached, so monitoring and the corrective-action trail generate themselves.

Three design choices make the pipeline work:

• Register as data. Each objective is a record carrying owner, metric, target and review date. Status becomes a query, and the management review pack assembles itself from the register.
• Metrics bound to sources. Patch SLAs pull from the scanner, training completion from the LMS, and access review closure from the IdP or ticketing system. Monitoring happens because the pipeline runs, not because someone remembers.
• Variance as an event. A metric drifting past its threshold opens a ticket with the owner attached, so the corrective-action trail the auditor wants comes from the workflow itself.

People keep the judgement: choosing objectives, deciding root causes and approving revisions. The pipeline handles chasing, collecting and timestamping.

Before each quarterly check, the owner reviews a variance report instead of hunting for exports, and the management review minutes record decisions rather than data entry.

The payoff is commercial. Enterprise buyers and regulators increasingly ask not whether you are certified but what you are improving and how you know. Credible objectives answer that question, and give the board a defensible basis for security spend instead of busywork.

At 50 people, a register run this way satisfies auditors and enterprise customers with the same evidence.

Frequently asked questions