Protego
Insights

What an ISO 27001 auditor actually asks for.

7 min read

An auditor is not looking for the largest folder of policies. They are looking for a management system that makes decisions, operates controls, keeps records and corrects itself when something fails.

A policy pack is not a management system.

The fastest way to make an ISO 27001 project look finished is to produce policies. The fastest way to expose that it is not finished is to ask for the records those policies should have created. An access-control policy may say that access is reviewed quarterly. The auditor will ask for the last review, the population considered, the decisions made, the removals completed and the person who approved them.

ISO 27001 is a management-system standard. The documents describe how the organisation intends to manage information security. The records show whether it actually does so. A working ISMS connects scope, risk, controls, ownership, operation, measurement, internal audit, management review and corrective action. A set of templates can cover the headings while leaving those connections absent.

Auditors do not expect every organisation to use the same tools or produce identical files. They expect the organisation's stated process to be credible, proportionate and followed. If the policy says one thing, the ticketing system shows another and the person doing the work describes a third, the problem is not presentation. The process is not under control.

Stage 1 asks whether the system is ready to be tested.

An initial certification audit has two stages. Stage 1 is primarily about scope, design and readiness. The auditor needs to understand the organisation, confirm the intended certification scope and decide whether Stage 2 can be planned with confidence. It is not a rehearsal where incomplete work can be hidden until the next visit.

Expect to provide the ISMS scope, information-security policy, risk-assessment method, current risk register, risk treatment plan and Statement of Applicability. The auditor will look at how the organisation identified interested parties and legal, regulatory and contractual requirements. They will want to understand sites, teams, systems and suppliers inside the scope, and why anything close to the boundary was excluded.

Stage 1 also tests whether the management cycle has begun. Internal audit and management review cannot be future intentions if certification is imminent. There should be records showing that the organisation has inspected its own system, presented performance and risk information to management, made decisions, assigned actions and followed them. Objectives need measures, owners and evidence of review.

A Stage 1 report may identify areas of concern that must be resolved before Stage 2. Certification bodies use different language and processes, but the practical point is consistent: if the ISMS has not operated long enough to create evidence, more polished documents will not make it ready.

Stage 2 asks whether it works.

Stage 2 tests implementation and effectiveness. The auditor samples records, interviews people and observes processes. They may select a recent joiner and trace screening, approval, account creation, training and access. They may select a leaver and trace revocation. They may take a supplier from the register and ask for tiering, due diligence, contractual controls, review and a decision by an accountable owner.

Technical controls need technical evidence. Depending on scope, that may include configuration exports, identity-provider settings, device-management status, vulnerability and patch records, backup results, restore tests, logging coverage, incident tickets, secure-development records and changes approved through the normal workflow. A screenshot can support a sample, but it is weak when it has no date, population, owner or connection to a repeatable process.

Interviews matter because an ISMS belongs to the organisation, not the consultant who wrote it. Senior management should understand the material risks and the decisions recorded in management review. Control owners should know what they are responsible for and where the records live. Staff should understand the security expectations relevant to their work. Perfect recitation is not required. Consistent understanding is.

The evidence that routinely fails.

Access reviews fail when they contain only a list of accounts and a signature. A useful record defines the population, identifies privileged and exceptional access, records decisions, assigns removals and proves completion. Risk registers fail when every risk has the same owner, treatment dates are historic, scores never change and treatment choices have no rationale.

Supplier assurance fails when questionnaires are collected but no one makes or records a decision. Vulnerability management fails when scans exist but exceptions, ownership and remediation are unclear. Security objectives fail when they are statements such as improve awareness rather than measurable outcomes reviewed by management. Incident processes fail when the organisation has a plan but no evidence of exercises, lessons or changes.

Internal audit is another frequent weakness. It should be independent of the work being audited and should test conformity and effectiveness, not simply confirm that documents exist. Findings need owners, causes, corrective actions and closure evidence. Management review should then use that information to make decisions. Minutes that repeat an agenda without recording inputs, discussion and outputs do not demonstrate review.

The common thread is absence of a closed loop. The organisation states a control, performs part of it, notices a problem and then loses the decision or the follow-up. Auditors follow samples through the loop because that is where management systems either operate or stop.

What to have ready.

For Stage 1, have a controlled set of core ISMS documents, a defensible scope, a completed risk assessment and treatment process, a current Statement of Applicability, evidence that internal audit and management review occurred, and a clear account of the system's maturity. Make sure the certification body's scope wording matches the business and technology that customers believe is covered.

For Stage 2, build an evidence index by process and control. Do not manufacture a special audit folder that conceals how work is normally done. Point to the real systems of record and export stable copies where necessary. Sample your own evidence before the auditor does. Select recent joiners, leavers, changes, incidents, suppliers, risks and vulnerabilities, then trace each from trigger to closure.

Brief people on the purpose and schedule, but do not script answers. Resolve obvious contradictions between policy, system configuration and daily practice. Check that every overdue action has a recorded decision rather than a silent date change. If a control does not work, correct it and preserve the record of correction. A management system is allowed to find problems. It is required to manage them.

The audit room is not where an organisation should first discover its own process. If the evidence can be produced without a meeting, the owner can explain it, and the record shows the full decision cycle, the audit becomes a review of work already under control rather than a search for documents that were never created.

Working template

Download the AI system inventory template.

A practical starting register for systems, owners, purposes, data, providers, risk classification and evidence.

By requesting the template, you agree that Protego may email you about related assurance work. You can unsubscribe at any time.