Security Objectives Versus Controls
In ISO/IEC 27001, security objectives and controls are closely linked but serve different purposes. A Lead Auditor must understand the difference to judge whether an ISMS is designed and working effectively. Security objectives describe what the organization wants to achieve. Clause 6.2 requires in… In ISO/IEC 27001, security objectives and controls are closely linked but serve different purposes. A Lead Auditor must understand the difference to judge whether an ISMS is designed and working effectively. Security objectives describe what the organization wants to achieve. Clause 6.2 requires information security objectives to be consistent with the information security policy, measurable where practicable, aligned with applicable requirements and risk assessment and treatment results, monitored, communicated, updated as needed, and documented. Objectives are usually expressed as outcomes, such as reducing phishing-related incidents by 50 percent within twelve months, achieving 99.9 percent availability of a critical service, or ensuring all staff complete awareness training annually. The organization must also plan how to achieve them, defining what will be done, what resources are needed, who is responsible, when it will be completed, and how results will be evaluated. Controls describe how the organization achieves those outcomes and treats risk. A control is any measure that maintains or modifies risk, such as policies, procedures, technical mechanisms, or physical safeguards. Controls are selected through the risk treatment process in clause 6.1.3, compared against Annex A to ensure no necessary control is omitted, and justified in the Statement of Applicability. ISO/IEC 27002 provides implementation guidance. For the phishing objective, relevant controls might include awareness training (A.6.3) and protection against malware (A.8.7). The key distinction is that objectives define direction and expected results, while controls are the means of delivering them. Controls without objectives may become box-ticking, and objectives without controls remain aspirations. From an audit perspective, the Lead Auditor checks traceability between policy, risks, objectives, and selected controls. The auditor seeks evidence that controls are implemented and operating, and that their effectiveness is measured under clause 9.1. If controls exist but objectives are not being met, this may indicate weak control design or poor risk analysis, and it should trigger corrective action and continual improvement under clause 10.
Security Objectives Versus Controls in ISO/IEC 27001: A Complete Guide for Lead Auditors
Introduction
One of the most frequently tested ISMS concepts in the ISO/IEC 27001 Lead Auditor exam is the difference between information security objectives and information security controls. Candidates often confuse the two because both relate to protecting information. In ISO/IEC 27001:2022, however, they sit in different places, serve different purposes and are audited in different ways. This guide explains what each one is, why the difference matters, how they work together inside an ISMS, and how to answer exam questions about them with confidence.
Why This Concept Is Important
1. It separates results from means. Objectives describe what the organization wants to achieve. Controls describe how it reduces risk. Mixing them up leads to weak audit findings and poor ISMS design.
2. It drives performance evaluation. Clause 9.1 requires the organization to monitor and measure information security performance and the effectiveness of the ISMS. Without measurable objectives, the organization cannot show it is improving.
3. It underpins risk-based thinking. Controls are selected through risk treatment (Clause 6.1.3). Objectives are set at relevant functions and levels (Clause 6.2). An auditor must check that both exist and are linked.
4. It is a common source of nonconformities. Auditors often find organizations that list controls (for example, "we use firewalls") as if they were objectives, or set objectives that are not measurable, not monitored or not communicated.
5. Exam relevance. Scenario-based questions often ask you to identify whether a statement is an objective or a control, or to judge whether a clause requirement is met.
What Are Information Security Objectives?
Information security objectives are results to be achieved. They are defined in Clause 6.2 (Information security objectives and planning to achieve them) of ISO/IEC 27001:2022.
According to Clause 6.2, information security objectives shall:
a) be consistent with the information security policy;
b) be measurable (if practicable);
c) take into account applicable information security requirements and the results of risk assessment and risk treatment;
d) be monitored (added in the 2022 version);
e) be communicated;
f) be updated as appropriate;
g) be available as documented information.
When planning how to achieve the objectives, the organization shall determine:
- what will be done;
- what resources will be required;
- who will be responsible;
- when it will be completed;
- how the results will be evaluated.
The 2022 amendment also added Clause 6.3 (Planning of changes), which supports controlled change to the ISMS.
Examples of objectives:
- Reduce reportable security incidents by 30% within 12 months.
- Achieve 100% completion of security awareness training for all staff by Q4.
- Ensure 99.9% availability of the customer portal.
- Close all critical vulnerabilities within 7 days of discovery.
Objectives are often written in a SMART form: Specific, Measurable, Achievable, Relevant, Time-bound. The policy (Clause 5.2) must provide a framework for setting objectives or include the objectives themselves, and top management must make sure objectives are established and compatible with the strategic direction (Clause 5.1).
What Are Information Security Controls?
Controls are measures that maintain and/or modify risk. ISO/IEC 27000 defines a control as a measure that maintains and/or modifies risk. Controls include policies, procedures, guidelines, practices, organizational structures, and technical or physical safeguards.
Controls are selected during risk treatment (Clause 6.1.3). The organization must:
- determine all controls needed to implement the chosen risk treatment options;
- compare them with Annex A to make sure no necessary controls have been omitted;
- produce a Statement of Applicability (SoA) listing the necessary controls, the justification for including them, whether they are implemented, and the justification for any Annex A exclusions;
- create a risk treatment plan and obtain risk owners' approval of the plan and acceptance of residual risks.
In ISO/IEC 27001:2022, Annex A contains 93 controls in four themes:
- Organizational controls (5.1 to 5.37), 37 controls
- People controls (6.1 to 6.8), 8 controls
- Physical controls (7.1 to 7.14), 14 controls
- Technological controls (8.1 to 8.34), 34 controls
ISO/IEC 27002:2022 gives implementation guidance for each control, plus attributes such as control type (preventive, detective, corrective) and the security properties each one supports (confidentiality, integrity, availability).
Examples of controls:
- Multi-factor authentication (8.5 Secure authentication)
- Information backup (8.13)
- Security awareness, education and training (6.3)
- Physical entry controls (7.2)
- Threat intelligence (5.7, new in 2022)
Historical Note: "Control Objectives"
In ISO/IEC 27001:2013, Annex A contained control objectives (for example, "To limit access to information and information processing facilities") grouped under 14 domains, with 114 controls. The 2022 version removed control objectives from Annex A. Each control in ISO/IEC 27002:2022 now has a purpose statement instead. Exam questions may test whether you know that "control objectives" are no longer part of Annex A in the 2022 edition. Do not confuse these old control objectives with the ISMS information security objectives in Clause 6.2.
How Objectives and Controls Work Together
Think of the relationship as a chain:
1. Context and policy (Clauses 4 and 5): The organization understands its issues, interested parties and requirements, and top management sets a policy.
2. Risk assessment (6.1.2): Risks to confidentiality, integrity and availability are identified, analysed and evaluated.
3. Risk treatment (6.1.3): Controls are chosen to modify risks, checked against Annex A and documented in the SoA.
4. Objectives (6.2): Measurable targets are set, taking account of risk assessment and treatment results.
5. Operation (Clause 8): Controls and plans are implemented.
6. Performance evaluation (Clause 9): The organization monitors whether objectives are achieved and controls are effective, then runs internal audit and management review.
7. Improvement (Clause 10): Nonconformities are corrected and the ISMS is continually improved.
Key distinctions:
- Nature: An objective is a result or target. A control is a measure or mechanism.
- Clause: Objectives fall under Clause 6.2. Controls fall under Clause 6.1.3 and Annex A.
- Question answered: An objective answers "What do we want to achieve?" A control answers "How do we reduce risk?"
- Measurement: Objectives are measured by achievement against targets. Controls are measured by effectiveness in modifying risk.
- Documentation: Objectives appear as documented objectives and plans. Controls appear in the SoA, the risk treatment plan, policies and procedures.
- Example: "Zero unauthorized access incidents this year" is an objective. "Role-based access control" is a control.
A control can help achieve an objective. For example, deploying endpoint detection (control 8.7 Protection against malware) supports the objective "reduce malware infections by 50%." Measuring a control's effectiveness can also produce data for an objective. Even so, the two are never the same thing.
How an Auditor Evaluates Each
Auditing objectives:
- Are objectives established at relevant functions and levels?
- Are they consistent with the policy and measurable where practicable?
- Do they take risk assessment and treatment results into account?
- Are they monitored, communicated, updated and documented?
- Is there a plan covering what, resources, who, when and how results are evaluated?
- Does management review (9.3) consider the fulfilment of objectives?
Auditing controls:
- Is the SoA complete, with justifications for inclusion and exclusion?
- Are the selected controls traceable to risk treatment?
- Are the controls implemented as described (sample evidence, interviews, observation)?
- Are the controls effective (Clause 9.1 monitoring and measurement)?
- Have risk owners approved the treatment plan and accepted residual risks?
Common Pitfalls and Nonconformity Examples
- Objectives stated as activities ("implement a firewall"). This is a control or action, not a result.
- Objectives with no measure or timeframe ("improve security").
- Objectives not communicated to the relevant personnel.
- An SoA that lists Annex A controls with no link to the risk assessment.
- Annex A controls excluded with no justification.
- No evidence that objectives are monitored, which is a breach of 6.2 d) in the 2022 version.
- An organization assuming Annex A is mandatory in full. Controls are selected based on risk. Annex A is a reference checklist, but the SoA must address all of its controls.
Exam Tips: Answering Questions on Security Objectives Versus Controls
1. Apply the "result versus means" test. If the statement describes a target, outcome or measurable state, it is an objective. If it describes a mechanism, process, technology or practice that modifies risk, it is a control.
2. Link to the correct clause. Objectives go with Clause 6.2. Controls go with Clause 6.1.3, Annex A and the SoA. Questions asking "which clause is not met" often hinge on this.
3. Remember the 2022 changes. Annex A has 93 controls in 4 themes, control objectives were removed, and Clause 6.2 now explicitly requires objectives to be monitored. Watch for distractors that cite 114 controls or 14 domains.
4. Look for measurability. Objectives must be measurable if practicable. An objective with no metric is a likely nonconformity, or at least an opportunity for improvement.
5. Check the planning elements. If a scenario shows objectives without assigned responsibility, resources, timeline or an evaluation method, cite Clause 6.2.
6. Do not treat Annex A as a mandatory list. The right answer usually says controls are determined by risk treatment and compared with Annex A, not that all 93 must be implemented.
7. Distinguish effectiveness from achievement. Control effectiveness and objective achievement are both evaluated under Clause 9.1, but they are different. An effective control does not by itself mean an objective is met.
8. Watch for top management roles. Under Clause 5.1, top management makes sure objectives are established. Under Clause 5.2, the policy provides the framework. Questions may ask who is responsible.
9. Use auditor language. In scenario answers, cite the requirement, the evidence and the gap. For example: "Clause 6.2 requires objectives to be measurable. The audited objective 'improve security' has no metric. Nonconformity (minor)."
10. Grade nonconformities carefully. A complete absence of objectives, or an SoA missing entirely, usually points to a major nonconformity, because it is a systemic failure of a requirement. A single objective that lacks a metric is usually minor.
11. Eliminate distractors. Wrong options often mix terms, such as "control objectives must be documented in the SoA under 6.2." Read every word and check that the clause matches the concept.
12. Remember the risk link. Objectives must take into account risk assessment and treatment results. Controls are derived from risk treatment. If a scenario shows no link to risk, that is a gap.
Quick Practice Examples
- "Encrypt all laptops." This is a control (8.1 User endpoint devices / 8.24 Use of cryptography).
- "Ensure no data loss from stolen laptops in 2025." This is an objective.
- "Conduct quarterly phishing simulations." This is a control or action supporting awareness (6.3).
- "Reduce the phishing click rate below 5% by year end." This is an objective.
- "Maintain an access control policy." This is a control (5.15 Access control).
Summary
Information security objectives are measurable results the ISMS aims to achieve (Clause 6.2). Controls are risk-modifying measures selected through risk treatment and documented in the SoA (Clause 6.1.3 and Annex A). Objectives tell you where the organization wants to go. Controls are part of how it gets there safely. As a lead auditor, verify that both exist, are linked to risk, are monitored and evaluated, and are kept up to date. In the exam, apply the result-versus-means test, map each item to the right clause, and remember the 2022 updates.
Unlock Premium Access
ISO/IEC 27001 Lead Auditor
- Access to ALL Certifications: Study for any certification on our platform with one subscription
- 3041 Superior-grade ISO/IEC 27001 Lead Auditor practice questions
- Unlimited practice tests across all certifications
- Detailed explanations for every question
- ISO 27001 LA: 5 full exams plus all other certification exams
- 100% Satisfaction Guaranteed: Full refund if unsatisfied
- Risk-Free: 7-day free trial with all premium features!