If you’re building a SaaS product and selling to enterprise customers, you’ve probably already been asked for ISO 27001. Or you know it’s coming. I certainly get a lot of small startups and SaaS companies approaching me for support in getting certified without overcomplicating things.
This guide explains what ISO 27001 actually means for a software company, what’s different compared to other types of organisation, and how to get certified without it becoming an all-consuming project.
Why SaaS Companies Pursue ISO 27001
For most SaaS companies, the trigger is a specific enterprise sales conversation. A large customer — a bank, an NHS trust, a FTSE 250 business — wants to put your product in their procurement process. Their security team runs a vendor assessment. They ask about ISO 27001. And the deal stalls.
ISO 27001 has become the de facto standard that enterprise security and procurement teams recognise. It tells them that you have a formal, audited information security management system — that someone qualified has reviewed how you protect customer data and found it to be up to standard.
Beyond the sales trigger, SaaS companies increasingly find that certification:
- Reduces the friction of vendor security assessments (you can share your certificate and a summary rather than completing every questionnaire from scratch)
- Supports cyber insurance applications and can reduce premiums
- Provides a framework for managing security as the product scales
- Demonstrates a level of maturity that matters in M&A due diligence
What’s Different About ISO 27001 for a SaaS Company?
The standard is the same regardless of industry. But the way you apply it to a SaaS business has some specific characteristics:
You’re probably cloud-native
Most SaaS companies run on AWS, Azure, or Google Cloud rather than on-premises infrastructure. This changes how you approach several controls:
Your cloud provider is a shared responsibility model. AWS, Azure, and GCP are all ISO 27001 certified themselves — but that doesn’t mean you are. The provider is responsible for the security of the cloud (physical infrastructure, hypervisor, networking). You’re responsible for security in the cloud: your application, your data, your access controls, your configuration.
This is an important point to understand clearly. Having AWS as your infrastructure provider gives you strong foundations, but you still need to implement and evidence your own controls on top.
SaaS Shared Responsibility Model
ISO 27001 requires you to understand and document who is responsible for what — this split determines the scope of your ISMS
Your data is your customers’ data
SaaS companies are typically data processors under GDPR — you process personal data on behalf of your customers (who are the data controllers). This means:
- Your customer agreements should include appropriate data processing terms
- You need to understand what personal data you process and where it’s stored
- Your data retention and deletion processes need to be solid
- You’ll need to demonstrate to your customers that you protect their data appropriately
ISO 27001 certification is excellent evidence for this last point.
Your development environment is in scope
Unlike many organisations that just need to protect data in systems they use, SaaS companies build the systems. That means your software development practices are part of the ISMS:
- How you manage code access and review
- How you test security before releasing features
- How you manage vulnerabilities in your codebase and dependencies
- How you separate development, test, and production environments
Controls like 8.25 (Secure development lifecycle), 8.28 (Secure coding), 8.29 (Security testing), and 8.31 (Separation of environments) are highly relevant and auditors will look at them closely.
Security at Every Stage of Your SaaS Development Lifecycle
ISO 27001 Annex A requires security to be built in — not bolted on. Here's where each control fits in a typical SaaS pipeline.
- Define security requirements alongside functional ones
- Identify data classification needs
- Assess privacy and regulatory obligations
- Agree acceptance criteria
- Threat modelling (STRIDE / DREAD)
- Secure architecture review
- Principle of least privilege in design
- Encryption strategy for data at rest & transit
- Secure coding standards enforced
- SAST / linting in CI pipeline
- Secrets management (no hardcoded keys)
- Dependency vulnerability scanning
- DAST and penetration testing
- Security regression tests
- Separate test environments — no prod data
- Annual third-party pen test
- Change management approval process
- Configuration baseline enforced (IaC)
- Rollback plan documented
- Release sign-off by security
- Continuous monitoring & alerting
- Incident detection and response
- Patch management SLAs
- Periodic access reviews
Supplier management includes your cloud and SaaS stack
Your technology stack is often your biggest collection of “suppliers.” AWS, Cloudflare, Stripe, Salesforce, GitHub, Jira, Slack — each of these processes your data or has privileged access to your systems. Your supplier management process needs to cover them.
This doesn’t mean you conduct a full security assessment of each one — these are large, mature organisations with their own certifications. But it does mean you:
- Know which suppliers you use and what data they access
- Have reviewed their security certifications and terms
- Have considered what happens if they have an incident
Scoping Your ISMS as a SaaS Company
Getting the scope right is particularly important for SaaS companies. A few options:
Scope to the whole company — the most common approach for smaller SaaS businesses. The ISMS covers all operations, people, and systems. Simple to explain, clean for auditors.
Scope to a specific product or service — more appropriate if you have multiple distinct products or a large organisation where one product is seeking certification. You define the scope as the team and infrastructure responsible for that specific product.
Scope to include or exclude development — some organisations scope out development environments and focus the ISMS on production. This is possible but can create awkward gaps if your development processes genuinely affect security.
Whatever you choose, the scope document needs to be specific: what services are covered, what infrastructure, which teams, and which locations (or “cloud-only, remote-first” if applicable).
Key Controls for SaaS Companies
While all Annex A controls need to be considered, these are the ones that SaaS companies typically invest most effort in:
Access control (5.15, 5.16, 5.17, 5.18, 8.2, 8.3) — who has access to what? How is access granted, reviewed, and revoked? How do you handle privileged access to production systems?
Secure development (8.25–8.31) — your development lifecycle security practices. Code review, security testing, dependency management, secrets management.
Cloud configuration (8.9) — configuration management for your cloud infrastructure. Infrastructure-as-code, hardened defaults, no unnecessary open ports.
Vulnerability management (8.8) — how you identify, prioritise, and patch vulnerabilities in your systems and dependencies.
Encryption (8.24) — encryption at rest and in transit. This should be a given for a SaaS product but it needs to be documented and verified.
Incident management (5.24–5.27) — your plan for responding to a security incident. What’s the call tree? Who makes decisions? How do you notify customers?
Business continuity (5.29, 5.30) — how do you keep running if something goes wrong? What’s your RTO/RPO for key services?
Supplier management (5.19–5.22) — how you assess and manage your technology suppliers.
The Fastest Path to Certification
For a SaaS company with basic security hygiene already in place (MFA everywhere, access controls, HTTPS throughout, version control, basic incident response), a realistic timeline to certification is three to five months.
The fastest route:
- Gap analysis to understand where you are vs. where you need to be
- Document toolkit to build your policies and risk assessment quickly
- Implement any missing controls (access reviews, supplier assessments, staff training)
- Run an internal audit and management review
- Stage 1 and Stage 2 with your certification body
Explore the ISO 27001 toolkit — it’s designed specifically for organisations that want to move quickly without building everything from scratch.
Or if you want a guided, fixed-timeline approach, learn about the 90-day consultancy programme.
ISO 27001 Online Course + Full Toolkit
Stop guessing. Follow a proven step-by-step process.
“Highly recommended for anyone looking to understand ISO 27001, whether attempting it on your own or even using a consultant.“
Verified Trust.me Review
✓ Full toolkit included
✓ Learn as you build
✓ 12-month access
✓ 6 hours of video
✓ Email consultancy
✓ 30-day upgrade credit to consultancy
£285
Instant access
Common Questions from SaaS Companies
Does ISO 27001 cover our SaaS product itself, or just how we operate?
Both. The ISMS covers the organisation and its operations, including the way the product is built, deployed, and supported. If there’s a security vulnerability in your product, that’s an information security event within scope of the ISMS.
Our infrastructure is all in AWS. Does that help?
Yes, because AWS handles a lot of the physical and infrastructure-level controls. It doesn’t eliminate the need for your own ISMS, but it means some controls (physical security of data centres, for example) can reference AWS’s own certifications as part of your justification.
We’re a small team — do we really need all 93 controls?
No — you need to assess all 93, but you can exclude controls that genuinely aren’t applicable. A five-person remote-first SaaS company probably doesn’t have a “secure area” that requires a physical security perimeter policy. Just document your exclusions and justify them in the Statement of Applicability.
Can we be ISO 27001 certified on a cloud-only, remote-first basis?
Absolutely. Many SaaS companies have no office and no physical infrastructure — and that’s fine. The ISMS scope simply reflects your actual operating model. Auditors are well used to reviewing cloud-native, remote-first organisations.
