Building an ISMS: The Complete Guide for Companies with 50 to 500 Employees

TL;DR

An ISMS is not a one-time project but a living management process following the PDCA cycle (Plan-Do-Check-Act).
Without visible support from management, every ISMS fails — budget, resources, and clear communication are mandatory.
The nine steps include: management commitment, scope, roles, risk assessment, SoA, measures, training, audit, and continuous improvement.
A company with 100 employees can build a certification-ready ISMS in 9 to 12 months.
The most common pitfalls: scope too large, missing responsibilities, and documentation without lived practice.

What Is an ISMS and Why Do You Need One?

An information security management system (ISMS) is far more than a collection of policies in a folder. It is a systematic approach to permanently protecting the confidentiality, integrity, and availability of your information. The international standard ISO 27001 defines the requirements and has established itself as the global benchmark.

Why should a company with 50 to 500 employees concern itself with this? The reasons are tangible. Customers and business partners increasingly demand proof of information security. Cyberattacks hit mid-market companies just as hard as large corporations — often harder, because reserves are smaller. Regulations like NIS2 or industry-specific requirements (TISAX, critical infrastructure) make an ISMS mandatory in many cases. And not least: A well-designed ISMS saves money in the long run because security incidents become less frequent and the response to them works faster.

The crucial point is that an ISMS is not purely an IT topic. It affects processes, people, physical security, and organisation. This is precisely why it requires a structured approach that goes beyond merely installing firewalls.

The PDCA Logic as a Guiding Thread

The entire ISMS follows the PDCA cycle — the cycle of Plan, Do, Check, and Act. This model originally comes from quality management and is excellently suited for information security because it builds continuous improvement into the system's DNA.

Plan means creating the foundations: defining scope, assessing risks, planning measures. Do means implementing these measures and embedding them in day-to-day operations. Check stands for regular review through audits, metrics, and management reviews. And Act means drawing conclusions from the findings and evolving the system.

This cycle does not run once and is then done. It continues turning and ensures that your ISMS grows with the company and adapts to new threats. The following nine steps are oriented to this logic and guide you through the complete setup.

Step 1: Secure Management Support

Without management, nothing works. This is not a platitude but one of the hardest lessons companies learn during ISMS implementation. ISO 27001 explicitly requires top management commitment in Chapter 5 — not as a signature on a document, but as active, visible support.

What does this mean specifically for a company with around 100 employees? First, management must provide a budget. Plan realistically with a half to full FTE for the Information Security Officer (ISO) and a project budget for tools, external consulting, and training. For a company of this size, we are talking about EUR 30,000 to 80,000 in the first year, depending on the starting point and certification ambitions.

Second, management must communicate the ISMS internally. If the workforce gets the impression that information security is just an IT department hobby, acceptance will be minimal. A clear statement from the top that information security is a strategic priority fundamentally changes the dynamic.

Third, management needs an information security policy that they personally sign and publish. This document describes in one to two pages the security objectives, the commitment to continuous improvement, and the fundamental responsibility of all employees.

Practical tip: Prepare a compact decision paper for management that makes the business case clear. Show which customers expect an ISMS, which regulatory requirements exist, and what a security incident would cost the company. Executives think in risks and opportunities, not in control catalogues.

Step 2: Define the Scope

The scope determines which parts of your company the ISMS covers. Here, the course is set early, and an incorrect scope is one of the most common reasons for failed ISMS projects.

For a mid-market company, it is generally recommended to start with the entire company as the scope, provided it is limited to a few locations and a manageable organisational structure. The alternative of including only individual departments or processes sounds tempting but leads to delineation problems. Where does the IT department end and where does sales begin if both use the same CRM?

The scope must be documented and consider the following aspects: internal and external issues relevant to the ISMS (e.g. industry, regulatory environment, market requirements), the requirements of interested parties (customers, regulators, employees, suppliers), and the interfaces and dependencies with areas that may lie outside the scope.

An example: A software company with 100 employees spread across two offices and with remote work defines its scope as "Development, operation, and distribution of the SaaS platform XY including all supporting processes at the Munich and Berlin locations and in remote operations." This is specific, traceable, and leaves no room for interpretation.

Step 3: Staff the Roles — ISO, Risk Owners, and Asset Owners

An ISMS only works when it is clear who is responsible for what. The three most important roles are the Information Security Officer, risk owners, and asset owners.

The Information Security Officer (ISO) is the central figure. They coordinate the entire ISMS build, maintain documentation, prepare audits, and serve as the contact point for all information security questions. In a company with 100 employees, this can be a dedicated position or a role someone fills with 50 to 70 percent of their working time. It is important that the ISO is not simultaneously the IT manager, because they must also be able to critically review IT. If this is not feasible from a staffing perspective, there needs to be at least a clear role separation and external support for audits.

Risk owners are the people responsible for specific risks who decide on risk treatment. These are typically department heads or process owners. The sales director, for example, is the risk owner for risks involving customer data in the CRM; the development lead for risks in software development. Risk owners must know their risks, support the measures, and regularly assess residual risks.

Asset owners manage the specific information assets of the company. An asset can be a server, a database, a business process, or a paper document. The asset owner knows what data is on the system, who needs access, and how critical a failure would be. In a 100-person company, many asset owner roles overlap with risk owner roles, which is perfectly fine as long as it is documented.

Create a RACI matrix that clarifies responsibilities for each area: Who is Responsible, who is Accountable, who is Consulted, and who is Informed?

Step 4: Conduct the Risk Assessment

The risk assessment is the heart of your ISMS. Here you identify what can go wrong, how likely it is, and what the impact would be. ISO 27001 gives you freedom in methodology, but the process must be repeatable, traceable, and documented.

First, you need an asset inventory. List all information assets that are important to your company: customer data, source code, production plans, employee data, financial data, IT systems, network components, physical locations. For a 100-employee company, this quickly results in a list of 80 to 150 assets.

Then assess the assets in terms of confidentiality, integrity, and availability. A simple three-level scale (low, medium, high) is sufficient to start. The customer database probably has high requirements for confidentiality and availability. The internal phone list probably low.

Next, identify threats and vulnerabilities. What could harm the assets? Ransomware attacks, misconfigurations, employee errors, hardware failures, natural events, social engineering. Which vulnerabilities make these threats more likely? Missing backups, outdated software, no multi-factor authentication, untrained employees.

Then determine the likelihood and impact for each risk scenario. Multiply both to a risk score and set thresholds: Which risk score is acceptable? Which requires action? Which is so high that immediate action is needed?

A pragmatic approach for mid-market companies: Work with a 5x5 matrix (likelihood and impact each from 1 to 5). In ISMS Lite, this matrix is pre-configured and automatically calculates the risk score and residual risk. Risks scoring 12 or above are actively treated; risks scoring 20 or above are highest priority. You define these thresholds in your risk assessment methodology, which must also be documented.

At the end of this step, you have a risk register with all identified risks, their assessment, and a decision on risk treatment. Keep in mind that this risk register is itself among the most sensitive documents of your company, and the question of data sovereignty plays an important role in choosing where to store it. Reduce (implement measure), transfer (e.g. insurance), avoid (cease activity), or accept (consciously bear).

Step 5: Create the Statement of Applicability

The Statement of Applicability (SoA) is one of the most important documents in the ISMS and simultaneously one of the most underestimated. It lists all 93 controls from Annex A of ISO 27001:2022 and documents for each one whether it is applicable or not and why.

The SoA is not a mere checkbox exercise. For each control, you must justify whether and how it is implemented. "Not applicable" is a legitimate statement, but it requires a traceable justification. If you do not develop software, you can exclude controls for secure development. But you should carefully verify whether that is actually true — even macros in Excel sheets or configurations in no-code tools can count as development.

For a typical 100-employee company, approximately 70 to 85 of the 93 controls are relevant. The Statement of Applicability links each control to the risks it addresses and the current implementation status. This makes the SoA a kind of map of your ISMS: At a glance, you can see where you stand and where gaps remain.

Specifically, the SoA contains for each control: the control number and name (e.g. A.8.1 User Endpoint Devices), whether it is applicable (yes/no), the justification for exclusion, the implementation status (fully, partially, planned, not implemented), a reference to the associated policy or evidence, and the reference to the risk it addresses.

Step 6: Implement Policies and Measures

Now comes the real work. Risks are assessed, controls defined in the SoA, and now they must be put into practice. This means: writing policies, implementing technical measures, and establishing organisational processes.

Policies are the documented rulebook of your ISMS. A typical mid-market company needs between 15 and 25 policies. The most important are: information security policy (Step 1), risk assessment policy, access control policy, information classification policy, incident management policy, backup policy, mobile device and remote work policy, supplier management policy, and business continuity policy.

When writing these policies, the principle applies: as short as possible, as long as necessary. Nobody reads a 40-page access control policy. Two to five pages per policy is sufficient in most cases. Write in language that non-technical people can also understand. And ensure the policies are findable and version-controlled — ideally in a central system and not scattered across various SharePoint folders.

Technical measures affect the IT infrastructure: introducing multi-factor authentication, enabling encryption for laptops and mobile devices, implementing network segmentation, establishing a patch management process, implementing and testing the backup concept, setting up logging and monitoring. Prioritise by risk score: Measures for the highest risks come first.

Organisational measures are often harder than technical ones because they involve human behaviour: clean desk policy, visitor regulations, processes for employee onboarding and offboarding (access rights provisioning/deprovisioning), information classification rules, and requirements for secure disposal of data carriers.

Assign a responsible person and a deadline for each measure. ISMS Lite links measures directly to the risks and controls they address and automatically reminds about expiring deadlines. Without both, measures remain permanently in "planned" status.

Step 7: Training and Awareness Programme

You can build the best technical infrastructure, but if your employees click on every phishing link, it all amounts to little. Training and awareness are a mandatory component of ISO 27001 and one of the most effective levers for better security.

Basic training for all employees: Every person in the company must know the basics: What is phishing and how do I recognise it? Why are strong passwords and MFA important? What do I do when I notice a security incident? How do I handle confidential information? How does the clean desk policy work?

This basic training should take place during onboarding and be refreshed at least annually thereafter. In a 100-employee company, a 60 to 90-minute format is sufficient — either as in-person training or as e-learning with a short follow-up test.

Role-specific training goes deeper: The IT department needs training on secure configuration and incident response. Managers must understand what their responsibility as risk owners means. Procurement should know how to assess suppliers in terms of information security.

Ongoing awareness goes beyond individual training sessions. Phishing simulations (monthly or quarterly), brief security tips on the intranet or via email, a clearly communicated reporting channel for suspicious activities, and regular communication of current threats keep the topic present.

Document everything: Who was trained when, what content was delivered, what was the participation rate? You need this evidence for audits and management reviews. A simple training register in spreadsheet format is sufficient.

Step 8: Internal Audit and Management Review

The internal audit is the acid test for your ISMS. Here, the system is systematically examined to determine whether it works, whether policies are followed, and whether there are gaps between documentation and reality.

Internal audits must take place at least annually; better is a rolling audit plan that reviews different areas throughout the year. The auditor must be independent — meaning they may not audit the area they are responsible for. In a 100-employee company, this can be solved internally through cross-audits (the ISO audits IT, the quality manager audits the ISO), or you bring in an external auditor for one to two days per year.

The audit process includes: audit planning (scope, timeline, criteria), execution (interviews, document review, sampling), the audit report with findings, and the action plan for identified deviations. Distinguish between major nonconformities (severe, threaten ISMS effectiveness), minor nonconformities (smaller deficiencies), and improvement opportunities (recommendations without deviation).

The management review takes place at least annually. Management reviews the state of the ISMS together with the ISO and makes strategic decisions. The review has defined inputs: results of internal audits, status of risks and measures, security incidents since the last review, ISMS performance metrics, feedback from employees and stakeholders, changes in the business environment and threat landscape.

The outputs of the management review are concrete decisions: What resources will be provided? Which risks will be reassessed? Which strategic objectives change? These decisions are recorded and serve as input for the next PDCA cycle.

Step 9: Live Continuous Improvement

The last step is not really a final step but a permanent mindset. Continuous improvement (CIP) means systematically using insights from audits, incidents, metrics, and environmental changes to evolve your ISMS.

Specifically, this means: Every nonconformity from an audit receives a root cause analysis. It is not enough to fix the error — you must understand why it occurred and ensure it does not recur. If an employee lost a laptop on a train and the hard drive was not encrypted, the correction is obvious (enable encryption). The root cause analysis goes deeper: Why was encryption not active? Was the policy unclear? Did onboarding fail? Is a technical enforcement mechanism missing?

Define ISMS metrics that show you how well the system is working: number of security incidents per quarter, average response time for incidents, percentage of trained employees, percentage of implemented measures from the risk treatment plan, results of phishing simulations (click rate), and number of open audit findings.

These metrics feed into the management review and show management whether the investment in information security is paying off. Trends matter more than absolute numbers: Is the click rate on phishing simulations declining over the quarters? Are measures being implemented faster than the previous year? Then your ISMS is on the right track.

Realistic Timeline for a Company with 100 Employees

How long does it take to build an ISMS? The honest answer: it depends. But for a typical company with 100 employees, an IT department of three to five people, and no prior ISMS, you can expect the following timeline:

Months 1 to 2 — Lay the foundation: Convince management and secure commitment, appoint the ISO and provide resources, define scope, set up the project plan, create and publish the information security policy.

Months 3 to 4 — Take stock: Create the asset inventory, establish risk assessment methodology, conduct the first risk assessment. Simultaneously: review existing documentation and conduct a gap analysis against ISO 27001.

Months 5 to 7 — Build and document: Create the SoA, write policies (prioritised by risk assessment), plan and implement technical measures, define organisational processes, develop the training concept.

Months 8 to 9 — Embed: First training round for all employees, conduct role-specific training, live the policies in daily operations and adjust, complete technical measures.

Months 10 to 11 — Verify: Conduct internal audit, remediate findings, conduct management review, finalise ISMS documentation.

Month 12 — Optional certification: Engage an external certification body (early, as lead times of 2 to 3 months are common). Complete Stage 1 audit (document review) and Stage 2 audit (on-site assessment).

This timeline assumes the ISO drives the topic with high priority and can dedicate at least 50 percent of their working time to it. With external consulting, the timeline can be shortened by one to two months because experience and templates accelerate the documentation phase. Without dedicated resources, it takes correspondingly longer — 15 to 18 months is then more realistic.

Typical Pitfalls When Building an ISMS

After hundreds of mid-market ISMS projects, the same mistakes crystallise again and again. Know them before they slow you down.

Scope too large at the start. Anyone who wants to secure everything at once will get scattered. Better: Start with a clearly defined area, gain experience, and then expand. This applies especially to companies with multiple international locations or very heterogeneous business areas.

Documentation without lived practice. An ISMS that exists only on paper will not survive an audit. Worse: It does not protect either. Auditors explicitly check whether policies are known to employees and whether they are actually followed. If the access control policy requires that accounts are disabled on the same day an employee leaves, but in practice weeks sometimes pass, that is a major nonconformity.

Missing responsibilities. When risks are not assigned to an owner, nobody feels responsible. The same applies to measures without deadlines and responsible persons. Anything that belongs to nobody stays undone.

Copy-paste policies. Templates are a good starting point, but they must be adapted to your company. An auditor immediately recognises whether a policy came from a template and was never adapted — at the latest when company names, department designations, or system landscapes do not match the company.

IT as a lone wolf. Information security affects the entire company. If only the IT department deals with it, the organisational measures, integration of business units, and ultimately management understanding are missing. Involve HR, procurement, facility management, and the business units from the start.

No follow-up. Defining measures is easy; following up on them requires discipline. Set a fixed rhythm — monthly or quarterly — in which you check the status of all open measures. Without this rhythm, a backlog of measures gradually creeps in that leads to panic just before the audit.

Perfectionism instead of pragmatism. Your ISMS does not need to be perfect on the first pass. It needs to work and complete the PDCA cycle. Improvement comes with each iteration. A good ISMS in six months beats a perfect ISMS that is never finished.

Conclusion: Building an ISMS Is a Marathon, Not a Sprint

Building an ISMS is achievable, even for companies starting from scratch. The key lies in the right sequence, sufficient resources, and the willingness to view information security as an ongoing process rather than a one-time project.

The nine steps in this guide give you a proven roadmap. But the best framework helps little if the tools are not right. Anyone who maintains risk assessments in Excel spreadsheets, manages policies in Word documents, and tracks measures via email spends more time on administration than on actual security work.