Launching the ISMS Implementation Project

Foundation covered what ISO/IEC 27001 requires. This roadmap is about building it — and the single biggest reason implementation projects fail has nothing to do with technical controls: it's treating the ISMS as an IT initiative instead of an organization-wide management project with real executive backing.

Why this needs a sponsor, not just an owner

Recall from Foundation (clause 5) that leadership commitment must be demonstrable, not symbolic. In practice, this means the implementation project needs an executive sponsor — someone senior enough to authorize budget, resolve cross-department conflicts (e.g., when a control requires HR and Legal and Engineering to all change how they work), and be personally accountable if the project stalls. A well-intentioned IT manager, however competent, typically lacks the organizational authority to mandate that Sales stop storing customer data in personal spreadsheets — that requires someone with cross-functional authority.

A simple test: if the only person who could explain why the organization is pursuing certification is someone in IT, the project doesn't yet have real sponsorship — and Foundation's clause 5 findings (leadership signs a policy once a year with no other engagement) will likely resurface later as certification audit findings.

Building the project's RACI

A RACI matrix (Responsible, Accountable, Consulted, Informed) clarifies who does what — critical because ISMS implementation touches nearly every department:

A common implementation mistake: naming an "ISMS Manager" and assuming that's sufficient — without also clearly naming control owners for each Annex A theme, you get an ISMS Manager who personally tries to implement all 93 controls alone, which doesn't scale and isn't how the standard's roles are meant to work.

A realistic implementation timeline

Every organization's pace differs, but a typical sequence looks roughly like this:

Phase 1: Initiation        — charter, sponsor, RACI, scope confirmation
Phase 2: Gap analysis       — where does the organization stand today?
Phase 3: Risk assessment    — build the risk register (next lesson)
Phase 4: Policy development — write the policy framework (lesson after that)
Phase 5: Control implementation — roll out Annex A controls by theme
Phase 6: Internal audit     — verify what was actually implemented
Phase 7: Management review  — leadership reviews readiness
Phase 8: Certification audit — Stage 1, then Stage 2 (covered in Foundation)

Phases often overlap in practice — policy development and control implementation frequently run in parallel rather than strictly sequentially — but skipping the order of dependency causes real problems: writing detailed access control procedures (Phase 4/5) before the risk assessment (Phase 3) has identified which access risks actually matter produces a policy built on guesswork rather than evidence.

The most common reason implementation stalls

Not technical difficulty — scope creep without re-approval. A project scoped to "our SaaS product's production environment" quietly expands to "the whole company" three months in, without the sponsor formally re-approving the larger scope, larger budget, and longer timeline that implies. The fix isn't avoiding scope changes entirely — sometimes they're the right call — it's routing any scope change back through the same sponsorship and RACI structure established at Phase 1, rather than letting it happen by drift.