ISO/IEC 27001 asks an organisation to run an information security management system: to understand its risks, choose controls to treat them, operate those controls, and check that they work. Writing the policies is the easy part. Certification audits look for evidence that the policies are followed.

The current edition, ISO/IEC 27001:2022, groups its Annex A reference controls into four themes: organisational, people, physical and technological. The organisation decides which controls apply through its risk assessment, and records the decisions in a Statement of Applicability.

Where the gaps usually are

#
  1. Asset inventories that were accurate on the day they were written and not since.
  2. Access reviews that are scheduled in policy but have no records showing they took place.
  3. Leavers whose accounts are disabled in one system and still active in another.
  4. Supplier security requirements written into the policy but missing from contracts.
  5. Logs that are collected but never reviewed.
  6. Backups that run nightly but have never been restored in a test.
  7. An incident response plan that nobody has rehearsed.
  8. Security awareness training without attendance records.

None of these is a documentation problem. Each is an operational habit that the documentation describes but does not create.

Close the gap before the audit

#
  • Start from the risk assessment, so that controls are chosen for a reason the team understands.
  • Give each control an owner and a record it produces when it is performed.
  • Run the system for long enough to generate evidence before the certification audit, including at least one internal audit and one management review.
  • Treat findings from the internal audit as the cheapest ones you will get.

What auditors look for

#

A certification audit tests whether the management system is designed sensibly and whether it operates. Auditors sample. They pick a control, ask for the records it should produce, and follow the trail.

  • A risk assessment that reflects the organisation's actual systems, suppliers and threats, with treatment decisions that can be traced to the Statement of Applicability.
  • Records that show controls are performed: access reviews, change approvals, restore tests, training attendance.
  • Internal audit findings and management review minutes that show the organisation found and fixed its own problems.
  • People who can explain what they do and why, not only point to a policy.

Who should own what

#

An information security management system fails when it belongs to one person. Leadership sets direction and resources, control owners operate their controls, and a coordinator keeps the system running. Technology teams own many of the technical controls, but asset owners in the business decide what level of protection their information needs.

Certification is the start of a cycle

#

A certificate is typically issued for three years, with surveillance audits in the intervening years and a recertification audit at the end. Each visit samples the system again. Organisations that treat the first audit as a finish line tend to find their second one harder than the first, because the evidence trail has gone quiet.

Build the routine into normal operations instead: a calendar of control activities, owners who receive reminders, a quarterly look at the risk register, and an internal audit programme that covers the whole system over the cycle.

Keep it proportionate

#

A management system that is too heavy for the organisation will not be operated. Match the depth of each control to the risk it treats, automate evidence where systems can produce it, and remember that the standard expects continual improvement, not perfection on day one.