Two companies with identically organised document folders go through an audit very differently. The first answers the auditor's questions with records from recent months; the second explains its intentions. The standard contains no formal maturity scale, yet an experienced audit team tells these two states apart within the first two hours. Here is what gives it away.
ISMS — what it means to a certification body
The abbreviation stands for information security management system. Whether you call it an ISMS or use a local acronym makes no difference: the terms describe the same thing.
What matters more to an auditor is this: a management system is not a software product, not a separate department and not a folder of policies. It is the way a company makes decisions about protecting information — how it identifies risks, selects controls, verifies that they work and fixes what it finds.
ISMS objectives: how an auditor reads them
Clause 6.2 requires objectives to be measurable, consistent with the policy, communicated to those responsible and updated as appropriate. During an audit this turns into four simple questions: what is the unit of measure, who owns it, by what date, and where does the number come from.
| Weak wording | What the auditor will ask | A workable version |
|---|---|---|
| Improve our security posture | How would you know it improved? | Reduce mean time to remediate critical weaknesses from 30 days to 7 by year end |
| Train the staff | Whom, in what, and verified how? | Brief 100% of new joiners in their first week; measured quarterly |
| Reduce the number of incidents | What is the baseline? | Halve repeat incidents in one category compared with the previous six months |
The test for a workable objective is simple: a year later, both sides will say "achieved" or "not achieved" without arguing.
The first two hours
The opening meeting reveals more about the state of affairs than the following day spent with documents. A few requests come up almost every time:
- Show us the latest management review minutes. The date, and whether decisions appear in them, is the fastest indicator there is.
- Name the three biggest risks facing the organisation, in your own words.
- When did you last change the Statement of Applicability, and why?
- Give us an example of an internal audit finding and how it was closed.
Six signs of a living system
- The risk register moves. New contractors, services and locations have appeared, and the assessment shows it.
- The company finds its own nonconformities. Internal audits produce findings. A report with not a single finding in a year raises more doubt than a dozen small ones.
- Incidents come with root cause analysis. Not merely "service restored", but "why it became possible", with a decision attached.
- Management review ends in decisions. Minutes with deadlines and owners, not a statement of facts.
- Suppliers are in view. External parties are actually assessed, not merely mentioned.
- People know their own patch. A process owner explains in their own words how their area works, without prompting from a consultant.
How the audit changes from cycle to cycle
The first certification visit is the deepest: the team studies the system from scratch, covers every mandatory clause and a representative sample of controls.
Surveillance audits are shorter, but they always touch internal audits, management review, complaints, changes in the business and correct use of the certification mark — plus the areas where findings were raised last year.
Recertification in year three takes a wider view: performance across the whole cycle rather than isolated episodes.
Cloud and ISO 27001: whose responsibility during the audit
Moving infrastructure to a provider removes nothing from the scope — it merely redistributes controls between the parties. The provider's certificate covers the provider's part; your part remains yours.
Three things the auditor will ask to see:
- the contract or service level agreement with responsibilities explicitly divided;
- your own settings in the management console — access rights, logs, backups;
- evidence that the validity of the provider's certificate was checked rather than taken on trust.
ISO 27001, business continuity and the neighbouring field
Annex A contains two controls that address resilience: 5.29 — information security during disruption, and 5.30 — ICT readiness for business continuity. Both are examined as part of the ordinary audit, and they are where it most often emerges that the recovery plan has never been tested.
ISO 22301 BCMS is a separate business continuity management system with its own toolkit: business impact analysis, recovery time objective, tolerable data loss. That toolkit is not required for an audit against 27001, although companies that have it get through the resilience part noticeably more easily.
Where maturity begins
The most expensive decision of the project is taken at the very start: the boundaries of the scope. Cover too much and the audit drowns in sites and systems, resources run short, timelines slip. Cover too little and you hold a certificate while your customer reads the scope line and sees that the service they buy is not in it.
The working rule is to draw the line where the company's genuine control ends. An area you do not govern becomes, inside the system, a permanent source of nonconformities.
Planning an audit? Submit an application — we will assess readiness, agree the scope boundaries and calculate the effort. The basics are covered in ISO 27001 certification: what it is and who needs it.