You Have ISO 27001 Documentation. But Do You Actually Follow It in Practice?
One of the first questions during an ISO 27001 GAP analysis is often whether a particular policy or procedure exists. The document exists, has been approved, has an owner, a version number, and a date of last review. It states that user access is reviewed regularly, security incidents are recorded, backups are tested, and access is revoked when an employee leaves the organization. On paper, everything looks fine. The problem appears when the next question is asked: when was the last user access review performed? If the organization cannot show when the review took place, who performed it, and what was changed as a result, the existence of the policy tells us very little about whether the process it describes is actually being followed.
This is one of the important differences between ISO 27001 documentation and an ISMS that actually works. Documentation defines the rules, but the implementation of those rules must be visible in the organization’s day-to-day operations. An organization may, for example, have a well-written policy requiring periodic reviews of user access rights, but during an assessment it becomes clear that the last formal review was performed two years ago. In the meantime, employees have changed roles, projects have ended, new applications have been introduced, and permissions that are no longer required have remained active. The policy itself is not necessarily the problem. The problem is the difference between what the organization says it does and what actually happens.
The same applies to other parts of the ISMS. An incident management procedure may describe in detail how incidents should be reported, classified, and escalated, but if security events are handled through phone calls and messages without any record, it becomes difficult to determine later how an incident was handled, which decisions were made, or whether anything changed as a result. Backups may be clearly defined in an internal procedure and run successfully every night, with reports showing no errors for months. That is still not the same as evidence that the organization can restore a system when it actually needs to. If the last restore test was performed several years ago, or nobody knows how long recovery of a critical system would take, there is a clear difference between evidence that backups are being created and evidence that the recovery process works. The same problem appears with suppliers. An organization may have a procedure requiring security requirements to be assessed before engaging a supplier. If there is only a supplier list, but no record of who was assessed, against which criteria, or what happened when a risk was identified, it is difficult to conclude that the defined process is actually being followed.
That is why an ISO 27001 GAP analysis should not stop at asking, “Do you have this?” It needs to examine what actually happens behind the document. AresISEC does not look only at whether a policy, procedure, or other document exists. It is also important to determine whether the process described by that document exists in practice and whether there is an appropriate record of its implementation. That record does not always need to be a new document created specifically for ISO 27001. If access reviews are already performed through an existing IT system, evidence may be the record of the review and the changes made afterwards. If recovery is tested, the test results may provide the evidence. If security training is conducted, existing records can show when it took place and who participated. If suppliers are already assessed as part of procurement, there is little value in creating a parallel process simply to produce “ISO evidence.”
This is particularly important for organizations that already have established security practices. ISO 27001 implementation should not mean discarding existing ways of working and replacing them with a collection of new Word documents and spreadsheets. If a process already exists and works, the first step is to determine whether it meets the needs of the ISMS and whether its implementation can be demonstrated. Only then does it make sense to determine what needs to change. There is also another side to the problem. If certain evidence is not available during a GAP analysis, that does not automatically mean the activity has never been performed. It may be performed without the results being recorded. The evidence may exist in a system that the people participating in the assessment cannot access. The process may also be informal and depend on one person who has performed it for years, but it has never been defined in a way that allows the organization to repeat it reliably. This is why it is important to distinguish between a control that has not been implemented and one whose implementation cannot be confirmed from the available evidence.
That distinction matters for more than an audit. It matters to the organization itself. If a security process works only because one person knows what needs to be done, the organization has a problem even if that person has always done everything correctly. If nobody can determine when the last access review took place, it is difficult to know whether the next review is already overdue. If incidents are not recorded, it becomes difficult to identify recurring causes later. Evidence is therefore not paperwork that should be produced simply for a certification audit. It allows an organization to determine whether its own rules are being followed and whether its security controls are producing the expected results.
ISO/IEC 27001 does not end with writing policies. An ISMS needs to be established, implemented, maintained, and continually improved. When an ISO 27001 project becomes too focused on producing documentation, that distinction is easily lost. In the end, an organization can have a well-organized collection of policies, procedures, and registers, but one simple question remains: can you show that you actually do what they say?
Sources:
ISO – ISO/IEC 27001:2022 Information security management systems
ISO – ISO/IEC TS 27008:2019 Guidelines for the assessment of information security controls
ISO – How to measure the effectiveness of information security
This is one of the important differences between ISO 27001 documentation and an ISMS that actually works. Documentation defines the rules, but the implementation of those rules must be visible in the organization’s day-to-day operations. An organization may, for example, have a well-written policy requiring periodic reviews of user access rights, but during an assessment it becomes clear that the last formal review was performed two years ago. In the meantime, employees have changed roles, projects have ended, new applications have been introduced, and permissions that are no longer required have remained active. The policy itself is not necessarily the problem. The problem is the difference between what the organization says it does and what actually happens.
The same applies to other parts of the ISMS. An incident management procedure may describe in detail how incidents should be reported, classified, and escalated, but if security events are handled through phone calls and messages without any record, it becomes difficult to determine later how an incident was handled, which decisions were made, or whether anything changed as a result. Backups may be clearly defined in an internal procedure and run successfully every night, with reports showing no errors for months. That is still not the same as evidence that the organization can restore a system when it actually needs to. If the last restore test was performed several years ago, or nobody knows how long recovery of a critical system would take, there is a clear difference between evidence that backups are being created and evidence that the recovery process works. The same problem appears with suppliers. An organization may have a procedure requiring security requirements to be assessed before engaging a supplier. If there is only a supplier list, but no record of who was assessed, against which criteria, or what happened when a risk was identified, it is difficult to conclude that the defined process is actually being followed.
That is why an ISO 27001 GAP analysis should not stop at asking, “Do you have this?” It needs to examine what actually happens behind the document. AresISEC does not look only at whether a policy, procedure, or other document exists. It is also important to determine whether the process described by that document exists in practice and whether there is an appropriate record of its implementation. That record does not always need to be a new document created specifically for ISO 27001. If access reviews are already performed through an existing IT system, evidence may be the record of the review and the changes made afterwards. If recovery is tested, the test results may provide the evidence. If security training is conducted, existing records can show when it took place and who participated. If suppliers are already assessed as part of procurement, there is little value in creating a parallel process simply to produce “ISO evidence.”
This is particularly important for organizations that already have established security practices. ISO 27001 implementation should not mean discarding existing ways of working and replacing them with a collection of new Word documents and spreadsheets. If a process already exists and works, the first step is to determine whether it meets the needs of the ISMS and whether its implementation can be demonstrated. Only then does it make sense to determine what needs to change. There is also another side to the problem. If certain evidence is not available during a GAP analysis, that does not automatically mean the activity has never been performed. It may be performed without the results being recorded. The evidence may exist in a system that the people participating in the assessment cannot access. The process may also be informal and depend on one person who has performed it for years, but it has never been defined in a way that allows the organization to repeat it reliably. This is why it is important to distinguish between a control that has not been implemented and one whose implementation cannot be confirmed from the available evidence.
That distinction matters for more than an audit. It matters to the organization itself. If a security process works only because one person knows what needs to be done, the organization has a problem even if that person has always done everything correctly. If nobody can determine when the last access review took place, it is difficult to know whether the next review is already overdue. If incidents are not recorded, it becomes difficult to identify recurring causes later. Evidence is therefore not paperwork that should be produced simply for a certification audit. It allows an organization to determine whether its own rules are being followed and whether its security controls are producing the expected results.
ISO/IEC 27001 does not end with writing policies. An ISMS needs to be established, implemented, maintained, and continually improved. When an ISO 27001 project becomes too focused on producing documentation, that distinction is easily lost. In the end, an organization can have a well-organized collection of policies, procedures, and registers, but one simple question remains: can you show that you actually do what they say?
Sources:
ISO – ISO/IEC 27001:2022 Information security management systems
ISO – ISO/IEC TS 27008:2019 Guidelines for the assessment of information security controls
ISO – How to measure the effectiveness of information security
Do you have ISO 27001 documentation but are not sure how closely it reflects the way your organization actually works?An AresISEC ISO 27001 GAP analysis reviews existing processes and available evidence to identify what already works, what cannot yet be demonstrated, and what still needs to be established.