ISO 27001 Clause 6.2 Audit Checklist

The ultimate audit guide to ISO 27001 Clause 6.2 Information Security Objectives and Planning to Achieve Them

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.

About the author