Information Security Objectives

Information security objectives are the measurable intentions an organisation sets for what its ISMS is to achieve. ISO/IEC 27001 requires them in clause 6.2 at the relevant functions and levels: consistent with the policy, measurable where practicable, monitored, communicated, updated, and available as documented information.

ISMSLast reviewed:

Objectives are the point at which it becomes visible whether an ISMS is being steered or merely operated. Without them, the question the management review has to answer, whether the system is still suitable, adequate and effective, can only be answered with a feeling. With badly cut objectives, it gets answered with numbers nobody cares about.

What clause 6.2 requires

The standard places a series of requirements on each objective. It has to be consistent with the information security policy, measurable where practicable, take account of the applicable requirements from clause 4 and the results of risk assessment and risk treatment, and be monitored, communicated, updated as necessary and available as documented information.

There is a second half that is frequently overlooked. For each objective, it has to be planned what will be done, what resources are required, who is responsible, when it is to be completed and how the results will be evaluated. An objective without those five details is a statement of intent.

Objective, metric and measure are not the same thing

LevelQuestionExample
ObjectiveWhat state is to be reached?Critical systems are restorable within the agreed resumption time
MetricHow is that measured?Share of critical systems with a successfully tested restore
MeasureWhat is being done about it?Restore tests per system, remediation of findings, retest

Without that separation, the two typical malformations appear: the objective that is really a measure ("introduce a SIEM") and the objective that is really a metric with no target state ("number of incidents").

Where objectives should come from

Usable objectives have a discernible origin. Four sources carry: risk treatment, because the material risks set the priorities; the requirements of interested parties, such as contractually committed resumption times; findings from internal audits, incidents and exercises; and strategic initiatives with a security dimension, such as a cloud migration.

Objectives that cannot be traced to any of those four are usually inherited from a template. They survive the first year, but not the second management review.

Measurable where practicable

The qualifier is deliberate. Not every sensible objective can be reduced to a number; a maturity statement or the outcome of an exercise are legitimate measures. What the standard does not permit is an objective whose achievement cannot be established at all. Where a number is chosen, three details belong with it: a baseline, a target and an as-at date. Without the baseline, there is no way at year end to decide whether anything was achieved.

One note on how high to set a target: target values are organisation-specific. Targets derived from someone else's industry figures regularly lead to either the objective or the measurement being adjusted until it fits.

Cascading to functions

The standard requires objectives at the relevant functions and levels. That means a manageable number of objectives at the level of the management system, with contributions derived from them in the areas that can actually contribute: IT operations, engineering, HR, procurement. A cascade that assigns every area the same objective creates effort without any steering effect.

Communicating is not publishing

The standard requires objectives to be communicated. What is meant is not filing them on the intranet, but that the people expected to contribute know what their contribution is. The audit test is simple: an owner in IT operations is asked which objective concerns their area and how its achievement is measured. If no answer comes, a well-maintained objectives document will not help.

What works is anchoring objectives where steering already happens: in departmental objectives, in project planning, and in the regular reporting line to management.

Typical audit findings

  • Objectives unchanged since initial certification, although they were achieved or have become moot.
  • Objectives with no implementation plan: no resources, no owners, no date, nothing about evaluation.
  • No link to risk treatment, so that the material risks do not appear among the objectives at all.
  • Objectives communicated nowhere, so that the people involved cannot name them in an audit.
  • Achievement is reported but not evaluated; the management review contains no decision about what happens next.
Browse all entriesBack to top

Frequently asked questions

See compliance run on your real assets

Rizzqo turns framework requirements into owned tasks on the assets you already have, and prices the risk in real money.

Made in GermanyEU-hostedMulti-framework