In the first part of this Chapter 6 series, we looked at clause 6.1 and the way ISO/IEC 27001 requires an organization to address risks and opportunities through structured planning. That planning begins with the risks and opportunities that can affect the Information Security Management System, but it does not stop there. The organization must also define and apply an information security risk assessment process and determine how information security risks will be treated. In practical terms, clause 6.1 helps the organization understand what could go wrong, what needs to be protected, which risks require treatment, and which actions are needed to bring those risks within acceptable limits. Clause 6.2 builds on that foundation by asking the organization to express the direction created by risk-based planning in a more concrete manner. Risk assessment and risk treatment tell the organization what matters, what needs attention, and what must be addressed, but they do not, by themselves, define what success should look like. An organization can identify serious risks, assign owners, select controls, and still fall short if it never translates those decisions into clear objectives. This is the gap that clause 6.2 closes. It turns risk-based planning into something operational, measurable, and manageable over time, making this part of Chapter 6 the point where planning becomes more visible in day-to-day management.
This follows naturally from the logic of Chapter 6. The previous section required the organization to determine risks and opportunities, perform a risk assessment, and define means of treating those risks. Now the standard requires the organization to establish information security objectives at relevant functions and levels, ensure that those objectives meet specific criteria, retain documented information on them, and determine how they will be achieved. These objectives must be consistent with the information security policy, measurable if practicable, take into account applicable information security requirements and the results from risk assessment and risk treatment, be monitored, communicated, updated as appropriate, and be available as documented information. The organization must also determine what will be done, what resources are required, who will be responsible, when it will be completed, and how the results will be evaluated.
That may sound simple at first, but in practice clause 6.2 is often where many Information Security Management Systems either become more effective or begin to drift into vagueness. Many organizations are comfortable talking about risk in general terms, but less comfortable turning that discussion into specific objectives that can actually be followed, monitored, and reviewed. It is easier to say that security should improve than to define how, where, by whom, and by what standard of success. This requirement prevents that kind of ambiguity by forcing the organization to move beyond general aspiration and into managed intent.
Why objectives matter after risk decisions
One of the easiest mistakes in implementing ISO 27001 is to assume that once risks have been assessed and treatment plans have been created, the planning work is largely done. That assumption is understandable, especially in organizations where the risk assessment and risk treatment plan require significant effort. After all, risks have been identified, owners have been assigned, controls have been selected, and actions have been planned. Yet this does not fully answer the management question behind the work. Risk treatment may identify necessary controls, but objectives explain what the organization is trying to accomplish through those efforts. Without objectives, the organization can become absorbed in activity without a clear sense of destination. Controls may be implemented, training may be delivered, systems may be configured, and audits may be scheduled, while the broader question remains unanswered: what exactly is the organization aiming to achieve through these efforts?
ISO 27000 is useful here because it defines an objective as a result to be achieved and notes that, in the context of information security management systems, information security objectives are set by the organization, consistent with the information security policy, to achieve specific results. That definition is brief, but important. An objective is not merely a topic of interest, a vague intention, or a generic statement that security matters. It is a result that the organization has decided it intends to achieve, and that distinction changes the way planning is understood. The focus is no longer only on whether something has been done, but on whether the activity contributes to a defined result.
ISO 27003 helps make the same point from an implementation perspective. It explains that an ISMS emphasizes the importance of establishing information security policy and information security objectives, and places planning among the key management processes within the system. In other words, objectives are not a decorative extra or a formality added to satisfy an auditor. They are part of how the management system functions. They provide a basis for action, measurement, review, and improvement, and they help connect information security work to the organization’s actual priorities.
Consider a familiar example. During risk assessment, an organization may conclude that too many employees have access to critical systems, or that some users have more access than they actually need for their work. The risk treatment plan may then include stronger access control, a clearer process for granting and removing access, and better monitoring of user accounts. Those are sensible actions, but the objective-setting requirement asks the organization to go one step further. What result should these actions achieve? For example, the organization may want to reduce unnecessary access rights, ensure that all critical systems are reviewed every quarter, or make sure that user accounts are removed quickly when employees leave the organization. The controls remain important, but the objective gives those controls a clearer purpose and makes it easier for management to see whether the work is actually producing the intended result.
What clause 6.2 requires
Clause 6.2 begins by requiring the organization to establish information security objectives at relevant functions and levels. That wording is important because it shows that objectives should be placed where they can actually guide the ISMS. They do not need to exist only at the top of the organization as broad strategic statements, but the standard also does not require a separate formal objective for every minor activity. The organization needs to determine where objectives are relevant, taking into account its size, structure, services, risks, and responsibilities. This allows the objective structure to fit the organization while still preventing objectives from becoming so abstract that they cannot be managed in practice.
For some organizations, this may mean a small number of high-level objectives supported by more specific operational targets. For others, particularly larger or more complex organizations, objectives may need to exist across several functions, systems, services, locations, or business areas. The important point is not the number of objectives, but whether they are relevant, useful, and capable of guiding action. A long list of weak objectives is not better than a shorter list of meaningful ones.
The standard then sets out several characteristics these objectives must have.
First, they must be consistent with the information security policy. This creates a necessary connection between leadership direction and operational planning. Clause 5 required top management to establish an information security policy that either includes information security objectives or provides the framework for setting them. Clause 6.2 then carries that requirement into planning by making sure the objectives do not drift away from the policy. For example, if the information security policy says that customer information must be protected, the objectives should show how the organization intends to support that commitment in practice. That could include improving access control for customer databases, completing regular reviews of who can access customer information, reducing unresolved security findings related to customer systems, or improving incident response for events involving customer data. The objective does not need to repeat the policy, but it should clearly support it.
Second, objectives must be measurable, if practicable. This phrase is often discussed and sometimes misunderstood. It does not mean that every objective must be reduced to a perfect mathematical formula, but it also does not allow the organization to avoid measurement simply because measurement is inconvenient. The point is that an objective should be written in a way that allows the organization to determine whether progress is being made and whether the intended result has been achieved. In some cases, this can be done with numbers, deadlines, completion rates, or defined thresholds. In other cases, evaluation may need to include qualitative evidence, such as review results, management decisions, audit findings, or evidence that agreed actions have been completed. The underlying principle is still the same: an objective should not be so vague that no one can tell whether it has been achieved.
Third, objectives must take into account applicable information security requirements and the results from risk assessment and risk treatment. This is one of the most important parts of the requirement because it ties objectives directly to the actual needs of the organization. Objectives are not meant to be generic slogans copied from a template. They should arise from the organization’s context, its applicable requirements, and the findings of its risk-based planning. Where the organization has identified significant risks, contractual expectations, legal obligations, customer commitments, or operational dependencies, its objectives should reflect those realities. This helps ensure that objective setting is not an isolated administrative exercise, but part of the same planning logic that began with risks, opportunities, and treatment decisions.
Fourth, objectives must be monitored, communicated, updated as appropriate, and available as documented information. These requirements keep objectives alive within the management system. An objective that is written once, stored in a document, and then forgotten is not functioning as an objective in any meaningful sense. Monitoring ensures that progress is tracked. Communication ensures that relevant people know what is expected and understand their part in achieving the objective. Updating ensures that objectives remain suitable when risks, requirements, priorities, systems, or organizational circumstances change. Documented information ensures that the objective is defined in a controlled form and can be reviewed, used, and evidenced when needed.
Measurable, if practicable
The requirement that objectives be measurable, if practicable, deserves special attention because it sits at the boundary between formal compliance and effective management. Organizations often respond to this requirement in one of two unhelpful ways. Some write objectives so broadly that no one can meaningfully evaluate them. Others force every objective into a simple number, even when the number does not say much about the real result. Neither approach is very useful. A vague objective may sound professional, but it gives little direction. A poorly chosen metric may look precise, but it can create the impression of control without showing whether information security has actually improved.
A better approach begins by asking what meaningful evidence of achievement would look like. In some cases, measurement can be straightforward. An objective to complete privileged access reviews every quarter for all critical systems can be tracked through review records, open findings, and overdue actions. An objective to improve phishing awareness can be supported by training completion rates, exercise results, and follow-up actions for employees who need additional support. An objective to reduce the number of unsupported systems can be tracked through asset inventories, remediation plans, and progress reports. In these examples, the organization is not merely saying that it wants improvement. It is identifying evidence that can show whether progress is being made.
In other cases, measurement may need to combine quantitative and qualitative evidence. For example, an objective to improve supplier security oversight may involve several indicators, such as completed due diligence reviews, updated contractual requirements, closure of supplier-related findings, and evidence from periodic supplier monitoring. A single number may not tell the whole story, but the combination of evidence can still give management a reasonable basis for evaluation. The point is not to force all objectives into the same metric style. The point is to ensure that the organization can evaluate whether the objective is being achieved in a disciplined and credible way.
ISO 27003 reinforces this broader management view by treating performance assessment, measurement, monitoring, and review as integral parts of the ISMS rather than isolated reporting exercises. Objectives should therefore be written with later evaluation in mind. If the organization cannot explain how, it will determine whether an objective has been achieved, the objective is probably not yet mature enough. A good objective should make later review easier, not leave management guessing about whether the planned result was actually achieved.
Linking objectives to policy, requirements, and risk decisions
Clause 6.2 becomes much easier to apply once the organization understands that objectives should not be invented in isolation. They should not be created simply because a template says objectives are needed, or because an auditor will expect to see them. The standard ties them to the information security policy, applicable information security requirements, and the results of risk assessment and risk treatment. This means the organization should be able to explain why a particular objective exists and the need it is meant to address.
For example, if the risk assessment identifies a significant availability risk affecting a critical business service, an objective might focus on improving the resilience of that service. In practical terms, this could mean reducing recovery times, testing recovery arrangements, improving backup reliability, or making sure that responsibilities during a disruption are clearly assigned. If risk treatment identifies weaknesses in access control, an objective might focus on completing regular access reviews, improving the process for granting, changing, and removing user access, or reducing unnecessary privileged access. If legal or contractual requirements emphasize the protection of customer data, an objective might focus on classifying that data correctly, improving secure handling procedures, or strengthening incident response for events involving customer information.
This linkage matters because it prevents objectives from becoming detached from the organization’s real needs. A list of standard-looking objectives may appear polished, but if it does not reflect the policy, applicable requirements, risk assessment results, or risk treatment decisions, it contributes little to the effectiveness of the Information Security Management System. Clause 6.2 expects more than presentation. It expects alignment between what the organization says is important, what its risks and requirements show is important, and what it is actively trying to achieve.
Planning how objectives will be achieved
The second half of clause 6.2 is sometimes given less attention than the first, but it is equally important. Once the organization has established its information security objectives, it must also determine how those objectives will be achieved. The standard requires the organization to decide what will be done, what resources are required, who will be responsible, when the work will be completed, and how the results will be evaluated. This is where objectives stop being statements of intent and become practical plans.
This structure is highly useful because it pushes the organization to think through implementation rather than merely declaration. It is not enough to say that access control should improve, incidents should be handled more effectively, or suppliers should be reviewed more consistently. Those statements may point in the right direction, but they do not yet explain how the organization will get there. Clause 6.2 requires the organization to connect the objective to action.
What will be done requires a defined course of action. If the objective is to improve log review for critical systems, the organization should identify the actual steps involved. That may include defining which systems are in scope, deciding which logs need to be reviewed, configuring relevant systems, assigning reviewers, setting escalation rules, and documenting how suspicious activity will be handled. The objective becomes more practical once the organization has described the work needed to achieve it.
What resources are required forces realism. Many security objectives fail not because they are conceptually wrong, but because they were adopted without enough attention to staffing, tooling, budget, knowledge, or time. An organization may want stronger monitoring, better supplier oversight, or more frequent access reviews, but those objectives will not progress if no one has the capacity or tools to carry them out. Clause 6.2 places resources directly into the planning conversation, which helps prevent objectives from becoming unfunded expectations.
Who will be responsible addresses accountability. An objective without ownership is unlikely to progress consistently. Responsibility does not mean that one person performs every task, but it does mean that someone is answerable for driving the work forward, coordinating the necessary actions, and reporting on progress. Without clear responsibility, objectives can easily become shared intentions that everyone agrees with but no one actively manages.
When it will be completed introduces time discipline. This matters because objectives can otherwise become permanent ambitions that are never actually achieved or reassessed. A defined timeframe helps the organization decide whether progress is on track, whether delays need to be escalated, and whether the objective remains realistic.
How the results will be evaluated brings the requirement back to measurement and review. The organization should decide in advance how it will judge success, rather than improvising after the fact. This may involve completion records, performance indicators, audit results, management review inputs, test results, or other evidence that shows whether the intended result has been achieved.
Taken together, these requirements make clause 6.2 one of the clearest examples in ISO 27001 of how management system thinking works. It is not enough to identify what should improve. The organization must turn improvement into a planned activity with actions, resources, responsibility, timeframes, and a method for evaluating results.
Practical examples and common mistakes
It is useful to consider a few practical examples of how objectives under clause 6.2 might be framed. The purpose of these examples is not to provide wording that every organization should copy, but to show how objectives can be connected to risk decisions, planned actions, responsibility, and later evaluation.
An organization that identified gaps in user access governance during risk treatment might establish an objective to complete quarterly access reviews for all critical applications and remove inappropriate access within agreed timeframes. The associated plan would identify the systems in scope, the application owners involved, the review schedule, the evidence to be retained, and the method for tracking overdue actions. This makes the objective concrete enough to manage, because the organization can see who is responsible, what needs to happen, and whether the reviews have actually been completed.
An organization concerned about incident detection and response might establish an objective to improve incident handling readiness by testing defined incident categories, reporting routes, and response responsibilities during the year. The evaluation could include completion of the exercises, lessons learned, and closure of follow-up actions. In this case, the objective is not simply to “improve incident management.” It explains what improvement should look like in practice and gives the organization a way to review whether readiness has actually increased.
An organization with heavy supplier dependency might set an objective to ensure that key suppliers handling important information are reviewed against defined information security requirements during a set period. The plan could identify the relevant suppliers, the review criteria, required documentation, responsible functions, and how results are reported. This helps prevent supplier oversight from becoming a vague intention and turns it into a planned activity that can be monitored and reviewed.
In each case, the objective does not stand alone. It is tied to risk, supported by planning, and capable of monitoring and review. That is the practical value of clause 6.2. It turns the organization’s security concerns into defined results and connects those results to action.
Several recurring mistakes appear when organizations work with this requirement. The first is confusing activities with objectives. “Run awareness training” is an activity. “Improve information security awareness among relevant personnel, demonstrated through completion and evaluation criteria” is closer to an objective. The difference matters because objectives describe intended results, not just tasks.
The second mistake is setting objectives that are too broad to manage. Statements such as “improve information security” or “be compliant” may sound important, but they are too vague to guide action effectively. Useful objectives are focused enough to support planning and evaluation. They should help the organization understand what is to be achieved, not merely express a general desire to improve.
The third mistake is setting objectives that are disconnected from risk. An objective that has no visible relationship to the organization’s policy, applicable requirements, risk assessment results, or treatment decisions may still sound professional, but it is unlikely to support the ISMS where it matters most. Objectives should reflect the organization’s actual priorities, not just generic examples from a template.
The fourth mistake is neglecting ownership and resources. An objective may be well written, but if no one is clearly responsible and no realistic resources are available, it is unlikely to progress. The organization should be able to identify who is responsible for driving the objective forward and whether the necessary time, people, tools, and budget have been considered.
The fifth mistake is treating documented objectives as static. Clause 6.2 requires that objectives be updated as appropriate. As risks change, projects evolve, business priorities shift, or controls mature, objectives may need to be revised. An Information Security Management System is not strengthened by keeping outdated objectives alive merely because they were once approved.
Conclusion
Clause 6.2 takes the planning logic of Chapter 6 a step further. The previous part of the chapter required the organization to assess risks and opportunities and determine how they should be addressed. This part now requires the organization to express that planning through information security objectives and practical arrangements for achieving them. In this way, the Information Security Management System begins to show not only what the organization is concerned about, but what it is actively trying to accomplish.
That is why objectives matter so much in an effective ISMS. They create a bridge between policy and action, between risk treatment and measurable progress, and between management intent and operational follow-through. A mature organization does not simply say that security is important. It defines what it wants to achieve, assigns responsibility, provides resources, sets timeframes, and evaluates results. Objectives make that discipline visible.
In the next and final part of this Chapter 6 series, we will turn to clause 6.3 and look at the planning of changes. That final section may be brief in wording, but it carries significant practical weight. It reminds the organization that an ISMS is not meant to remain static, and that changes to it should be introduced in a deliberate and planned manner rather than left to drift or reaction.