What is an ISMS?

An ISMS — information security management system — is the organized way a company decides what it protects, what could go wrong, and what it does about it, with evidence that all of it actually happens. It is not a piece of software and not a folder of policies: it is a management system, in the same sense as a quality or safety management system — scope, risks, controls, responsibilities, checks and improvement, running as a loop. It matters mostly because of ISO 27001: the ISMS is the thing ISO 27001 certifies. When a customer asks "are you ISO 27001 certified?", they are asking "has an accredited auditor confirmed your ISMS is real and working?"

What an ISMS actually contains

Strip the jargon and an ISMS is a set of answers, written down and kept current:

• What are we protecting? A defined scope: the systems, data, locations and people the ISMS covers.
• What could go wrong? A risk assessment with a repeatable method, so two assessors would reach comparable results.
• What do we do about each risk? Chosen treatments, mapped to controls — the safeguards you operate.
• Who does what? Named owners for risks, controls and the system itself, with management visibly accountable.
• How do we know it works? Evidence that controls operate, internal audits that check honestly, and management reviews that act on what they find.

Everything else — the Statement of Applicability, the policies, the registers — is the paperwork form of those five answers.

How an ISMS relates to ISO 27001

ISO/IEC 27001 is the international standard that defines what a certifiable ISMS must include. Its clauses 4 through 10 set the management system: context and scope (4), leadership (5), planning and risk assessment (6), support and competence (7), operation (8), performance evaluation (9), improvement (10). Its Annex A lists 93 reference controls in four themes — organizational, people, physical, technological — which you select from, justify, or exclude via the Statement of Applicability. Our guide to how ISO 27002 differs from ISO 27001 covers where the implementation guidance for those controls lives.

You can run an ISMS without ever certifying. Most companies build one because a customer or regulator wants the certificate — which is fine; the discipline is the same.

The core components

• Scope — the boundary. Too wide and the project drowns; too narrow and auditors (and customers) notice what is excluded.
• Risk assessment — the engine. Identify risks to confidentiality, integrity and availability inside the scope, rate them with defined criteria, and name an owner per risk.
• Controls — the response. Selected from Annex A and anywhere else, each mapped to the risks it treats, each with an owner and evidence.
• Statement of Applicability — the index. Every Annex A control: applicable or not, why, and its implementation state. Auditors read this first.
• Internal audit — the honesty check. Someone with distance examines whether the system matches reality, before the external auditor does.
• Management review — the loop closure. Leadership looks at audit results, incidents and measurements, and decides changes. Minuted, because unminuted reviews did not happen, as far as an auditor is concerned.

The risk assessment, concretely

Because it is the part teams most often fake: a working risk assessment names an asset or process, a threat to it, the existing safeguards, a likelihood and impact on defined scales, and an owner. "Ransomware — high" is not a risk assessment; "customer database exposed through a compromised admin account; MFA and access reviews in place; likelihood medium, impact high; owner: head of engineering; treatment: restrict admin access further" is. The method matters more than the math — auditors accept simple scales happily, but they test whether two risks were rated by the same logic and whether treatments actually connect to controls that exist.

The other property that separates real ISMSs from paper ones: the risk register moves. People leave, suppliers change, systems ship — each of those events should visibly change a risk, a control or an assessment. A register with the same twelve rows it had at certification is the first thing an experienced auditor notices.

Building one: the practical sequence

1. Fix the scope and get management to own the project — the ISMS dies without a sponsor who signs things.
2. Inventory what is in scope: systems, data, suppliers, people, access.
3. Run the risk assessment and choose treatments.
4. Write the Statement of Applicability and close the control gaps it exposes — policies drafted, controls implemented, evidence flowing.
5. Operate for long enough to have evidence (auditors want records, not intentions).
6. Internal audit, management review, fix what they find.
7. Certification audit: stage 1 (documentation) then stage 2 (does reality match).

Who runs it: the roles that must exist

An ISMS needs surprisingly few roles, but they must be real people, not job titles invented for the audit:

• Top management — approves the scope and the risk criteria, chairs the management review, and is named in the standard deliberately: clause 5 exists because ISMSs delegated entirely to one enthusiast die when that enthusiast leaves.
• An ISMS owner — often a CISO, a security lead, or in small companies a founder or CTO wearing the hat. Coordinates the loop; does not have to do all the work in it.
• Risk and control owners — the people who actually operate each safeguard. The standard's quiet insistence that owners be named is its most useful discipline: "engineering owns backups" evaporates under audit questions in a way "Maria owns backups" does not.
• An internal auditor with distance — someone not auditing their own work. Small companies solve this with a cross-functional colleague, a fractional consultant, or a peer swap; what matters is independence from the thing audited, not a certification.

None of this requires headcount. It requires names against responsibilities, which is also the first thing that falls over in tool-less programs.

How long it takes and what it costs

For a small, cloud-native company: typically three to six months from start to audit-ready, then the certification audit itself. Costs split three ways: the certification body (commonly a few thousand to €15k depending on size and auditor days), any tooling, and — the dominant cost — internal time. Consultants can compress the calendar but add five figures; whether you need one is a real question, not a given.

After certification the cost does not go to zero: the certificate runs a three-year cycle — surveillance audits in years one and two, recertification in year three — and each surveillance expects the loop to have kept turning: internal audits done, management reviews minuted, incidents handled, controls still evidenced. Budget the ISMS as an operating cost with an annual audit line, not as a project with an end date.

The single biggest driver of both time and cost is who does the drafting and evidence-gathering work: a team doing it by hand in documents and spreadsheets, or a platform doing the heavy lifting. This is exactly the work ZeroRisk's agent automates — it pre-fills the assessment from what it can already observe, drafts the missing policies and controls, and keeps evidence current, with a named person signing every verdict.

Common mistakes

• Writing policies first. Policies are outputs of the risk assessment, not the starting point. Template policies that do not match reality are audit findings waiting to happen.
• A scope drawn to hide problems. Excluding the messy system everyone actually uses fools nobody, least of all a stage-2 auditor.
• Treating it as a one-time project. The certificate has a three-year cycle with surveillance audits; an ISMS that froze the day after certification fails its first surveillance.
• Evidence archaeology. Reconstructing a year of records the month before the audit is painful and visible. Evidence should be a byproduct of operating, not a deliverable.
• No real management review. A calendar invite is not a management system. Decisions, minuted.

Do you need software for it?

Honestly: no — a disciplined team can run an ISMS in documents and spreadsheets, and small organizations have certified that way for years. The trade is time and fragility: manual evidence collection, version-controlled-by-hope policies, and an audit season that eats a quarter. Software earns its keep when it removes the drafting and collection work rather than just storing files — which is the difference between a document repository and an agent that does the homework. If you want to see where your current state lands against ISO 27001 before deciding anything, the free gap report answers that in about ten minutes.