What Is an ISMS? The Thing ISO 27001 Actually Certifies

An information security management system, an ISMS, is the thing an ISO 27001 certificate is issued against. Our glossary puts it in one sentence: "An information security management system is the set of policies, processes, roles, objectives and controls an organization manages as a single system to direct and control its information security risk." The standard's own introduction describes what that system is for: it "preserves the confidentiality, integrity and availability of information by applying a risk management process and gives confidence to interested parties that risks are adequately managed." The contrarian point, and the reason this page exists, is that the ISMS is not the list of security controls. ISO/IEC 27001:2022 calls Annex A "a list of possible information security controls" and says organizations "can design controls as required, or identify them from any source." What cannot be left out is clauses 4 to 10, the management system itself: "Excluding any of the requirements specified in Clauses 4 to 10 is not acceptable when an organization claims conformity to this document."

That distinction decides almost everything downstream. It is why a company can have strong engineering and still fail to certify, why the certificate names a scope rather than a company, and why the incremental work between a SOC 2 attestation and an ISO 27001 certificate is documentation of a system rather than new technical controls. The rest of this article works through what the standard requires the system to contain, how the scope is set, what an ISMS is not, and what a certificate does and does not tell the person reading it.

A word on sources. iso.org blocked every fetch during the writing of this piece, so the quotations come from the standards' own front pages as republished in a distributor's preview PDF: ISO/IEC 27001:2022 clauses 1 to 6.3, plus ISO/IEC 27006-1:2024 (the standard certification bodies for ISMS are accredited against) and ISO/IEC 17021-1:2015 (the standard for all management system certification bodies). Where a clause below is named only by its title, that is because only its title was in the fetched text, and we say so rather than describing it from memory.

Key takeaways

• An ISMS is a management system, in ISO's Annex SL sense: "set of interrelated or interacting elements of an organization to establish policies and objectives, and processes to achieve those objectives." The information security controls sit inside it; they are not it.
• ISO/IEC 27001:2022 certifies conformity to clauses 4 to 10, none of which may be excluded. Annex A is a reference list checked for omissions, not a checklist implemented in full.
• The scope is yours to determine under clause 4.3, it must be documented, and the certificate is a statement about the ISMS within that scope. ISO certifies the system, not the company and not a product.
• The required documented information starts with scope, policy, the risk assessment and risk treatment processes and the objectives; everything else in the clause map is built on those.
• A certificate is evidence of an audited system, and audits sample. ISO/IEC 17021-1 says in plain words that an audit "is not a guarantee of 100 % conformity with requirements."

The definition, and why "management system" is the load-bearing phrase

ISO/IEC 27001:2022 does not define the ISMS in its own clause 3; it says "the terms and definitions given in ISO/IEC 27000 apply." The definition that does the work is the generic one every ISO management system standard shares. ISO/IEC 27006-1:2024, the ISMS certification-body standard, restates it from ISO 9000:2015: a management system is a "set of interrelated or interacting elements of an organization to establish policies and objectives, and processes to achieve those objectives." Its note adds that those elements "establish the organization's structure, roles and responsibilities, planning, operation, policies, practices, rules, beliefs, objectives and processes to achieve those objectives."

Read that list again and notice what is absent: firewalls, encryption, access reviews. Those are controls, and in ISO's vocabulary a control is "measure that maintains and/or modifies risk" (ISO/IEC 27006-1:2024 clause 3.2, sourced to ISO/IEC 27002:2022). A control is something the system selects, operates and improves. The system is the apparatus for deciding which controls, running them, checking they work and fixing them when they do not. An organization with ninety implemented controls and no process for choosing, owning, auditing or reviewing them has controls and no ISMS, and a certification auditor will say so.

ISO/IEC 27001:2022 makes the same point structurally. Its introduction says the standard "applies the high-level structure, identical sub-clause titles, identical text, common terms, and core definitions defined in Annex SL of ISO/IEC Directives, Part 1," which is what lets one management system meet two or more standards at once. The security-specific content is in the requirements; the shape is common to ISO 9001, ISO 14001 and the rest.

The clause map: what the system has to contain

The standard "specifies the requirements for establishing, implementing, maintaining and continually improving an information security management system within the context of the organization," and its contents page lays those requirements out in seven numbered clauses. The table gives each clause with what the fetched text says it asks for; for clauses 7 to 10 only the sub-clause titles were in the fetched pages, so the right-hand column stays at the level of those titles.

Two things stand out. First, risk appears three times: it is planned in clause 6, performed in clause 8, and fed back through clause 9. The risk assessment is not a project deliverable; it is a running process, and clause 6.1.2 b requires that "repeated information security risk assessments produce consistent, valid and comparable results," which is a requirement about the second assessment, not the first. Second, the words "the order in which requirements are presented in this document does not reflect their importance or imply the order in which they are to be implemented" are in the standard's introduction. Nobody has to build clause 4 before clause 7. What they do have to do is build all of them.

The pieces the fetched text names as documented information are the scope (4.3), the policy (5.2 e), the risk assessment process (6.1.2), the risk treatment process (6.1.3) and the objectives (6.2 g). Those five are the skeleton; if any is missing there is no system to audit, which is why they are the first things a Stage 1 auditor reads. What each audit stage actually checks is owned by our piece on Stage 1 versus Stage 2, and we will not restate it here.

Scope: the decision that writes the certificate

Clause 4.3 is short and it is the highest-leverage paragraph in the standard. "The organization shall determine the boundaries and applicability of the information security management system to establish its scope." In doing so it must consider the external and internal issues from 4.1, the requirements of interested parties from 4.2, and "interfaces and dependencies between activities performed by the organization, and those that are performed by other organizations." Then: "The scope shall be available as documented information."

Three consequences follow.

The scope can be smaller than the company. ISO/IEC 27006-1:2024 carries the note that "the scope of a management system can include the whole of the organization, specific and identified functions of the organization, specific and identified sections of the organization, or one or more functions across a group of organizations." A certificate for one product line's ISMS is legitimate. It is also exactly what it says, and a buyer who reads scope statements will notice if the service they are buying sits outside it.

The scope has to account for what other organizations do for you. That third consideration in 4.3, interfaces and dependencies, is where cloud providers, outsourced engineering and managed service providers enter the system. A scope that describes your offices and ignores that production runs on someone else's infrastructure has not done what 4.3 asks. The certification-body side takes this seriously: ISO/IEC 27006-1:2024 requires the people who make certification decisions to have the knowledge to verify "the continuing validity of the identification of interfaces and dependencies and the associated risks."

The scope drives the requirements you are held to. Clause 4.2's note says the requirements of interested parties "can include legal and regulatory requirements and contractual obligations." A scope that includes a service sold under a contract with security clauses brings that contract into the ISMS as a requirement, and a nonconformity can be raised against it. Scope is not only a boundary; it is a list of promises.

How to write a scope statement that survives audit, including the exclusion patterns auditors challenge, is covered in our Statement of Applicability guide, because the two documents fail together.

What an ISMS is not

It is not the Annex A control set. Clause 6.1.3 has you "determine all controls that are necessary to implement the information security risk treatment option(s) chosen," then "compare the controls determined in 6.1.3 b) above with those in Annex A and verify that no necessary controls have been omitted." Annex A is a completeness check on a decision you made from your risks. Starting from Annex A and working backwards produces a Statement of Applicability whose justifications do not trace to anything, which is the most common structural finding in the whole document set.

It is not a security program with a certificate stapled on. A good security program has most of the same content. What makes it an ISMS is the management-system machinery: a documented scope, risk criteria that include "the risk acceptance criteria," named risk owners (6.1.2 c 2), an internal audit, a management review, and a nonconformity process. Those are the elements clause 10 and clause 9 name and clause 4.4 requires to interact. A program that has never recorded a nonconformity against itself is not running clause 10, whatever its controls look like.

It is not a SOC 2 prerequisite. SOC 2 is an attestation examination under AICPA criteria that produces an auditor's opinion on your controls; it does not require an ISMS and it does not produce a certificate. The two frameworks cover much of the same control ground, and the practical difference in effort is the management-system documentation this article is about. Which to pursue first, and how they sequence, is owned by our ISO 27001 versus SOC 2 comparison.

It is not something a platform builds for you. Evidence automation is genuinely useful for the control layer. The five management-system deliverables (scope, risk assessment, SoA justifications, internal audit, management review) need a person, and our piece on consultant versus platform draws that line in detail.

What the certificate actually says

Because the object of certification is the ISMS, what a certificate asserts is narrower and more precise than "this company is secure."

ISO/IEC 27006-1:2024 defines a certification document as a "document indicating that a client's information security management system (ISMS) conforms to specified ISMS standards and any supplementary documentation required under the management system." ISO/IEC 17021-1:2015 defines a certified client as an "organization whose management system has been certified," and its introduction says certification "provides independent demonstration that the management system of the organization: a) conforms to specified requirements; b) is capable of consistently achieving its stated policy and objectives; c) is effectively implemented."

So the reader of a certificate learns three things: a management system exists within a stated scope, it conforms to ISO/IEC 27001, and an accredited third party found it to be operating. The reader does not learn that every control worked every day. ISO/IEC 17021-1 is explicit: "Any audit is based on sampling within an organization's management system and therefore is not a guarantee of 100 % conformity with requirements." And responsibility stays where it was: "The certified client, and not the certification body, has the responsibility for consistently achieving the intended results of implementation of the management system standard."

That is not a weakness of the certificate. It is what a management-system certificate is for: assurance that the organization has a working process for finding and fixing its own problems, which is a more durable claim than a point-in-time statement that no problems were found. For the years after the certificate arrives, what the annual audits look at is covered in our surveillance audit guide.

The honest caveat: when an ISMS is more system than you need

We build these, so weigh this accordingly. Clause 4.3 and the introduction both give you permission to be small: the standard says "it is expected that an information security management system implementation will be scaled in accordance with the needs of the organization." A twenty-person company does not need a governance committee and a forty-page policy set. It needs the seven clauses, satisfied at a size that matches it.

The failure we see most is the opposite of under-building. Teams import a template ISMS sized for an enterprise, cannot operate it, and then carry nonconformities against their own documents at Stage 2 because the procedures describe a company that does not exist. If nobody has asked you for the certificate, the right first step is to ask two prospects whether it would change their procurement answer, not to start writing policies. If someone has asked, scope narrowly, write procedures you will actually follow, and let the system grow with the business.

Where Top Floor fits

The part of this work worth paying for is the management-system layer: a scope statement that accounts for your real dependencies, a risk assessment process that produces comparable results the second time, and a clause 9 cadence that keeps running after the project ends. That sits inside our ISO 27001 practice, and for teams with no internal owner it runs as part of compliance as a service. Where the honest gap is that nobody owns security decisions at all, a vCISO is the better purchase than a certification project. The clause 9.2 internal audit has to be independent of whoever built the system, which is why we keep it in audit and assurance rather than bundling it.

Where we are not needed: a company with an experienced security lead, a patient timeline and no hard customer deadline can build this from the standard itself. The expensive mistakes are structural, and they are the ones described above.

How to decide this week

• Write your scope in three sentences without looking at a template: what is in, what is out, and which other organizations you depend on for what is in. If the third sentence is hard, that is the work.
• List the five pieces of documented information named above and check each exists as a document someone can open, not as a plan to write one.
• Name the risk owners. Clause 6.1.2 requires them, and a risk assessment with a methodology but no names is half-built.
• Ask whether your organization has ever recorded a nonconformity against its own ISMS and acted on it. If never, clause 10 is not running yet.
• Decide what the certificate is for. If the answer is a specific customer or market, scope to that and expand later.

Frequently asked questions

Does ISO 27001 certify the company or the ISMS?

The ISMS, within the scope the organization determined under clause 4.3. ISO/IEC 27006-1:2024 defines a certification document as one indicating that a client's information security management system conforms to specified ISMS standards, and ISO/IEC 17021-1:2015 defines a certified client as an organization whose management system has been certified. The scope can be the whole organization, a function, a section, or a function across a group, so the only reliable way to know what a certificate covers is to read its scope statement. A product is not certified either; the management system that governs the product's information security is.

What is an ISMS scope statement?

It is the documented information clause 4.3 requires: a statement of "the boundaries and applicability" of the management system, determined after considering the organization's external and internal issues, the requirements of its interested parties, and the interfaces and dependencies between its own activities and those performed by other organizations. In practice it names the services, locations, teams and systems inside the ISMS, and it has to account for suppliers and providers whose work sits on the boundary. It is the first document an auditor reads and the one that determines what everything else has to cover.

Are the Annex A controls the ISMS?

No. ISO/IEC 27001:2022 describes Annex A as a list of possible information security controls and says organizations can design controls as required or identify them from any source. The requirement is to determine the controls your risk treatment needs, then compare that set against Annex A to verify nothing necessary has been omitted. The ISMS is the management system in clauses 4 to 10, none of which can be excluded when claiming conformity; the controls are what that system selects, operates and improves.

Do we need an ISMS for SOC 2?

No. SOC 2 is an attestation examination against AICPA criteria that results in an auditor's opinion, and it has no requirement for a management system in the ISO sense and no certificate. If you will eventually want both, the control work overlaps heavily and the additional effort for ISO 27001 is mostly the management-system documentation: scope, risk assessment and treatment processes, Statement of Applicability, internal audit and management review. Our comparison of the two frameworks covers which to pursue first and how to sequence them.