ISO 27001 is a general-purpose information security standard. It was designed to certify banks, hospitals, manufacturers, government agencies, and software companies under one framework. That generality is a feature -but it makes the standard hard to apply directly to a modern SaaS product. The controls that matter for a 200-person engineering team running a multi-tenant cloud platform are different from the ones that matter for a 200-person factory. The standard treats both as in scope.
This guide is the SaaS-specific lens on ISO 27001. Scope decisions that fit a cloud product, the Annex A controls that actually carry the audit weight in this context, how the shared responsibility model affects the implementation, and the customer-trust artefacts that turn the certificate into a competitive asset. If you have read the general implementation roadmap, this is the SaaS-specific complement.
1. Why SaaS Is Different
The standard does not care that you are SaaS. But four characteristics of the SaaS operating model materially affect how each clause and control plays out:
- Multi-tenancy. Customer A's data sits on the same database, application stack, and infrastructure as Customer B's. Logical segregation, not physical separation, is the boundary. A.5.34 (privacy and protection of PII) and A.8.31 (separation of development, test, and production environments) become more sensitive -and tenant isolation becomes a control the auditor will explicitly test.
- Cloud-native infrastructure. You do not own data centres. You do not own hardware. The physical and environmental controls of Annex A.7 are largely outsourced to the cloud provider -but the auditor still expects you to manage that outsourcing rigorously through supplier controls.
- DevOps velocity. Production deploys happen daily, sometimes hourly. Change management cannot be a weekly Change Advisory Board meeting. The control must be designed to fit the velocity -automated security gates in CI/CD, peer review with security context, post-deploy monitoring, fast rollback.
- Customer-data sensitivity. Customers send you their data, often regulated data (PII, PHI, financial). Your security posture is part of their compliance posture. They will ask security questionnaires, request the SoC reports, and require contractual protections (DPAs, sub-processor lists).
For most SaaS companies the right pattern is ISO 27001 as the primary certification, supplemented by ISO 27017 (cloud-services security) and often ISO 27018 (cloud privacy of PII). 27017 and 27018 are extensions, not separate certifications -they layer additional cloud-specific controls on top of an ISO 27001 ISMS. Larger customers will ask about 27017/27018 specifically when SaaS is your model.
2. Scoping the ISMS for SaaS
Scope is the single most consequential decision in any ISO 27001 project -but for SaaS companies the scope question has a specific shape. The product is the asset. Everything that supports the product is candidate scope.
Typically In Scope
- Production environment hosting the SaaS product
- The product itself -application code, APIs, infrastructure-as-code
- CI/CD pipelines and build infrastructure
- Development environments where production data may transit
- Customer-facing identity and access systems
- Customer support tooling with data access
- Engineering, security, and infra teams
- Logging, monitoring, and SIEM systems
- Cloud accounts hosting the product
Typically Out of Scope
- Marketing website and content management
- Lead CRM with no customer data
- HR systems with no customer data access
- Other non-SaaS product lines (separate scopes)
- Corporate IT (laptops, email, productivity tools) where they do not handle customer data
- Geographic regions with no production presence
- Acquired products not yet integrated
The "single product or product family" rule
For multi-product SaaS companies, the cleanest first certification scopes to one product or one closely-related product family. Adding products later is straightforward -adding the wrong scope at the start is expensive. If you have two products on completely different infrastructure, certify them in sequence rather than together. The auditor's sample sizes scale with scope, not with product count.
The boundary statement
Write the scope as a sentence the auditor can verify, not a paragraph nobody reads. Example: "The ISMS covers the production infrastructure, application code, CI/CD pipelines, and customer-support tooling for ProductName, hosted in AWS regions us-east-1 and eu-west-1, including the engineering, security, and customer-support teams that operate it." That sentence is short enough to test on the ground -the auditor walks through every clause and asks "does this match the scope?"
3. The Annex A Controls That Matter Most for SaaS
All 93 Annex A controls are technically in play. But ~30 carry the audit weight for a typical SaaS organisation. The auditor will sample more deeply in these areas and expect strong operating evidence.
Identity and access -the highest-weight area for SaaS
Access Control, Identity Management, Authentication, Privileged Access
For SaaS, this is everything. MFA on every production system, SSO for the engineering team, just-in-time elevation for production access, regular access reviews. The auditor will sample 5-10 access changes over the audit period and verify approval, implementation, and review evidence for each.
Privileged Access, Information Access Restriction, Secure Authentication
The technical implementations of the policy controls above. Strong password policies, MFA enforcement (technical control verified, not just policy), SSH key rotation, service account management, secret storage. Auditors increasingly ask to see actual configuration -not just policy claims.
Cryptography and data protection
Use of Cryptography
Encryption in transit (TLS configuration on every public endpoint), encryption at rest (database and object storage), key management lifecycle (rotation, escrow, revocation). Customers increasingly ask about key custody -whether you hold keys or use the cloud provider's KMS.
Operations and change management
Change Management
The hardest control to get right for a SaaS company. Must be designed to fit DevOps velocity -automated security checks, peer review with security context, deploy approval lightweight for routine changes and rigorous for high-risk ones. Auditors test by sampling production changes over the audit period.
Logging, Monitoring Activities
What gets logged, where logs are stored, how long they are retained, who reviews them, what triggers an alert, who responds. For SaaS the volume is significant -auditors expect a SIEM or equivalent, with documented use cases and response procedures.
Information Backup
Backup strategy, retention, and restoration testing. The standard does not just want backups -it wants evidence you have tested restoring from them. A documented restoration test once or twice a year, with timing and outcome captured, is what auditors sample.
Development and acquisition
Secure Development Life Cycle, Secure Coding
Documented SDLC with security gates at each phase. Code review requirements that include security considerations. Secure coding standards published and known to engineers. Often the lightest-touch area for SaaS audits, because mature engineering teams typically already do these things -the question is whether they are documented as requirements, not just practices.
Security Testing in Development
Static analysis (SAST), dependency scanning (SCA), dynamic application testing (DAST), and penetration testing. Auditors expect to see evidence of each running and triaging findings. Annual external pen test results are commonly sampled.
Supplier security -heavy for SaaS
Information Security in Supplier Relationships
The most under-prepared area for many SaaS companies. Risk assessment of each sub-processor and major vendor. Contracts with DPA addenda for processors of customer data. Maintained sub-processor list. Onboarding and offboarding controls. Auditors will sample 3-5 supplier files and check completeness.
Incident management
Information Security Incident Management
Incident classification, response procedure, evidence collection, notification (including regulatory and customer notification timelines), post-incident review. For SaaS, customer notification SLAs in DPAs become material here -if your contract says "notify within 72 hours of confirmed breach," your incident response process needs to make that achievable.
Business continuity
ICT Readiness for Business Continuity
The 2022 update added explicit ICT readiness requirements. For SaaS this means RTO/RPO definitions per service, documented failover procedures, regular continuity tests. Multi-region deployments make this much easier; single-region deployments require more rigorous documentation of degraded modes.
4. Cloud & Shared Responsibility
Every major cloud provider publishes a shared responsibility model. AWS, Azure, GCP each define which security responsibilities sit with them and which sit with the customer. For ISO 27001, your scope covers your responsibilities, not theirs.
What the cloud provider handles
- Physical security of data centres (A.7 controls largely outsourced)
- Hardware lifecycle and disposal
- Hypervisor security and tenant isolation at the hardware layer
- Network infrastructure between availability zones and regions
What you handle
- Identity management within your cloud accounts
- Network segmentation (security groups, VPC design, firewalls)
- Encryption key management and configuration
- Application-layer security
- Logging and monitoring of your workloads
- Tenant isolation at the application layer
- Backup and restoration strategy for your data
- Cloud-account access controls and audit logging
How the audit treats the cloud provider
Auditors will not audit AWS, Azure, or GCP directly. They will check that you treat them as suppliers under A.5.19-5.23 -risk assessed, contracted (cloud provider Master Service Agreement + DPA), with their compliance posture verified (your auditor will ask to see the provider's most recent SoC 2, ISO 27001 certificate, and ISO 27017 certificate). They will also sample your configuration in the cloud -your IAM policies, your VPC design, your KMS configuration -to verify you are operating your side of the line correctly.
A common misconception -"AWS is ISO 27001 certified, so we are covered." No. The cloud provider's certification covers their infrastructure. Yours has to cover what you build on top of their infrastructure. The provider's certificate is evidence of supplier compliance, not a substitute for your own certification.
5. Security in CI/CD
The fastest-moving area of any SaaS company is the deploy pipeline. ISO 27001 does not require you to slow it down. It requires you to demonstrate that security is built into it.
The CI/CD security stack
- Pre-commit: Secret scanning, license compliance checks. Catches credentials before they reach the repository.
- Pull request: Static application security testing (SAST), dependency vulnerability scanning (SCA), security-aware code review. Findings block the merge by default for high-severity items.
- Build: Software bill of materials (SBOM) generation, container image scanning if applicable. Artefacts are signed before publication.
- Pre-deploy: Infrastructure-as-code security checks (e.g. Terraform compliance scanning). Production deploy approval -automated for low-risk changes, gated for high-risk ones.
- Post-deploy: Dynamic application security testing (DAST), runtime monitoring, anomaly detection. Rollback is automated for critical detections.
This is one workflow with security at each phase, not a separate "security release". For auditors, the evidence is straightforward -pipeline configuration, scan results retained for the audit period, examples of findings that blocked a merge, examples of incident response triggered by post-deploy detection.
The audit evidence for CI/CD security
- Pipeline configuration stored in version control, demonstrating security checks are required not optional.
- Sample findings from each tool over the audit period. Auditor wants to see findings, not just claims that scanning happens.
- Triage records showing how findings are classified and prioritised. Severity-1 findings reaching production is a finding the auditor will follow up on.
- Change-by-sample. Auditor picks 5 production changes from the audit period and walks each through the pipeline -what scans ran, what findings were generated, what approvals occurred, what monitoring detected.
6. Sub-Processors & Supplier Security
SaaS companies typically use 10-30 sub-processors -third parties that process customer data on their behalf. Email delivery, payment processing, analytics, customer support tooling, error tracking, monitoring providers. Each one is a supplier under Annex A.5.19-5.23.
The four supplier artefacts
- Sub-processor list. A maintained, customer-facing list of every sub-processor that handles customer data, plus the purpose and the data type. Most SaaS companies publish this on their trust page.
- Supplier risk assessment. For each sub-processor, an assessment of the risk they introduce -based on what data they touch, where they operate, and their own compliance posture. Reviewed annually.
- Contracts with DPAs. Data Processing Agreements addressing the GDPR and equivalent obligations. Required for any sub-processor handling personal data. Pre-signed by the vendor's standard DPA template, ideally, to avoid renegotiation per customer.
- Sub-processor monitoring. Routine review of sub-processor compliance posture -annual review of their security certifications, incident notifications, contract changes. Documented in a supplier review log.
How auditors test supplier security
The auditor will pick 3-5 sub-processors from your list and trace each through the lifecycle. Was risk assessed before onboarding? Is the contract in place with appropriate DPA? Has the supplier been reviewed in the past 12 months? Is their certification still valid? Gaps in this lifecycle are common Minor NCs and occasional Major NCs.
7. Customer-Trust Artefacts
ISO 27001 certification is internal -it certifies your ISMS. But once you have it, customers will want to consume it. The companion artefacts are what turn the certificate from compliance achievement into commercial asset.
The four artefacts that matter most
Trust page
A public-facing page on your website that brings together your compliance posture in one place -ISO 27001 certificate (downloadable), security overview, sub-processor list, DPA template, incident disclosure history, security questionnaire response (often via Whistic, Vanta Trust Reports, or similar). Enterprise sales cycles materially shorten when a buyer can self-serve answers to standard questions.
DPA template
A pre-drafted Data Processing Agreement that customers can sign as part of the contract. Saves negotiation time on every deal. Standard provisions: parties' roles, types of data processed, security measures, sub-processor list, breach notification timeline, audit rights, data return on termination.
Security questionnaire response library
Customer security questionnaires (SIG, CAIQ, custom) ask hundreds of overlapping questions. Build a library of vetted answers that maps your ISMS to the common questionnaire frameworks. Answer once, reuse across customers. Annual review to keep answers current with the actual control state.
Incident disclosure history
A history page listing material security incidents disclosed in the past 12-36 months. Transparency here is increasingly expected by enterprise customers. The absence of disclosures over a long window is sometimes more concerning than a small number of well-handled disclosures.
Certification without the supporting customer-trust artefacts is incomplete. Most enterprise buyers will not request the ISO 27001 certificate directly -they will ask their standard set of questions, and the certificate is one of many inputs to their assessment. Build the certificate; build the platform around it.
Implementing ISO 27001 for a SaaS product?
SecComply has implemented ISO 27001 across many SaaS organisations -from early-stage seed to scale-up. Cloud-native scope, DevOps-compatible controls, sub-processor governance, and the trust artefacts that turn the certificate into a sales asset.
Book a SaaS-specific call →FAQ
Yes -the cloud infrastructure that hosts the SaaS product is in scope. The shared-responsibility model means the cloud provider is responsible for some controls (physical security of data centres, hardware lifecycle, hypervisor isolation) and you are responsible for others (identity management, encryption configuration, network segmentation, logging). ISO 27001 audits your side of the line. Combine ISO 27001 with ISO 27017 (cloud-specific guidance) or ISO 27018 (cloud privacy) for sharper alignment with cloud-specific concerns.
Most SaaS companies scope the ISMS as "the production environment supporting the named product or product family, including the development, build, deployment, and operations infrastructure, the support function that has customer-data access, and the corporate functions that materially handle customer data such as legal and finance." Excluded scope is typically marketing tooling, lead-management CRM with no customer data, and any non-customer-facing product lines.
Sub-processors -third parties that process customer data on your behalf, such as email delivery, payment processing, analytics -fall under Annex A supplier controls (A.5.19 through A.5.23). They are not in your ISMS scope, but your management of them is. Auditors will check sub-processor risk assessments, contracts with DPAs in place, and a maintained sub-processor list.
ISO 27001 does not require change-freeze gates that would slow DevOps. It requires change management to be defined, documented, and consistently applied. A well-designed change process for a SaaS company often looks like: peer code review with security checklist, automated security scanning in CI/CD, deploy-to-production approval that can be lightweight for routine changes and rigorous for high-risk ones, post-deploy monitoring. The audit tests whether the process exists and is followed, not whether it slows you down.
Not for ISO 27001 directly, but most B2B SaaS companies build one shortly after certification because it dramatically shortens enterprise sales cycles. A trust page typically includes the ISO 27001 certificate, SOC 2 if applicable, sub-processor list, DPA template, security overview, and incident disclosure history. Customers asking the same questionnaire over and over can self-serve answers.