ISMS in 6 Months: A Realistic Experience Report

The starting point: A company under pressure

SecuTech GmbH is a fictional but very realistic company. An IT service provider with 100 employees, three locations in Germany, and a customer base that is asking increasingly uncomfortable questions. The largest customer, an automotive supplier, had made an ISO 27001 certificate a condition for contract renewal during the last negotiation. Two other customers had sent extensive security questionnaires that the team could only answer with considerable effort. The message was clear: without demonstrable information security, staying in business would become difficult.

In October, senior management decided to build an ISMS with the goal of being certification-ready within six months. Not certified — that would be unrealistic, since the certification audit requires lead time and an auditor. But positioned so that an external auditor could give the green light.

What follows is the report on these six months. Unfiltered, including everything that went wrong and the lessons the team drew from it.

Month 1: Laying foundations and reality-checking

What was planned

The first four weeks were supposed to be preparation: assemble the project team, define the scope, start the inventory, and adopt the information security policy. Sounds manageable.

What actually happened

The IT manager took on the project lead, in addition to his regular duties. That was the first mistake — though it only became clear later. He assembled a core team: himself as the designated ISM, a colleague from quality assurance, a system administrator, and the data protection officer. Senior management additionally engaged an external consultant for two days per week.

The scope definition took three meetings instead of one. The central question was whether the small development office in Leipzig with its 12 employees should be included. Leipzig partially used its own systems and had its own processes. The consultant recommended initially excluding Leipzig and limiting the scope to the main location plus the second office. This decision likely saved two months, because harmonizing Leipzig's systems would have been a project in itself.

The inventory revealed surprises. Policies already existed — scattered across a SharePoint, a knowledge base, and the minds of individual people. Some were four years old and had never been updated. Others were current but unknown to anyone outside IT.

The information security policy was finalized in the last week of the month. The CEO signed it, and it was published on the intranet. That was a good symbolic starting point.

Lesson from Month 1

Allow double the planned time for the inventory. Every organization has more existing documentation than expected, but it's scattered, outdated, or unknown. Reviewing this material before creating new documents saves massive duplication of effort later.

Month 2: Capturing assets and assessing risks

What was planned

Capture all information-processing assets, determine protection needs, and conduct the first complete risk assessment. The team planned to use an Excel template from the consultant.

What actually happened

The asset capture became the first real stress test. The system administrator started with the obvious assets: servers, firewalls, switches, laptops. Then came the applications: ERP, CRM, ticket system, time tracking, email, collaboration platform, various cloud services. Then the data holdings: customer data, contract documents, technical documentation, source code, personnel data.

After two weeks, there were 187 assets in the Excel spreadsheet. That was more than expected and presented the team with a problem: for each asset, protection needs had to be assessed across the dimensions of confidentiality, integrity, and availability, followed by a risk assessment with threats, vulnerabilities, likelihood, and impact.

The Excel spreadsheet quickly became unwieldy. Links between assets and risks could only be mapped through free-text fields or separate worksheets. When a risk related to multiple assets, it had to be entered multiple times or referenced awkwardly. By the third week, the file was 4 MB and noticeably sluggish.

The risk assessment itself went better than expected because the external consultant took a workshop approach. Instead of interviewing each risk owner individually, he scheduled thematic workshops: one for infrastructure, one for applications, one for organizational risks. In three hours each, the team assessed the risks together. This had the side benefit that participants learned about risks in other areas and connections became visible.

At the end of the month, there were 94 identified risks, of which 23 were high and 8 were critical. The critical ones primarily concerned missing network segmentation, an inadequate backup concept, and missing multi-factor authentication for privileged accounts.

Lesson from Month 2

Excel works for the first risk assessment, but it doesn't scale. As soon as risks, assets, and controls need to be linked and multiple people need to work on them simultaneously, a specialized tool becomes indispensable. The team switched to an ISMS tool in Month 3, which meant one week of migration effort. In retrospect, it would have been worth starting with the tool from day one. A specialized ISMS tool like ISMS Lite would have ensured the linkage between assets, risks, and controls from the start.

Month 3: Statement of Applicability and controls planning

What was planned

Create the Statement of Applicability (SoA) — that is, decide which of the 93 controls from Annex A of ISO 27001 are applicable. Then assess the implementation status of each applicable control and derive measures.

What actually happened

The first week was consumed by migrating the risk assessment from Excel to the new ISMS tool. The consultant had strongly recommended making this move now, not later. The migration was tedious: risk assessments had to be manually transferred and partially restructured in the process. But afterwards, the work flowed significantly more smoothly.

The ISM created the SoA together with the consultant in two intensive working days. Of the 93 controls, 87 were classified as applicable. The six excluded ones related to areas with no relevance to the company — such as the physical security of data centers, since all servers were hosted by an external provider.

The assessment of implementation status revealed a mixed picture. Roughly 40 percent of the controls were already partially implemented, often without conscious awareness. There was a password policy technically enforced in Active Directory. There was a backup concept, though it had never been tested. There were access permissions, though they weren't consistently adjusted when employees changed roles.

The remaining 60 percent ranged from "initial approaches exist but aren't documented" to "completely missing." The biggest gaps were in supplier assessment, logging and monitoring, change management, and training.

For each gap, the team defined one or more measures with a responsible person, deadline, and priority. At the end, there were 68 measures on the list. That was an honest but also intimidating number. The consultant categorized the measures into three tiers: quick wins (implementable in under one week), medium-term measures (one to three months), and strategic measures (ongoing).

Lesson from Month 3

The SoA is not a document you fill out once and file away. It is the central management tool of the ISMS and must be updated with every change. Those who treat the SoA as a living document from the start will have a much easier time during the audit. Additionally, categorizing measures by effort and impact is essential so the team doesn't try to work on all 68 measures at once.

Month 4: Writing policies and implementing quick wins

What was planned

Create all required policies, implement the quick-win measures, and begin awareness training.

What actually happened

This month was the most labor-intensive of the entire project. The team had to work on three fronts simultaneously: writing policies, implementing technical measures, and preparing training.

For the policies, the inventory from Month 1 helped. Some existing policies could be revised rather than written from scratch. The password policy just needed an update. The server room access control was documented and current. But for topics like supplier assessment, change management, capacity planning, and cryptography, everything had to be created from the ground up.

The ISM made an error here that is typical: he tried to write perfect policies. Multi-page documents with detailed procedures, flowcharts, and appendices. The consultant put the brakes on after the third policy: "An auditor wants to see that the policy exists, that it's adequate, and that it's lived. Ten pages that nobody reads are worse than two pages that everyone knows."

This shift in thinking dramatically accelerated the work. The team defined a standard format: maximum length of three pages, uniform structure with purpose, scope, responsibilities, provisions, and review. A total of 14 policies were produced this month.

The quick wins ran in parallel and showed rapid results. MFA was activated for all admin accounts and VPN access. Firewall rules were cleaned up (in the process, three rules were found still pointing to a server that had been decommissioned two years earlier). Automatic screen locks were enforced via group policy. The server room received access control with logging.

The first awareness training was held as an in-person session for all employees. The ISM had prepared a presentation that began with a live demo of a phishing attack. He showed how he had created a convincing fake login page for the company intranet in 15 minutes. That made an impact: the attention in the room was immediate. After the presentation, several employees came forward with questions and reports of suspicious emails they had received in the past.

Lesson from Month 4

Policies need to be practical, not academic. Short, clear documents with concrete rules that everyone understands beat comprehensive works that sit unread on the intranet. And for training: a single concrete example from your own company is more powerful than twenty generic slides about cyber threats.

Month 5: Embedding and testing processes

What was planned

Integrate new processes into daily operations, set up incident management and change management, and conduct the first backup restore tests.

What actually happened

Month 5 was the month of uncomfortable truths. The policies existed, the technical measures were largely implemented, but the question was: was the team actually living the processes?

The first real test came with incident management. An employee reported a suspicious email. The report went to the ISM, who started the defined process: analyze the email, check sender and links, conduct assessment, document the result, and give feedback to the reporter. The process worked, but it took four hours instead of the target two, because the responsibilities between the ISM and the IT team weren't clearly enough defined. This led to a process adjustment: the helpdesk would handle initial analysis going forward, with the ISM only being brought in for confirmed incidents.

The backup restore tests revealed a serious problem. The daily backup of the file servers ran reliably, but when the team tested a full restore of a virtual server, the process took 14 hours instead of the expected 4. The reason: the backup solution was configured for incremental backups, and the last full backup was three weeks old. The 14-hour recovery time was unacceptable for critical systems. The backup concept was revised: weekly full backups and a new retention policy.

Change management was the most difficult process. Previously, administrators had made changes to systems at their own discretion, often without documentation. The new process required that every change to production systems go through a change request: description, risk assessment, approval, execution, documentation. The administrators perceived this as bureaucratic friction. It took two team meetings and a clear statement from senior management before the process was accepted and consistently followed.

At the end of the month, the ISM organized a tabletop exercise: a simulated ransomware attack where the crisis team walked through the response. The exercise lasted two hours and uncovered three blind spots: there was no current emergency contact list (the existing one included two employees who had left the company), the alternative communication channel hadn't been set up, and nobody knew where the contract with the external forensics provider was filed.

Lesson from Month 5

Processes on paper and processes in practice are two different things. The only way to close the gap is testing, testing, and more testing. Every test that uncovers a problem is a win — because in a real incident or during an audit, it would be a major nonconformity.

Month 6: Internal audit and fine-tuning

What was planned

Conduct an internal audit, address findings, hold the management review, and prepare documentation for the certification audit.

What actually happened

For the internal audit, the company engaged an external auditor. This was a deliberate decision: an internal auditor would have had to ensure independence, but in a company this size, it's difficult to find someone who isn't directly involved in the ISMS yet has sufficient expertise. The external auditor brought a fresh perspective and experience from other certification processes.

The audit lasted three days and resulted in 4 major nonconformities, 11 minor nonconformities, and 7 recommendations. The major nonconformities concerned:

1. Missing risk re-assessment after implementation of controls. The team had assessed risks and implemented controls but hadn't documented how the risk assessment changed after implementation.

2. Incomplete supplier assessment. Three critical IT service providers had not yet been assessed, including the hosting provider where the entire infrastructure was running.

3. Gaps in logging. Security-relevant events were logged on individual systems but not centrally aggregated. Correlation of events across system boundaries was not possible.

4. No formal process for access rights review. Access rights were assigned upon joining but regular recertification did not exist.

Each major nonconformity was assigned a concrete corrective action, a responsible person, and a deadline. Two of the four nonconformities could be resolved within two weeks. The supplier assessment took longer because questionnaires had to be sent to the service providers and their responses evaluated. Central logging was planned as a medium-term measure, with an interim step: manual weekly log reviews for the most critical systems.

The management review took place in the last week. Senior management received a compact report on the ISMS status: risk situation, controls status, audit results, incidents, and metrics. The CEO was surprised by how much the team had achieved in six months — but also by how many open items remained on the list.

Lesson from Month 6

An internal audit by an external person is worthwhile, especially during the first cycle. The fresh perspective uncovers blind spots that the team can't see itself. And major nonconformities in the internal audit are not a disaster — they're the norm. What matters is that you address them systematically and can prove the correction.

The balance sheet after six months

What the project cost

The honest cost breakdown for SecuTech GmbH:

• External consultant (2 days/week, 6 months): EUR 48,000
• ISMS tool (annual license): EUR 3,600
• External internal auditor (3 days): EUR 4,500
• Technical measures (MFA, logging, backup expansion): EUR 12,000
• Training and awareness (external + internal): EUR 5,000
• Internal personnel costs (estimated, ISM 50%, team 20%): approx. EUR 80,000

Total cost: approximately EUR 153,000, with the largest item being internal personnel costs. This is a significant investment, but one that already paid for itself in the first year through the secured major customer and three new customer inquiries that explicitly referenced ISO 27001 compliance.

What went well

Management support was there from the start and remained constant. This carried the project through the difficult phases, especially when change management met resistance.

The workshop approach for risk assessment was a home run. Instead of months of individual interviews, risks were assessed in two weeks, and the team had a shared understanding of the risk landscape.

The early quick wins (MFA, firewall cleanup, screen lock) generated visible progress and kept motivation high, even when the bigger challenges were still ahead.

What didn't go well

The ISM in a dual role was a persistent problem. The IT manager could never give the ISMS project the full attention it needed. From Month 3 onward, a second employee was assigned half-time to assist. In retrospect, that should have happened from the start.

The Excel phase in Month 2 set the project back by at least two weeks. The migration to the ISMS tool could have been avoided if the tool decision had been made earlier.

The awareness training as a single event was a good start but not sustainable. By Month 5, many employees had already forgotten the content. A continuous program with monthly short sessions would have been more effective.

What's still open

After six months, the ISMS is built but not complete. Open items that need to be addressed in the coming months:

• Introduce a central logging solution (SIEM)
• Automate regular recertification of access rights
• Bring the Leipzig location into scope
• Switch the awareness program to monthly sessions
• Complete supplier assessments for all critical service providers
• Conduct a second tabletop exercise with an expanded scenario

What you can take away from this report

SecuTech GmbH is fictional, but the experiences are not. They are based on typical patterns that keep recurring in ISMS projects at mid-market companies. Here are the key insights, distilled to the essentials:

Start with the scope, not the tool. The temptation is great to select a tool first and then define the scope around it. Do it the other way: understand what you want to protect, and then choose the tool that fits.

Plan the ISM as a real role, not a side job. Building an ISMS while also running IT is like two full-time jobs in parallel. At least 50 percent of working time must be reserved for the ISMS — in the intensive phases, more like 80 percent.

Use workshops instead of individual interviews. Joint risk assessment in workshops produces better results in less time and simultaneously creates a shared risk understanding across the team.

Perfectionism is the enemy of progress. An ISMS that is 80 percent complete after the first cycle and is actually lived is worth more than one that is 100 percent documented but exists only on paper. The PDCA cycle is your friend: what isn't perfect now will be better in the next iteration.

Test everything you document. Every restore test, every tabletop exercise, every process run-through uncovers weaknesses you can't see from your desk. Better to fail in a test than in a real incident.

Expect resistance to organizational measures. Technical controls are easy to implement because they don't ask anyone. But when processes change — when change requests suddenly need to be written or incidents documented — that affects people. And people need explanation, support, and sometimes a clear directive from senior management.

Six months is ambitious but achievable. SecuTech GmbH did it, and your company can too. The key isn't making everything perfect the first time — it's starting and staying the course.

Further reading

• Building an ISMS: The complete guide for companies with 50 to 500 employees
• What does an ISMS cost? Budget, resources, and hidden costs
• ISM external or internal? Pros and cons of both models
• From Excel ISMS to tool: Migration guide without data loss
• Internal ISMS audit: Planning, execution, and follow-up