ISO 27001 implementation in 8 weeks: a week-by-week plan for SaaS startups

Most "ISO 27001 in 90 days" guides are written by certification bodies trying to fill audit slots. Here's what an actual 8-week implementation looks like at a 10–50 person SaaS company — broken into the documents you produce, the meetings you run, the auditor questions you'll answer at Stage 1, and the small decisions that compound into easy or hard audits.

This is the cadence we've watched succeed at fintechs, dev-tool startups, MSPs, and B2B SaaS sales-engineering teams. It assumes you already have basic security hygiene (SSO, password manager, an incident response Slack channel) — what you're adding is the documentation and discipline that an auditor will trace.

Before week 1: three decisions you need to make

You can't start week 1 until these three are signed off. Skipping this step is the single most common cause of mid-implementation rework.

• Scope. One product line or the whole company? Resist the urge to certify everything on the first pass. A scoped ISMS (e.g. "Product X engineering and infrastructure team") is faster to certify and produces a credible certificate. You can widen it later.
• Risk appetite. Defined by the exec team. One sentence, in writing: "We will not accept any single risk with potential financial loss greater than ₹X without board approval." Auditors look for evidence that leadership has set the bar.
• Certification body. Avoid the cheapest. They book audits 3 months out, send junior auditors, and produce certificates with question marks against them in enterprise procurement reviews. Use one of: BSI, DNV, TÜV, BV, Intertek, or a major regional CB with UKAS/IAS accreditation.

Week 1–2: Foundation (scope, policy, governance)

The first fortnight is documentation-heavy and conversation-light. You'll produce three documents and confirm one signoff.

Documents to draft:

• ISMS scope statement — what's in, what's out, where the boundary lives (network, data, people)
• Information Security Policy — the master policy, 2–4 pages, signed by the CEO or equivalent
• Roles and Responsibilities matrix — who owns which controls (RACI-style)

Stakeholders to involve: the CTO or security lead, the executive sponsor, and at least one product manager who can speak to scope edges. Total time commitment: 4–6 hours of meetings.

Common pitfall: defining scope too broadly because "we'll need to certify everything eventually anyway." Wrong instinct. The first audit is where the auditor learns your business and you learn the standard. Make it small enough to be sure.

End-of-fortnight checkpoint: scope statement signed off by the exec team, in writing. A meeting note suffices. The auditor will ask "who decided this is the scope?" — you need a name and a date.

Week 3–4: Risk methodology and register

This is where most teams get stuck. Don't overthink the methodology — pick one and execute. The auditor cares that you have a consistent approach, not that the approach is novel.

Documents:

• Risk Assessment Methodology — typically CIA-impact × likelihood, with explicit inherent vs residual scoring
• Risk Register — initially 15–40 risks across the scope, each tagged to one or more Annex A controls
• Statement of Applicability (SoA) draft — what controls are in scope and why

About the 93 Annex A controls: the 2022 revision condensed the older 114 into 93. Most SaaS teams legitimately exclude 10–15 of these (e.g. physical access controls when fully cloud-hosted). The SoA is where you justify each exclusion — auditors will pick three at random and ask you to defend them.

Output by end of week 4: SoA v1 — a single spreadsheet listing all 93 Annex A controls, marked Included or Excluded, with a one-line justification for each Excluded row. This is the document auditors return to most often.

Week 5–6: Operational controls

This is the implementation fortnight, not a documentation fortnight. Stop writing new docs; configure the controls you've committed to in the SoA.

What you'll actually configure:

• SSO + MFA across all systems with access to production data or customer information
• Quarterly access review process — automated where possible, with evidence captured (who, when, what was reviewed, what was removed)
• Vendor onboarding checklist — a one-pager run for every new SaaS vendor that touches customer data
• Incident response runbook + a tabletop exercise (90 minutes, scripted scenario, full team)

Records to capture this fortnight: access review log (first cycle), supplier review log (first 3–5 suppliers), incident-response tabletop minutes, security awareness training attendance (everyone in scope completes a 30-minute module).

If you skip the tabletop exercise, the auditor will know. They always ask "when was your last incident response drill?" — silence is a non-conformity.

Week 7: Internal audit

A structured 1–2 day walkthrough against your SoA, executed by someone other than the person who wrote the docs. Hire a consultant for a day if you don't have a second qualified person internally — it's the most cost-effective spend in the whole project.

What you produce: a non-conformity register and a corrective actions plan. Both are required documents under ISO 27001:2022 clause 9.2 (internal audit) and clause 10.1 (continual improvement).

The goal of internal audit: find 5–10 small issues now so the certification audit doesn't find 5–10 big ones. A clean internal audit with zero findings is a yellow flag — auditors expect you to find something, and "we audited ourselves and everything's perfect" reads as "you didn't actually look."

Week 8: Management Review and Stage 1 prep

The last week is light. You hold a half-day Management Review meeting (clause 9.3) with the exec team, walking through a fixed agenda: ISMS performance, internal audit results, non-conformities, customer feedback, supplier performance, risk register status, opportunities for improvement.

Capture minutes. Decisions go in writing. The MR template is the most reusable single document in the toolkit — you'll run this meeting at least annually for the life of the ISMS.

What you also do this week: assemble the evidence binder. Stage 1 auditors arrive 4–6 weeks after your booking, but ideally you book in week 1 so the slot is reserved. By end of week 8 the binder is ready and you're rehearsing the walkthrough.

What the auditor actually looks at

Stage 1 (documentation review, 1 day) and Stage 2 (operational audit, 2–3 days) both follow the same evidence pattern. The auditor asks to see eight records:

1. ISMS scope statement — signed, dated
2. Risk methodology + risk register — current within 12 months
3. Statement of Applicability — with justifications for each excluded control
4. Internal audit programme + most recent audit report
5. Management Review minutes — most recent
6. Corrective actions tracker — open items + closed items with closure evidence
7. Access reviews — at least one cycle completed
8. Incident response evidence — even if it's a tabletop, not a real incident

Three records that are almost always missing on first audits: supplier reviews (most teams assume the supplier's own ISO certificate is enough — it isn't), training records with named attendees, and information classification applied to actual documents (not just a policy stating the classes).

When 8 weeks isn't enough

Some signals you need 12–16 weeks instead:

• Distributed team across more than 3 countries — physical document signoffs become the bottleneck
• Active enterprise customer contract requiring certification by a specific date — the contract becomes the boss, not the standard
• Regulated industry (fintech, health, defence) — overlapping frameworks (PCI-DSS, HIPAA, RBI guidelines) consume calendar time
• You're the only person working on it part-time — solo implementations are slower regardless of skill

If two or more of those apply, plan 12 weeks. Don't compress at the cost of skipping the internal audit or tabletop exercise — those are the steps that change an audit from "passed with NCs" to "certified, no issues."

When to use a toolkit vs hire a consultant

Toolkits work when you have someone internal who can read the standard, understand the clauses, and make scope decisions. The toolkit removes the document-rebuilding step (which is 60–70% of the work) and lets you focus on the implementation.

Hire a consultant when you have nobody internal who's seen an ISO audit, or when the certification is contractually critical and you can't risk a delay. A good consultant runs the whole programme; they shouldn't disappear after the docs are written.

Final thoughts

Most teams that fail their first audit didn't lack expertise — they lacked discipline about the calendar. Eight weeks is enough if you treat the deadlines as fixed and the scope as small. It's not enough if you keep widening scope, deferring the internal audit, or rewriting policies for elegance.

Auditors are not looking for perfect ISMS implementations. They're looking for evidence that you've thought about the risks, made decisions, captured the decisions in writing, and stuck to them. The standard is a discipline, not an aesthetic.

If you do this in 8 weeks, the second pass at any other ISO standard (9001, 14001, 42001) takes 4–6 weeks because you've already built the management-system skeleton. That's the compounding value of getting the first one right.