What Is an ISMS? Information Security Management System

An information security management system is the set of policies, processes, people and decisions an organisation uses to manage its information security risks deliberately rather than by accident. It is a management system, not a set of security controls. The controls are what it produces; the system is what decides which controls, why, and whether they work.

The ISMS definition, and the part that matters

Start with the one definition the standards do give plainly. Information security is the preservation of the confidentiality, integrity and availability of information. An ISMS is the management system through which an organisation does that preserving deliberately — the standard sets out what such a system must contain rather than offering a one-line definition of it.

What that definition leaves implicit is the useful part. A firewall is not an ISMS. Nor is a password policy, an encryption standard, or a well-run security team. Those are outputs. The ISMS is the machinery that decides what an organisation is protecting, from what, how much protection is enough, who owns that decision, and whether the answer is still true a year later.

Most explanations of ISO/IEC 27001 are written for the person building the system. This one is written for the person auditing it, which is a different job with different questions. An auditor is not asked whether an organisation is secure. They are asked whether the system that produces its security decisions actually works.

A word on sources, because it matters more here than on most pages. Clause references are to ISO/IEC 27001. Definitions are given in short form rather than reproduced, because the standards are copyright documents you buy. And the vocabulary position has moved: the overview standard in this family used to carry the whole vocabulary and no longer does — its current edition keeps only a handful of terms and points readers elsewhere. Several definitions people still quote from it, including “asset”, come from editions that have been superseded. Where that matters, this page says so.

What is inside an ISO 27001 ISMS

ISO/IEC 27001 sets out the requirements in Clauses 4 to 10. The plan-do-check-act column below is a teaching convention rather than part of the standard — the current text contains no cycle diagram — but it is a useful way to hold the shape, and where a clause sits in it is arguable at the edges.

Clauses 1 to 3 — scope, normative references, and terms and definitions — are not audited as requirements, and knowing that saves a candidate from a wrong answer. They are not inert, though: Clause 3 is what makes the family’s definitions binding on the standard, and Clause 1 contains the sentence that excluding any requirement of Clauses 4 to 10 is not acceptable in a claim of conformity.

One consequence of that structure is worth stating plainly, because it is where most misunderstanding starts. This is not an IT standard. Clauses 4 to 10 are the generic management-system spine, shared with the quality, environmental and health and safety standards, and what makes this one about information security sits in Clause 6, Clause 8 and Annex A. The information being protected includes paper, conversations, people, premises and suppliers, and a great deal of what an ISMS audit examines never touches a computer.

The engine room of ISO 27001: Clause 6

If you read only one clause properly, read this one. Clause 6 is where the risk work is done, and it is the part of the standard an audit spends most of its time in.

It opens with a requirement people skip. Clause 6.1.1 asks the organisation to determine the risks and opportunities that need addressing so the ISMS can achieve its intended outcomes, prevent undesired effects and achieve continual improvement, and to plan actions and how to evaluate them. That is a separate, auditable thing from the information security risk assessment that follows it.

Clause 6.1.2 requires a defined information security risk assessment process, and Clause 6.1.3 the treatment that follows from it. The output is a set of controls, a risk treatment plan, a Statement of Applicability, and residual risks accepted by the people accountable for them.

Two things about that output are worth fixing in your head now, because most confusion in the subject starts here. The Statement of Applicability is not the risk treatment plan: the plan says how risks will be treated, the Statement says which controls apply, why, and whether they are in place. And Annex A is not a shopping list: controls come from the risk treatment, and Annex A is the cross-check that nothing necessary was missed.

The risk vocabulary itself — threat, vulnerability, asset and control — is worth taking apart properly, because the words are the reasoning.

What makes an ISMS real rather than just documented

This is the distinction the whole discipline turns on, and it is what separates an auditor from a document reviewer.

An organisation can hold every document ISO/IEC 27001 asks for and still not have a functioning ISMS. The documents describe intent. The evidence shows whether the intent survived contact with the business.

Three tests do most of the work.

Does the risk assessment reconcile to the controls? Take one real risk. Is it identified, does it have a named owner, was it analysed against defined criteria, which treatment was chosen, which controls were selected, and does the Statement of Applicability say the same thing?

Are the controls actually operating? The Statement of Applicability says a control is implemented. Clause 8 is where you test whether that is true. A control marked implemented that operations cannot demonstrate is a finding regardless of how good the policy is.

Is the system live? Risk assessments repeated at planned intervals or when significant changes are proposed or occur, internal audits that deliver what Clause 9.2.1 asks them to deliver, management reviews that produce decisions rather than minutes. An ISMS assessed once and never revisited is a project, not a management system.

Documented information ISO 27001 expects

The standard’s word is documented information, which deliberately covers both documents and records — the older split between the two went when the harmonized structure arrived. Certain documented information is expected by name, and its absence is usually a symptom rather than the disease. If an organisation cannot produce retained risk assessment results, the more interesting question is whether the risk process is operating at all.

The ISMS scope, and the information security policy.

The risk assessment process and its results; the risk treatment process and its results.

The Statement of Applicability.

Information security objectives, and evidence of competence.

Monitoring and measurement results; the internal audit programme and its results; management review results.

Evidence of nonconformities and the actions taken.

Whatever the organisation itself determines is necessary for the effectiveness of the ISMS — a requirement with no fixed list, and one that makes an organisation’s own documented procedures part of the audit criteria.

How an ISO 27001 auditor approaches an ISMS

An auditor works from three things and nothing else: the requirement, the objective evidence, and the gap between them. Everything below is an application of that.

In practice that means following trails rather than working down a list. Leadership is a good example: Clause 5 asks for top management commitment, which is hard to evidence directly. An experienced auditor probes it through other clauses instead — were the resources Clause 7.1 requires actually provided, and did the management review Clause 9.3 requires actually happen, with decisions recorded?

The same logic runs through the whole standard. A documented scope that carefully excludes the riskiest part of the business is a Clause 4 problem you find by reading Clause 6. An obsolete policy in use while an approved newer version exists is a Clause 7.5.3 problem you find by asking someone to show you the one they use.

The clause-by-clause version for auditors works through the whole standard in that spirit — what to ask, and what a broken answer looks like.

Who audits an ISMS, and on whose behalf: first, second and third party

Three kinds of audit look at the same system for different reasons, and the words for them are worth getting right early.

First party — an internal audit, run by or for the organisation itself. Clause 9.2.1 requires internal audits at planned intervals, conducted to provide information on whether the ISMS a) conforms to the organisation’s own requirements for it and to the requirements of the standard, and b) is effectively implemented and maintained. Clause 9.2.2 requires a programme, and requires auditors to be selected and audits conducted so as to ensure objectivity and the impartiality of the audit process.

Second party — an audit by an interested party, most often a customer auditing a supplier.

Third party — an audit by an independent organisation. Certification bodies are the usual case, running an initial certification in two stages and then maintaining it by surveillance and recertification audits, but regulators and other statutory bodies are third-party auditors too.

One distinction inside that third category catches people out. The audit team recommends; the certification body decides. The decision is taken independently of the people who did the audit, and that separation is a requirement on the certification body rather than a courtesy.

Frequently asked questions about an ISMS

Where to go next: more ISO 27001 Lead Auditor exam preparation

Confidentiality, integrity and availability in an audit

Six myths that cost Lead Auditor candidates marks

If you are considering auditing these systems professionally, the ISO 27001 Lead Auditor training course is the CQI and IRCA certified route.

3FOLD TRAINING is a CQI and IRCA Approved Training Partner, ATP number 6039853. Its ISO 27001 Lead Auditor training course is the CQI and IRCA Certified ISO/IEC 27001:2022 Lead Auditor (Information Security Management Systems) Training Course. The course identification number is 2889. Both the partner approval and the course certification are on 3FOLD TRAINING’s Approved Training Partner record, and any provider’s certified courses can be looked up in CQI and IRCA’s own directory of certified courses and approved training partners. The course page carries the schedule and what the course includes. If you would rather ask a person first, use the course enquiry form.