- IAF CertSearch describes verification and monitoring of accredited certifications, including status changes such as suspension, withdrawal, and expiry.
"Certified Once, Accepted Everywhere"
Prepare the ISMS evidence an auditor will expect: scope, risk method, risk results, treatment plan, Statement of Applicability, Annex A control samples, internal audit findings, management review outputs, and corrective actions.
Use this as practical implementation guidance for ISO/IEC 27001 audit preparation and certification readiness, not as a substitute for your certification body's audit criteria.
Structured answer sets in this page tree.
Cited legal and guidance references.
Use this page to turn ISO/IEC 27001 audit readiness into a working evidence pack. The goal is not to create more policy text; it is to show that the ISMS scope, risk decisions, control selection, operating controls, audit findings, management review, and corrective actions are current and traceable.
Audit readiness starts with a clear ISMS boundary. The auditor should be able to see which business activities, locations, technologies, teams, suppliers, and information assets are inside scope, which interfaces are outside scope, and why those boundaries are reasonable.
Treat the scope statement as the anchor for the rest of the evidence pack. Risk assessments, treatment plans, Annex A control decisions, internal audit samples, management review inputs, and certification claims should all map back to the same boundary.
If a product, cloud environment, acquisition, outsourced process, or customer commitment changed since the last review, audit readiness means refreshing the scope and downstream evidence before the external audit exposes the gap.
A useful ISO/IEC 27001 audit pack connects risk assessment to risk treatment and then to the Statement of Applicability. The risk method should define criteria, the risk results should be repeatable enough to compare over time, and the treatment plan should show which risks are reduced, accepted, avoided, or transferred.
The Statement of Applicability should not be a static Annex A checklist. For each Annex A control, it should show whether the control is applicable, the justification for inclusion or exclusion, the implementation status, and the relationship to selected risk treatments or other information security requirements.
Before the audit, reconcile the risk register, treatment plan, SoA, policy exceptions, and control evidence. If a risk treatment relies on a control that is marked incomplete or excluded in the SoA, fix the inconsistency or document the accepted residual risk.
Use this ISO/IEC 27001 guide as the starting point for a tracked evidence pack: map risks to treatments and SoA decisions, gather Annex A samples, close internal audit findings, and keep management-review actions visible.
Convert ISO/IEC 27001 audit readiness into accountable tasks, evidence requests, SoA checks, internal-audit follow-up, and management-review checkpoints.
Review your ISMS scope, risk-to-control traceability, SoA gaps, certification evidence, and next audit-readiness steps.
Annex A evidence should prove controls are designed, owned, operating, and reviewed. A policy alone rarely proves operation. For each selected control, prepare a small sample that shows the process running inside the ISMS scope.
Good samples are specific: access review export and sign-off, supplier due-diligence record, incident postmortem, backup restore test, secure development review, vulnerability remediation ticket, awareness completion record, asset inventory extract, logging review, or change approval. Tie each sample to the control owner and date range.
Do not try to prove every control with the same evidence type. ISO/IEC 27002 is control guidance; audit readiness comes from mapping that guidance to real operating records, monitoring results, exceptions, and corrective actions.
The internal audit should test whether the ISMS conforms to ISO/IEC 27001 and to the organization's own requirements before a certification or surveillance auditor arrives. It should not be a document collection exercise run the week before the external audit.
Build an internal audit programme that covers scope, risk assessment, risk treatment, SoA decisions, selected Annex A controls, monitoring results, previous findings, and high-risk processes. Audit reports should state criteria, samples, evidence reviewed, findings, responsible owners, and due dates.
Use internal audit findings as a rehearsal for the external audit trail: can the team explain why a control was selected, where it operates, what evidence proves it operated, and how exceptions are tracked to closure?
Management review is where audit readiness becomes leadership evidence. The review should consider prior actions, changes in internal and external issues, interested-party needs, nonconformities, monitoring results, audit results, information security objectives, risk assessment results, risk treatment status, opportunities for improvement, and needed ISMS changes.
For certification and surveillance audits, keep the management-review output action-oriented. It should show decisions on resources, risk acceptance, scope changes, improvement priorities, overdue treatments, control weaknesses, and corrective-action effectiveness.
After the audit, update the evidence register instead of treating the audit report as a separate file. Findings should flow into corrective actions, corrective actions should be checked for effectiveness, and recurring weaknesses should influence the next internal audit programme and management review.
"Certified Once, Accepted Everywhere"
"Information security management systems - Requirements"
"Information security controls"
"Guidance on managing information security risks"
"Requirements for bodies providing audit and certification of information security management systems"