Building Your First ISMS: What ISO 27001 Actually Requires (vs. What Consultants Tell You It Does)

The consultancy playbook

There's a predictable arc to most first ISO 27001 engagements. A consultancy wins the project, scopes it generously, and delivers a documentation set that would make a bank's information security team weep with admiration. Sixty policies. A risk register with 200 line items. An ISMS manual thick enough to use as a monitor stand. You pay somewhere between $40,000 and $150,000 and end up with a system that nobody outside the compliance team has read, understands, or could maintain without the consultants coming back next year.

The dirty secret is that ISO 27001 doesn't require any of that. The standard is surprisingly lean about what it mandates. What it's generous about is the space it gives you to decide how to meet those requirements, which is exactly the space consultants fill with billable hours.

This post is about closing that gap. What the standard actually requires, what a proportionate ISMS looks like for a 20-200 person SaaS company, where first-timers consistently over-invest, and where they consistently under-invest.

What the standard mandates vs. what it doesn't

ISO 27001:2022 has two parts you need to care about: the clauses (Clauses 4-10) and Annex A. The clauses define the management system requirements. Annex A lists 93 controls across four themes: Organizational, People, Physical, and Technological. The relationship between them matters; the clauses are mandatory. Annex A is a reference set.

That last sentence trips up a lot of people. You are not required to implement all 93 Annex A controls. You are required to produce a Statement of Applicability (SoA) that documents which controls are applicable to your organization, which you've implemented, and, critically, a justification for any you've excluded. An auditor won't penalize you for excluding Physical controls because you have no on-premise infrastructure. They will penalize you for not being able to explain why.

The mandatory documented information under the clauses is a much shorter list than most people assume. You need:

• the scope of the ISMS (Clause 4.3), an information security policy (Clause 5.2),
• a risk assessment process and results (Clause 6.1),
• risk treatment plans and results (Clause 6.1.3),
• security objectives (Clause 6.2),
• evidence of competence (Clause 7.2),
• documented information required by the ISMS itself (Clause 7.5),
• operational planning results (Clause 8.1),
• internal audit program and results (Clause 9.2),
• management review outputs (Clause 9.3), and
• nonconformity and corrective action records (Clause 10.1).

That's it as a floor. A well-scoped SaaS company could satisfy those requirements with a handful of living documents, a risk register, and consistent evidence of the management review cycle. The question isn't whether you can get away with less — it's whether what you build will actually hold up in an audit and survive your second year without needing to be rebuilt.

Scope is where you win or lose

Clause 4.3 is deceptively short. It says you need to determine the boundaries and applicability of the ISMS, considering external and internal issues, interested party requirements, and interfaces and dependencies between your activities and those of other organizations. In practice, this is the decision that sets the cost and complexity of everything else.

A consultant motivated by project size will push you toward a broader scope. "The whole company" sounds comprehensive. It's also frequently overkill. A SaaS product company whose primary compliance driver is enterprise customer security questionnaires probably has a natural scope boundary: the systems, people, and processes involved in developing, hosting, and delivering the product. Corporate functions - finance, marketing, most of HR - are often out of scope without any material risk to your certification or the security assurances you're making to customers.

Narrow scope done well beats broad scope done poorly in every audit I've seen. An auditor examining a tight, well-evidenced scope is easier to satisfy than one wading through a sprawling program with uneven coverage. Get the scope documented, get it signed off by leadership, and treat any expansion as a deliberate project decision rather than a default.

Risk assessment: the part that actually matters

Clause 6.1 is the heart of the standard. Everything in ISO 27001 flows from the risk assessment - your controls exist to treat identified risks, your SoA is derived from it, your treatment plans reference it. If your risk assessment is a generic list of 200 industry-standard risks that someone pasted in from a template, your ISMS is ornamental.

The standard doesn't prescribe a risk methodology. It requires that you define one (Clause 6.1.2) and apply it consistently. Asset-based, scenario-based, threat-based: all are acceptable. What matters is that the assessment reflects your actual environment and that the resulting treatment decisions are defensible. An auditor will sample your risks and ask how you arrived at the rating, what controls you selected in response, and whether they're operating. "It came from the template" is not an answer.

For a first ISMS, a focused risk register of 40-80 risks that you actually understand and have mapped to real controls is worth ten times a comprehensive 200-item list nobody can maintain. You can always expand it. Starting with something honest is non-negotiable.

One area that consistently gets under-served in first implementations: supplier and third-party risk. Clause 6.1 covers information security risks broadly, and your cloud providers, SaaS vendors, and development tools are part of your threat surface whether your consultants treated them that way or not. ISO 27001:2022 put a renewed emphasis on this with the expanded supplier controls in Annex A (particularly A.5.19 through A.5.23). If your risk assessment has nothing about your AWS environment, your CI/CD pipeline, or the SaaS tools your engineers use with production credentials, that's a gap that will come up in stage 2.

Annex A: the 93-control trap

Most of the over-engineering in first ISMS projects happens here. Someone looks at 93 controls and concludes that implementing them all is the safe play. It's not! It's the expensive play, and it's often counterproductive.

Controls that don't reflect your actual environment become paper controls. Paper controls fail audits, because auditors sample for evidence of operation, not just documentation of intent. A physical media control policy at a cloud-native company with no on-premise servers isn't demonstrating compliance - it's demonstrating that you copied from a template and didn't think about what you were copying.

The controls worth careful attention for a typical B2B SaaS company:

Access control (A.5.15-A.5.18, A.8.2-A.8.5). This is where auditors spend the most time and where most companies have the most genuine gaps. Joiners/movers/leavers process, privileged access management, access reviews - if these aren't operating and evidenced, nothing else in your ISMS saves you.

Cryptography (A.8.24). A single-page policy isn't enough. You need to show what's encrypted, where, with what, and under what key management arrangements. Cloud-native companies often have this handled by default tooling but haven't documented it.

Secure development (A.8.25-A.8.31). For SaaS companies, this cluster is where the audit gets technical. SAST, DAST, dependency scanning, code review process, change management - you don't need to implement every control, but you need to show your risk treatment rationale for anything you've excluded.

Incident management (A.5.24–A.5.28). Most companies have an incident response plan that's never been tested. Auditors know this. Having evidence of a tabletop exercise, even a light one, is worth more than a polished policy document.

Supplier relationships (A.5.19–A.5.23). As noted above, this gets more attention under ISO 27001:2022 than the 2013 version, and cloud-heavy companies tend to be under-prepared for it.

The controls you can often exclude or minimize with a clear justification: physical and environmental controls if you're cloud-native, media handling if you have no physical media, a substantial portion of the telecommunications controls depending on your architecture.

The Statement of Applicability is not a checkbox exercise

The SoA is one of the few documents the standard explicitly names. It needs to list all Annex A controls, state whether each is applicable, document implementation status, and provide justification for inclusions and exclusions. Your auditor will read it.

The failure mode is treating it as a binary table - "applicable / not applicable" with a one-line rationale that amounts to "we don't do this." A good SoA tells the story of your control environment. Why certain controls exist, what they're treating, and what evidence of operation exists. It's also the bridge between your risk assessment and your control implementation - every applicable control should trace back to a treated risk.

Building the SoA before the risk assessment is done is a common sequencing mistake that produces a document that doesn't reflect your actual decisions. Do the risk assessment, complete the risk treatment plan, then build the SoA from the treatment decisions. In that order.

Documentation: enough, not more

Clause 7.5 requires that you maintain documented information required by the standard and by your own ISMS. The key phrase is "required by your own ISMS" - whatever processes you define, you need documentation to support them. But you define the processes, which means you control the documentation burden.

Where consultants expand the scope: every process gets a formal procedure document, work instruction, and record template. Where a lean implementation works: define your processes at the right level of abstraction, document what matters, and resist the urge to create records nobody will maintain. An information security policy that's two pages and actually read by staff is better compliance than a twenty-page policy that lives in a SharePoint folder nobody visits.

One thing worth investing in that often gets shortchanged: the ISMS scope document and the internal audit program. Both are examined in every certification audit and both are frequently superficial in first implementations. The scope document should be specific enough that an auditor can determine what's in and what's out without asking. The audit program should show a realistic plan to cover the full scope over the audit cycle, not a single annual audit that samples three processes.

The management review: taking it seriously

Clause 9.3 requires management reviews at planned intervals covering a defined input list: audit results, nonconformities and corrective actions, monitoring results, risk assessment results, opportunities for improvement. This is not a fifteen-minute quarterly check-in. It's the mechanism by which leadership demonstrates commitment to the ISMS (Clause 5.1) and the mechanism by which the system actually improves.

Auditors examine management review records and look for evidence that the inputs were genuinely reviewed and that the outputs (decisions and actions) are tracked to completion. Generic minutes that restate the input list without real decisions are a red flag. If your management review doesn't result in at least some action items, you're probably not doing it right.

For small teams: a quarterly review with documented minutes covering the required inputs is proportionate. Twice a year is the minimum that typically satisfies auditors. Once a year rarely holds up.

Where to actually spend money on documentation

If you're doing your first ISO 27001 implementation and you want to move efficiently, the most defensible use of money isn't a consultant, it's a good documentation toolkit and internal time to customize it properly.

A quality toolkit gives you auditor-tested templates for everything the standard requires: the ISMS policy, the risk assessment methodology, the SoA, treatment plans, the internal audit program, and the full Annex A control documentation set. The alternative is writing all of that from scratch, which takes months and frequently produces documents that miss things a practitioner would catch.

The caveat is that templates only work if someone with domain knowledge customizes them to reflect your actual environment. A 148-template documentation set that's been filled in with placeholder text and renamed is not an ISMS. It's a folder. The templates handle the structure and the mandatory content requirements; your team handles the substance. That division of labor is where the value is.

IT Governance USA's ISO 27001 toolkit is the one I'd point practitioners to. It's built by the team that led the world's first ISO 27001 certification project, the templates are organized by clause and control, and the platform includes a gap analysis tool, an SoA tool, and an implementation manager to track progress. At $799 for the first year with a 12-month update service, it's a fraction of what a single consulting engagement costs, and it leaves you with documentation you actually own and understand.

The second-year problem

Certification is a stage 1 and stage 2 audit. Maintenance is surveillance audits in years two and three, then recertification. Most first-time implementations are built for certification and not for the years after it.

The things that tend to break down in year two: the internal audit program (nobody maintains it after the initial certification push), the risk assessment (it doesn't get updated when the environment changes), and access reviews (they happen once for certification and then quarterly cadence slips). These are the areas where surveillance auditors look hardest, because they know the pattern.

Building for maintainability from the start, with simpler processes, realistic audit cadence, clear ownership assignments, a risk register that's actually integrated into how you operate, is worth more than a comprehensive system that requires heroic effort to sustain.

If you're choosing between a more elaborate ISMS and a simpler one, and both satisfy the mandatory requirements, choose the simpler one. You'll be living with it for three years before recertification, and the team that built it probably won't all still be there.