ISO 27001 Readiness for SaaS: The Complete Guide

Most SaaS companies do not fail ISO 27001 because their security is weak. They struggle because their management system is thin, their evidence is scattered, and control ownership is unclear when the auditor starts sampling. This guide walks through what readiness actually means for a 50-250 person SaaS, fintech or payments business, and how to build a system that holds up under scrutiny rather than one assembled the week before a stage 1 audit.

What ISO 27001 Really Requires for SaaS

ISO 27001 is a standard for an Information Security Management System, or ISMS. That word "system" matters. The certificate is not awarded for having good controls. It is awarded for demonstrating that you identify risks, decide how to treat them, implement controls, and then check that those controls keep working over time.

For a SaaS company, this splits into two parts:

• The management system clauses (4 to 10): context, leadership, planning, support, operation, performance evaluation and improvement. These are non-negotiable and often the weakest area for engineering-led teams.
• The Annex A controls: the 93 controls in the 2022 revision, grouped into organizational, people, physical and technological themes. You select which apply and justify the rest.

Auditors spend a surprising amount of time on clauses 4 to 10. A founder who can talk fluently about firewalls but cannot show a risk treatment plan or a management review record will lose time and confidence in the room. Readiness means both halves are real.

To be clear, Kellwick is an advisory firm, not a certification body. We help you get genuinely ready. A separate accredited certification body runs the audit and issues the certificate. No advisor can guarantee a certification outcome, and you should be wary of anyone who does.

Why Product-Led Readiness Matters

For a SaaS business, the product is the asset. Your customer data, your build pipeline, your cloud infrastructure and your access model are where real risk lives. A readiness effort that treats ISO 27001 as a documentation exercise, sitting to one side of engineering, produces a system that looks compliant and behaves fragile.

Product-led readiness means the ISMS reflects how you actually build and run software:

• Controls map to your real cloud accounts, repositories and CI/CD pipeline.
• Evidence is produced as a byproduct of normal engineering work, not manufactured for the auditor.
• Engineers recognize the controls as things they already do, described in ISMS language.

When readiness is product-led, the audit samples your day-to-day reality and finds it consistent. When it is document-led, the audit finds a gap between the policy and the pull request. That gap is where nonconformities come from.

Scope Decisions

Scope is the first major decision, and it is easy to get wrong in both directions. Too broad, and you take on controls and evidence for parts of the business that add cost without adding customer value. Too narrow, and your certificate does not cover what customers actually care about, which defeats the commercial purpose.

A defensible SaaS scope usually covers:

• The production platform and the data it processes.
• The teams that build, operate and support that platform.
• The corporate systems that touch it: identity, laptops, code hosting, cloud.

Getting the Scope Statement Right

Write a scope statement that names the service, the locations or "remote-first" model, and the boundaries. State clearly what is in and what is out, and why. If you use AWS, Google Cloud or Azure, the underlying data centres are the provider's responsibility under a shared responsibility model. Your scope covers how you configure and operate on top of that. Make this explicit so the auditor is not left guessing.

Building a Risk Register That Works

The risk register is the engine of the ISMS. Done well, it drives everything downstream: your controls, your Statement of Applicability and your improvement plan. Done badly, it is a spreadsheet nobody reads.

A working register has a few properties:

1. Risks are specific to your business, not generic. "Unauthorized access to customer database via leaked long-lived credentials" beats "cyber attack."
2. Each risk has an owner who can actually influence it.
3. Each risk is scored for likelihood and impact using a consistent, documented method.
4. Each risk has a treatment decision: mitigate, accept, transfer or avoid.
5. Accepted risks are signed off by someone senior enough to accept them.

Keeping It Alive

The most common finding is a register that was written once and never revisited. Set a cadence. Review the top risks quarterly and after any significant change: a new product line, a major architecture shift, a serious incident. The register should show movement over time. A register with identical scores across three quarters tells an auditor nobody is looking.

The Statement of Applicability

The Statement of Applicability, or SoA, is the document that connects your risk decisions to the Annex A controls. For every one of the 93 controls, you state whether it applies, whether it is implemented, and your justification.

Two mistakes are common. The first is marking almost everything applicable to look thorough, then failing to produce evidence for controls you do not really operate. The second is excluding controls without a credible reason. If you exclude physical security controls because you are remote-first, say so and explain how you handle the few physical assets you have, such as laptops. Every exclusion needs a rationale an auditor will accept.

The SoA is also a living document. When you add a control or change how one works, the SoA should reflect it. Treat it as the index to your whole ISMS.

Evidence: What Auditors Actually Sample

Evidence is where readiness is won or lost. Auditors do not accept "we do this." They ask to see it, and they sample. Understanding what they sample lets you prepare the right artifacts.

Typical samples for a SaaS business:

• A specific new joiner: show the onboarding checklist, access grants and security training completion.
• A specific leaver: show that access was revoked within your stated timeframe.
• A specific production change: show the pull request, review, approval and deployment record.
• A specific incident: show the ticket, timeline, response and any follow-up actions.
• A specific access review: show who reviewed what, when, and what changed as a result.

The pattern is consistent. The auditor picks a real case and follows it end to end. If your evidence is complete and timestamped, this is quick. If you have to reconstruct it, the audit slows and doubt grows.

Make Evidence a Byproduct

Wherever possible, generate evidence automatically. Use your identity provider for access logs. Use your CI/CD system for deployment records. Use your ticketing tool for incidents and changes. The goal is that producing evidence costs almost nothing because the system already records it.

Access Reviews

Access control is one of the most heavily sampled areas, especially for fintech and payments companies. You need a clear model: least privilege, role-based access where practical, and multi-factor authentication enforced.

Run periodic access reviews, typically quarterly for production and sensitive systems. For each review, record who reviewed the access, what they checked, and what was removed or changed. A review that never removes anything is a warning sign. Real reviews find stale access, and the evidence should show that.

Supplier and Subprocessor Risk

SaaS companies run on third parties: cloud providers, payment processors, analytics tools, support platforms. ISO 27001 expects you to manage this supply chain, and your customers increasingly ask about it directly.

Build a subprocessor inventory that lists each supplier, what data they touch, and their assurance status, such as their own ISO 27001 or SOC 2 report. For material suppliers:

• Assess them before onboarding, proportionate to the data they handle.
• Keep contracts and data processing agreements on file.
• Reassess periodically and when their role changes.

Keep the inventory current. When customers or auditors ask, you produce it in minutes rather than assembling it under pressure.

Change, Release and SDLC Evidence

Your software development lifecycle is core scope for a SaaS ISMS. The relevant Annex A controls cover secure development, change management, separation of environments and testing. The good news is that a modern engineering team already does most of this. The task is to make it visible.

Show that:

• Changes go through review before reaching production.
• Production is separated from development and test.
• Deployments are recorded and traceable to an approved change.
• Security is considered in development, through code review, dependency scanning and testing.

You do not need heavy process. You need a consistent, evidenced flow from commit to production that an auditor can sample and follow.

Incident Management

Incidents happen. What matters is that you detect, respond, record and learn. You need a documented incident process, a way to classify severity, and defined roles for response.

Every incident should leave a record: what happened, when, who responded, the impact, and the corrective actions taken. Auditors like to sample a real incident and trace it. If you have had none, be ready to show a test or tabletop exercise instead. A team that claims zero incidents ever is not more secure, it is less credible.

Internal Audit, Management Review and Corrective Actions

These three clauses are where document-led readiness usually collapses, so treat them as first-class work.

Internal Audit

Before the certification body arrives, you audit yourself. An internal audit checks the ISMS against the standard and against your own procedures. It must be objective, so the person auditing an area should not be the person who runs it. Record findings and feed them into improvement.

Management Review

Leadership must formally review the ISMS at planned intervals, at least annually and ideally quarterly. The review looks at risks, incidents, audit findings, objectives and resources, and produces decisions. Keep minutes. This is a clause 9 requirement and a common finding when it is skipped.

Corrective Actions

When something goes wrong, whether a nonconformity or an incident, you record it, find the root cause, fix it and verify the fix held. A living corrective action log is strong evidence that your ISMS improves rather than stagnates.

The Operating Rhythm Between Cycles

Certification is not the finish line. The certificate lasts three years with surveillance audits in between, so the ISMS has to keep running. The companies that stay ready with minimal pain are the ones with a steady operating rhythm:

• Quarterly: access reviews, risk register review, management review.
• Monthly: check outstanding corrective actions and supplier changes.
• Annually: full internal audit, policy review, objectives reset.
• Continuously: evidence generated automatically from your existing tooling.

This rhythm turns readiness from an annual scramble into a habit. Surveillance audits become routine because nothing was ever allowed to lapse.

Common SaaS Mistakes

• Treating ISO 27001 as documentation and ignoring clauses 4 to 10.
• Writing a risk register once and never updating it.
• Marking controls applicable in the SoA with no evidence behind them.
• Reconstructing evidence for the audit instead of generating it continuously.
• Skipping management review and internal audit until the last minute.
• Access reviews that never remove access.
• A subprocessor list that is out of date the day it is written.
• Buying a tool and assuming the tool is the ISMS. The tool helps. The system is yours.

The 90-Day Readiness Checklist

A realistic path for a focused SaaS team:

1. Define and document scope, including the scope statement.
2. Build the risk register with owners, scoring and treatment decisions.
3. Draft the Statement of Applicability against all 93 Annex A controls.
4. Stand up core policies: information security, access control, incident response, supplier management, secure development.
5. Wire up evidence collection from identity, CI/CD and ticketing tools.
6. Implement and evidence quarterly access reviews.
7. Build the subprocessor inventory and gather supplier assurance.
8. Confirm change and release records trace commit to production.
9. Run one internal audit and log the findings.
10. Hold a management review and record the minutes.
11. Close or plan any corrective actions raised.
12. Establish the ongoing operating rhythm before you engage a certification body.

Bottom Line

ISO 27001 readiness for SaaS is not about proving you are secure on one day. It is about building a management system that produces evidence continuously, assigns clear ownership, and improves over time. Get the risk register, the SoA and the evidence flow right, keep the operating rhythm, and the audit becomes a confirmation of how you already work rather than a test you cram for.

If you want an objective view of where you stand, a Kellwick readiness review will map your current state against the standard, flag the gaps that matter and give you a practical plan to close them. No guarantees of certification, just a clear-eyed assessment and a route to being genuinely ready.