ISO 27001
ISO 27001 for SaaS companies: the implementation guide
Everything you need to run an ISO 27001:2022 implementation for a SaaS product, written for the person who has to actually do it. Clause by clause, with the documents auditors ask for, realistic timings, and the failure modes that catch first-timers.
The short version
- ISO 27001 certifies a management system. The 93 Annex A controls are the visible part; Clauses 4 to 10 are what actually gets audited first.
- Your scope statement and Statement of Applicability are the two documents Stage 1 exists to check. Get them wrong and nothing downstream matters.
- Internal audit and management review are mandatory, frequently skipped, and the fastest way to fail Stage 1.
- Budget 12 to 20 weeks to audit-ready for a 10 to 100 person SaaS company with reasonable engineering hygiene, plus the certification body's own scheduling.
- The certificate runs on a three-year cycle with surveillance audits in years one and two. Most lapses are calendar failures, not control failures.
Almost nobody sets out to get ISO 27001 certified. What happens is that a deal reaches procurement, a security questionnaire lands, and someone forwards it to engineering with a note asking how long this will take. That is the real starting point for most SaaS companies, and it shapes everything about how the project should be run.
This guide covers ISO/IEC 27001:2022 specifically. If you are looking at older material referencing 114 controls in 14 domains, that is the 2013 version, and the transition period for existing certificates closed in October 2025. Everything below assumes the 2022 revision.
What ISO 27001 actually certifies
The certificate says you operate an Information Security Management System that meets the standard. Not that your product is secure. Not that you have no vulnerabilities. It says you have a repeatable system for identifying risks to information, deciding what to do about them, and checking that the decisions were carried out.
That distinction sounds academic until you are sitting in a Stage 2 audit. The auditor will spend far more time asking who approved a risk treatment decision and when it was last reviewed than asking whether your TLS configuration is current. They are testing the machinery, not the output.
The standard splits into two parts, and teams consistently underestimate the first one.
| Part | What it covers | Negotiable? |
|---|---|---|
| Clauses 4 to 10 | Context, leadership, planning, support, operation, performance evaluation, improvement. The management system itself. | No. Every requirement applies to every organisation. |
| Annex A (93 controls) | The security controls: access control, cryptography, logging, supplier relationships, secure development and so on. | Yes. You justify inclusion or exclusion of each one in your Statement of Applicability. |
Compliance platforms are built almost entirely around Annex A, because controls map neatly to evidence you can collect automatically. Clauses 4 to 10 do not automate well. They require decisions, and decisions need a person who can explain them.
Drawing the scope
Clause 4.3 requires you to determine the boundaries of the ISMS. This is the single most consequential decision in the project and it takes about two hours to get right.
For a SaaS company the useful scope is almost always the product, the environments that run it, and the people who can access either. Something like:
The provision of the [Product] SaaS platform to customers, including the development, operation and support of the platform and its supporting cloud infrastructure, and the head office and remote working environments of personnel involved.
Two things to watch. First, whatever you write here has to be consistent with your asset inventory, your risk register and your supplier list. If your scope says cloud infrastructure and your asset inventory lists three AWS accounts but you actually run four, that inconsistency will surface, and it makes an auditor start pulling other threads.
Second, resist the urge to scope broadly to look impressive. A wider scope means more controls in play, more evidence to maintain, and more surface for a nonconformity. It also means more of your business gets disrupted during surveillance audits every year for the life of the certificate. Customers care that the product is in scope. They do not care that your marketing team is.
The Statement of Applicability
The SoA is required by Clause 6.1.3 d). It lists all 93 Annex A controls and, for each one, states whether it applies, why, and whether it is currently implemented. It is the document an auditor will have open for most of Stage 2.
The 2022 revision reorganised the controls into four themes:
| Theme | Controls | Typical SaaS relevance |
|---|---|---|
| A.5 Organizational | 37 | Policies, roles, supplier relationships, incident management, legal and contractual requirements. Nearly all apply. |
| A.6 People | 8 | Screening, terms of employment, awareness and training, disciplinary process, remote working. Nearly all apply. |
| A.7 Physical | 14 | Where remote-first companies legitimately exclude several, with a written justification about not operating data centres or offices. |
| A.8 Technological | 34 | Access control, cryptography, logging, secure development, vulnerability management, network security. Nearly all apply. |
Exclusions are allowed and normal. A fully remote company with no offices and no on-premise infrastructure will reasonably exclude several A.7 controls. What matters is the justification. "Not applicable" is not a justification. "The organisation does not operate physical premises or data centre facilities; all infrastructure is provided by cloud service providers assessed under A.5.19 to A.5.22" is.
Risk assessment, and why auditors can spot a fake one
Clause 6.1.2 requires a defined process for assessing information security risk, and Clause 8.2 requires you to perform it at planned intervals and when significant changes occur. The words "planned intervals" are doing a lot of work there.
A register populated in a single sitting is visible from across the room. Every risk has the same creation date, the same assessor, and a suspiciously even distribution of scores. Real risk management leaves a trail: entries added at different times, some risks accepted with a written rationale and a named approver, at least one reassessed after an incident or an architecture change.
Your methodology needs to state, at minimum:
- How you identify risks (asset-based, scenario-based, threat-based, or a combination)
- Your impact and likelihood scales, with what each level actually means in your business
- Your risk acceptance criteria, and who has authority to accept a residual risk at each level
- How often the register is reviewed, and what events trigger an out-of-cycle review
On the last point, pick a cadence you will genuinely keep. Quarterly is common and defensible. Monthly sounds diligent in the document and becomes a nonconformity in month four when the records stop.
The documents the standard actually requires
People ask for a definitive list of mandatory documented information. Here it is, with the clause that requires each one. Anything beyond this is either an Annex A control artefact or something you chose to write.
| Clause | Document or record |
|---|---|
| 4.3 | Scope of the ISMS |
| 5.2 | Information security policy |
| 6.1.2 | Information security risk assessment process |
| 6.1.3 | Information security risk treatment process |
| 6.1.3 d) | Statement of Applicability |
| 6.2 | Information security objectives and plans to achieve them |
| 7.2 | Evidence of competence |
| 8.1 | Evidence that processes were carried out as planned |
| 8.2 | Results of information security risk assessments |
| 8.3 | Results of information security risk treatment |
| 9.1 | Evidence of monitoring and measurement results |
| 9.2 | Internal audit programme and audit results |
| 9.3 | Results of management reviews |
| 10.2 | Nature of nonconformities, actions taken, and results |
Fourteen items. A typical consultancy will hand you sixty documents. Most of the extra is Annex A control evidence, which you do need, but the distinction matters when you are triaging what to write first.
Internal audit and management review
These two get skipped more than anything else in the standard, and they are both mandatory. Clause 9.2 requires internal audits at planned intervals. Clause 9.3 requires top management to review the ISMS at planned intervals. If neither has happened, you are not ready for Stage 1, regardless of how complete your controls are.
The internal audit has an independence requirement: the auditor cannot audit their own work. In a company of twenty people this is genuinely awkward, and there are three normal solutions. Someone from a different function audits, an external party runs it, or your consultant runs it while a member of staff owns the outcome. All three are accepted in practice.
Management review needs specific inputs, listed in Clause 9.3.2: status of actions from previous reviews, changes in external and internal issues, feedback on security performance, results of risk assessment and treatment status, audit results, and opportunities for improvement. Write the minutes against those headings. An auditor will check them off.
What happens in Stage 1 and Stage 2
Stage 1
Usually a day, often remote. The auditor reviews your documentation and assesses whether you are ready for Stage 2. They will read the scope, the SoA, the risk assessment, the internal audit report and the management review minutes. They will ask questions about anything inconsistent between them.
You will get a written outcome listing areas of concern. These are not nonconformities in the formal sense, but anything on that list will be examined closely at Stage 2. Treat it as a to-do list with a deadline.
Stage 2
Two to four days for a company of this size, depending on scope and headcount. This is the effectiveness audit. The auditor samples: they will pick three leavers and ask to see the offboarding records, pick a change and trace it through your change management process, pick a supplier and ask for the due diligence.
They will interview control owners directly. This catches teams out. Your access control policy might be excellent, but if the engineer who runs the quarterly access review cannot describe how they do it, that is a finding. Prepare each named owner for a fifteen minute conversation about their own control.
| Type | Meaning | Effect |
|---|---|---|
| Observation / opportunity for improvement | Not a failure. A suggestion. | None. Address it before the next surveillance if you agree with it. |
| Minor nonconformity | An isolated lapse against a requirement. | Certificate can still be recommended. You submit a corrective action plan, usually within 30 days, and evidence of closure. |
| Major nonconformity | A systemic failure, or total absence of a required process. | Certification is withheld until resolved and verified, often requiring a follow-up audit. This is the outcome to avoid. |
Major nonconformities are rare when the internal audit was run properly, because the internal audit is designed to find exactly the things a Stage 2 auditor would find. That is the entire reason it is mandatory.
Realistic timelines and costs
For a SaaS company between roughly 10 and 100 people, with MFA already enforced, cloud infrastructure managed as code, and no prior ISMS:
| Phase | Elapsed | What dominates the effort |
|---|---|---|
| Gap analysis and scoping | Weeks 1 to 3 | Asset inventory, control-by-control assessment, threat model |
| ISMS build | Weeks 2 to 10 | Scope, SoA, risk methodology and register, policy set |
| Remediation | Weeks 3 to 14 | Access reviews, logging, onboarding and offboarding, supplier due diligence |
| Security testing | Weeks 6 to 12 | Penetration test, remediation of findings, retest |
| Internal audit and management review | Weeks 10 to 14 | Running them properly, and fixing what they find |
| Stage 1 | Week 14 to 18 | Certification body scheduling is often the constraint here |
| Stage 2 | 4 to 8 weeks after Stage 1 | Sampling, interviews, evidence |
On cost, there are two separate numbers and conflating them causes most of the confusion in the market.
- Implementation support. Market rate for consultant-led ISO 27001 runs roughly $15,000 to $30,000. Ours starts at $9,500.
- Certification body fees, paid directly to them and never marked up by a consultancy. Budget roughly $8,000 to $25,000 for Stage 1 plus Stage 2, and $4,000 to $10,000 a year for surveillance.
Get quotes from at least two accredited certification bodies. Prices vary more than you would expect for the same audit days, and accreditation matters: a certificate from a body accredited by a recognised national accreditation body is what enterprise procurement checks for.
Where first-time certifications actually fail
Not on technical controls. In our experience the failures cluster into four patterns, and all four are avoidable.
- The scope statement contradicts another document. Usually the asset inventory or the supplier list. Cheap to fix, expensive to discover at Stage 1.
- The risk register has one creation date and no review history. Fixable only by starting earlier, which is why the risk work should begin in week two rather than week ten.
- Policies describe an aspirational company. If the access control policy says quarterly reviews and you have run one, you have written yourself a nonconformity. Write what you do, then improve the practice.
- Control owners cannot describe their own control. The document is correct, the person has never read it. Fifteen minutes of preparation per owner solves this entirely.
After the certificate arrives
The certificate is valid for three years. Surveillance audits happen in years one and two, and a full recertification in year three. Surveillance audits are shorter, typically one to two days, and sample a subset of controls plus anything flagged previously.
What lapses certificates is almost never a control failure. It is a calendar failure: the annual internal audit does not get scheduled, the risk register is not refreshed, the management review does not happen, and the surveillance audit arrives to find twelve months of nothing. Put all four in a recurring calendar with a named owner on the day the certificate is issued.
Pre-Stage 1 readiness check
- Scope statement signed off, and consistent with the asset inventory and supplier list
- Statement of Applicability complete, with a written justification for every exclusion
- Risk methodology documented, register populated, at least one review cycle recorded
- Information security policy approved by top management, with a date and a version
- Full policy set covering the Annex A controls you claimed
- Access reviews run at the stated frequency, with retained records
- Onboarding and offboarding checklists completed for recent joiners and leavers
- Supplier due diligence records for your significant vendors
- Independent security testing complete, findings remediated and retested
- Internal audit performed, report written, corrective actions tracked
- Management review held, minutes written against the Clause 9.3.2 inputs
- Each control owner briefed and able to describe their control
If you are starting this week
Do the scope statement and the asset inventory first. Everything else depends on them, and both are quick. Start the risk register in week two so it has history by the time an auditor sees it. Book the certification body early, because their scheduling is frequently the longest pole in the whole project, and book the penetration test with enough runway to fix what it finds.
If you want a picture of where you stand before committing to any of it, our readiness assessment maps your current position to the specific Annex A controls in about four minutes, and gives you the gaps ranked. It costs nothing and does not require an email for the score.
Common questions
No, and neither can a compliance platform. Certificates are issued by certification bodies accredited by a national accreditation body, and they must be independent of whoever implemented your controls. Any vendor claiming to certify you is either misusing the word or selling something that enterprise procurement will not accept.
There is no minimum in the standard, and we have seen certified companies under ten people. The question is commercial rather than technical: if nobody is asking for it, the money is usually better spent on the underlying security work. Once a deal is blocked on it, the calculation changes immediately.
No. Maintenance for a company of this size is roughly two to four days a quarter, plus the annual internal audit and management review. What you do need is a named owner with the authority to make the calendar happen, because the failure mode is neglect rather than difficulty.
Different rather than harder. ISO front-loads scoping, risk methodology and internal audit. SOC 2 Type II front-loads evidence discipline across an observation window of three to twelve months. Teams with strong process documentation often find ISO easier; teams with strong automation often find SOC 2 easier.
Keep it. It handles evidence collection and drift monitoring well, which is real work. It will not scope your ISMS, produce a defensible risk assessment, write policies matched to your business, run your internal audit, or justify a control exclusion to an auditor. Those are the parts that decide the outcome.
This guide is maintained by the innsecs practice and last reviewed on 7 September 2026. It reflects how we run these engagements. It is not legal advice, and standards get revised, so check the current text of any standard before relying on a clause reference.