What ISO 27001 information security objectives and metrics require before certification
The organization owns its information security objectives and its metrics. Clause 6.2 of ISO/IEC 27001:2022 requires the organization to set measurable information security objectives that are consistent with the policy, and to plan how each objective will be achieved. Clause 9.1 requires the organization to monitor and measure the ISMS and its controls, then analyze and evaluate the results. Before a certification audit, an assessor expects to see both halves working: objectives on record, and measurement results that show whether those objectives are being met. How much work this takes depends on the scope of the ISMS, the systems inside it, and how mature the organization's existing measurement already is. A company that already tracks patching, access reviews and incident response times will start from a different place than one that has a policy but no operating data.
The first decision is which objectives to set. Each objective needs a defined owner, a target, a measurement method, a frequency and a due date, and it should trace back to the risk treatment plan under clause 6.1.3 and to the information security policy. Next, decide what to measure for each objective: the metric, the data source, who collects it and how results are reviewed. Confirm with your certification body how it expects clause 9.1 to be evidenced for your scope, since audit practice varies. The ISO/IEC 27004 guidance on performance measurement is the natural reference for designing these metrics, and an updated edition is in progress, so confirm which version your auditor will reference at the time of your audit.
Before certification, the ISMS must have run its performance evaluation activities: monitoring and measurement under clause 9.1, internal audit under clause 9.2 and management review under clause 9.3. Corrective action under clause 10.2 closes the loop when results fall short. Auditors typically sample measurement records across several months, so a metric that was defined but never collected will be found. Ask your implementation partner or internal team to run at least one full measurement cycle, record the results and show the corrective actions taken. Independent certification bodies issue the certificate; no consultant or tool can do that for you.
What to monitor and measure under clause 9.1
Clause 9.1 asks the organization to decide what it monitors and measures, how, when and who analyzes the results, and whether the results are valid. The categories below are common starting points, not a mandatory list. Each measure should trace back to an information security objective set under clause 6.2.
Control effectiveness measures
Pick measures that show whether the controls selected in the Statement of Applicability operate as intended, such as the share of privileged accounts reviewed on schedule or the percentage of endpoints with approved configurations. For each measure, record the data source, the owner, the frequency and the threshold that triggers analysis. Ask whether the measure proves operation over time, not just that a control exists on paper.
Risk treatment progress
Track how far each risk treatment plan from clause 6.1.3 has advanced, including overdue actions, accepted residual risks and risks whose owners have changed. Measures here show whether the risk picture is improving or whether treatment is stalling. Confirm that each treatment action has a named owner, a due date and a link back to the risk register entry it addresses.
Incident and nonconformity trends
Count security incidents and open nonconformities by category, severity and age, and review the trend rather than single events. Trends reveal recurring root causes that point to weak controls. Check that corrective actions taken under clause 10.2 are measured for effectiveness, so a closed nonconformity is not treated as proof that the problem is gone.
Awareness and training completion
Measure completion of security awareness activities and role-based training, along with the results of phishing exercises or knowledge checks where the organization runs them. Relate completion to people in roles that handle sensitive systems or data. Confirm the measure shows competence and not just attendance, since completion rates alone rarely demonstrate that people act correctly.
Supplier review status
Monitor whether suppliers with access to information or systems have been assessed, whether their contracts include the required security terms, and whether their reviews are current. Track findings from supplier assessments and whether they were resolved. Ask which suppliers are in scope, since an incomplete supplier list leaves the measure looking healthy while gaps remain.
Internal and external audit results
Record the results of internal audits under clause 9.2 and any external reviews, including the number of findings by clause and whether each finding has a corrective action. Audit results show whether the ISMS itself is working, not only whether individual controls are. Make sure the audit programme covers the measures chosen, so the results feed back into the decision about what to measure next.
How ISO/IEC 27004 guides metrics and what its revision changes
ISO/IEC 27004:2016 is the guidance standard that helps an organization design how it measures information security performance and ISMS effectivection in support of clause 9.1 of ISO/IEC 27001. Clause 9.1 requires you to decide what to monitor and measure, how, when and by whom, and to analyze and evaluate the results. ISO/IEC 27004 explains how to build that measurement design: selecting measures, defining how each one is collected and calculated, setting the points at which results are analyzed, and deciding how the conclusions feed corrective action and management review. The 2016 edition is the one most organizations currently reference, and ISO marks it as due for revision. Use it as a method reference when you define the metrics that trace back to your clause 6.2 objectives, not as a list you must adopt word for word.
The revision is ISO/IEC DIS 27004, edition 3, which is 66 pages long. It reached stage 40.60, close of voting, on 16 September 2026 and is intended to replace the 2016 edition. A draft that has closed voting is not the same as a published standard, so confirm the final publication status, date and content directly with ISO before you fix a measurement design around it. Ask the standard's committee page whether the published version has replaced ISO/IEC 27004:2016, and ask your certification body which edition it will use when it reviews your metrics. Until that is settled, document which edition your measurement design follows so the reference is traceable in your records.
Two points matter for planning. First, ISO/IEC 27004 is guidance. No auditor certifies you against it, and a certification audit tests whether your metrics are defined, measured, analyzed and acted on in line with clause 9.1 and your own objectives. Second, the edition you choose affects the rework you may face later. Build metric definitions with an owner, a data source, a calculation method and a review frequency so that they can be mapped to either edition without being rebuilt. An implementation partner can help structure these definitions, but the organization must own the choice of measures and the decisions taken from them.
How NIST CSF 2.0 references clause 9.1
GV.OV-01 sits in the Govern function under oversight and asks whether cybersecurity risk management strategy outcomes are reviewed to inform adjustments. NIST's Reference Tool export lists ISO/IEC 27001:2022 clause 9.1 as an informative reference for this outcome, along with Annex A controls 5.1, 5.5, 5.6, 5.19 and 5.24. These are NIST's mappings, not a DeployOpen or certification-body mapping, and an accredited certification body will judge conformity on its own terms.
- Clause 9.1 link: the monitoring and measurement results that show whether the ISMS is achieving its objectives are the natural input for reviewing the risk management strategy.
- Control 5.1: the policies approved by management give the strategy its written form, so the review has a document to test against.
- Controls 5.5 and 5.6: contact with authorities and special interest groups can feed external signals into the same review.
- Controls 5.19 and 5.24: supplier security and incident management planning supply performance data that management reviews.
Confirm these references against the Reference Tool export before you cite them in a customer response or an assessment pack.
GV.OV-03 asks whether cybersecurity risk management performance is evaluated and reviewed for adjustments. NIST's Reference Tool export maps ISO/IEC 27001:2022 clause 9.1 to this outcome, together with Annex A controls 5.1, 5.19, 5.20, 8.30, 8.32 and 8.34. This is the closest NIST outcome to the performance evaluation itself, so it is the one most teams will reuse first.
- Clause 9.1 link: evaluation of performance is the activity that clause 9.1 describes for the ISMS as a whole.
- Controls 5.19 and 5.20: supplier security requirements and agreements provide measurable indicators for third-party performance.
- Control 8.30: outsourced development measured against agreed security requirements gives a second performance series.
- Controls 8.32 and 8.34: change management and protection of audit information define how changes are recorded and how audit evidence stays intact.
Ask your certification body how it wants performance evaluation records presented, because the same data may be sampled under both frameworks.
DE.CM-03 sits in the Detect function under continuous monitoring and covers monitoring of personnel activity, technology and external service provider activity for potential cybersecurity events. NIST's Reference Tool export maps ISO/IEC 27001:2022 clause 9.1 to this outcome, with Annex A controls 7.4 and 8.16. The mapping is narrower than GV.OV-03 and focuses on what is observed, not on how the ISMS is judged.
- Clause 9.1 link: monitoring activities defined by the organization for the ISMS are the records clause 9.1 expects to exist.
- Control 7.4: physical security monitoring provides records for monitoring of personnel and premises.
- Control 8.16: monitoring activities cover networks, systems and applications, so logs and alert records serve both the Detect outcome and the clause 9.1 record set.
- Practical reuse: a single monitoring plan that names what is watched, how often and who reviews it can answer both frameworks.
Confirm that the monitoring scope in your plan includes external service provider activity, since the NIST reference points to that element directly.
ID.IM-03 sits in the Identify function under improvement and asks whether improvements are identified from execution of operational processes, activities, controls and projects. NIST's Reference Tool export maps ISO/IEC 27001:2022 clause 9.1 to this outcome, together with Annex A control 5.27. Of the four outcomes, this one has the single Annex A reference, so the reuse story is mostly about clause 9.1 records feeding lessons learned.
- Clause 9.1 link: results from monitoring and measurement show which processes are underperforming and which need change.
- Control 5.27: learning from information security incidents is the Annex A source for turning incident outcomes into improvements.
- Feeding the register: improvement actions recorded from clause 9.1 can be tracked to closure in the same register used for nonconformities under clause 10.2.
- Limit of the mapping: the Reference Tool links improvement to clause 9.1 and one control, so do not assume it covers every improvement source.
Check that improvement actions in both frameworks point to the same owner, due date and closure evidence.
How the performance evaluation cycle must run before a certification audit
The sequence runs from setting objectives under clause 6.2 to correcting gaps under clause 10.2, and each step leaves a record that an auditor can test before certification.
Set information security objectives under clause 6.2
Top management and the ISMS owner define information security objectives that are consistent with the policy and the risk treatment plan, state what will be achieved, who is responsible, what resources are needed, when it will be completed and how results will be evaluated. The output is a documented objectives register, approved by the people accountable for it, with each objective traceable to a risk or to a requirement from the scope. Confirm with your certification body how it expects objectives to be shown in documented form.
Define metrics and collect monitoring data
For each objective, the organization chooses measures under clause 9.1, decides what to monitor, when to measure, who measures and who analyzes the results. Data then comes from operating tools such as logs, ticketing systems, vulnerability scanners and access reviews. The output is a metrics definition sheet and a dated set of measurement results that show the method used, so an auditor can repeat the calculation and check it.
Analyze and evaluate results against objectives
The ISMS owner reviews the measured data, identifies trends and deviations, and decides whether each objective is met, partly met or missed. ISO/IEC 27004 gives guidance on this analysis, and its revision is in progress, so confirm which edition your certification body references. The output is a dated evaluation record for each objective, with conclusions and any follow-up actions that feed later steps.
Run the internal audit programme under clause 9.2
The organization plans an internal audit programme that covers the ISMS, with auditors who are independent of the work they examine. Each audit checks conformance to the organization's own requirements and to ISO/IEC 27001, and whether the ISMS is effectively implemented and maintained. The output is an audit plan, audit reports with findings, and records showing that the programme was carried out before the certification audit.
Hold management review under clause 9.3
Top management reviews the ISMS at planned intervals. The meeting considers the inputs the standard lists, including the status of actions from earlier reviews, changes in issues and risks, the results of monitoring and internal audit, and feedback from interested parties. The output is minuted decisions and actions on improvement, changes to the ISMS and resource needs. Auditors read the minutes closely, so they should show real discussion of the objective results rather than a signed attendance list.
Open nonconformities and corrective action under clause 10.2
When monitoring, internal audit or management review finds a nonconformity, the organization reacts to control it, assesses whether the cause must be removed, implements the action, reviews its effectiveness and updates the ISMS where needed. Each nonconformity gets a record with the cause and the corrective action taken. European Accreditation's guidance on corrections and corrective actions explains how certification bodies distinguish these. The output is a corrective action log showing that open items were closed or have a credible plan.
Confirm the run period before the certification audit
Before booking the certification audit, the organization checks that every step above has run and left records. The ISMS must have completed its performance evaluation activities before the audit, so a stage 2 audit will look for evidence that they happened in practice. Ask the certification body how long the cycle must have run before stage 1 and stage 2, and what records it expects to see. The output is a readiness check confirming each step has evidence, which the organization can show the auditor.
What auditors check in the objectives and metrics evidence
Auditors test whether objectives and metrics form a closed loop: each objective traces back to policy and risk treatment, each metric has a defined method, and results lead to visible decisions. The six checks below follow that loop, and each one can be verified internally before a certification body arrives.
Objectives traceable to policy and risk treatment
Auditors start by asking why each objective exists. Clause 6.2 requires objectives that are consistent with the information security policy and that take account of the results of the risk assessment and risk treatment plan under clause 6.1. Before the audit, pick five objectives at random and trace each one back to a policy statement and a risk treatment decision. If a link is missing, the objective is either decorative or the risk treatment plan is incomplete.
Defined measurement method for each metric
Each metric needs a written method: what is measured, the data source, the calculation, the frequency, the owner and the target. Clause 9.1 requires the organization to determine what needs monitoring and measurement and the methods to use. Check that every metric on the dashboard has a one-page definition that a new analyst could follow. A metric with no stated method cannot be reproduced, and auditors will treat its results as unverified.
Dated measurement results retained
Auditors expect a record of what was measured, when, and by whom. Results should be timestamped and kept in a controlled location, such as the ISMS documented information repository, so they cannot be edited after the fact. Verify that the last several reporting periods exist for each metric, that no gaps have been filled retrospectively, and that the raw data can be traced back to the source system where the reading was taken.
Trend analysis and decisions taken
Clause 9.1 requires the organization to analyze and evaluate the results, not just collect them. Auditors look for commentary that explains a trend, such as a metric drifting toward its target, and for a decision that followed from it. Before the audit, review each metric's history and write down what the trend showed and what action was agreed. A chart without an interpretation is a common reason auditors raise questions.
Management review of results
Clause 9.3 requires top management to review the ISMS, and objective performance is a standard input. Check the management review minutes for evidence that the objectives and metric results were presented, discussed and that the outcome was recorded. Confirm that the reviewers are the people with authority over the objectives, not only the security team preparing the slides.
Corrective actions opened from gaps
When an objective is missed or a metric falls outside its target, clause 10.2 requires a nonconformity to be handled and corrective action to be taken. Auditors check that misses produced a logged action with a root cause, an owner and a closure check. Review the register for any metric that stayed red for several periods without an action. Those unaddressed gaps are the most likely source of findings in a certification audit.
Who owns the objectives, the metrics and the audit evidence
This table compares what the organization, an implementation partner such as DeployOpen, and the independent certification body each own for ISO 27001 objectives and metrics. Read each row as a split of responsibility: the organization makes the decisions and holds the results, the partner builds the systems that record them, and the certification body tests them and alone issues any certificate.
| Area | The organization | Implementation partner (DeployOpen) | Certification body |
|---|---|---|---|
| Setting objectives (6.2) | Sets the information security objectives, approves them and assigns owners and target dates | Helps draft objective wording and drafts the planning record, but does not set or approve objectives | Checks that objectives exist, are consistent with the policy and are reviewed; does not write them |
| Choosing metrics (9.1) | Decides what to measure, why each metric matters and what counts as a satisfactory result | Proposes measurement designs and documents the method behind each metric for the organization to approve | Tests whether the chosen metrics are defined, repeatable and used in decisions |
| Collecting data | Owns the source systems, access rights and data quality; decides what is collected and retained | Builds and hosts collection pipelines, dashboards and logs inside the client's own environment | Samples data and traces it back to source systems during audit visits |
| Analysis and decisions | Reviews results, decides on corrective action and records what was decided and why | Prepares reports and trend views; does not decide whether a result is acceptable | Assesses whether analysis and follow-up actions happened and were effective |
| Audit evidence | Signs off the measurement results, the management review minutes and the corrective action records | Stores exported records, configuration history and dashboard snapshots in self-hosted systems the client controls | Reviews evidence and forms its own opinion; issues the certificate only if the requirements are met |
| Final assurance | Accountable for the ISMS and its results at all times | Does not issue reports, attestations or certificates and does not guarantee an audit outcome | Sole party that audits and issues a certificate, subject to its accreditation |
How self-hosted open-source tooling can produce metric evidence
Clause 9.1 asks the organization to show that it monitors and measures the metrics it chose under clause 6.2, and that it analyzes and evaluates the results. The evidence is the dated record of each measurement and the reasoning applied to it, so the tooling question is really a records question: can the systems that already hold the data produce it consistently, with timestamps the organization can defend. Self-hosted monitoring, logging and ticketing platforms running inside your own cloud accounts, data centers or air-gapped network can do this without sending security data to a third party. Monitoring systems can poll or receive data on a schedule, log platforms can retain raw events, and ticketing systems can record remediation dates and owners. Each of these is a source an assessor may sample.
The organization should decide each metric first and then select the tool that feeds it, never the reverse. For each objective, write down the data source, the collection frequency, the owner who reviews the output, and the retention period the auditor will need to see. Then confirm in your own environment whether each candidate tool can export results with reliable timestamps, restrict who can edit historical values, and keep a change history of dashboards, alert thresholds and queries. Ask your implementation partner to document these settings, and ask your auditor which formats they accept. Tool features change between releases, so verify each capability against the version you deploy rather than relying on marketing descriptions or secondhand summaries.
Records that look authoritative but can be silently rewritten will weaken the evidence. Keep exports of metric results in a controlled location, protect the monitoring and ticketing databases with access control and backups, and record who changed a threshold or a definition and why. When a metric is revised after the management review or an internal audit, the earlier value and the revision should both remain visible. An illustrative example: a team that stores weekly patch-latency figures as spreadsheet cells overwritten each week will struggle to show trend data, while a team whose ticketing system holds closed remediation tickets with open and close dates can answer the same question from the source records.
Questions buyers ask about ISO 27001 objectives and metrics
Does a consultant have to set our ISO 27001 information security objectives?
No. Clause 6.2 requires the organization to set its information security objectives, and top management must be accountable for them. A consultant can draft objectives, suggest structure and challenge weak wording, but the objectives must reflect your business, your risk assessment and your priorities, and your leadership must approve them. Auditors will ask who agreed the objectives, when, and how they link to the risk treatment plan. If an outside party wrote them and no one inside understands or owns them, that gap is usually visible in management review minutes. Confirm with your certification body how it expects the approval record to look.
How many information security metrics are enough for ISO 27001?
The standard does not set a number. What matters is that each objective has at least one measure that shows whether it is being met, that the measures are defined in advance, and that the organization can explain why it chose them. A small ISMS with a few objectives may need only a handful of metrics, while a larger, multi-site organization will need more, grouped by objective. Avoid adding metrics that nobody reviews or acts on, because auditors look for evidence that results were analyzed and used. Ask your certification body and consultant to show you how each metric traces back to an objective and an owner.
Can we set objectives and run measurement in-house without a partner?
Often yes, if you have someone who understands the ISMS, can access the data sources, and has time to review results every reporting period. The work includes defining objectives, choosing measures, collecting data from tools such as ticketing, logging and vulnerability systems, recording results, and reviewing them in management review under clause 9.3. Outside help is most useful for a readiness review, for testing whether your metrics are meaningful, or for building the data pipelines and dashboards that produce evidence without manual effort. Your organization remains responsible for its objectives and results in every case.
How long must measurement run before the ISO 27001 certification audit?
The standard does not give a fixed period, and the answer depends on whether the performance evaluation has actually run and produced records. Auditors generally expect to see monitoring results, internal audit and management review outputs from the ISMS in operation, not just a plan. The certification body decides how much history it needs for your scope and size, and it sets the timing of stage 1 and stage 2 audits. Ask the certification body in writing what evidence period it expects before you book the stage 2 audit, and plan your measurement cycle around that answer rather than a guess from a consultant.
What does the status of ISO/IEC 27004 mean for our current measurement work?
ISO/IEC 27004:2016 is the current guidance on monitoring, measurement, analysis and evaluation for clause 9.1, and it is marked for revision. A revision, ISO/IEC DIS 27004, is at the close of voting stage, and it will replace the 2016 edition once published. Building your measurement approach on the current edition is still sensible, because the clause 9.1 requirement itself does not change with the guidance. Keep your metric definitions, owners and review records documented so that you can adjust to the revised guidance without rebuilding the whole ISMS. Check the ISO committee page for the published status before your audit.
What drives the effort and cost of an implementation partner's work on objectives and metrics?
Cost depends on scope and on how much of the measurement system already exists. The main drivers are the number of objectives and metrics, how many systems must feed data into them, whether data is clean and consistently recorded, the number of sites and business units, and how many management review cycles the partner must support. One-time work includes defining objectives, designing metrics, setting up data collection and producing the first set of records. Recurring work includes reviewing results, updating metrics after changes in risk or scope, and preparing for audits. DeployOpen does not publish prices. Ask any partner for a written scope that lists the objectives, data sources, deliverables and review cycles.
How DeployOpen prepares objectives, metrics and evidence
DeployOpen works as a fixed-scope implementation partner on the measurement side of ISO 27001. Each card below marks a step where the organization decides something, DeployOpen prepares a system or record, and an independent auditor or certification body later judges the result. DeployOpen does not issue audit reports, attestations or certificates.
Scope the measurement work in writing
Before any build, DeployOpen and the client agree in writing which objectives, metrics and data sources fall inside the work, who owns each measurement, and how often each one is reported. The client keeps ownership of the objectives under clause 6.2 and the evaluation criteria under clause 9.1. A useful check is whether every objective in the scope document has a named owner, a target and a defined data source.
Implement self-hosted measurement tooling
DeployOpen deploys and configures the monitoring, logging and reporting tools that produce metric data inside the client's own cloud accounts, data centers or air-gapped networks. The aim is that each metric is pulled from a system of record rather than typed into a spreadsheet. Ask for the data flow diagram and confirm which systems hold the raw measurements.
Harden access to metric data
Metric dashboards and security records often expose sensitive detail about incidents, vulnerabilities and gaps. DeployOpen applies role-based access, separates administrative rights from reporting rights and enables audit logging on the measurement platform. Confirm with your own security team which roles may change target values, since those changes are themselves evidence auditors review.
Document metric definitions and records
For each metric, DeployOpen writes a definition covering purpose, formula, data source, frequency, responsible owner and the decision it informs. These definitions and the resulting records are kept as documented information under clause 7.5. Confirm that the client approves each definition and that the version history is retained for the period the auditor will sample.
Connect metrics to corrective action
A metric that misses its target should lead to a documented analysis and, where needed, a nonconformity and corrective action under clause 10.2. DeployOpen configures ticket workflows so that a breached threshold opens a tracked record with an owner and a due date. Check that the management review under clause 9.3 receives these results as inputs.
Hand over evidence for independent review
DeployOpen packages the configuration records, metric reports, access logs and review minutes into an evidence set the client can review before the certification audit. The client decides what to submit and what to explain. The independent auditor or certification body performs the assessment and issues any report or certificate, and DeployOpen does not take that role.
