>> All posts

So you're being asked for ISO 27001 — here's where to start

June 29, 2026By J. Foster Davis, Co-Founder & COO5 min readComplianceBest practices

A European (or global) customer emailed: Do you have ISO 27001? Sales forwarded it with a grinning deadline. You're the CIO/CISO, and you might have SOC 2 already — or nothing but good intentions.

ISO 27001 is doable. It is also easy to overbuy and misunderstand. Start by decoding the ask.

Important: Certification is issued by an accredited certification body after audit — not by BreachBits, and not by writing policies alone. This post is a starting map, not an ISMS implementation manual. Confirm requirements with your auditor/certifier.

Core concepts (read this first)

ISO/IEC 27001 is an international standard for an ISMS — an Information Security Management System. Think "how leadership runs information security as a managed system" (risk assessment, controls, internal review, continual improvement), not merely a pile of IT checkboxes. ISO's ISMS overview is a good plain-language companion to the paid standard text.

Certification vs "aligned":

  • Certified — an accredited certification body (how accreditation works via IAF) audits you and issues a certificate for a stated scope (e.g., a product or business unit).
  • Aligned / working toward — you may use ISO 27001 as a blueprint without (yet) holding a certificate. Some customers accept that; many will eventually ask for the certificate or for another report (often SOC 2). Ask which artifact they need.

How long does certification last? In common practice, an ISO 27001 certificate is issued for a three-year cycle, with surveillance audits (often annually) in between, then a recertification audit — confirm the exact cadence with your certification body. It is not "set and forget for three years."

Stage 1 and Stage 2 (typical certification path): certification bodies commonly use a two-stage initial audit — roughly, documentation/readiness first, then a deeper check that the ISMS operates. Ask your chosen firm how they run it; naming varies less than the idea.

Statement of Applicability (SoA): your reasoned list of which controls apply (and which don't) for your scope. Auditors care that it's honest and tied to risk — not that every control on earth is "green."

ISO 27001 vs SOC 2: different animals. SOC 2 is a CPA attest report on controls for a service; ISO 27001 certification is a management-system certificate from a certification body. Customers sometimes say "ISO" when they mean "show us a serious program" — clarify before you dual-track.

What people usually mean

Customers may want a certificate, evidence you're aligned, or — sometimes — your SOC 2 report instead. Get the artifact name in writing.

Clarify these first

  1. Certificate vs alignment vs "security packet" — get it in writing
  2. Scope of the ISMS — whole company, one product, one business unit?
  3. Deadline and contract language — binding requirement or preference?
  4. Do we already have SOC 2 / other audits? Reuse; don't dual-track blindly
  5. Geographic / customer context — sometimes the real need is customer trust in the EU, not the number on the certificate

Who you'll need in the room

  • Executive sponsor — ISMS fails without management commitment (that's not slogan; auditors look for it)
  • ISMS owner — day-to-day program lead
  • Risk & control owners across IT, Eng, HR, Facilities as scope requires
  • Internal audit / compliance support if you have it
  • Certification body / external auditor when you pursue formal certification — select deliberately

Consultants can accelerate documentation; they shouldn't own your risk decisions.

What the journey usually feels like

Durations depend on maturity and scope — ask firms who've certified companies your size; ignore blog stopwatches. Typical shape:

  1. Define ISMS scope & context
  2. Risk assessment approach — how you identify and treat information risk
  3. Statement of Applicability mindset — which controls apply and why (your auditor will care about honesty here)
  4. Operate the system — not just publish policies
  5. Internal readiness — find gaps before the external audit
  6. Certification audit (staged how your certification body runs it — ask them)
  7. Surveillance / continual improvement — certification is a relationship, not a one-time stamp

Evidence categories (high level)

Expect to show:

  • ISMS documentation that matches reality
  • Risk assessment / treatment records
  • Proof controls operate — tickets, reviews, logs, training, vendor oversight — for what's in scope
  • Internal review / corrective action history as you mature

Pretty templates that nobody follows are a liability.

Common surprises

  • Customers said ISO; they accept SOC 2 — verify before you dual-certify for fun
  • Scope too wide — boiling the ocean on corporate IT + every product
  • Paper ISMS — policies without operation
  • Tool sprawl — buying GRC before scope exists

First 30 days — starter checklist

  • Email the customer: certificate required, or other evidence acceptable?
  • If SOC 2 exists, ask whether it satisfies them for this deal
  • Draft a proposed ISMS scope (one page) for leadership debate
  • Name sponsor + ISMS owner
  • Inventory existing policies, risks registers, diagrams, prior audit reports
  • Talk to 1–2 peers or advisors about certification bodies they'd use — then shortlist
  • Pause net-new "ISO project tool" purchases until scope is approved

Where continuous testing helps (lightly)

An ISMS still needs technical truth: what's exposed, what's vulnerable, whether remediation is happening. Continuous outside-in verification and compliance-mapped reporting (including ISO-oriented mapping where you use it) can feed the technical side of risk treatment.

It does not replace an ISMS or a certification body's audit.

When the customer ask is clear and you want that technical feed, see Compliance or book a demo.

Authoritative sources

See your cyber risk, proven.

Book a demo>> More posts