ISO 27001 Certification for SaaS Companies: Your Questions Answered

SaaS companies pursuing ISO 27001 certification tend to arrive at the process with a specific set of questions — some of which differ meaningfully from those asked by traditional enterprises. The nature of SaaS businesses creates particular scoping considerations, supplier dependencies, and commercial drivers that shape how certification works in practice.

This guide addresses the questions we hear most often from SaaS companies going through certification for the first time.

---

Why do SaaS companies pursue ISO 27001?

The driving force is almost always commercial. Enterprise customers — particularly larger organisations in financial services, healthcare, legal, and the public sector — increasingly require ISO 27001 certification as a condition of vendor selection or contract renewal. Security questionnaires have become a standard part of procurement, and certification provides a credible, independently verified answer to a significant portion of them.

Beyond procurement, certification has a secondary benefit: it forces a structured review of your security posture. Many SaaS companies that go through the process discover gaps they did not know existed — not because they were being negligent, but because fast-growing software companies tend to build features first and formalise processes later. ISO 27001 provides the framework to catch up systematically.

A third driver, particularly for companies operating in or entering regulated markets, is regulatory positioning. Demonstrating ISO 27001 certification can support compliance with GDPR, sector-specific data protection requirements, and customer contract obligations around data security.

---

Does the whole company need to be certified, or just the product?

This is the most common scoping question from SaaS companies, and the answer is: it depends on what your customers are actually buying, and what you can credibly ring-fence.

If your customers are purchasing and relying on a specific product or service, it is entirely legitimate to scope the ISMS around that product and the teams, processes, and infrastructure that support it. This is how many SaaS companies achieve their first certification — a defined product scope — rather than certifying the entire business.

For this to work cleanly, the in-scope product must be genuinely separable from the rest of the business. The teams involved in product development, operations, and support need to be identifiable. The infrastructure supporting the product — your cloud environment — needs to be distinct or at least clearly bounded. Shared services like HR and finance can typically be excluded from scope, provided they do not have direct access to in-scope systems or customer data.

Where this approach creates difficulty is when your ISMS scope does not match what customers think they are getting. If a customer asks “is your product ISO 27001 certified?” and you say yes, but your customer data is actually processed by a part of the business that is outside scope, that is a problem — both ethically and practically, as a sophisticated customer will interrogate your scope statement.

---

What does the scope statement look like for a SaaS product?

A well-constructed SaaS scope statement typically names:

• The product or service being certified (e.g. “the ClientPortal SaaS platform”)
• The teams involved in its delivery (development, operations, customer support)
• The cloud infrastructure on which it runs (e.g. “AWS eu-west-1, production and staging environments”)
• Any explicit exclusions and their rationale

Example: “The ISMS covers the design, development, hosting, and customer support of the ClientPortal SaaS platform operated by Acme Technologies Ltd. The scope includes the product engineering team, platform operations team, and customer success team, and the AWS eu-west-1 infrastructure hosting the platform. Internal corporate IT systems, the finance function, and the sales team are outside the scope of this ISMS.”

The scope statement becomes part of your certificate. Sophisticated procurement teams will read it.

---

We run everything on AWS (or Azure, or GCP). Does our cloud provider’s certification count for us?

No — but it does help. AWS, Azure, and GCP are all ISO 27001 certified, which means the security of the underlying cloud infrastructure is independently verified. You can and should reference your cloud provider’s certification when completing security questionnaires, but it does not substitute for your own.

The reason is straightforward: cloud provider certification covers the security of the cloud infrastructure. Your certification covers the security of what you build on top of it — your application, your configuration decisions, your access controls, your code, your processes. The shared responsibility model means you own security responsibility for everything above the infrastructure layer, and that is what your customers’ procurement teams want to see evidenced.

Where cloud certifications help is in Annex A compliance. Controls relating to physical security (data centre access, environmental controls) and certain infrastructure controls may reference your cloud provider’s certified posture as evidence that those controls are addressed.

---

What are the most relevant Annex A controls for a SaaS company?

While all applicable controls matter, several are particularly central to SaaS environments:

Access control (Controls 5.15–5.18 and 8.2–8.5). Managing who can access your production environment, customer data, and internal systems is fundamental. Privileged access management, just-in-time access, and regular access reviews are all directly relevant.

Secure development (Controls 8.25–8.32). For software companies, the secure software development lifecycle is a core area of scrutiny. Code review processes, security testing, vulnerability management in dependencies, and separation of development/production environments are all in scope.

Cryptography (Control 8.24). Encryption of customer data at rest and in transit is expected. Your key management approach will be examined.

Supplier relationships (Controls 5.19–5.22). Your SaaS product likely relies on a chain of third-party services — cloud providers, payment processors, email services, analytics tools, monitoring platforms. Each represents a link in the security chain, and the standard requires you to manage those relationships.

Logging and monitoring (Control 8.15–8.16). Evidence that you can detect, alert on, and investigate security events in your production environment.

Vulnerability management (Control 8.8). How you track and remediate security vulnerabilities in your application and infrastructure. This often overlaps with your existing engineering processes around dependency management and patching.

---

How does the risk assessment work for a SaaS company?

The same way as for any organisation — you identify information assets, assess threats and vulnerabilities, score likelihood and impact, and decide on treatment options. What differs is the shape of the risk landscape.

For a SaaS company, your most significant information assets are typically: customer data (including personal data), the source code and intellectual property that constitutes your product, and the availability of the service itself. Your threat landscape is likely dominated by: external attack against your application or infrastructure, insider threats (developers with production access), supply chain compromise through third-party dependencies, and cloud misconfiguration.

A risk assessment that reflects a SaaS company’s actual environment will look different from a generic enterprise risk register. Your auditor will expect to see risks that are specific and credible, not a generic list of IT risks that could apply to any organisation.

---

What about our customers’ data? Are we the controller or processor?

Most SaaS companies are data processors under GDPR — you process personal data on behalf of your customers, who are the controllers. This matters for ISO 27001 because:

• Your customers’ data is an information asset that must be protected
• Your contractual obligations to customers form part of your “interested party requirements” under Clause 4.2
• Breach notification obligations run both to regulators and to your customers as data controllers
• Your Data Processing Agreements (DPAs) may contain specific security requirements that should be reflected in your ISMS

The processor relationship also means that if your organisation suffers a personal data breach, your customers are entitled to notification so they can fulfil their own controller obligations. Your incident response procedure should reflect this explicitly.

---

How long does certification take for a SaaS company?

The timeline varies considerably depending on your starting point. A SaaS company with mature engineering processes, existing security tooling, and a culture of documentation will move faster than one starting from scratch.

A realistic timeline for a first certification:

• Gap assessment and planning: 4–8 weeks
• Implementation (policies, procedures, controls): 3–6 months
• Internal audit and management review: 4–6 weeks
• Stage 1 audit: typically 2–4 weeks after booking
• Addressing Stage 1 findings: 2–4 weeks
• Stage 2 audit: typically 4–8 weeks after Stage 1
• Certification decision: 1–2 weeks after Stage 2

Total: typically 9–15 months from starting implementation to receiving a certificate. Some well-prepared organisations move faster; organisations with significant control gaps take longer.

---

What do customers actually check once we’re certified?

Most customers, once you share your certificate, will verify that it is current (not expired), that the scope covers the product or service they are procuring, and that it was issued by an accredited certification body. Some will ask for a summary of your last audit findings.

Larger enterprise customers with sophisticated procurement teams may go further — reviewing your scope statement, asking for your Statement of Applicability, requesting security questionnaire responses that go beyond the certificate, or conducting their own vendor security assessments. Certification makes these conversations easier and faster; it does not eliminate them entirely.

The certificate is most valuable as a first filter. It allows procurement teams to confirm a baseline level of security assurance without conducting a full assessment. For most SME SaaS companies, this is exactly what unlocks the enterprise deals that drove the certification investment.

---

Do we need to certify our staging and development environments?

This depends on your scope decision and what data those environments contain. If your staging environment contains real customer data — even anonymised or partially masked — there is a strong argument that it should be within scope. Development environments that contain production-equivalent data are a common finding: the security controls applied to production are often not applied consistently to staging, yet the data is the same.

Best practice for SaaS companies is to ensure that non-production environments do not contain real customer data, that access controls are applied consistently across environments, and that the boundary between production and non-production is clearly managed. This makes scoping decisions cleaner and reduces the security risk that blurred environment boundaries create.

---

What does the certification body actually look at during the audit?

At the Stage 2 audit — the certification assessment — auditors will sample controls across your ISMS. For a SaaS company this typically includes:

• Access control evidence: who has access to production, how is it provisioned and reviewed, is privileged access managed
• Incident management: have you had incidents, how were they handled, what evidence exists
• Secure development: how is code reviewed, how are vulnerabilities managed, how is the production environment protected from development changes
• Supplier management: what third-party services do you rely on, how are they assessed, what contractual protections are in place
• Risk assessment: is it current, does it reflect your actual environment, are treatment decisions documented
• Management review and internal audit: have these taken place, are they evidenced

They will also confirm that your documentation (policies, procedures) is approved, current, and accessible to staff who need it.

---

Common Mistakes

Scoping out too much. A scope that excludes the teams and systems that actually handle customer data is not a credible scope. Auditors understand SaaS environments — they know that the development team has access to production systems and that this needs to be controlled, not excluded.

Treating certification as a documentation exercise. SaaS companies with engineering culture sometimes approach ISO 27001 as a writing exercise — producing policies that do not reflect how the organisation actually operates. Auditors interview staff and examine systems; paper controls that do not match reality are quickly identified.

Neglecting the human element. The most technically sophisticated SaaS companies often focus on technical controls and underinvest in the people-related Annex A controls — training and awareness, acceptable use policies, HR security. People controls are frequently where findings occur.

Not involving engineering leads. ISMS implementation led solely by an operations or compliance function, without meaningful involvement from engineering leadership, tends to produce an ISMS that sits alongside engineering processes rather than being embedded in them. For a SaaS company, security needs to be part of how engineers build and operate the product.

---