Five ISO 27001 Internal Audit Findings That Come Up Before Every External Certification

An ISO 27001 internal audit with no major nonconformities is a good result. It means the ISMS is documented, controls are operating, and the evidence library supports the conclusions. Most organizations reach that point before their first external certification.

But no major nonconformities is not the same as nothing to fix. Almost every internal audit surfaces a cluster of observations in the same five areas. They're not certification blockers on their own, but left unaddressed, they create friction at the external stage or return as minor nonconformities at the first surveillance audit.

These are the five areas we see consistently, and what to do about each before the external auditor arrives.

1. Policy Ownership Without a Named Approver

A common finding across organizations of every size: the information security policy, and often several supporting policies, lists multiple owners but has no named individual in the approval field.

ISO 27001:2022 Clause 5.2 requires that top management establish the information security policy. In practice, auditors treat establish as requiring documented evidence of senior-level sign-off, including a named approver and an approval date on the document itself. ISO 27002 A.5.1 reinforces this by requiring that the policy be approved, published, and communicated. The standard does not prescribe a single owner, but distributing ownership across four people while leaving the approval field blank produces the same outcome as having no ownership at all: no single person is accountable for the document's accuracy and currency.

This is a one-hour fix per policy. It is also one of the first things the external auditor checks when reviewing the information security policy under Clause 5.2.

2. Tool Mismatch Between Policy and Evidence

The access control policy says requests are processed through System A. The evidence uploaded to the GRC platform shows System B.

This observation comes up in almost every audit that involves a recent tool migration or a team that has grown faster than its documentation. The gap is usually innocent: the organization switched from one ticketing tool to another, updated their processes, but did not update the policy or did not replace the old evidence screenshots.

For ISO 27001, the problem is structural. The auditor's job is to confirm that the documented policy matches operational reality. When a policy references Jira and the evidence shows Asana, or vice versa, the auditor cannot confirm the control is operating as documented. Under A.5.15 and A.5.16 (access control and identity management), this creates a gap that requires either a policy update or fresh evidence, not both.

This requires a policy update and evidence refresh, but not a control redesign. The control is operating; the documentation needs to reflect what is actually happening.

3. Vendor Security Assessments Not Completed for In-Scope Suppliers

ISO 27002:2022 controls A.5.19 through A.5.22 cover supplier relationships, requiring that security requirements be addressed for in-scope suppliers, that supplier agreements include security clauses, and that supplier relationships be monitored on an ongoing basis.

Most organizations maintain a third-party list in their GRC platform and complete security assessments for their highest-risk vendors before the initial certification audit. The gap is typically not with the major cloud providers or the SaaS tools with SOC 2 reports and ISO certificates. The gap is with the mid-tier vendors: tools used by specific teams, newer additions to the stack, or vendors that fell into a lower risk tier during the initial classification and were deprioritized.

Before the external audit, every vendor classified as medium or high risk should have a completed security assessment in the evidence library. Low-risk vendors can be documented as such with a brief justification, but they should be documented.

4. Risk Treatment Items Documented as Incomplete

The risk register is reviewed during the internal audit for both completeness and accuracy. In organizations that have been running their ISMS for one to two years, the risk register typically shows a mix of accepted risks, treated risks, and risks with treatment plans that are marked as in progress.

In progress is not a problem. Risks take time to remediate. The problem is treatment items documented as incomplete with no updated target date, no owner, or no record of why the original target date passed.

ISO 27001:2022 Clause 6.1.3 requires that a risk treatment plan be established and that the plan be approved by risk owners and accepted by those accountable for the residual risk. Clause 8.3 requires that the results of the information security risk treatment be retained as documented information. An incomplete treatment item with no status update does not satisfy either requirement.

5. Incident Reports Without Named Approvers

The incident response policy describes a process for logging, analyzing, and closing security incidents. The process includes a root cause analysis report that is reviewed and approved before the incident record is closed.

The gap: the report template has Approved by and Prepared by fields, but the fields are blank. Or the process description names a role (for example, reviewed by Legal Counsel) without confirming who in that role is responsible.

Under ISO 27002:2022 A.5.24, A.5.26, and A.5.27, incidents must be managed through a documented process, root cause analysis findings must be captured, and lessons learned must feed back into the ISMS. An approval field with no name makes it impossible for the auditor to confirm that the review step actually occurred.

The Pattern Behind These Five Areas

These observations cluster because they share a root cause: the gap between the documented ISMS and the organization's operational reality. Policies are written during the certification sprint and not updated when tools change. Evidence is uploaded for the first cycle and not refreshed when processes evolve. Approval fields are treated as formalities rather than accountability mechanisms.

The ISO 27001 internal audit is the mechanism the standard provides to surface this gap before the external auditor does. A clean internal audit with these items identified and closed puts the organization in a materially better position than one that reaches external certification with observations the auditor has to raise formally.

For a structured review of where your ISMS stands against these and other common gaps, the ISO 27001 readiness scorecard covers the full Annex A and Clause 4 through 10 requirements in a self-assessment format.

Further Reading

• ISO 27001 Internal Audit: What Gets Reviewed and What You Receive
• ISO 27001 Certification Cost: What to Expect
• ISO 27001 Compliance Software: Vanta, Drata, and Secureframe Compared
• Building an Effective Security Program Before Compliance

Frequently Asked Questions

What is the most common ISO 27001 internal audit finding?

A recurring observation across ISO 27001 internal audits is policy ownership without a named approver. Organizations often distribute ownership across multiple roles but leave the approval field blank or populate it with a role title rather than an individual's name. ISO 27001 Clause 5.2 requires top management to establish the information security policy, and auditors treat this as requiring a named approver and an approval date on the document itself.

How many nonconformities can an organization have and still pass ISO 27001 certification?

There is no fixed limit on minor nonconformities, but major nonconformities must be resolved before certification can be issued. The external auditor will set a correction deadline for major findings, typically 90 days, after which the evidence of resolution is reviewed before the certificate is granted. Minor nonconformities are tracked and must be closed before the next surveillance audit.

Does switching ticketing tools require an ISMS policy update?

Yes. If your access control policy or any other ISMS procedure names a specific tool, switching to a different tool requires a policy update. The internal audit will check whether the policy matches the evidence, and a mismatch between the documented tool and the operational tool is raised as an observation at minimum. Update the policy before uploading evidence from the new system.

How often should vendor security assessments be completed under ISO 27001?

ISO 27002 A.5.19 requires that supplier security requirements be established and that supplier agreements include appropriate controls. A.5.22 requires ongoing monitoring. In practice, most organizations conduct initial assessments at onboarding and annual reviews for medium- and high-risk vendors. The frequency should be defined in the Third Party Management Policy and consistently applied.

What happens if a risk treatment item is still incomplete at the external audit?

An incomplete risk treatment item is not automatically a nonconformity. The auditor will assess whether the item has a documented status, a named owner, and a current target date. An item that is formally accepted as residual risk with a named risk owner satisfies the requirement. An item that simply shows a passed deadline with no update or decision recorded is more likely to be raised as a finding.

Do incident reports need a named approver or is a role title enough?

A named individual is required. ISO 27002 A.5.24 and A.5.26 require that incident response activities be documented and that lessons learned are captured and reviewed. When auditors sample incident reports, they look for specific names in the approval fields, not just role titles. A report showing Approved by: CISO with no name attached does not give the auditor sufficient evidence that the review step occurred.