ISO 27001 for Growing SaaS: What It Actually Takes

Your sales team keeps coming back with the same message. The enterprise prospect liked the demo, the pricing works, procurement is ready to move, and then someone on their security team asks the question: “Are you ISO 27001 certified?” The answer is no, and the deal quietly moves to the back burner. Meanwhile the big consultancies quote you 300-500K DKK and nine months to get there, and your CFO understandably asks whether this is really the best use of cash.

There is a real path between ignoring the problem and handing over half a million kroner. This article walks through what ISO 27001 actually is, when it is worth pursuing, what the work really looks like, and what it should realistically cost a Danish or Nordic SaaS between 40 and 250 people. I've helped teams through this a few times now, and most of what you read online is either vendor marketing or consultant fear-mongering. The reality is more boring and more manageable.

What ISO 27001 actually is

ISO/IEC 27001:2022 is an international standard for an Information Security Management System, usually shortened to ISMS. The word that matters there is “management system.” This is not a technical checklist of firewalls and encryption algorithms. It is a framework for how your organization identifies information security risks, decides what to do about them, implements controls, and checks that the whole thing is working over time.

People often confuse ISO 27001 with its companion standard, ISO/IEC 27002:2022. The distinction matters. ISO 27001 contains the requirements you certify against. It is prescriptive about the management system itself: scope, leadership, planning, support, operation, performance evaluation, improvement. ISO 27002 is the guidance document that explains how to implement the individual controls. You get certified against 27001. You read 27002 when you need to understand what a specific control actually means in practice.

The 2022 version of the standard introduced Annex A, which lists 93 controls organized into four themes:

• A.5 Organizational controls (37 controls). Policies, roles, supplier relationships, incident management, the governance layer.
• A.6 People controls (8 controls). Screening, terms of employment, awareness training, disciplinary processes, remote working.
• A.7 Physical controls (14 controls). Secure areas, equipment, clear desk, working in secure areas. Much lighter if you're a cloud-native SaaS with no data center.
• A.8 Technological controls (34 controls). Access management, cryptography, secure development, logging, backup, network security, vulnerability management.

You do not have to implement all 93. You assess which apply to your business in your Statement of Applicability, justify any exclusions, and implement the ones that apply at a level proportionate to the risks you identified. That word, proportionate, is the heart of the standard and the thing most teams miss when they first read it.

When it is worth pursuing, and when it is not

ISO 27001 is a tool, not a goal. The question is whether it solves a problem you actually have. Here is the honest decision framework I use with advisory clients.

Pursue it if

• Your enterprise pipeline is blocked. You have two or more active deals where the buyer's security questionnaire explicitly asks for ISO 27001 or equivalent, and “we're working on it” is no longer buying you time.
• You sell into regulated customers. Banks, insurance, healthcare, public sector, critical infrastructure. Many of these have requirements flowing down from their own regulators (DORA, NIS2, GDPR processor obligations) that effectively require their suppliers to have a recognized ISMS.
• SOC 2 is not enough. SOC 2 is well known in North America but carries less weight with European buyers, particularly in regulated sectors. If your pipeline shifted from US mid-market to EU enterprise, you will feel this.
• You are going upmarket deliberately. You are moving from SMB to mid-market to enterprise over the next 18-24 months, and procurement gates will get harder, not easier.

Do not pursue it yet if

• You are under about 40 staff and not enterprise-selling. The overhead of maintaining an ISMS is real. If you don't have the pipeline to justify it, you are taking a tax on growth for no return.
• There is no clear pipeline signal. “Someone on the board thinks we should get certified” is not a pipeline signal. Count the deals. If the number is zero or one, it is probably too early.
• A simpler response would satisfy your buyers. A well-written security questionnaire response, a SIG-lite, or a short security whitepaper is often enough for your current tier of customers. Do that first.

The opportunity cost argument cuts both ways. Certification consumes 0.5-1 full-time equivalent for four to six months. That is real product work you are not shipping, real hiring conversations you are not having, real roadmap items that slip a quarter. But a blocked enterprise deal worth 2-5M DKK in ARR, multiplied across a few prospects, dwarfs that cost quickly. Do the math with your own numbers, not with vendor slide decks.

One more honest test: ask your two best sales people what percentage of their pipeline in the last six months has been delayed or lost because of a missing security certification. If the answer is under 15%, it is probably too early. If it is over 30%, you are already paying the cost of not being certified in lost revenue. Somewhere in between is a judgement call based on where you think the business is heading over the next 12 months.

The realistic timeline

For a reasonably prepared SaaS of 50-150 people with decent engineering hygiene already in place, four to six months end to end is achievable. I've seen teams try to do it in three, and they almost always slip. The bottleneck is rarely writing policies. It is accumulating enough operational evidence that the Stage 2 auditor can sample it.

Here is how the gates break down.

The evidence window at Gate 3 is where most timelines break. You cannot compress a three-month evidence period into three weeks by working harder. The auditor wants to see an access review that was actually run on a real schedule, an incident that was actually logged and closed, a supplier risk assessment that actually happened. In my experience the teams that try to shortcut this are the ones that get major nonconformities at Stage 2.

What the work actually involves

ISMS scope

This is the single most important decision you will make, and most teams get it wrong by over-scoping. You do not have to certify the whole company. You certify the ISMS that supports a defined set of products, services, and the teams and infrastructure that deliver them.

A well-scoped first certification for a SaaS might read something like: “The provision of the [Product Name] SaaS platform, including the engineering, product, security, and customer operations functions, and the supporting cloud infrastructure hosted in [region].” That excludes marketing, sales operations, finance, HR as a primary function, the office coffee machine, and everything else that does not directly deliver the product. You can always widen scope at recertification.

Narrow, defensible scope reduces the surface area the auditor can sample, reduces the number of controls that apply substantively, and reduces ongoing maintenance cost forever. Get this right before you write a single policy.

Policies and procedures

Somewhere online someone will tell you that you need 40 policies. You do not. For a SaaS of this size, I typically see the policy set land at 10-12 top-level documents:

• Information Security Policy (the umbrella)
• Access Control Policy
• Acceptable Use Policy
• Cryptography Policy
• Secure Development Policy
• Supplier Security Policy
• Incident Management Policy
• Business Continuity and Disaster Recovery Policy
• Data Classification and Handling Policy
• Human Resources Security Policy
• Physical and Environmental Security Policy (short, if you are cloud-native)
• Risk Management Policy

Below that sit procedures (how things are actually done) and records (evidence that they happened). The documentation pyramid runs policy to procedure to records. Auditors care about records more than anything else. A beautifully written policy with no evidence it is followed is worse than a scrappy policy with a clean audit trail.

Risk assessment and risk register

The 2022 standard requires a defined risk assessment methodology and a risk register that is actually used, not just produced once and filed. Pick a methodology that suits your organization. Likelihood and impact scored 1-5 on a matrix is fine for most SaaS. What matters is that you apply it consistently, you review risks at a defined cadence (quarterly is typical), and the risk register drives real decisions about which controls you implement.

Statement of Applicability

The SoA is the document that lists all 93 Annex A controls, states whether each one applies to you, and justifies the decision. It is the map between your risk assessment and the controls you have implemented. Auditors will read this closely. Exclusions need to be genuinely justified, not handwaved.

Internal audit and management review

You need an internal audit program that covers the whole ISMS over a defined period, usually annually. The internal auditor must be independent of the activity being audited, which for small SaaS usually means hiring an external fractional resource for this or using someone from a completely separate part of the business. You also need a management review, which is a documented meeting where leadership formally reviews ISMS performance. Both are audit-critical. Skip them and you will get findings.

The four real cost categories

Budgeting is where most conversations go off the rails, because the number you see in a consultancy proposal is rarely what you actually need to spend. There are four categories. Internal time is the largest. The others are smaller than you think.

Internal time

Plan on 0.5-1 FTE for four to six months. That is a security lead or a technical project owner carrying the work, plus material contributions from engineering, people operations, and legal at various points. If you count this cost honestly at blended rates, it is 300-600K DKK of loaded internal cost. This is the biggest line item in almost every certification, and the one most teams fail to budget for.

Advisor or consultant fees

This is where the gap between providers is enormous. A fractional advisor who has done this work before, engaged end to end, typically lands at 50-150K DKK total for the certification engagement depending on scope, organizational maturity, and how much of the writing and implementation the advisor does versus guides. A Big 4 or large dedicated compliance consultancy typically quotes 300-700K DKK for similar scope, sometimes more. The deliverables are broadly similar. The difference is overhead, brand premium, and whether you get a partner with 20 years of experience or a junior consultant working off a template.

Certification body fees

The accredited certification body (DNV, Bureau Veritas, BSI, Intertek, LRQA, TÜV, and others) charges for Stage 1, Stage 2, and annual surveillance audits. For a 50-150 person SaaS with reasonably tight scope, expect combined Stage 1 and Stage 2 fees in the 40-60K DKK range. Surveillance audits in years 1 and 2 are smaller, usually half to two-thirds of the initial cost. Recertification at year 3 is closer to the initial.

Tooling

GRC platforms like Vanta, Drata, Sprinto, Secureframe, and Thoropass will sell you a subscription that claims to automate compliance. For a first certification, tooling is optional. A well-maintained set of spreadsheets, a shared policy repository, and your existing ticketing system covers everything you need. If you do buy, expect 3-6K EUR per year for the platforms that are actually useful at this size. My honest view: wait until after your first certification to evaluate these. You will know what evidence you actually need, and you will buy a better tool with better requirements.

Totalled up, a realistic all-in budget for a first certification at this size sits somewhere between 450K and 800K DKK including internal time, advisor fees, and certification body fees. The number your Big 4 quote shows is not the total cost. It is one line item, often the line item with the least impact on whether you actually pass Stage 2.

The three buying options, honestly compared

There are effectively three ways to get from “we should do this” to a certificate on the wall. They are not equivalent, and the right choice depends on what you value.

DIY works if you have hired a CISO or head of security who has personally led an ISO 27001 certification before. It does not work if your lead is learning on the job. The standard rewards experience, and the mistakes are not obvious until the auditor finds them.

The fractional advisor model works well for companies at this size because the work is bounded, the advisor is accountable for outcomes, and your internal team learns enough to run the ISMS on their own once certified. The Big 4 option makes sense if you are a bank, you are buying insurance rather than compliance, or your board is going to ask who you used by brand.

Common traps I see

Over-scoping the ISMS

I've seen teams decide to certify the entire company when they could have certified the product and its supporting infrastructure. The larger scope doubled their workload, added months to the timeline, and did not win them a single additional deal. Every customer security questionnaire I've seen accepts a scope statement that clearly covers the service being purchased.

Buying a GRC tool before knowing what evidence you need

The sales pitch is that the tool automates compliance. The reality is that the tool automates collection of evidence you have already decided to produce. If you have not defined your controls or your evidence requirements, the tool will happily collect the wrong things beautifully. Buy the tool after your first certification, not before.

Writing 40 policies because someone said you needed them

Policy sprawl is a sign of copy-pasted templates, not of a mature ISMS. Every policy you write is a policy you need to maintain, review, train people on, and demonstrate compliance with. Fewer, better policies always win.

Running risk assessment as a box-tick

If your risk register was populated once in week 3 and never updated, the auditor will see it, and it will shape their opinion of your entire ISMS. Risk assessment is supposed to drive management decisions. Make it drive at least one visible decision during the evidence period (a control added, a supplier changed, a project prioritized) and the whole system becomes easier to defend.

Treating internal audit as optional

Internal audit is a hard requirement. It is also the control that most commonly gets neglected because it feels like administrative overhead. Budget for it, assign an independent auditor, and get it done before Stage 2. Do not try to have the same person who wrote the policies audit them.

Skipping supplier risk because “we don't really have suppliers”

Your cloud provider is a supplier. Your CI/CD platform is a supplier. Your email, your identity provider, your database-as-a-service, your monitoring stack, your payroll system. SaaS companies have lots of suppliers. The 2022 version of the standard takes supplier security more seriously than the 2013 version did. A short supplier risk assessment for your critical vendors is non-negotiable.

Picking a certification body without checking lead time

Some certification bodies are booked out two or three months in advance, particularly in the Nordics. If you plan your Stage 2 for week 22 and only call the certification body in week 18, you will miss your window. Engage the certification body early, ideally at Gate 1, and lock in Stage 1 and Stage 2 dates well in advance.

What changed in the 2022 revision

If you have read older material or have a 2013 certification to transition, here is what is different.

• Annex A reorganized. The 14 control domains of the 2013 version were collapsed into 4 themes (Organizational, People, Physical, Technological). The structure is cleaner and reflects how modern organizations actually think about controls.
• Controls reduced from 114 to 93. Some controls were merged, some split, some consolidated. The net count is lower but coverage is broader.
• 11 new controls added. The notable ones include threat intelligence, information security for use of cloud services, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering, and secure coding. Most of these formalize things mature engineering teams already do informally.
• Attributes added to controls. Each control now carries attributes (control type, information security properties, cybersecurity concepts, operational capabilities, security domains) that let you filter and group controls in different ways. Useful for reporting, not required for certification.

If you hold a 2013 certificate, your certification body has a defined transition process. Most organizations can transition at their next surveillance audit with moderate additional effort. The IAF transition deadline (31 October 2025) has passed for new certifications, so any new certification is against 2022 directly.

What the audits actually look like

Stage 1

Stage 1 is a documentation review and readiness check. The auditor reads your ISMS scope, your policies, your Statement of Applicability, your risk assessment, your internal audit results, and your management review minutes. They spend one to two days on this, usually remote. The output is a Stage 1 report listing areas you need to address before Stage 2. None of it should be a surprise if you have done the work. Stage 1 is not pass/fail in the same way Stage 2 is, but unresolved Stage 1 findings will block Stage 2.

Stage 2

Stage 2 is the real thing. The auditor samples evidence across the ISMS. They pick three or four employees and trace their onboarding: offer letter, contract, background check, access provisioning, security training completion. They pick two recent production changes and trace them through your secure development process: ticket, code review, test evidence, deployment approval. They pick two suppliers and ask for the risk assessment, the contract review, the ongoing monitoring. They ask to see incident records, access reviews, vulnerability scan outputs, backup restoration tests.

Stage 2 takes two to five days depending on scope and organization size. At the end, the auditor writes findings at three levels: major nonconformities (which block certification until resolved), minor nonconformities (which require a corrective action plan but do not block), and observations (improvement suggestions). Common Stage 2 findings I've seen:

• Access reviews not actually performed at the stated cadence
• Supplier risk assessments missing or stale for at least one critical vendor
• Incidents closed without the required post-incident review or lessons learned
• Management review held but minutes do not cover all required inputs
• Risk register not updated after a material change in the business
• Training completion records incomplete, particularly for new joiners

All of these are avoidable with a disciplined evidence period. None of them require more than ordinary operational hygiene.

The auditor is not your enemy. They have seen hundreds of ISMS implementations, and they are usually happy to have a real conversation about how you run yours. If something is imperfect but you can explain the reasoning, show the risk-based decision, and point to compensating activity, most experienced auditors will raise an observation rather than a nonconformity. Be honest about what you do and do not do. Trying to hide a gap almost always makes it worse when the auditor finds it by sampling.

After certification: the annual rhythm

The certificate is valid for three years. The certification body performs surveillance audits in year 1 and year 2, each smaller in scope than Stage 2 (usually one to three days depending on organization size). In year 3 you go through a recertification audit, which is broader again and leads to a new three-year certificate.

Between audits, the ISMS needs to actually live. That means running your defined cadences:

• Quarterly or semi-annual risk register review
• Annual internal audit covering the full ISMS across a defined period
• Annual management review with documented inputs and outputs
• Scheduled access reviews (typically quarterly for privileged access, semi-annual for general)
• Annual supplier reassessment for critical vendors
• Annual business continuity test
• Ongoing security awareness training and phishing simulations
• Ongoing incident management with post-incident reviews
• Ongoing vulnerability management and remediation tracking

Most of this is work you would do anyway if you take security seriously. The ISMS gives it structure and makes it auditable. The teams that struggle post-certification are the ones that treated the certification as a project with a deadline rather than a change to how they operate. The ones that do it well barely notice the surveillance audits because they are auditing the same disciplines they run every month anyway.

Closing

ISO 27001 is not a silver bullet and it is not a nightmare. It is a defined, bounded piece of work that opens a specific commercial door when the pipeline signal justifies it. If you have two or more enterprise deals stalled on a missing certificate, it is almost certainly worth doing. If you are doing it because it feels like the grown-up thing to do, think again.

If you want to talk through whether it is worth it for your specific situation, or stress-test a plan you already have, a scoping call is free. No pitch deck, no follow-up email sequence, no pressure. Just an honest conversation about whether the work actually fits the problem you have today.