Look at the objectives register of an organisation that has just finished building its ISMS and you will often find entries like "zero security incidents," "raise security awareness," "strengthen the company's overall security posture." They read as restatements of the policy — and a year later nobody can determine whether any of them was achieved.
Information security objectives are the one place in an ISMS where the organisation declares what it intends to make better this year. When that place is filled with slogans, Clause 9 has nothing to measure, the management review ends with "no particular issues," and Clause 10 improvement never turns. The quality of the objectives determines whether the ISMS is actually running.
This article turns objective and KPI design into practice: what "measurable" really demands, why "zero incidents" cannot work, how to fix deadline and evaluation method together, and how to cascade to departments. For where the requirement sits, see Clause 6: Planning; for the standard as a whole, What Is an ISMS (ISO/IEC 27001)?.
Disclaimer: This article is general information. The authoritative texts are ISO/IEC 27001 (JIS Q 27001) itself and the publications of the accreditation and certification bodies. Base actual decisions on those.
Why This Trips People Up
Reading "measurable" as "contains a number"
The standard asks that objectives be measurable where practicable. That does not mean a figure appears in the text. It means anyone following the same method reaches the same value, and achievement or shortfall can be determined.
Adding "twice a year" to "strengthen training" does not make it measurable if nobody has defined what counts as one session, who the audience is, or how to treat people who did not attend. Conversely, "every person in scope completes annual training by year end" is decidable without any percentage, provided a roster and completion records exist. Measurability comes from the data source, not from the wording of the metric.
"Zero incidents" does not function as an objective
It is a very common entry, and it fails on four counts.
- The result depends on factors outside your control — supply-chain attacks, unknown vulnerabilities, a supplier's mistake. Effort and outcome are decoupled, so neither achievement nor shortfall tells you whether the organisation behaved well
- It creates an incentive to suppress reporting. Where zero is rewarded, minor events quietly stop being raised. Incident management is precisely the domain where what never gets reported is the biggest risk
- It dies the moment it is missed. One event in month three leaves nine months carrying an unachievable objective
- It does not decompose into action. Nothing about what to do tomorrow follows from it
If incidents are the concern, measure a process the organisation controls: time from detection to first response; share of reported events carried through to a completed preventive action; share of severity calls made according to procedure. Each moves with your own behaviour, and each has an unambiguous good direction.
Objectives disconnected from the risk assessment
The standard asks you to take account of applicable requirements and the results of risk assessment and treatment when setting objectives. In practice, objectives often get drafted from the corporate services department's annual plan while the risk treatment plan lives in a separate file. Asked at audit "why this objective," you then have no answer. The cleanest position is that objectives are the parts of the risk treatment plan you have chosen to emphasise this year.
Objectives that differ from the Clause 9 measurement plan
Metrics appear in the objectives register, and an entirely different list appears in the monitoring and measurement plan. The metric attached to an objective is the thing Clause 9 monitors. The measurement table in Clause 9: Performance Evaluation and the metric column of the objectives register must point at the same things.
What You Have to Decide
The standard requires the plan to state what will be done, what resources are needed, who is responsible, when it completes, and how results will be evaluated. In practice, add objective, metric, target, data source and measurement frequency, and manage it all in one table.
| Column | What goes in it | Test |
|---|---|---|
| Objective | The state to reach this year | Is it just the policy restated? |
| Basis | Risk ID, or a legal/contractual requirement | Can you point at the risk register? |
| Metric | The quantity that expresses progress | Would two people get the same value? |
| Data source | Which system or record supplies the value | Does it exist? If manual, who does it? |
| Baseline | Value at the time of setting | Was the target set without measuring? |
| Target | Value wanted at period end | Is the gap from baseline meaningful? |
| Frequency | Monthly / quarterly / annual | Is it only measurable at year end? |
| Owner | Who drives it | Does it match actual authority? |
| Resources | Budget, people, tooling | Approved? |
| Deadline | The date | More specific than "this fiscal year"? |
| Evaluation method | Who decides, when, how | Is it on the management review agenda? |
Three to five objectives is the workable range. A table of a dozen cannot be reviewed mid-period, so results get backfilled at year end. For smaller organisations this matters more, not less — as covered in ISMS in a Small Organisation, cutting to what you can actually operate is the honest design.
Set targets after measuring the baseline. Writing "95%" without knowing the current figure usually means either you were already at 98% (no improvement implied) or you were at 40% (unreachable). In the first year, making measurement itself the objective is legitimate: "measure mean days to remediate critical vulnerabilities monthly and establish a baseline" is real preparation for setting a target in year two.
Some metrics deserve a 100% target and some do not. Where the population is fixed and completion is entirely within your control — training completion, annual supplier reviews — 100% is right. Where external factors intrude, such as remediation or detection rates, a 100% target normalises shortfall and hollows out the register.
How to Do It
Step 1: Draw candidates from the risk treatment plan
From the treatments scheduled this year, take those that are cross-cutting and trackable. A one-off capital item ("install a door access system") is managed perfectly well inside the treatment plan and need not become an objective. Objectives suit things that raise the standard of ongoing operation.
Step 2: Cut to three to five corporate objectives
Choose the ones top management can genuinely say "this is what we improve this year" about. Weigh risk magnitude, legal and contractual requirements, and last year's nonconformities and observations. Areas that show up in Common Nonconformities make good objectives because the record then doubles as evidence of improvement.
Step 3: Fix the metric and its data source together
Never decide a metric without deciding, in the same breath, where the number comes from. If it turns out there is no way to obtain it, either change the metric or make building the collection mechanism part of the objective. A metric with no source produces an estimate at year end and no evidence at audit.
Step 4: Measure the baseline, then set the target
A single month of real data is enough. If even that is impractical, make the first-year objective "establish measurement and record the baseline."
Step 5: Cascade to departments
The standard asks for objectives at relevant functions and levels. Copying the corporate objective into every department's row produces entries the department cannot control. Correct cascading carves out the part each department owns.
| Corporate objective | Engineering | Sales | Corporate services |
|---|---|---|---|
| Remediate critical vulnerabilities within 14 days | Run dependency scans weekly; clear "high" within 14 days | — | Single intake point for vulnerability notices; relay to engineering within 24h |
| All workers complete annual training | All engineers complete secure coding training | All staff complete customer-data handling training | Compile completion monthly; chase non-completers |
| Complete annual supplier reviews | Verify technical requirements for development suppliers | — | Maintain the in-scope supplier list; run the reviews |
| Refresh the asset register quarterly | Inventory owned systems and repositories | Inventory where customer data is stored | Consolidate the register; record the delta |
Having the nerve to write "—" matters. A token objective handed to an unrelated department produces a meaningless progress report.
Step 6: Set the review cadence
Update results quarterly and intervene mid-period when a shortfall appears. Reviewing once a year only records "missed" at the end; no correction cycle turns. Results feed the management review, so settle the cadence alongside the agenda design in Running a Management Review.
Step 7: Decide in advance how a shortfall is handled
A missed target is not a failure; it is material for analysis. Record whether the cause was an unrealistic target, resources that never materialised, or a changed premise, and carry that into next year. Once shortfalls start getting hidden, the register itself loses credibility. Whether a miss should be raised as a nonconformity follows the criteria in Clause 10: Improvement.
Where It Goes Wrong
The objective is the policy restated
"Protect information assets appropriately" is policy language, not this year's objective. The policy is a multi-year statement of intent; the objective is this year's destination. The division of labour is set out in Writing an Information Security Policy.
A metric with no way to obtain the number
"Suspicious email reporting rate" fails because the denominator — how many suspicious emails actually arrived — is unknowable. Replace it with "reporting rate for simulated phishing," where the denominator is fixed. See Phishing Simulation Exercises.
Every target is 100%
Completion rate 100%, review rate 100%, inspection rate 100%. It looks airtight, but everything is measured as done/not done, so no quality improvement can register. Include at least one continuous metric — time, or counts — to leave room for improvement to show.
The objective quietly changes mid-year
A metric heading for a shortfall gets swapped out, target and all, in the final month. Discovered at audit it reads badly, and it destroys the improvement opportunity. If a change is warranted, record the reason, the approver and the date, then revise. Clause 6 also requires ISMS changes to be planned.
Department objectives are copies of the corporate one
Identical wording in every department's row is evidence that no cascading happened. Auditors ask department heads "what is your department's objective," so the structure surfaces immediately.
Results entered in one batch at year end
A quarterly metric with all four quarters dated 31 March means measurement did not really happen, and can be treated as a nonconformity against the monitoring requirement. Keeping the measurement date separate from the recording date demonstrates the reality.
Objectives never reach the executives
Objectives are approved by top management, which should track progress. An objective known only to the ISMS secretariat gets no resources and is missed. From the Clause 5: Leadership angle too, keep the approval record and reporting route explicit.
Healthcare Examples
A healthcare SaaS provider
The highest-value objective here is control over access to production patient data. Engineers do inspect live data during incident investigation, so metrics such as "share of production data accesses preceded by request and approval" and "share of accesses whose logs were subsequently reviewed" are fully within your control and answer exactly what hospital customers care about.
The second is review coverage for changes touching tenant separation — the share of changes to separation logic approved by a designated reviewer. That is a direct metric for the risks discussed in Multi-Tenant Risk in Healthcare SaaS.
A PHR operator
Because data is held under the individual's consent, completeness of consent records becomes the objective: share of grants, changes and withdrawals recorded; elapsed time from withdrawal to cessation of use. These overlap the personal information law, letting legal compliance and the ISMS objective share one register. See ISMS for PHR Operators.
A SaMD developer
Security and product safety run in separate streams, so a metric at the junction is valuable: "share of security vulnerabilities for which a safety impact assessment was performed" sits exactly between the ISMS and product risk management. See SaMD, ISMS and ISO 13485.
A company doing contract development or maintenance for hospitals
The customer is the party accountable under the three-ministry guidelines, so quality of response as a supplier is the objective: days to answer a hospital's security questionnaire; share of remote maintenance sessions with both prior approval and a work record. Both bear directly on contractual demarcation. See The Three-Ministry Guidelines and Integrating ISMS Documents with the Three-Ministry Guidelines.
Common to all of them: take the items hospital customers ask you to explain and make them your metrics. ISMS operation and your sales-facing evidence then become one artefact. For what procurement actually asks, see When ISMS Becomes a Contract Condition.
Conclusion
- "Measurable" means a data source exists and achievement can be determined — not that a number appears
- Do not make "zero incidents" an objective. It depends on uncontrollable factors, suppresses reporting, and dies when missed. Replace it with process metrics such as detection-to-response time or preventive-action completion rate
- Draw objectives from the risk treatment plan. Drafted from an administrative annual plan, they cannot be justified at audit
- The register needs metric, data source, baseline, target, frequency, owner, resources, deadline and evaluation method — deadline and evaluation method decided together
- Cascade by carving out, not copying; write "—" for departments with no part to play
- Keep it to three to five objectives, updated quarterly. Analyse shortfalls openly and carry the lesson into next year
Pottech supports ISMS build and operation with a focus on healthcare. Objective and KPI design is an area where, without knowing both your own risks and what hospital customers ask about, you end up with metrics that get measured and never used. See ISMS Certification Support or contact us.
References and Sources
- Information Management System Accreditation Center (ISMS-AC)
- ISO/IEC 27001 Information security management systems | ISO
- Japanese Industrial Standards Committee (JISC)
- Personal Information Protection Commission, Japan
- Guidelines for the Safe Management of Medical Information Systems | MHLW
Note: interpretation of requirements and the handling of accreditation and certification are governed by the standard itself and by the publications of the accreditation and certification bodies, and may change with revisions.