I have sat through enough ISO 27001 certification audits to know how they usually go. The auditor asks to see evidence of a control. The team scrambles. Someone opens a SharePoint folder, scrolls through dozens of files, and eventually produces a document that was last updated eight months ago. The auditor notes the gap. The team promises to update it. Everyone moves on to the next control, where the same scene plays out again.

The certification usually gets granted anyway, because the auditor can see that the organisation is trying and the controls broadly exist. But the process is painful, expensive, and — most importantly — it reveals something that the information security team already knew: the policies exist, but the evidence of enforcement does not.

That is the evidence gap. And it is the single biggest challenge in ISO 27001 governance.

What the standard actually requires

ISO 27001:2022 is structured around two things: the Information Security Management System (ISMS) requirements in Clauses 4 through 10, and the Annex A controls — a reference set of 93 controls organised into four themes.

The ISMS requirements are about the management system itself: leadership commitment, risk assessment, objectives, competence, documented information, monitoring, internal audit, and management review. These are the governance wrapper around your security controls.

Annex A provides the controls. In the 2022 revision, these were reorganised from 14 domains into four themes:

  • A.5 — Organisational controls (37 controls): Policies, roles, threat intelligence, asset management, access control, supplier relationships, incident management, business continuity, compliance
  • A.6 — People controls (8 controls): Screening, terms and conditions, awareness, disciplinary process, responsibilities after termination
  • A.7 — Physical controls (14 controls): Physical perimeters, entry controls, office security, equipment, storage media, utilities, cabling
  • A.8 — Technological controls (34 controls): User devices, privileged access, information access, source code, authentication, capacity management, malware protection, vulnerability management, logging, network security, secure development

Through the Statement of Applicability, you declare which controls are relevant to your organisation and how you implement them. The auditor then verifies two things: that your declared controls exist, and that evidence demonstrates they are working.

The second part is where it falls apart.

The evidence gap in practice

Let me give you some specific examples, because the gap is easier to understand through concrete scenarios than through abstractions.

Access control (A.8.2, A.8.3, A.8.5)

The standard requires that access to information is restricted according to the access control policy. Most organisations have role-based access control. They have an access policy. What they do not have is a continuous, auditable record of every access change: who was granted what access, when, by whom, and why. They cannot produce a report showing all access changes over the last twelve months. They cannot demonstrate that access reviews happened quarterly as the policy states. The reviews probably did happen — in a meeting, discussed verbally, with no record beyond an action item in someone's notebook.

The control exists. The evidence does not.

Change management (A.8.32)

A.8.32 requires that changes to information processing facilities and systems are subject to change management procedures. Engineering teams use pull requests and deployment pipelines. The changes are technically recorded in Git. But can the auditor trace a specific change from the business requirement through the approval, implementation, testing, and deployment? Usually not without significant manual effort. The approval might be in Jira, the code review in GitHub, the deployment in a CI pipeline, and the post-deployment verification in a Slack channel. Nobody stitched them together into a single auditable record.

Supplier management (A.5.19 through A.5.23)

The standard requires that information security requirements are agreed with suppliers, that supplier services are monitored and reviewed, and that changes to supplier services are managed. Most organisations have a procurement process. Some have a supplier register. Very few have a structured record of security assessments conducted during onboarding, the security clauses agreed in contracts, the periodic review schedule, or evidence that reviews actually happened.

The supplier management process exists. The evidence trail does not.

Asset management (A.5.9 through A.5.13)

The standard requires an inventory of information assets, defined ownership, acceptable use rules, and a classification scheme. This is one of the most common audit findings: the asset register is incomplete, outdated, or both. IT teams know what they run. They just do not maintain a formal, current register with assigned owners and classification levels. The information lives in people's heads, in deployment scripts, and in infrastructure-as-code repositories that the auditor cannot easily interpret.

The controls exist. The policies exist. What does not exist is the continuous, structured evidence that they are actually working.

Why GRC tools do not solve this

The instinct when facing this problem is to buy a GRC platform. Map your controls, upload your policies, set review reminders, generate compliance reports. I understand the appeal. But I have watched this approach fail repeatedly, and the failure mode is always the same.

GRC tools are designed to manage compliance metadata. They track which controls exist, which policies are assigned, which reviews are scheduled. What they do not do — what they fundamentally cannot do — is generate the operational evidence that proves the controls work.

A GRC tool can remind you that an access review is due. It cannot conduct the access review. It can track that a supplier assessment is scheduled. It cannot produce the assessment. It manages the meta-layer of compliance — the schedule, the status, the assignments — but it does not touch the actual operations that generate evidence.

This is why organisations end up with a GRC platform that is beautifully organised and a SharePoint folder full of stale evidence documents. The GRC tool tells them what they need. It does not help them produce it.

Governance tooling approaches this differently. Instead of managing compliance metadata about your operations, it becomes part of your operations. The evidence is not attached to a control register after the fact. It is generated as a byproduct of the governed activity itself.

Where HelixGate generates evidence automatically

I want to walk through specific Annex A controls and show how HelixGate produces audit evidence as part of normal operations. This is not theoretical. These are the controls where I have personally seen organisations struggle to produce evidence during certification audits.

Access control: A.8.2, A.8.3, A.8.5

HelixGate implements role-based access control with mandatory TOTP-based multi-factor authentication. Every access change — role assignments, permission modifications, user provisioning, user deprovisioning — is recorded in the immutable audit trail with the actor, timestamp, IP address, and the specific change made. The audit trail cannot be modified or deleted. When your auditor asks for evidence of access management, you export the report. Five minutes, not five days.

Periodic access reviews are structured within the platform. You can see the current state of all user access, when each assignment was last reviewed, and who reviewed it. The evidence of the review is the review itself, captured in the system.

Change management: A.8.32

Every governance record in HelixGate — business cases, architecture decisions, supplier assessments, service catalogue entries — maintains a complete change history. The audit trail captures who changed what, when, what the previous value was, and what the new value is. For architecture decision records, the full lifecycle from proposal through review, approval, and implementation is captured with all approvers and their timestamps.

This is change management evidence generated by the act of making the change. Nobody fills in a separate change management form. The form is the change.

Supplier management: A.5.19 through A.5.23

HelixGate's Supplier Management module captures the full supplier lifecycle: onboarding assessments, risk ratings, contract linkages, review schedules, and review outcomes. When your auditor asks to see evidence that you assessed a supplier's security posture before onboarding them, the assessment record is in the system. When they ask for evidence of periodic reviews, the review history is there — with dates, reviewers, findings, and actions.

The supplier record links to the contracts it supports and the services it provides. The cross-referencing that auditors love — and that organisations spend weeks manually assembling — is built into the data model.

Asset management: A.5.9 through A.5.13

The Service Catalogue provides the asset inventory that A.5.9 requires. Each service has a defined owner, a classification, a description of the information it processes, and relationships to the business capabilities it supports, the suppliers that provide it, and the other services it depends on.

Because the Service Catalogue is a living part of how the organisation manages its technology portfolio — not a compliance artefact maintained separately — it stays current. People use it because it is useful, not because an auditor requires it. That is the only way an asset register stays accurate over time.

The recertification advantage

ISO 27001 certification is not a one-off event. After the initial certification audit, you face surveillance audits annually and a full recertification every three years. This is where the evidence gap becomes most expensive.

Organisations that reconstruct evidence at audit time face the same scramble every year. The two weeks before the surveillance audit become a frantic period of updating documents, chasing approvals, and praying that nobody asks about the gap between the last documented review and the current state.

Organisations that generate evidence continuously do not have this problem. The evidence is always current because it is a byproduct of ongoing operations. When the surveillance auditor arrives, you open the platform and show them. The preparation time drops from weeks to hours.

Over a three-year certification cycle, this difference compounds dramatically. I have seen organisations spend the equivalent of two full-time employees' time on annual evidence preparation. That cost disappears when evidence generates itself.

Over a three-year certification cycle, the difference between reconstructed evidence and continuous evidence is measured in months of effort.

Practical advice for organisations pursuing certification

Whether you are pursuing ISO 27001 for the first time or preparing for recertification, here is what I have learned works:

  1. Start with the evidence, not the policies. Most organisations write policies first and then try to figure out how to produce evidence of compliance. Reverse this. Identify what evidence the auditor will request for each applicable control. Then design your processes to generate that evidence as a natural output. The policies describe what you do. The evidence proves you did it. Both matter, but the evidence is harder.
  2. Prioritise the controls that require continuous evidence. Some Annex A controls require point-in-time evidence (a policy document, a risk assessment). Others require evidence of ongoing operation (access reviews, change management, incident response). The second category is where the evidence gap is widest. Focus your tooling and process design on making these controls self-evidencing.
  3. Connect your governance domains. An auditor does not evaluate controls in isolation. They follow threads. They start with an asset in the service catalogue, trace it to the supplier that provides it, check the contract, verify the access controls, and examine the change history. If your governance data is in five disconnected systems, you cannot follow these threads. If it is in one connected system, the threads are built into the data model.
  4. Do not buy tooling to solve a process problem. If your access review process does not exist, buying a tool that reminds you to do access reviews will not help. Design the process first. Then find tooling that embeds the process into daily operations so that evidence is a byproduct, not an overhead.
  5. Make the ISMS a living system. Clause 10 of ISO 27001 requires continual improvement. The auditor wants to see that your ISMS is not static — that you learn from incidents, update your risk assessments, and refine your controls over time. If your ISMS is a set of documents that gets updated annually before the audit, that is not continual improvement. That is annual theatre. Build the improvement cycle into your operations so it happens naturally.
  6. Internal audits are your best friend. Clause 9.2 requires internal audits of the ISMS. Treat these seriously. A good internal audit conducted six months before the certification audit will identify every evidence gap the external auditor would have found, giving you time to close them. The organisations that treat internal audits as a box-ticking exercise are the ones that get caught out in certification.

Closing the gap

ISO 27001 is a good standard. It is well-structured, practical, and widely recognised. The challenge is not the standard itself. It is the gap between having controls and proving they work.

That gap exists because most organisations built their information security practices and their evidence collection as separate activities. The security team implements controls. The compliance team collects evidence. The two activities happen on different schedules, in different systems, by different people. The result is a perpetual scramble to produce evidence that should have been generating itself all along.

Closing the evidence gap requires a change in approach. Stop treating evidence collection as a compliance activity that happens periodically. Start treating it as an operational capability that runs continuously. Build your governance processes — access management, change management, supplier management, asset management — in systems that record what happens as it happens.

That is what we built HelixGate to do. Not because we wanted a compliance tool, but because after years of watching organisations struggle with this exact problem, it became clear that the only governance that works is governance embedded in operations. Not governance bolted on afterwards.

The evidence gap is not inevitable. It is a design choice. And you can make a different one.