How I Built a Complete ISO 27001 ISMS in 8 Hours — and What It Taught Me About Real Security Work

A walkthrough of my end-to-end ISO 27001:2022 implementation for WSSCK, a Water & Sanitation Services company — covering every phase, every decision, and every mistake.

Maimoona Iqbal:GRC Analyst · ISO 27001 Practitioner

Most people studying ISO 27001 read about it. They watch videos. They memorize clause numbers. They pass exams. And then a hiring manager asks “tell me about a risk assessment you’ve conducted” — and they freeze.

I didn’t want that to be me. So I did the work.

Over about eight hours spread across one week, I completed a full ISO 27001:2022 ISMS implementation for WSSCK —A Water & Sanitation Services company I used as a realistic simulation. This article is a detailed walkthrough of what I built, the decisions I made, and what I’d do differently.

“The resume line isn’t the point. The thinking is.”

The Scenario: Why WSSCK Needed ISO 27001

WSSCK is a water & Sanitation Services company serving ~450 B2B customers in Kohat Peshawar. In 2024, they had two security incidents in three months:, three employees clicked phishing links that compromised access, and their database admin accounts came under a sustained brute-force attack .

Meanwhile, their sales team was losing deals. Enterprise prospects — with contracts worth $100K–$300K — all required ISO 27001 certification before signing. $450K in stalled pipeline. The decision to pursue certification was partly about security maturity and entirely about survival.

My role

External ISMS Implementation Consultant. $150,000 budget. 8–9 months to certification. No dedicated security team on WSSCK’s side.

Phase 1 — Getting the Scope Right (The Part Everyone Rushes)

I spent more time on scope than I expected to. The temptation is to scope everything “all WSSCK operations ” sounds thorough. But with 85 people, three locations, a tight budget, and less than nine months, that scope would fail at Stage 1.

I defined the scope as: customer data lifecycle from ingestion to deletion, all employees and contractors with access to production systems, and the software development and customer support processes.

Phase 2 is where ISO 27001 becomes real. Everything else …the policies, the procedures, the controls flows from the risk assessment. Get this wrong and the entire ISMS is built on a false foundation.

I assessed 15 critical assets, organized into five categories: data/information, software, services, hardware, and people. For each of the five most critical assets, I identified threats, documented existing vulnerabilities, rated likelihood and impact on a 1–5 scale, and calculated a risk score.

Here are the highest-priority findings:

Phase 3 — Controls Selection & The Statement of Applicability

The SoA is the document auditors spend the most time on. It lists every Annex A control, whether it applies, why, what its current status is, and what procedure supports it. Vague justifications fail here. “We selected A.5.15 (Access Control) because security is important” is not a justification.

My SoA covered 28 controls. For each CRITICAL and HIGH risk I documented a treatment approach. For unauthorized database access (score 20), for example:

Phase 4 — Writing Procedures That Actually Work

I wrote four operational security procedures: Access Control, Incident Response, Change Management, and Onboarding/Offboarding. The hardest part was not the content ,it was writing for the right audience.

A security procedure must be followed by an HR coordinator who has never heard of NIST, a developer who thinks security slows them down, and a customer support agent who joined last month. It has to be specific enough to be followed, concise enough to be read, and clear enough to require no translation.

The change management procedure was the most contentious to design. WSSCK’s VP of Engineering pushed back immediately ,they deploy 10–20 times daily. A traditional change management process with approval windows and CAB meetings would have killed their velocity.

My solution: a tiered change management model. Low-risk automated pipeline deployments ,no additional approval. Medium-risk changes (config modifications, dependency updates) approval from one senior engineer. High-risk changes (production database schema, IAM policy changes, infrastructure) a formal lightweight CAB with 24-hour notice.

Phase 5 — Internal Audit Planning & KPIs

An internal audit is not a self-congratulatory exercise. The goal is to find problems before a certification auditor does. I designed WSSCK’s annual audit program with four quarterly cycles, rotating auditor assignments to maintain independence, and risk-based frequency ,critical controls audited quarterly, standard controls annually.

For the KPI dashboard, I chose 10 metrics split between leading indicators (predict future performance) and lagging indicators (measure past performance). The most important insight here: KPIs only matter if they drive action when targets are missed.

What I’d Do Differently

If I ran this project again, I’d start Phase 2 earlier and spend more time on it. Risk assessment is the hardest phase to get right, and everything downstream depends on it. I’d also have written the SoA and Risk Treatment Plan simultaneously,they are deeply interdependent and writing them in sequence created unnecessary backtracking.

I would also have involved “Nina” (the VP of Engineering archetype) from Day 1 on procedure design rather than presenting a draft and facing pushback. Resistance to security procedures is almost always predictable if you have talked to the right people early.

These are not hypotheticals. They are documented decisions I made, with trade-offs I can explain and outcomes I can defend. That is the difference between “I know ISO 27001” and “I have done ISO 27001 work.”