From zero to ISO 27001 certified in ten months
“A program manager who only sits in meetings solves nothing. You need to get your hands dirty, only then do you know if it actually works.”
Situation
A fast-growing financial services company with over one hundred and fifty employees was facing a hard deadline. The financial regulator required DORA compliance, and ISO 27001 certification was on the path to get there. The board had set the ambition. But between ambition and certification lay an entire program that still needed to be built from scratch.
The organization worked agile. Sprints and release cycles ran at full speed, but without a security layer. Development had complete freedom and reacted with mixed feelings to the idea of more structure. Some were open. Some were defensive. The mood: skeptical, but not hostile.
Maurits den Dunnen, program manager at House of Data, was brought in as external program manager to lead the ISO 27001 initiative. This project took place before House of Data was founded. The approach and lessons from this engagement form the foundation of how we approach compliance programs today.
The brief: ten months. From a blank slate to a successful external audit. Halfway through, an internal audit by an independent Big Four firm would serve as the first real checkpoint.
The challenge
Four hundred action items. Zero structure.
A Big Four firm had been involved as advisory party in the preliminary phase. External risk managers from consultancies had also been brought in. Together with the existing project team, they had compiled an action list exceeding four hundred items through brainstorming sessions.
The variety was enormous. From “ensure visitors register at reception in advance” to “demonstrate that you have a comprehensive Business Continuity Plan.” Four levels of complexity, all on the same unsorted pile.
The problem was not the size. The problem was that nobody had oversight. Action items were scattered across teams, without owners, without prioritization, without a link to the ISO 27001 controls they were supposed to address. A lot had been done. But nobody could tell how far along they actually were.
Getting development on board
The hardest part was not the documentation or the technical controls. It was getting development on board.
Agile teams accustomed to fast iteration experience additional steps as delays. The tendency to bypass processes or keep working methods out of sight was present. Buy-in was not a given. It had to be earned.
Contracts being signed before anyone read them
Meanwhile, IT Security, Legal, Compliance and Vendor Management regularly encountered newly signed contracts. Before the content had actually been reviewed, a manager had already signed and a project had already started. That could no longer continue. These departments raised the alarm and that signal became the starting point for the entire change management framework.
Approach
From action list to work packages
The first step was understanding the ISO 27001 requirements and mapping the four hundred-plus action items to the corresponding controls. Many items turned out to touch multiple controls simultaneously. Others were duplicated or overlapped in content. Some were trivial; some touched the core of operations.
By introducing layers of abstraction, structure emerged. Action items were clustered per control domain, prioritized by audit risk and assigned to concrete work packages with clear owners. AI was used to identify patterns in the action list and accelerate the mapping to controls: without involving any sensitive data. Manually classifying four hundred items is a job that takes a week or two. With the right tools, it is a matter of hours.
The result: from an unstructured pile to work packages that teams could actually pick up. For the first time it was visible how far the organization had come and where the gaps were.
Four layers for change management
The signal from Legal and Compliance was the trigger to build change management from scratch. Maurits wrote the policies and procedures himself, after investigating how the company actually handled changes in practice. Everything was organized into a four-layer structure:
- Hotfix: immediate correction with mandatory risk assessment on a standard form. Even under time pressure.
- Sprint: security review per user story. Every story with data impact had its own security criterion in the definition of done.
- Project: deeper assessment, formal escalation line via PO and CISO to steering committee.
- Program: periodic reporting and management review at steering committee level.
Every hotfix with security impact followed the formal ladder: team, PO, CISO, steering committee based on risk classification. Demonstrability was ensured through process descriptions, an audit trail per layer and internal audit reports.
Secure SDLC embedded, not imposed
All development teams fell under the Secure SDLC. No exceptions. The implementation was deliberately pragmatic:
- OWASP Top 10 as the content reference framework: Security as a label and workflow step in Jira, visible to everyone
- Manual code review with security focus in the pull request process
The security criteria in the definition of done were written together with the teams. Not imposed from above, but designed based on what they themselves deemed necessary to demonstrate that a story was secure. That made the difference between an imposed process and an adopted way of working.
From Excel spaghetti to TPRM
The vendor assessment process was a story in itself. There was a multitude of interconnected Excel files that nobody dared touch. The process was technically fragile and organizationally opaque. It was untangled and moved to a SaaS solution, much to the delight of the auditor, who found a demonstrable and repeatable process instead of a spreadsheet swamp.
Eight themes that made security tangible
Together with a graphic designer, eight themes were created that made information security concrete and recognizable. Each theme received its own icon. Improvement projects were linked to a theme, so employees could see at a glance what a change was about. New projects were announced on internal pages, with regular updates. The effect: security was no longer an abstract concept from a handbook, but something with a face.
Getting your hands dirty
Maurits split his time roughly 70% at program level and 30% hands-on in the teams. Not because it was planned that way, but because that is how it evolved. He found that he made the biggest difference as a connector by actually helping out.
Contributing to security criteria. Being present when teams got stuck. Walking through the hotfix form live with the people who had to use it. Testing whether a new process actually relieved the pain for colleagues who were busy with their daily work.
That presence made a difference. People got to know him. He got to know them. And because of that, they were willing to go the extra mile. Teams did not go to a department with security questions, but to someone who understood how they worked.
Agile, PRINCE2 and MSP served as a toolbox, not a straitjacket.
The turning point
Four months after the start, an independent auditor conducted the internal audit, deliberately separated from the advisory party to ensure objectivity. The result: eight minor non-conformities and a substantial list of opportunities for improvement.
The findings were numerous and visible. The urgency became undeniable. It was no longer just about attendance, but a serious matter. Failing the external audit would have major consequences. And the internal audit also made clear that there was nowhere to hide.
After that, everyone pulled in the same direction.
What was built
Documentation and processes:: Information security policy + 15 procedures (Risk register with treatment plan: Statement of Applicability (SoA)) Change management policies and procedures: Internal audit program and reports (TPRM process (from Excel to SaaS)) 8 awareness themes with visual identity
Technical controls:: Logging and monitoring implemented: MFA rolled out for all critical systems (Access management cleaned up: Vulnerability management and patch process established) Encryption of data at rest and in transit improved
Result: 0 major non-conformities at external certification audit
- 2 minors, the first resolved within two weeks, the second formally closed at the next audit
- 10 months from blank slate to certified
- 0 majors at surveillance audit, 1 minor, one year later, conducted by the internal team
The external auditor was surprised by the maturity level for a first-time certification. The board explicitly acknowledged the success.
But the most tangible result was the behavioral change. Employees started asking security questions themselves when new projects kicked off. The tendency toward shadow IT decreased noticeably. Security was no longer an afterthought, it was part of how teams worked.
Handover as the end product
After certification, Maurits focused on handover. An internal security team of five people was built, all hired to structurally maintain the ISMS. Responsibilities were gradually transferred. Maurits scaled back his hours, remained available for questions and escalations, and meanwhile took on smaller implementation projects for the same organization.
One year later came the surveillance audit. The real test. If the internal team could pass that audit independently, the handover had succeeded.
They did. Zero majors, one minor.
Setting things up properly means making yourself redundant. That is not a loss; it is proof that it works.
This project was carried out by Maurits den Dunnen before House of Data was founded. The approach and lessons from this engagement form the foundation of how we approach compliance and governance challenges today.
Working toward ISO 27001 or DORA compliance? House of Data guides organizations from strategy to certification. Get in touch for an initial consultation.