Lessons Learned from ISMS Projects: What Always Goes Wrong

TL;DR

Mistake #1: Lack of management support. An ISMS without visible management commitment becomes the ISM's solo project and fails due to a lack of resource allocation.
Mistake #2: The risk assessment is treated as a formality rather than a real management tool. Unrealistic assessments lead to misplaced priorities and useless measures.
Mistake #3: Documentation is written for the auditor, not for the organization. The result: Nobody reads the policies, and practice diverges massively from what's on paper.
Mistake #4: Technology is prioritized over organization. The latest security appliance won't help if employees write passwords on sticky notes and the incident response process doesn't exist.
Mistake #5: Work stops after certification. The ISMS becomes outdated, and at the surveillance audit the company faces the choice between frantic catch-up work and losing the certificate.

Why the same mistakes keep happening

ISMS projects at mid-market companies don't fail because of exotic problems. They fail due to the same mistakes that other organizations have made before them. That's frustrating, because these mistakes are well-known and avoidable. But it's also reassuring, because it means you can benefit from others' experiences.

The following lessons learned don't come from textbooks — they come from practice. They describe situations that occur with remarkable regularity in ISMS projects and give you concrete guidance on how to avoid or identify them early.

Lesson 1: Management commitment is not lip service

What goes wrong: Senior management gives the green light for the ISMS project, allocates a budget, and expects the Information Security Manager (ISM) to handle the rest. On paper, the commitment is there. In practice, it quickly becomes apparent that management has other priorities. When the ISM needs resources from business units, he has to beg. When he needs a decision, his request lands in an inbox and stays there. When he wants to schedule a management review, it gets postponed three times because something more important always comes up.

The signal to the organization is clear: information security is not a genuine concern of leadership. It's a project that needs to be done at some point, but it's not a priority. The business units adjust their behavior accordingly and treat ISMS requests as such.

What you can do about it: Management commitment doesn't just mean saying "yes" and approving a budget. It means that senior management actively and visibly stands behind the project. Specifically, this means: management communicates the project to the organization themselves (not via an email from the ISM), attends management reviews in person (not via a delegate), regularly asks about the status (not because they want to control, but because they're genuinely interested), and intervenes when resources aren't being allocated.

A proven mechanism: agree with senior management on a monthly 15-minute slot where the ISM reports on status and obtains open decisions. This regular contact keeps the topic on the radar and gives the ISM a direct escalation path.

Lesson 2: The risk assessment as a box-ticking exercise

What goes wrong: The risk assessment is carried out because the standard requires it. The risk owners sit in the workshop, nod along to the ISM's pre-prepared assessments, and go back to their work. The assessments are often unrealistically optimistic ("Our risks are all low to medium") or unrealistically pessimistic ("Everything is critical"). In both cases, the risk assessment is useless as a management tool.

The result: the measures derived from the risk assessment don't match the actual risks. Resources are invested in areas that don't have the highest priority, while genuine vulnerabilities remain unaddressed.

What you can do about it: Turn the risk assessment into a real conversation, not a form to be filled out. Ask risk owners concrete questions: "What happens if your CRM is unavailable for a week? How do you respond if an employee forwards confidential customer data to a personal email account? What would be the consequence if an attacker gains access to your development environment?"

Use concrete scenarios instead of abstract assessment matrices. When a risk owner says the risk of a ransomware attack on their area is "low," follow up: "What's your backup strategy? Have you ever tested a restore? How long can you operate without your systems?" The assessment often changes when you ask the questions concretely.

Lesson 3: Documentation for the auditor instead of the organization

What goes wrong: Policies are written in a style that pleases the auditor: formal, comprehensive, with references to standard requirements and a level of detail that covers every edge case. The result is 20-page documents that no employee reads and that have no connection to daily work.

The ISM knows the policies aren't being read. The auditor knows it too. But as long as they exist and are formally correct, the audit is passed. The problem only surfaces when a security incident occurs and employees don't know what to do because they never read the policy — and the policy doesn't describe what to do in their specific situation anyway.

What you can do about it: Write policies for the users, not for the auditor. This means: short, understandable sentences, concrete relevance to actual work processes, no standard jargon, and a clear answer to the question "What exactly do I need to do?"

A good information security policy is five to ten pages at most. If it gets longer, break it into multiple documents. Supplement the policy with a one-page summary (a "cheat sheet") that shows the key points at a glance.

Test the policy before you publish it. Give it to an employee from the target audience and ask: "According to this policy, what do you need to do if X happens?" If the answer doesn't come immediately, the policy isn't clear enough.

Lesson 4: The technology trap

What goes wrong: The ISMS project becomes an IT security project. The focus is on technical measures: new firewall, EDR solution, SIEM system, network segmentation, vulnerability scanner. The organizational aspects (policies, training, processes, roles) are treated as a necessary evil and handled with minimal effort.

The result is a company with impressive security technology and catastrophic security culture. The firewall blocks everything, but employees share passwords because the access controls are too restrictive. The SIEM produces thousands of alerts, but nobody has defined a process for how to respond to those alerts. The EDR solution detects malware, but incident response consists of the IT admin reinstalling the computer and hoping it doesn't happen again.

What you can do about it: Regularly remind yourself that an ISMS is a management system, not a technology project. Technical measures are an important part, but just one part. ISO 27001 devotes itself to technology in only a few Annex A controls. The rest is about organization, processes, people, and leadership.

Make sure the time allocation in the project reflects this balance. If 80 percent of project time goes into technical implementations and 20 percent into everything else, the ratio is off. Deliberately plan time for workshops with business units, for creating and coordinating policies, for training, and for organizational anchoring.

Lesson 5: The scope nightmare

What goes wrong: The ISMS scope is defined either too broadly or too narrowly. Both extremes lead to problems.

A scope that's too broad: A company with 200 employees, five locations, and three business units defines the entire organization as the scope, even though certification is actually only required for one business unit. The effort multiplies because each location and each business unit has its own risks, processes, and contacts. The project becomes never-ending.

A scope that's too narrow: A company defines the scope as "IT department" or "data center." That sounds manageable but leads to constant boundary issues. The IT department uses HR processes (onboarding, offboarding), sales processes confidential customer data on laptops, production controls machines over the same network. All these interfaces must be cleanly defined and delineated, which is often more effort than a broader scope.

What you can do about it: Choose a scope that is meaningfully delineated and that you can manage with the available resources. For most mid-market companies with one location and a manageable structure, the entire organization is the most pragmatic scope. For larger or more complex organizations, a partial scope can make sense if the boundaries are clear and traceable.

Test the scope mentally: Can you explain the boundaries without needing ten minutes? Are there interfaces to areas outside the scope that are hard to manage? Will customers or regulators accept the scope as sufficient?

Lesson 6: Copying policies instead of adapting them

What goes wrong: The ISM obtains policy templates — whether from a consultant, the internet, or a befriended company — and adopts them with minimal modifications. The password policy describes requirements that Active Directory can't even enforce. The remote work policy governs the use of a VPN that the company doesn't use. The classification schemes don't match the actual information flows.

The auditor recognizes copy-paste policies immediately. He asks the ISM why the policy contains a specific requirement, and the ISM can't explain what it means. Or he asks an employee how they implement a specific policy requirement in their daily work, and the employee has never heard of it.

What you can do about it: Templates are a good starting point, but not a finished product. Every policy must be adapted to the actual processes, systems, and structures of your organization. When you use a template, go through it point by point and ask yourself: "Is this how we operate? Do we implement this? Can we implement this? Does this make sense for our organization?"

Remove points that don't fit and add points that are missing. This takes longer than a pure copy-paste, but it produces policies that work and that the auditor won't see through.

Lesson 7: Training as a one-time event

What goes wrong: In the certification year, all employees are trained. One hour of lecture, a signature on the attendance list, done. Nothing happens in the following year. The year after that, there's a repeat of the same training. The participants are bored because they've heard it all before and take nothing away from it.

This shows in the phishing simulations: the click rate drops briefly after the training and then rises back to the baseline. Employees heard the content but didn't internalize it.

What you can do about it: Security awareness is a program, not an event. Plan different formats and content throughout the year. Use short, focused sessions (ten minutes instead of an hour), current references (a specific incident from the industry, not abstract threat scenarios), and interactive elements (quizzes, phishing simulations, live demo of an attack).

The most important metric for effectiveness is not the participation rate in training sessions, but the change in behavior. Reporting rates for suspicious emails, phishing simulation results, compliance with clean desk policies — these indicators show whether awareness is actually getting through.

Lesson 8: Ignoring suppliers

What goes wrong: The company builds a solid ISMS but overlooks the supply chain. Critical IT service providers have no contract with security requirements. Cloud services are used without a security assessment. Subcontractors have access to confidential data without a confidentiality agreement in place.

The auditor asks about the supplier assessment and receives an empty list. Or he asks how it's ensured that the hosting provider adequately protects the data and learns that nobody has ever asked the provider about it.

What you can do about it: Create a list of all service providers and suppliers that have access to your information or affect your IT infrastructure. Classify them by criticality: which service providers could cause the greatest damage in case of failure or compromise? A structured security questionnaire helps you carry out the assessment systematically.

For critical service providers, you need: contractual security requirements (data processing agreement, confidentiality agreement, SLA with security metrics), a regular assessment (annually for the most critical ones, every two to three years for less critical ones), and a process for assessing new service providers before they are engaged.

Lesson 9: No incident response process in practice

What goes wrong: The incident response plan exists on paper. It states who must be informed in the event of an incident, what steps must be taken, and how communication should proceed. But the plan has never been tested. The phone numbers are outdated. Employees don't know the plan exists. And when a real incident occurs, it's Friday evening, the ISM is on vacation, and nobody knows who should do what.

What you can do about it: Test the incident response plan at least once a year in a tabletop exercise. Simulate a realistic scenario (ransomware attack, data breach, failure of a critical system) and walk through it with the people involved. The exercise immediately shows whether the plan works, whether the contact details are correct, whether the roles are clear, and whether the participants know what's expected of them.

Make sure the plan isn't held only by the ISM but is known and accessible to all relevant personnel. A printed short version in the server room, at the front desk, and with the on-call team isn't a bad idea — because in an emergency, the network may not be available.

Lesson 10: The ISMS as an island

What goes wrong: The ISMS exists as a separate system alongside other management systems and business processes. It has its own documentation, its own meetings, its own processes that run in parallel to existing ones. ISMS risk management is not integrated with enterprise risk management. ISMS documentation lives in a different system than the rest of the company's documentation. ISMS audits run separately from quality audits.

The consequence: duplicate work, inconsistencies, and the perception that the ISMS is a parallel universe that has nothing to do with actual business operations.

What you can do about it: Integrate the ISMS as far as possible into existing management structures and business processes. ISMS risk management should be part of enterprise risk management (or at least inform it). In ISMS Lite (500 Euro pro Jahr) you can map the connection between risks, measures, and controls across all areas and thereby avoid duplicate work. ISMS policies should live in the same document management system as all other company documents. Internal audits can be combined with quality audits. The management review can take place as an agenda item in regular leadership meetings.

The less the ISMS is perceived as a separate construct and the more it's integrated into normal ways of working, the higher the acceptance and effectiveness.

The meta-lesson: Perfectionism is the enemy

Above all these individual lessons stands an overarching insight: perfectionism is the most common reason for delays and frustration in ISMS projects. The information security policy doesn't have to be perfect before you publish it. The risk assessment doesn't have to cover every conceivable scenario. The policies don't have to address every edge case.

An ISMS is by nature an iterative system. The PDCA cycle explicitly envisions that you start with a good-enough version, test it in practice, review the results, and then improve. Anyone who tries to make everything perfect on the first pass will never finish.

The motto is: Start with the essentials, do it right (not perfect), and improve continuously. That's not just pragmatic — it's exactly what the standard requires.