What Is an ISMS? Information Security Management System Under ISO/IEC 27001, Explained (2026)

Sooner or later, every business hears the same thing from a client, a tender, or a partner: "show us your ISMS." The phrase often causes a moment of panic, though the idea behind it is fairly simple. An ISMS is an information security management system (СУІБ in Ukrainian): not a program, not an antivirus, and not a separate IT department, but a set of processes, rules, and responsible people that keeps the risks to your information under control.

Here is a simple picture. Accounting is responsible for money, a quality system for product consistency, and an ISMS for making sure the company's important data doesn't leak, disappear, or become unavailable at the worst possible moment. Those three things, the confidentiality, integrity, and availability of information, are exactly what it protects. The data itself can be anything: customer personal data, source code, contracts, financial reports, know-how.

Formally, the ISMS is described in the international standard ISO/IEC 27001, and this is the standard a company can be certified against. Below we break down what the system consists of, how the PDCA cycle works, what Annex A controls and the Statement of Applicability are, and who actually needs all of this. And if, after the definition, you want to move straight to the practice of certification, our complete guide to ISO/IEC 27001 walks through the whole path step by step.

People often use "ISMS" and "ISO/IEC 27001" as synonyms, and the confusion is natural. The difference is this: ISO/IEC 27001 is the standard, a list of requirements for what the system should look like. The ISMS is the actual system, built in your company according to those requirements. The standard is like a building code; the ISMS is the specific house constructed to it.

What exactly does the standard require? Not that you buy particular technologies, but that you build a process: define what data you protect, assess the risks to it, and choose measures that fit those risks. That's why 27001 works equally well for a twenty-person IT company and for a large bank. The set of measures differs for each, but the logic is the same. This is why the standard is called technology-neutral: it doesn't say "install this firewall," it says "manage your risks deliberately."

Ukraine has an identical national edition, ДСТУ ISO/IEC 27001:2023, which corresponds to the 2022 international version. Certification against the Ukrainian version is no different in substance from the international one. And one more thing worth clearing up right away: certification is for having a working ISMS, not a handsome binder of documents on a shelf. The auditor checks whether the system actually works. The full path to the certificate is described in detail in our ISMS certification guide.

The most common reason a company suddenly takes up an ISMS is quite down-to-earth: a client or a tender demands it. Large customers, especially in the EU and US, almost always send a security questionnaire, and the question "do you hold an ISO/IEC 27001 certificate" sits near the top. Without it, you either drop out of the shortlist or spend weeks explaining yourself in free form. A certified ISMS closes that question in a single line.

But reducing it all to "a piece of paper for the client" would be a mistake. In my experience, companies get the most value where chaos used to reign. Before an ISMS, security often rests on a single system administrator who "knows it all anyway." What happens when he goes on vacation right in the middle of an incident is something nobody usually thinks about. The system moves that knowledge out of people's heads and into processes: who is responsible for what, how to react to a breach, where the backups are, and whether anyone has ever actually restored them.

There is a third reason too, a purely defensive one. The risk assessment that begins any ISMS often shows management for the first time where the real holes are, and rarely where they expected them. For IT and SaaS companies it's also an argument at the negotiating table: having a system cuts the number of questions from the customer and speeds up closing the contract. And for some industries, managed security is no longer a choice but a legal requirement, which applies to critical infrastructure operators and companies that process personal data at scale.

The core idea of an ISMS is that it isn't a one-off "set it up and forget it" project, but a cycle that keeps turning. Classically it's described in four steps, Plan-Do-Check-Act, shortened to PDCA. The same logic underpins quality systems under ISO 9001, so for many companies it's already familiar.

Let's break it down in plain terms. In the Plan stage you define what you protect and from what: the boundaries of the system, the security policy, then you assess risks and decide which measures to implement. Do is when the plan comes to life: measures go into operation, people are trained, processes start running. Check is regular review: internal audits, incident analysis, and management review of whether everything works as intended. Act is conclusions and corrections: wherever weak spots turn up, the system is adjusted, and the cycle starts again.

Why does this matter as a cycle? Because threats don't stand still. Measures that closed a risk a year ago can be full of holes today: new attacks appear, the company grows, new services are added. PDCA keeps the system from calcifying, because it checks itself against reality every time. Here is how the four steps look in practice.

For the concrete security measures, the standard doesn't leave you facing a blank page. Annex A gathers a ready catalog of controls, proven practices from which you pick the ones you need. In the ISO/IEC 27001:2022 edition this catalog holds 93 controls grouped into four themes. That's noticeably more compact than the 2013 edition, which had 114 controls across 14 sections: some were merged, and 11 new ones were added, including controls for cloud security and threat monitoring.

The four themes are a simple map to get your bearings by, running from management rules to purely technical measures.

The Statement of Applicability, or SoA for short, is the document that pulls your entire ISMS into a single table. The standard requires it directly, in clause 6.1.3, and certification is impossible without it. It's effectively the bridge between the risk assessment and the concrete measures: this is where you can see why you chose some controls and deliberately declined others.

What does the SoA contain? A list of all 93 Annex A controls, and against each one, four things: whether it applies to you, the justification for that decision, whether it's already implemented, and a reference to how. Exclusions have to be explained too. You can't just drop a control because it's inconvenient; you need a reason tied to your context and risks. For example, "the physical server-room control doesn't apply, because all infrastructure sits with a cloud provider" is a valid justification.

Why do I call the SoA the heart of the system? Because it's the first document an auditor asks for, and it shows at a glance how seriously the company approached the job. A formal Statement, where all 93 controls are marked "applicable" without a second thought, is a red flag: it means there was no real risk assessment. A living SoA, by contrast, tells the story of your security briefly and honestly. How to compile one without mistakes is covered in detail in our complete guide to ISO/IEC 27001.

Put it all together, and an ISMS consists of a few building blocks. They follow logically from one another, so the system is a connected structure rather than a set of scattered requirements.

• Scope and context. First you define what goes into the system: which units, services, and data. A small company can cover everything; a large one might start with a critical area.
• Information security policy. A short document in which management states its intentions and sets the rules of the game. This isn't a formality: without support from the top, an ISMS doesn't work.
• Risk assessment and treatment. The core of the whole system. You determine what could go wrong with your data, how likely and serious it is, and what to do about it: accept the risk, reduce it with measures, or transfer it.
• Statement of Applicability. The result of the previous step as a table of chosen controls, the one we already discussed.
• Security measures. The Annex A controls themselves, implemented to fit your risks.
• Internal audit and management review. Regular checks on whether the system is alive, and decisions about improving it.

Notice the pattern? These blocks map onto the PDCA cycle almost one to one: context and risks are Plan, measures are Do, audits are Check, and review and correction are Act. That's why experienced companies don't see an ISMS as separate bureaucracy: if you already run a quality system under ISO 9001, most of the management processes carry over without rework, because clauses 4 to 10 share a common structure across the standards.

The universal answer, "everyone with something to lose," sounds nice but doesn't help much. In practice there are industries where an ISMS is critical, and a simple order of steps for getting started.

First and foremost, IT and SaaS companies, especially those serving clients in the EU and US: for them a certificate is a condition of entry into serious contracts. Next come fintech and everyone who processes personal data at scale, where legal pressure joins the business logic. A separate category is critical infrastructure operators and companies supplying NATO chains, for whom managed security has become a direct requirement. But an ordinary business that simply doesn't want to read its own data on a criminal forum one morning also gains from an ISMS: it provides structure instead of hoping for luck.

Whatever your industry, the entry point is the same: ISO/IEC 27001 certification. First you get security in order in general, assessing risks and building the basic processes. Only later, if needed, do you add specialized layers such as data privacy or business continuity. Don't grab for everything at once: without a base ISMS, the specialized standards hang in the air. The most logical next stop after this article is our complete certification guide, where the path is laid out step by step.

In practice, most companies come to us with the same question: "a client is asking for ISO/IEC 27001, where do we start?" And that's the right first step: not to buy a certificate blindly, but to work out what you actually need. Ekontrol supports ISMS implementation as a single information security practice, so we begin by reviewing your situation: what data you handle, what clients and contracts require, and where your main risk actually lies.

Next comes a preliminary readiness assessment that shows the gap between what you have and what the standard wants. Then the system itself gets built: scope, policy, risk assessment, Statement of Applicability, the necessary controls, and support all the way to the certification audit. If you already run a quality system, adding an ISMS goes faster: a shared clause structure lets most management processes carry over without rework. Our certification preparation services cover the whole path, from the first diagnostic to the audit.

If you're not yet sure where to begin, there are two simple options: read the detailed guide to ISO/IEC 27001 to understand the main standard, or write to the Ekontrol team right away to discuss your situation. We have worked as a Bureau Veritas partner in Ukraine since 2014.