Most people meet the term "ISMS" in a sales cycle. A customer asks whether you are ISO 27001 certified, someone opens the standard, and the first page says it specifies requirements for an information security management system. It does not say what one looks like.
The usual guesses are a software product, a folder of policies, or the list of 93 controls at the back of the standard. Each is a piece of it. None of them is the thing an auditor certifies.
This article explains what an ISMS is in plain terms: what it is made of, what ISO/IEC 27001:2022 requires of it, how the controls fit, and what it changes about how a company works.
An ISMS is a way of running security, not a set of controls
A management system is the set of decisions, roles, processes, and records an organization uses to direct an area of its work toward stated goals. Quality management has one in ISO 9001. Environmental management has one in ISO 14001. An ISMS is the same idea applied to information security.
The useful distinction is between controls and the system that manages them. A control is a specific safeguard: multi-factor authentication, an access review, an encrypted backup. The management system decides which controls you need, who owns them, how you know they work, and what happens when they do not.
The standard's introduction describes the ISMS as preserving the confidentiality, integrity, and availability of information by applying a risk management process. That phrase carries most of the weight. You choose controls because of risks you have identified, not because they appear on a list.
Two companies with identical controls can have very different ISMSs. One picked its controls from a template and has never revisited them. The other can show why each control exists, which risk it addresses, and how it checks the control still works. Only the second has an ISMS in the sense the standard means.
What the standard requires, clause by clause
ISO/IEC 27001:2022 follows the harmonized structure ISO uses for its management system standards. The requirements sit in clauses 4 to 10. Clauses 1 to 3 cover scope, normative references, and terms, and contain nothing you implement.
| Clause | What it requires, in short | What it typically produces |
|---|---|---|
| 4 Context of the organization | Understand internal and external issues, interested parties and their requirements; define the scope | Context analysis, interested parties register, scope statement |
| 5 Leadership | Top management commitment, an information security policy, assigned roles and authorities | The policy, role definitions, records of management involvement |
| 6 Planning | Risk assessment and treatment, security objectives, planned changes | Risk method, risk register, Statement of Applicability, risk treatment plan, objectives |
| 7 Support | Resources, competence, awareness, communication, documented information | Training and competence records, document control |
| 8 Operation | Run and control the processes, repeat risk assessment and treatment, control external providers | Operational records, current risk assessment results |
| 9 Performance evaluation | Monitor and measure, run internal audits, hold management reviews | Metrics, internal audit reports, management review records |
| 10 Improvement | Continual improvement, nonconformity and corrective action | Corrective action records |
The standard states that excluding any requirement in clauses 4 to 10 is not acceptable when an organization claims conformity. You can decide that some Annex A controls do not apply to you. You cannot decide to skip the internal audit.
People often describe this as a plan, do, check, act cycle. The current edition does not name that model, but the shape is visible: clauses 4 to 6 plan, clauses 7 and 8 do, clause 9 checks, and clause 10 acts.
Where Annex A fits
Annex A is a list of 93 information security controls in four themes: organizational, people, physical, and technological. Implementation guidance for each control sits in a separate standard, ISO/IEC 27002:2022.
Annex A is not the ISMS, and it is not a checklist you must complete. Clause 6.1.3 asks you to determine the controls your risk treatment needs, from any source, and then compare them with Annex A to confirm nothing necessary was overlooked. The record of that comparison is the Statement of Applicability: every Annex A control, whether it is included, why, and whether it is implemented.
Most organizations end up with most Annex A controls included. The point is the reasoning behind each line. An auditor will ask why a control is excluded, and "it seemed like a lot of work" is not a justification.
What an ISMS is made of
Strip away the vocabulary and an ISMS comes down to a short list of things you can point at.
A defined scope. Which parts of the organization, which locations, which systems, and which services the ISMS covers.
Accountable people. Top management that sets direction and reviews results, and named owners for risks and controls.
A risk process. A documented method for identifying, analyzing, and evaluating information security risks, applied consistently and repeated at planned intervals.
Chosen controls. The safeguards selected to treat those risks, recorded in the Statement of Applicability.
Documented information. The policies, procedures, and records the standard requires, plus whatever else you decide you need, kept under version control.
Checking mechanisms. Measurement, internal audit, and management review, so the organization finds its own problems.
A way to fix things. A corrective action process that addresses causes, not only symptoms.
None of this needs special software. A small company can run a conforming ISMS on a document repository, a ticketing system, and a disciplined calendar. Tools help with the record keeping, which is where most of the effort goes.
What it changes in practice
The real cost of an ISMS is rarely the controls. Most companies selling to other businesses already run many of them. The cost is the management layer around them, and it shows up in four places.
Decisions get written down
When a risk is accepted, someone with the authority to accept it does so on the record. When a control is excluded, the reason is in the Statement of Applicability. This feels bureaucratic until a customer or an auditor asks, and then it is the only answer that holds.
Leadership has a defined job
Clauses 5 and 9.3 put specific obligations on top management, including reviewing the ISMS at planned intervals. Security stops being something the engineering team does on its own. For a small company this is often the hardest change, and it is one auditors probe directly.
The system checks itself
Internal audit and management review exist so the organization finds gaps before a certification body does. A first internal audit that finds nothing usually means the audit was too shallow, not that the ISMS is perfect.
Change is planned
Clause 6.3, added in the 2022 edition, requires changes to the ISMS to be carried out in a planned manner. A reorganization, a new product line, or a new hosting region is a prompt to revisit scope and risk, not something the ISMS discovers a year later.
Certification is an outside opinion on the system
ISO writes the standard but does not certify anyone. Certification bodies do, and the credible ones are accredited by a national accreditation body. The certification body examines whether your ISMS conforms to the standard and is operating, over a three-year cycle: an initial audit in two stages, surveillance audits in the following years, then recertification.
You can run an ISMS without seeking certification, and some organizations do so to structure their program before a customer demands the certificate. What you cannot do is claim certification because the documents exist. An ISMS that conforms on paper but has never been through a risk assessment, an internal audit, and a management review is not ready for an auditor.
If you already have SOC 2, much of the control work carries over. The SOC 2 trust services criteria state outcomes your controls must meet. ISO 27001 is more prescriptive about the system around the controls: a defined risk method, an internal audit program, and a management review. The ISO 27001 framework page summarizes the standard, and the glossary defines the terms you will meet in audit reports. If you also process personal data at scale, ISO 27701 extends the ISMS to privacy.
How TrustLynce helps
TrustLynce maps your controls to ISO 27001 and other frameworks so the same evidence serves each, through compliance automation. The readiness dashboard shows where each clause and control stands, so gaps surface before your auditor finds them.