When ISO 27001 shows up as a hard requirement — a tender that's blocked on it, a board that's set a date — the question changes from "how do we do this well" to "how do we do this fast without cutting a corner that fails the actual audit." Those are different problems, and worth being precise about which one you're solving.
What actually compresses the timeline
- One person with real authority, full-time on it. The single biggest lever. A self-led implementation done at 20% of someone's week takes a year; the same work at 80–100% takes a fraction of that.
- Existing security hygiene. If MFA, backups, and basic access control are already in place, you're mostly documenting reality. If they're not, implementing them — not writing about them — is what actually takes time, and no amount of process can compress that part.
- A pre-filled starting point. Going from a blank Statement of Applicability to a defensible one is the single biggest time sink in a self-led process. Starting from your actual risk register and context, rather than a static template, removes a large chunk of that assembly work.
What doesn't actually compress it
Hiring more people onto the project past the first one or two doesn't help much — this isn't a task that parallelizes well, since most of it depends on decisions only one accountable owner can make. Skipping the risk assessment to jump straight to filling in controls is the most common shortcut that backfires: it produces a Statement of Applicability that looks complete but isn't grounded in anything, which is exactly what an auditor is trained to probe.
A realistic answer for the board
With one dedicated owner, reasonable existing security hygiene, and a tool that starts from your actual data instead of a blank page, weeks-to-a-few-months for audit readiness is a realistic answer — not the marketing "as fast as 2 weeks" claims aimed at companies that already had everything in place. That's the honest version of the timeline worth bringing back to whoever set the deadline.