Auditing ISO 27001 Clause 6.2 verifies that an organisation has established measurable information security objectives that align with its strategic goals. The audit confirms the Primary Implementation Requirement that objectives are documented, communicated, and actively monitored for progress. The Business Benefit is a focused security strategy that drives continuous improvement and risk reduction.
Use this pass/fail checklist to strictly validate compliance with ISO 27001 Clause 6.2 (Information security objectives). For a detailed methodology on how to conduct the interviews and system tests required to generate this evidence, refer to our Clause 6.2 Audit Guide.
1. Objectives Formally Documented
- Verification Criteria: A specific document (or dashboard) exists listing current information security objectives. They are not merely “known” or verbal.
- Required Evidence: The “Information Security Objectives” document (or dedicated section in the Management Review deck) dated within the current audit period.
Pass/Fail Test: If the CISO lists objectives during the interview but cannot produce a formal record of them approved by leadership, mark as Non-Compliant.
2. Alignment with Security Policy Verified
- Verification Criteria: The stated objectives directly support the high-level commitments made in the Information Security Policy (Clause 5.2).
- Required Evidence: A mapping or cross-reference between the Policy Statement (e.g., “We commit to 99.9% availability”) and the Objective (e.g., “Implement redundant power supplies by Q3”).
Pass/Fail Test: If the Policy focuses on “Data Privacy” but all Objectives are solely about “Server Uptime,” mark as Non-Compliant (Lack of alignment).
3. Measurability Criteria (SMART) Verified
- Verification Criteria: Objectives are written in a way that allows for definite measurement (e.g., specific percentage, date, or binary outcome).
- Required Evidence: Review the wording of 3 objectives. Look for metrics like “% reduction,” “Zero critical incidents,” or “Completion by [Date].”
Pass/Fail Test: If an objective is vague, such as “Improve security culture,” without a metric (e.g., “Achieve 90% phishing test pass rate”), mark as Non-Compliant.
4. Risk & Requirement Alignment Verified
- Verification Criteria: Objectives address the specific risks identified in the Risk Treatment Plan (Clause 6.1) or legal/contractual requirements.
- Required Evidence: The “Risk Treatment Plan” showing that high-priority risks are linked to specific mitigation objectives.
Pass/Fail Test: If the top risk is “Ransomware” but there is no corresponding objective to improve backup or endpoint protection, mark as Non-Compliant.
5. Action Plans (Who, What, When) Verified
- Verification Criteria: Every objective has a detailed plan covering: What will be done, Who is responsible, and When it will be completed.
- Required Evidence: Project plans, Jira tickets, or a GRC Action Tracker showing assigned owners and due dates for each objective.
Pass/Fail Test: If an objective is listed as “Implement MFA” but has no assigned owner or target deadline, mark as Non-Compliant.
6. Resource Allocation Confirmed
- Verification Criteria: Budget, personnel, and tools required to achieve the objectives have been formally allocated.
- Required Evidence: Budget approval emails, resource planning documents, or purchase orders linked to the objective’s project plan.
Pass/Fail Test: If an objective is “Deploy DLP” but the Finance team confirms there is no budget approved for DLP software, mark as Non-Compliant.
7. Communication to Relevant Parties Verified
- Verification Criteria: Staff and stakeholders responsible for the objectives are aware of them and their specific role in achieving them.
- Required Evidence: Departmental meeting minutes, internal newsletters, or interview confirmation from the assigned “Objective Owners.”
Pass/Fail Test: If the “Owner” listed on the plan is surprised to learn they are responsible for that objective during the audit, mark as Non-Compliant.
8. Active Monitoring of Progress Verified
- Verification Criteria: Progress toward objectives is tracked regularly (e.g., monthly/quarterly), not just reviewed at the end of the year.
- Required Evidence: Monthly dashboard reports, project status updates, or GRC logs showing percentage complete over time.
Pass/Fail Test: If the objective was set in January and there are no status updates or progress logs until the audit in December, mark as Non-Compliant.
9. Formal Evaluation of Results Verified
- Verification Criteria: Completed objectives are evaluated to see if they achieved the intended security outcome.
- Required Evidence: “Post-Implementation Review” documents or the “Evaluation” column in the Objectives Register filled out for closed items.
Pass/Fail Test: If an objective is marked “Done” but there is no data showing it actually reduced the risk it was meant to address, mark as Non-Compliant.
10. Periodic Review & Update Verified
- Verification Criteria: Objectives are not static; they are updated when the business context or threat landscape changes.
- Required Evidence: Version control history of the Objectives Document showing updates/changes within the last 12 months.
Pass/Fail Test: If the objectives listed are from 3 years ago and reference retired systems or completed projects, mark as Non-Compliant.
| Control Requirement | The “Checkbox Compliance” Trap | The Reality Check |
|---|---|---|
| Measurability | Tool allows free-text objectives like “Be more secure.” | Auditor must check for metric fields. Does the tool force a Target Value (e.g., “99%”)? If it accepts vague text without a measure, it fails Clause 6.2. |
| Resource Linking | Tool lists objectives as simple tasks. | Auditor must check for resource allocation. Can you link a Budget Code or Person Hours to the objective? If not, it’s just a wish list, not a plan. |
| Progress Tracking | Status is manually toggled “Not Started” / “Done.” | Auditor must look for trend history. Does the tool show progress over time (e.g., 10% -> 50% -> 90%)? Binary toggles fail the “monitoring” requirement. |
| Owner Assignment | Objectives assigned to generic groups like “IT Dept.” | Auditor must verify individual accountability. Does the tool email a specific human owner when the deadline approaches? Generic assignments lead to inaction. |
| Evaluation Evidence | Objective marked complete and archived immediately. | Auditor must check for an evaluation step. Does the tool force a “Retrospective” or “Result Evaluation” comment before archiving? If not, it misses the evaluation requirement. |
| Risk Linkage | Objectives module is separate from Risk module. | Auditor must check for integration. Can you click a Risk and see the linked Objective? Disconnected modules fail to prove the risk-based approach. |
About the author
