What are information security objectives?
Information security objectives set out what state an ISMS is to reach within a given period, which makes its effectiveness testable. ISO/IEC 27001:2022 covers them in clause 6.2, together with the planning of how to achieve them. The BSI mapping table maps clause 6.2 to BSI-Standard 200-2, chapter 3. The objectives derive from the information security policy.
How objectives fit into building an ISMS is covered in the guide to ISMS implementation.
What does ISO 27001 clause 6.2 require?
Clause 6.2 covers two things: the objectives themselves and the planning of how to achieve them. Its core text comes from the harmonized structure that ISO sets for management system standards. In an audit, an auditor looks mainly at three points:
- Each objective can be traced back to the policy and applies to named functions or levels.
- Each objective has a plan for reaching it and for evaluating whether it was reached.
- The objectives are documented, known to the people involved and up to date.
Objective, metric, measure: three levels
An objective describes a state, a metric measures it, a measure brings it about. The table shows the split using one example:
| Level | Question | Example |
|---|---|---|
| Objective | What state is to be reached? | Critical systems can be restored within the agreed recovery time |
| Metric | How is it measured? | Share of critical systems with a successfully tested restore |
| Measure | What is done to get there? | Restore tests per system, fixing the findings, retest |
Without this split, two faulty forms appear. The first is an objective that is actually a measure ("introduce a SIEM"); the second is a metric with no target state ("number of incidents").
Where should information security objectives come from?
Information security objectives should have an origin that can be named in an audit. Four sources qualify:
- the risk treatment plan, because the significant risks set the priorities;
- requirements of interested parties, such as contractually committed recovery times;
- findings from internal audits, incidents and exercises;
- projects with a security dimension, such as a cloud migration.
An objective that cannot be traced to any of these sources does not belong on the list.
Three examples with a traceable origin
| Objective (example) | Origin | Measure of success |
|---|---|---|
| Privileged access is personal and traceable | Finding from the internal audit | Share of privileged accounts without shared use |
| Security-relevant vulnerabilities are handled within set deadlines by severity | Result of risk treatment | Time to remediation per severity |
| New staff know the reporting route and the policy from day one | Incident with an organisational cause | Share of joiners briefed before system access |
Target and baseline values are left out on purpose. They are specific to each organisation and have to be derived from its own requirements and risks.
Measurable if practicable: baseline, target, date
Under the core text, measurability applies only where it is practicable. Where no number fits, achievement can also be established through a maturity statement or the result of an exercise.
Where a number is chosen, three values belong with it: baseline, target and date. Without a baseline, nobody can decide at the end of the period whether the objective was met.
How are objectives cascaded across functions and levels?
The duty to set objectives at relevant functions and levels calls for a cascade. Objectives at management system level lead to derived contributions from the areas that actually deliver, such as IT operations, development, HR and procurement. A cascade that hands every area the same objective creates effort without steering anything.
Communicating does not mean publishing. Whoever is to contribute to an objective has to know their contribution. An auditor may ask someone responsible in IT operations which objective concerns their area and how its achievement is measured.
Four shortcomings that lead to audit findings
Findings arise where a requirement of clause 6.2 is not met:
- Objectives have stayed the same for years although they have been met or become irrelevant (updating).
- An objective has no plan, or its plan is never evaluated (planning).
- The people involved cannot name the objectives for their area (communication).
- Achievement is reported but not evaluated (monitoring).
The evaluation itself belongs in the management review, in which top management decides whether the ISMS is still fit for purpose and working.
How Rizzqo backs objectives with computed values
Rizzqo computes coverage per asset, per asset category and per framework from the finalised requirement answers. An objective such as "by year end, all cloud services are fully covered against the ISO 27001 requirements" then has a measure. It is the share of fully covered assets in that category. The value comes out of the work itself rather than being maintained by hand.
A daily snapshot records these values, so achievement can be shown over months. Open requirements appear with their responsible owner, and the measures for a missed objective can be derived from them directly.