What is an Information Security Management System (ISMS)? A Practical Guide for Industrial and OT Environments

An information security management system (ISMS) is a documented set of policies, procedures, and controls that an organization uses to manage information security risk in a consistent way. The goal is simple. Protect data, keep operations running, and prove to auditors, customers, and regulators that security is not being handled by guesswork.

That definition matches what you’ll read on most websites. Where most articles stop is also where the real questions begin, especially if you work in industrial automation, manufacturing, energy, water, or any sector that runs on operational technology (OT).

An ISMS built for an office is not the same thing as an ISMS that has to cover a refinery, a substation, or a packaging line. The principles overlap. The execution does not. This guide explains what an ISMS actually is, how the well-known ISO/IEC 27001 standard fits in, and why anyone running industrial control systems also needs to look at IEC 62443.

If you only care about IT, the second half of the article still applies to you. If you’re in OT, the first half is the language you’ll need when talking to your IT counterparts.

ISMS in one sentence

An ISMS is the system you put around your security controls. Not the firewall. Not the password policy. The framework that decides why you have a firewall, who maintains the password policy, when it gets reviewed, and how you prove all of that to someone who asks.

The international reference for this is ISO/IEC 27001. It does not tell you which tools to buy. It tells you what needs to exist in your management system: scope, leadership commitment, risk assessment, controls, documentation, internal audit, and continual improvement. Pass an audit against those requirements, and you can get certified.

That’s the standard most companies mean when they say “we have an ISMS.”

Why ISMS matters more than another security tool

Most security failures are not caused by missing technology. They are caused by missing process. A patch that nobody owned. A vendor account left active. A backup that was never tested. An incident report that died in someone’s inbox.

An ISMS forces those gaps into the open. It does this through four habits that the standard requires you to repeat, year after year:

1. Know what you have. Build and maintain an inventory of information assets — data, systems, devices, people, third parties.
2. Know what can go wrong. Run a risk assessment that ties threats and vulnerabilities back to those assets.
3. Decide what to do about it. Choose controls, accept the risk, transfer it, or avoid it. Document the decision.
4. Check yourself. Audit, measure, improve. Every cycle.

This is the Plan-Do-Check-Act loop that sits at the heart of every modern management system standard, including ISO 9001 for quality, ISO 14001 for environment, and ISO 27001 for security. If your organization already runs one of these, an ISMS will feel familiar.

What’s actually inside an ISMS

A typical ISMS has the following building blocks. The names vary by industry, but the parts are the same.

Scope statement. A short document that says what is in and out. “All systems supporting customer order processing at our Casablanca and Tangier offices” is a scope. “Everything” is not.

Information security policy. The top-level statement signed by management. One or two pages. It commits the company to securing information and complying with applicable laws.

Risk assessment methodology and register. How you score risk, and the live list of risks you’ve identified.

Statement of Applicability (SoA). A list of every control from ISO/IEC 27001 Annex A, with a yes/no on whether you’ve implemented it and why.

Controls and procedures. The actual day-to-day documents. Access control, change management, backup procedures, incident response plans, supplier security clauses, and so on.

Records. Audit logs, training attendance, incident reports, management review minutes, internal audit results. Auditors love records.

Continual improvement plan. What you’re going to fix next cycle. Nonconformities found in audits go here.

The size of these documents depends entirely on the size and complexity of the organization. A 30-person SaaS company might have 40 pages. A multinational manufacturer might have hundreds.

What are ISO/IEC 27001 Annex A controls?

Annex A is the control catalogue at the back of the ISO/IEC 27001 standard. It lists the security measures you can pick from when building your ISMS. The 2022 revision — the current version — contains 93 controls, grouped into four themes:

• Organizational controls (37 controls, A.5): policies, roles and responsibilities, supplier and cloud relationships, threat intelligence, incident management procedures.
• People controls (8 controls, A.6): screening, security awareness training, disciplinary process, remote working, confidentiality agreements.
• Physical controls (14 controls, A.7): entry controls, secure areas, equipment protection, clear desk and clear screen, physical security monitoring.
• Technological controls (34 controls, A.8): the bulk of what most people picture as “security.” This is where the day-to-day tooling lives.

A few of the most-asked-about technological controls in plain terms:

• Access control (A.5.15, A.8.2, A.8.3): who can sign in, what they can do once they’re in, and how privileged accounts (admins, engineers, service accounts) are kept on a shorter leash than everyone else.
• Logging and monitoring (A.8.15, A.8.16): keeping a record of what happened, and watching for activity that looks wrong. Without logging, you cannot investigate an incident, prove what happened, or meet most regulator requirements.
• Supplier security (A.5.19 through A.5.23): managing the security risk that comes from vendors, integrators, and cloud providers. This is the section most companies underestimate, and the one auditors increasingly drill into.
• Cryptography (A.8.24): encryption of data at rest and in transit, key management, and the policies around when each is required.
• Backup (A.8.13): the existence, scope, and tested restoration of backups. Untested backups are a leading cause of bad days during ransomware incidents.
• Vulnerability and patch management (A.8.8): finding weaknesses in your systems and fixing them on a defined timeline before someone else finds them first.

You’re not required to implement every Annex A control. You’re required to evaluate every one of them, then justify your choices in your Statement of Applicability. If you exclude A.6.7 (remote working) because nobody works remotely, that’s fine — write it down. If you include A.8.24 (cryptography), document how and where it applies.

A practical note for OT: many Annex A controls were written with IT systems in mind and need careful adaptation for industrial environments. Patch management on a PLC, antivirus on an HMI, and key management on a field device all have constraints that the generic control description doesn’t capture. This is exactly where IEC 62443 picks up the thread.

The CIA triad — and why OT teams sometimes flip it

Information security textbooks talk about three properties:

• Confidentiality — only the right people can see the data
• Integrity — the data has not been altered without authorization
• Availability — the data and systems are there when needed

In IT, the order above is usually the priority. A leaked customer database is a bigger problem than a website that’s down for an hour.

In OT, the priority often flips. Availability comes first. A control system that won’t talk to a turbine, a pump, or a robot is not just an outage. It can be a safety incident. Then integrity, because a tampered setpoint can be catastrophic. Confidentiality is usually last, because the data inside a control loop is rarely the prize attackers are after.

This single change in priorities is the reason an IT-focused ISMS doesn’t drop cleanly onto a plant floor. The risk calculus is different. The controls are different. The acceptable level of disruption during a security action is different.

Where ISO/IEC 27001 stops and IEC 62443 starts

ISO/IEC 27001 was written for information systems. It treats data as the thing being protected.

In an industrial environment, what’s being protected is also a physical process. A water treatment dosing system. A high-voltage relay. A safety instrumented system on a chemical reactor. The consequences of a security failure include leaks, explosions, blackouts, and injuries — not just data loss.

This is the gap that IEC 62443 was built to fill. IEC 62443 is a family of standards for the cybersecurity of Industrial Automation and Control Systems (IACS). Part IEC 62443-2-1 specifically defines what’s called a Cyber Security Management System (CSMS), which is basically an ISMS shaped for industrial reality.

The standard’s own introduction is direct about this relationship. ISO/IEC 27001 describes a management system for business and IT systems. Much of that content applies to IACS as well. But IACS has constraints — continuous operation, real-time response, safety implications — that the general standard does not address. IEC 62443-2-1 builds on ISO/IEC 27001 and adds what’s missing.

The ISA Global Cybersecurity Alliance position is even clearer. IEC 62443 does not require you to have an ISMS. But if you do have one based on ISO/IEC 27001, your OT security program should be coordinated with it. The two are designed to work together.

A short way to remember it:

	ISO/IEC 27001 (ISMS)	IEC 62443 (CSMS for IACS)
Primary asset	Information / data	Physical process and the systems controlling it
Priority order	Confidentiality, Integrity, Availability	Availability, Integrity, Confidentiality
Architecture model	Generic enterprise networks	Zones and conduits
Stakeholders	The organization	Asset owners, integrators, product suppliers
Certification	Organizational	Products, systems, and processes
Lifecycle focus	Continuous business operations	Plant assets that run for 20+ years

A mature industrial company runs both. ISO/IEC 27001 governs the enterprise-wide information security program. IEC 62443 governs how that program reaches into the control room.

The seven Foundational Requirements of IEC 62443

If you’re building an ISMS that needs to cover OT, this is the technical anchor you can’t skip. IEC 62443-3-3 defines seven Foundational Requirements (FRs). Every security control in an industrial system can be mapped back to one of them.

1. Identification and Authentication Control (IAC). Who or what is connecting? Humans, software processes, devices — all must be identified and authenticated before being granted access.
2. Use Control (UC). What is this authenticated entity allowed to do? This covers privileges, wireless use, portable devices, session locks, and audit logging.
3. System Integrity (SI). Has the system been tampered with? Covers protection against malicious code, input validation, software integrity, and protection of stored information.
4. Data Confidentiality (DC). Is the information in transit and at rest protected from unauthorized disclosure? Less central in OT than in IT, but still required.
5. Restricted Data Flow (RDF). Network segmentation. This is the zones-and-conduits model — drawing logical and physical boundaries around critical functions so that an intrusion in one zone cannot easily spread.
6. Timely Response to Events (TRE). Detection, logging, alerting, and response. When something goes wrong, the system must let someone know fast enough to act.
7. Resource Availability (RA). Protection against denial of service. In OT, this includes resistance to component faults, backup and restoration of services, and emergency power.

If your enterprise ISMS already documents access control, change management, logging, and incident response for IT, you have IT-side answers to FRs 1, 2, 3, 6, and 7. What you’re usually missing for OT is the engineering layer — the segmentation, the device-level authentication, the safety-aware response procedures. That’s where IEC 62443 earns its place.

Who actually needs an ISMS

The short answer: any organization that holds information someone else cares about. The longer answer breaks down like this.

You probably need an ISMS if:

• Your customers ask for ISO 27001 or SOC 2 reports in your sales process
• You are bound by GDPR, HIPAA, PCI DSS, NIS2, the Saudi NCA ECC, the Moroccan DGSSI directives, or similar regulations
• You handle critical infrastructure (energy, water, transport, health, finance)
• You manufacture industrial products that ship into regulated supply chains
• You’ve had a security incident and the board wants to be sure it doesn’t happen again

You probably need an OT-aware ISMS (ISO 27001 plus IEC 62443) if:

• Your operations include SCADA, PLCs, DCS, RTUs, HMIs, or any safety instrumented systems
• Cyber events at your facility could lead to a Health, Safety, or Environmental (HSE) impact
• Your customers in industries like automotive, pharma, aerospace, or energy require IEC 62443 conformance from their suppliers
• You operate in a sector where the convergence of IT and OT networks has accelerated in the last few years, which is now most of them

If you fall into both categories, you don’t run two separate programs. You run one program with two technical scopes underneath it.

How an ISMS is actually built — a working roadmap

The exact sequence depends on the organization, but a workable order looks like this. None of it is fast. A first ISO/IEC 27001 certification typically takes 6 to 18 months from kickoff to audit, sometimes longer when OT is in scope.

Step 1. Get leadership commitment. Without a signed mandate from the top, an ISMS becomes a side project that dies during the next budget cycle. Senior leaders need to understand the risk, fund the work, and stay informed.

Step 2. Define the scope. Decide what’s in. Be specific. The classic mistake is scoping too broadly on day one, then drowning in documentation. Start with what you can defend, and expand later.

Step 3. Build the asset inventory. Hardware, software, data, locations, third parties. For OT, walk the plant. Don’t rely on what was true three years ago. Many industrial sites discover assets nobody had documented.

Step 4. Run the risk assessment. Identify threats, identify vulnerabilities, score the risk to each asset. For OT assets, score with HSE consequences in mind, not just financial.

Step 5. Treat the risks. For each significant risk, decide: mitigate (apply a control), transfer (insurance, contract clauses), avoid (stop doing the risky activity), or accept (document why). Build the Statement of Applicability from Annex A controls. For OT, layer IEC 62443 controls on top, organized around the seven FRs.

Step 6. Apply zones and conduits to the OT environment. Segment the control network from the corporate network. Segment safety systems from process control. Define what data can cross each conduit, and what protections apply. This is where most legacy industrial networks need the most work.

Step 7. Write the documentation. Policies, procedures, work instructions. Keep them short and usable. Documentation that nobody reads is worse than no documentation, because it gives a false sense of security.

Step 8. Implement and train. Roll out the controls. Train the people who have to follow them. Security awareness training is not optional — most breaches still start with a human being clicking something.

Step 9. Monitor and audit. Internal audit at least once a year. Track metrics. Investigate every incident. Feed everything back into the risk register.

Step 10. External certification audit (optional but common). A certification body sends auditors to verify the ISMS in a Stage 1 (documentation review) and Stage 2 (implementation audit). Pass both, and you get certified for three years, with annual surveillance audits.

Step 11. Improve. Findings from audits, incidents, and changes in the business all feed the next cycle. The ISMS is never “done.”

Common mistakes that derail an industrial ISMS

These come up in almost every project that crosses the IT/OT line.

Treating OT like IT. Pushing antivirus updates onto a PLC during production. Forcing screen locks on an operator workstation in a control room (creating its own safety risk when an alarm fires and the operator has to log in). Blocking outbound traffic from a vendor service account without telling the vendor. These all happen, and they all cause incidents.

Documenting controls that nobody actually follows. Auditors will spot this. So will attackers.

Ignoring vendors and integrators. A huge share of OT risk lives in your supply chain — the system integrator who builds your line, the OEM who supports your robots, the service provider who comes in once a year. IEC 62443 explicitly defines responsibilities for asset owners, integrators, and product suppliers. Your ISMS needs to do the same.

Underestimating asset lifespan. A control system installed in 2008 might still be running. It probably can’t be patched. It probably uses default credentials. It probably talks to the corporate network through a flat path nobody documented. Compensating controls — segmentation, monitoring, restricted physical access — are the realistic answer, not “upgrade everything.”

Skipping the risk assessment. Buying tools before you’ve assessed risk gives you a security stack that’s expensive and still misses the things that would actually hurt you.

Treating certification as the goal. A certificate proves you had an ISMS the day the auditor visited. It proves nothing about the rest of the year.

What an ISMS costs and how long it takes

There’s no universal answer, but rough planning numbers for ISO/IEC 27001 implementation in a medium-sized organization (around 100 to 500 employees):

• Time: 6 to 12 months for a first certification when IT-only. Add another 6 months when OT is in scope and zones-and-conduits design is part of the project.
• Internal effort: A part-time project manager, a security lead, and contributions from IT, OT engineering, HR, legal, and operations. Plan for the equivalent of one to two full-time people for the duration.
• External cost: Certification body fees for a small organization run from a few thousand euros for a small scope to tens of thousands for a large multi-site scope. Add consulting if you don’t have the skills in-house — that’s usually the larger line item.
• Ongoing cost: Annual surveillance audits, internal audit time, training, and tooling. Budget at least 20 to 30 percent of the initial cost as a yearly running cost.

Plan honestly. Projects that get sold on optimistic timelines tend to produce shallow ISMSs that don’t survive the first real incident.

ISMS, ISO 27001, and IEC 62443 — frequently asked questions

The bottom line

An ISMS is a management system for security risk. ISO/IEC 27001 is the standard that defines what it has to contain. For most organizations, that’s enough.

For organizations that run industrial automation and control systems, the standard ISMS leaves a gap — the gap between protecting data and protecting physical processes that can hurt people if they go wrong. IEC 62443 fills that gap. It does not replace your ISMS. It extends it.

Build the ISMS first. Get leadership behind it. Scope it honestly. Then, if your operations include OT, layer IEC 62443 on top. The two standards were designed to coexist, and the organizations that get this right end up with a single coherent security program — one that the IT team and the plant team can both stand behind.

That’s what good security management actually looks like. Not a binder on a shelf. A system that runs every day, gets tested when something breaks, and gets a little better each year.