ISO 27001 Requirements: Clauses 4-10 Explained for SaaS Teams

ISO 27001 requirements are defined in Clauses 4 through 10 of the standard. These seven clauses specify what your Information Security Management System (ISMS) must include, how it must operate, and how your organization must govern it. They are mandatory — every single requirement in Clauses 4-10 must be addressed to achieve certification. There are no optional clauses.

This is the part of ISO 27001 that many SaaS teams misunderstand. They jump straight to Annex A — the catalog of 93 security controls — and start implementing technical measures. But Annex A controls are selected based on your risk assessment (Clause 6), documented in your Statement of Applicability (also Clause 6), and you can exclude controls with justification. Clauses 4-10, on the other hand, cannot be excluded. They are the management system requirements that make the security controls sustainable.

Think of it this way: Annex A controls are the “what” of information security (encrypt data, manage access, monitor logs). Clauses 4-10 are the “how” of running a security program (understand your context, get leadership buy-in, plan based on risk, support with resources, operate consistently, measure performance, improve continuously). For a complete overview of Annex A, see our Annex A Controls guide.

This guide breaks down each clause with what the standard requires, what auditors evaluate, how SaaS companies should implement each requirement, and the common mistakes that lead to nonconformities. If you’re just getting started with ISO 27001, our What Is ISO 27001? overview provides the foundational context.

Understanding the Clause Structure

ISO 27001:2022 is organized into sections:

• Clauses 0-3: Introduction, scope, normative references, terms and definitions. These are informational — no auditable requirements.
• Clauses 4-10: The mandatory ISMS requirements. Every sub-clause contains “shall” statements that your organization must satisfy.
• Annex A: A reference set of 93 controls organized into 4 themes (Organizational, People, Physical, Technological). Controls are selected based on your risk assessment and documented in the Statement of Applicability.

The relationship between the clauses and Annex A is critical: Clause 6 (Planning) requires you to conduct a risk assessment and determine which Annex A controls are needed to treat the identified risks. The clauses drive the management system; Annex A provides the control options for risk treatment. You cannot implement Annex A without the clauses, and the clauses without Annex A would be a management system with no security controls.

For a step-by-step certification approach that maps these requirements to a project plan, see our ISO 27001 Certification Checklist.

Clause 4: Context of the Organization

Clause 4 requires you to understand your organization, its environment, and the needs of stakeholders before designing your ISMS. This is the foundation — everything else in the ISMS flows from the context you establish here.

4.1 Understanding the Organization and Its Context

What the standard requires: Determine external and internal issues that are relevant to your organization’s purpose and that affect your ability to achieve the intended outcomes of your ISMS.

What auditors evaluate: The auditor wants to see documented evidence that you’ve considered the broader context in which your organization operates. This isn’t a theoretical exercise — it should reflect your actual business environment.

SaaS implementation:

• External issues: Regulatory requirements (GDPR, CCPA, industry-specific regulations), market expectations (customer security requirements, competitive landscape), technology trends (cloud security evolution, emerging threats), economic conditions, and supply chain risks (cloud provider dependencies, third-party integrations).
• Internal issues: Organizational structure, company culture and security awareness maturity, technical architecture (cloud infrastructure, application stack, data flows), existing security capabilities, resource availability, and strategic objectives.
• Documentation approach: Create a context analysis document that catalogs these issues. Many SaaS teams use a PESTLE analysis (Political, Economic, Social, Technological, Legal, Environmental) for external factors and a SWOT analysis for internal factors. Keep it practical — this document should inform real decisions about your ISMS scope and risk assessment, not sit in a drawer.

Common mistake: Treating this as a one-time exercise. Your context changes — new regulations appear, your customer base shifts, your technology stack evolves, new threats emerge. Review and update your context analysis at least annually, and whenever significant changes occur.

4.2 Understanding the Needs and Expectations of Interested Parties

What the standard requires: Identify the interested parties (stakeholders) relevant to your ISMS, determine their requirements regarding information security, and determine which of those requirements will be addressed through your ISMS.

What auditors evaluate: A documented list of stakeholders, their security-related requirements, and how those requirements feed into your ISMS design.

SaaS implementation:

Interested Party	Their Requirements
Customers	Data protection, availability, incident notification, security certifications, contractual SLAs
Regulatory bodies	GDPR compliance, data breach notification, lawful processing, data protection impact assessments
Employees	Personal data protection, clear security responsibilities, adequate training
Investors/Board	Risk management, business continuity, security governance reporting
Cloud providers	Shared responsibility model compliance, configuration security
Partners/Integrations	API security, data handling agreements, access controls
Industry bodies	Standard compliance, best practice adherence

Common mistake: Listing stakeholders without connecting their requirements to ISMS decisions. Each stakeholder requirement should trace to specific controls, policies, or processes in your ISMS. If a customer requirement is “encrypt data at rest and in transit,” that requirement should be traceable to specific Annex A controls in your Statement of Applicability.

4.3 Determining the Scope of the ISMS

What the standard requires: Define the boundaries and applicability of your ISMS, considering the external and internal issues (4.1), stakeholder requirements (4.2), and interfaces and dependencies between your activities and those of other organizations.

What auditors evaluate: A documented scope statement that clearly defines what is included and excluded, with justification for exclusions. The scope must be available as documented information.

SaaS implementation:

A well-defined scope for a SaaS company typically includes:

• The SaaS application and all supporting infrastructure (cloud environments, databases, application servers, CDN, DNS)
• The CI/CD pipeline and development infrastructure
• The team responsible for developing, deploying, and operating the application
• Customer data processed by the application
• Corporate systems that directly support information security (identity provider, email, communication tools, endpoint management)
• Physical locations from which the team operates (offices, or a statement about remote work arrangements)

Scope statement example: “The ISMS covers the development, deployment, operation, and maintenance of [Product Name], a cloud-based SaaS platform hosted on AWS, including all customer data processing activities, supporting IT infrastructure, and the team of [X] employees located at [location/remote]. The scope includes the cloud infrastructure (AWS eu-west-1 and us-east-1), the application layer, the CI/CD pipeline, and the administrative systems used to manage these services.”

Common mistake: Scoping too broadly (including every corporate system regardless of security relevance) or too narrowly (excluding systems that clearly affect the security of in-scope services). Your CB will challenge a scope that doesn’t make logical sense. If your identity provider controls access to everything in scope but the IdP itself is out of scope, the auditor will flag this as a gap.

4.4 Information Security Management System

What the standard requires: Establish, implement, maintain, and continually improve an ISMS in accordance with the requirements of the standard.

What auditors evaluate: Evidence that the ISMS exists as a functioning system — not just a collection of documents, but an integrated set of processes, controls, and governance mechanisms that work together.

SaaS implementation: This clause is satisfied by implementing everything in Clauses 4-10. It’s a meta-requirement — confirmation that the ISMS is established (designed and documented), implemented (operating in practice), maintained (kept current), and continually improved (enhanced based on performance data and changing conditions).

Clause 5: Leadership

Clause 5 ensures that information security isn’t an isolated initiative — it’s integrated into the organization’s leadership and governance. Without genuine leadership commitment, an ISMS becomes a paper exercise that satisfies the auditor but doesn’t actually protect information.

5.1 Leadership and Commitment

What the standard requires: Top management shall demonstrate leadership and commitment to the ISMS by ensuring the information security policy and objectives are established, ensuring integration of the ISMS into the organization’s processes, ensuring resources are available, communicating the importance of effective information security management, ensuring the ISMS achieves its intended outcomes, directing and supporting persons to contribute to ISMS effectiveness, promoting continual improvement, and supporting other relevant management roles.

What auditors evaluate: Evidence that leadership is genuinely involved — not just signatures on policies, but active participation in security governance. Auditors frequently interview executives to verify their understanding and engagement.

SaaS implementation:

• Executive participation in management reviews. The CEO, CTO, or equivalent must participate in formal ISMS management reviews (Clause 9.3). Meeting minutes should show executive presence, discussion of security topics, and decisions about resource allocation.
• Budget allocation. Leadership demonstrates commitment through budget — approving funding for security tools, GRC platforms, training, consulting, and dedicated security headcount.
• Strategic integration. Information security objectives should align with business objectives. If the company strategy includes expanding into regulated markets, the security program should evolve to support that expansion.
• Visible engagement. Leadership sets the tone. CEOs who skip security training, ignore policy requirements, or deprioritize security initiatives send a clear message to the organization — and auditors pick up on it.

Common mistake: Treating leadership commitment as a formality — getting the CEO to sign the information security policy and nothing more. Auditors test this requirement by interviewing leaders and asking them to describe their role in the ISMS, what security risks concern them, and how they ensure the program is effective. If a leader can’t answer these questions, the auditor may raise a nonconformity.

5.2 Policy

What the standard requires: Top management shall establish an information security policy that is appropriate to the purpose of the organization, includes information security objectives or provides the framework for setting them, includes a commitment to satisfy applicable requirements, and includes a commitment to continual improvement.

What auditors evaluate: The information security policy document itself, plus evidence that it’s been communicated to all employees and relevant external parties, and that it’s available as documented information.

SaaS implementation:

Your information security policy is the top-level document in your ISMS. It sets the direction and establishes the principles that all other policies and procedures follow. For SaaS companies, this policy should:

• State the organization’s commitment to protecting customer data and its own information assets
• Define the scope and objectives of the ISMS
• Commit to compliance with applicable legal, regulatory, and contractual requirements
• Commit to continual improvement of the ISMS
• Be written in language appropriate to your organization (a 40-person SaaS company doesn’t need a 20-page policy written in corporate legalese)

The information security policy is supported by topic-specific policies covering access control, cryptography, asset management, human resources security, incident management, and other areas. See our ISO 27001 Policies guide for the complete list and templates.

Common mistake: Writing an information security policy that’s generic and disconnected from the organization’s actual context. If your policy could belong to any company in any industry, it’s not appropriate to your purpose. A SaaS company’s policy should reflect cloud-native security principles, customer data protection priorities, and the specific regulatory landscape the company operates in.

5.3 Organizational Roles, Responsibilities, and Authorities

What the standard requires: Top management shall ensure that the responsibilities and authorities for roles relevant to information security are assigned and communicated.

What auditors evaluate: Documentation showing who is responsible for what in the ISMS, plus evidence that these people understand their responsibilities.

SaaS implementation:

Define and document security roles and responsibilities across the organization. For a SaaS company, this typically includes:

Role	ISMS Responsibilities
CEO/Founder	Overall accountability for the ISMS, resource allocation, strategic direction
CTO/VP Engineering	Technical security controls, secure development practices, infrastructure security
ISMS Manager/Security Lead	Day-to-day ISMS management, risk assessment coordination, audit preparation, policy maintenance
Engineering Managers	Secure development practices within their teams, access management, change control
HR Manager	Employee onboarding/offboarding security procedures, training coordination, background checks
All Employees	Compliance with policies, incident reporting, security awareness

In smaller SaaS companies, one person often holds multiple roles. That’s fine — document it and ensure the person has the bandwidth. The auditor will verify that roles are assigned, not that you have a dedicated person for every function.

Common mistake: Assigning responsibility without authority. If the ISMS Manager is responsible for information security but doesn’t have the authority to enforce policy compliance, approve security expenditures, or escalate issues to leadership, the role is ineffective. Ensure roles have both responsibility and the authority to act.

Clause 6: Planning

Clause 6 is the strategic planning clause — it connects your understanding of context and risk (Clause 4) to the specific actions and controls your ISMS implements. This is where the risk assessment lives, where information security objectives are defined, and where the Statement of Applicability is created.

6.1 Actions to Address Risks and Opportunities

What the standard requires:

• 6.1.1: Consider the context issues (4.1) and stakeholder requirements (4.2), and determine the risks and opportunities that need to be addressed to ensure the ISMS achieves its intended outcomes, prevent or reduce undesired effects, and achieve continual improvement.
• 6.1.2: Define and apply an information security risk assessment process that establishes risk acceptance criteria, produces consistent and comparable results, identifies information security risks (including risk owners), analyzes the risks (likelihood and consequences), and evaluates the risks (compare against acceptance criteria and prioritize for treatment).
• 6.1.3: Define and apply an information security risk treatment process that selects appropriate treatment options, determines all controls necessary to implement the chosen treatment options, compare the determined controls with Annex A to verify nothing necessary has been overlooked, and produce a Statement of Applicability that contains the necessary controls, justifications for their inclusion, whether they are implemented, and justification for excluding any Annex A controls.

What auditors evaluate: This is one of the most scrutinized areas of the audit. Auditors examine:

• Your risk assessment methodology (is it documented, repeatable, and consistently applied?)
• Your risk register (does it contain identified risks with likelihood, impact, risk level, risk owners, and treatment decisions?)
• Your risk treatment plan (for risks you chose to mitigate, what controls are being implemented, by whom, and by when?)
• Your Statement of Applicability (does it list all 93 Annex A controls with inclusion/exclusion decisions and justifications?)
• Consistency between the risk assessment, risk treatment plan, and SoA (do the controls in the SoA actually address the risks in the risk register?)

SaaS implementation:

The risk assessment is the most important deliverable in your ISMS. It drives everything — which controls you implement, how you allocate resources, and what your auditor evaluates. For a complete walkthrough, see our ISO 27001 Risk Assessment guide.

Risk assessment approach for SaaS companies:

1. Identify information assets. Catalog the systems, applications, data stores, and information that are in scope. For a SaaS company, this includes the production environment, databases, application code, CI/CD pipeline, backups, customer data, employee data, and supporting infrastructure.

2. Identify threats and vulnerabilities. For each asset, identify what could go wrong (threats: unauthorized access, data breach, service outage, malware, insider threat, vendor compromise) and what weaknesses could be exploited (vulnerabilities: misconfigured cloud resources, unpatched software, weak access controls, lack of encryption, insufficient logging).

3. Assess likelihood and impact. Rate each risk using a consistent scale (e.g., 1-5 for likelihood and 1-5 for impact). Multiply to get a risk level. Define what each rating means in your context — a “5” for impact at a 30-person SaaS company is different from a “5” at a multinational bank.

4. Determine treatment. For each risk, decide to mitigate (implement controls), accept (risk is within tolerance), transfer (insurance or contractual transfer), or avoid (eliminate the activity that creates the risk).

5. Select controls. For risks you’re mitigating, select controls from Annex A (and any additional controls you determine necessary). Document the selection in your Statement of Applicability.

Statement of Applicability (SoA):

The SoA is a controlled document that lists all 93 Annex A controls with:

• Whether each control is applicable (included or excluded)
• Justification for inclusion (typically referencing the risk it addresses)
• Justification for exclusion (why the control isn’t needed)
• Implementation status

Common mistakes:

• Risk assessment disconnected from reality. A risk assessment that was filled in as a compliance exercise, with arbitrary ratings that don’t reflect actual threats to your SaaS platform, will not survive auditor scrutiny. Rate risks based on real threat intelligence, actual incidents, and genuine assessment of your vulnerabilities.
• Excluding Annex A controls without justification. Every exclusion needs a valid reason. “We don’t want to implement this” is not a justification. “This control relates to physical media handling and our organization does not handle physical media” is a valid justification.
• No risk owners. Every risk needs an owner — someone accountable for ensuring the risk is treated according to the plan. Auditors verify that risk owners exist and understand their accountability.
• Static risk assessment. The risk assessment isn’t a one-time document. It must be reviewed and updated when changes occur (new products, new infrastructure, new threats, organizational changes) and at planned intervals (at least annually).

6.2 Information Security Objectives and Planning to Achieve Them

What the standard requires: Establish information security objectives at relevant functions and levels. Objectives must be consistent with the information security policy, measurable (if practicable), take into account applicable requirements and risk assessment results, be monitored, communicated, updated as appropriate, and available as documented information. Plan how to achieve objectives — what will be done, resources required, who is responsible, when it will be completed, and how results will be evaluated.

What auditors evaluate: Documented objectives with associated plans, evidence that objectives are measured and monitored, and consistency between objectives and the information security policy.

SaaS implementation:

Information security objectives translate your policy commitments into measurable targets. For SaaS companies, effective objectives include:

• “Achieve and maintain 99.9% system availability for the production environment” — measurable, directly relevant to customer commitments, supported by specific controls (redundancy, failover, monitoring).
• “Reduce mean time to detect (MTTD) security incidents to under 4 hours” — measurable through incident response metrics, drives investment in monitoring and alerting.
• “Complete security awareness training for 100% of employees within 30 days of hire and annually thereafter” — measurable through training platform records, directly tied to Clause 7.2 competence requirements.
• “Remediate critical vulnerabilities in production within 72 hours of identification” — measurable through vulnerability management records, drives patching and remediation processes.
• “Complete quarterly access reviews for all production systems with 100% coverage” — measurable through access review records, addresses access control risks.

Common mistake: Setting objectives that aren’t measurable or aren’t monitored. “Improve information security” is not an objective. “Reduce the number of security incidents caused by misconfigured cloud resources by 50% year-over-year” is an objective. If you can’t measure it, you can’t demonstrate progress, and the auditor will note this as a gap.

6.3 Planning of Changes

What the standard requires: When the organization determines the need for changes to the ISMS, the changes shall be carried out in a planned manner.

What auditors evaluate: Evidence that changes to the ISMS itself (not just changes to IT systems) are planned, approved, and implemented in a controlled way.

SaaS implementation: This applies when you change your ISMS — modifying scope, changing risk assessment methodology, restructuring roles and responsibilities, adopting new policies, or changing how you manage controls. Document why the change is needed, what the change entails, who approved it, and how it will be implemented. Keep a change log for your ISMS.

This is distinct from IT change management (which falls under Annex A controls). Clause 6.3 is about changes to the management system itself.

Clause 7: Support

Clause 7 covers the resources, competence, awareness, communication, and documentation that support the operation of your ISMS. Without adequate support, the ISMS cannot function — controls aren’t implemented, people don’t know their responsibilities, and documentation doesn’t exist for the auditor to verify.

7.1 Resources

What the standard requires: Determine and provide the resources needed to establish, implement, maintain, and continually improve the ISMS.

What auditors evaluate: Evidence that adequate resources (people, budget, tools, time) are allocated to the ISMS. This connects to Clause 5.1 — leadership commitment includes resource provision.

SaaS implementation: Document your resource allocation for the ISMS. This includes:

• Dedicated or shared headcount for ISMS management (security lead, compliance manager, or equivalent)
• Budget for GRC tooling, security tools, training, consulting, and certification body fees
• Engineering time allocated for security control implementation and maintenance
• Time allocated for risk assessments, internal audits, management reviews, and policy updates

Common mistake: Not formally documenting resource allocation. Even if your team is doing the work, the auditor needs evidence that management has intentionally allocated resources — not that a few people are doing compliance work in their spare time.

7.2 Competence

What the standard requires: Determine the necessary competence of persons doing work under the ISMS that affects its performance, ensure those persons are competent based on appropriate education, training, or experience, take actions to acquire the necessary competence (and evaluate the effectiveness of those actions), and retain evidence of competence.

What auditors evaluate: Competence records (training records, certifications, experience documentation) for people with ISMS responsibilities, plus evidence that competence gaps have been identified and addressed.

SaaS implementation:

Competence requirements for different roles in a SaaS company:

• ISMS Manager: ISO 27001 implementation experience, risk assessment competence, audit management skills. Evidence: ISO 27001 Lead Implementer certification, prior ISMS experience, relevant training records.
• Internal auditors: ISO 27001 internal audit competence. Evidence: ISO 27001 Internal Auditor training, prior audit experience.
• Engineers with security responsibilities: Cloud security competence, secure development practices. Evidence: AWS/Azure/GCP security certifications, secure coding training, DevSecOps experience.
• All employees: Information security awareness. Evidence: Completed security awareness training records.

Common mistake: Assuming competence without evidence. Your CTO may have 15 years of security experience, but the auditor needs documented evidence — training records, certifications, job descriptions showing relevant experience. Keep competence records in your GRC platform.

7.3 Awareness

What the standard requires: Persons doing work under the organization’s control shall be aware of the information security policy, their contribution to the effectiveness of the ISMS, the implications of not conforming with ISMS requirements, and how their work affects information security.

What auditors evaluate: Evidence that all employees understand the security policy, know their responsibilities, and understand the consequences of non-compliance. Auditors may interview any employee — not just the security team — to verify awareness.

SaaS implementation:

• Security awareness training program. Annual training for all employees covering the information security policy, acceptable use guidelines, incident reporting procedures, data handling requirements, phishing awareness, and social engineering risks. Track completion rates and follow up on overdue training.
• Role-specific awareness. Engineers need awareness of secure development practices and their specific responsibilities for controls they operate. Managers need awareness of their oversight responsibilities. HR needs awareness of onboarding/offboarding security requirements.
• New-hire onboarding. Security awareness training within the first week of employment, including policy acknowledgment and access to all relevant security documentation.
• Ongoing reinforcement. Security newsletters, Slack channel updates, phishing simulations, and incident debriefs keep security awareness active — not just an annual training checkbox.

Common mistake: Relying solely on annual training. Auditors can interview any employee at any time during the Stage 2 audit. If a developer hired three months ago can’t articulate the information security policy or explain how to report a security incident, it suggests your awareness program isn’t effective.

7.4 Communication

What the standard requires: Determine the need for internal and external communications relevant to the ISMS, including what to communicate, when, with whom, who communicates, and the processes by which communication is effected.

What auditors evaluate: A documented communication plan or matrix that covers ISMS-related communications, plus evidence that communications actually happen.

SaaS implementation:

Create a communication matrix:

What	When	Audience	Responsible	Method
Security incidents	Immediately upon detection	Internal: security team, leadership. External: affected customers, regulators (as required)	ISMS Manager	Incident response process, status page
Policy changes	Upon approval	All employees	ISMS Manager	Email, policy management platform
Risk assessment results	After completion (annual)	Leadership, risk owners	ISMS Manager	Management review
Internal audit results	After audit completion	Leadership, process owners	Internal auditor	Management review
ISMS performance metrics	Quarterly	Leadership	ISMS Manager	Management review
Security awareness updates	Ongoing	All employees	ISMS Manager	Slack, email, training platform

Common mistake: Having no documented communication plan. Informal communication works until someone forgets to notify the right people about a critical change. Document who communicates what to whom and how.

7.5 Documented Information

What the standard requires: The ISMS shall include documented information required by the standard and documented information determined by the organization as being necessary for ISMS effectiveness. Documented information must be controlled — created, updated, controlled, distributed, accessed, stored, preserved, and dispositioned appropriately.

What auditors evaluate: The existence, quality, and control of all required documented information. This includes policies, procedures, records, risk assessments, the SoA, internal audit reports, management review minutes, corrective action records, and more.

SaaS implementation:

ISO 27001:2022 requires the following documented information (this is not exhaustive — the standard references “documented information” throughout):

• ISMS scope statement (4.3)
• Information security policy (5.2)
• Risk assessment process and results (6.1.2)
• Risk treatment plan (6.1.3)
• Statement of Applicability (6.1.3)
• Information security objectives (6.2)
• Competence records (7.2)
• Operational planning and control records (8.1)
• Risk assessment results (8.2)
• Risk treatment results (8.3)
• Monitoring and measurement results (9.1)
• Internal audit program and results (9.2)
• Management review results (9.3)
• Nonconformities and corrective actions (10.2)

Document control requirements:

• Version control (track who changed what and when)
• Approval workflows (documents are reviewed and approved before publication)
• Access control (documents are available to those who need them and protected from unauthorized changes)
• Review scheduling (documents are reviewed at planned intervals and updated as needed)
• Retention policies (documents are retained for an appropriate period and disposed of properly)

A GRC platform handles document control natively — version history, approval workflows, access permissions, and review reminders are built in. See our ISO 27001 Policies guide for comprehensive documentation guidance.

Common mistake: Treating documentation as a one-time deliverable. Policies written for the certification audit and never updated become outdated within months. The auditor at your first surveillance audit will check document review dates and ask about changes since the initial certification. Stale documents suggest a stale ISMS.

Clause 8: Operation

Clause 8 is about executing the plans established in Clause 6. Where Clause 6 says “plan,” Clause 8 says “do.” This is where the ISMS operates on a daily basis.

8.1 Operational Planning and Control

What the standard requires: Plan, implement, and control the processes needed to meet ISMS requirements and to implement the actions determined in 6.1 (risk treatment) and 6.2 (objectives). Control planned changes and review the consequences of unintended changes, taking action to mitigate adverse effects. Ensure outsourced processes are controlled.

What auditors evaluate: Evidence that your planned controls are operating in practice — not just documented, but actually running. The auditor verifies that what you said you’d do (in policies, procedures, and the risk treatment plan) is what you’re actually doing.

SaaS implementation:

For SaaS companies, operational planning and control means:

• Control operations. Your Annex A controls should be operating as documented. If your access control policy says access reviews happen quarterly, they need to actually happen quarterly. If your change management procedure requires code review before deployment, code reviews must be happening for every deployment.
• Change management. Changes to the ISMS scope, controls, or processes should be planned, approved, and documented. This includes infrastructure changes that affect security controls.
• Outsourced processes. If you outsource security-relevant processes (managed SOC, penetration testing, cloud infrastructure management), you need to control those processes through contracts, SLAs, and monitoring. This connects to Annex A supplier management controls.
• Evidence of operation. Maintain records that demonstrate controls are operating — access review records, change management logs, incident response records, vulnerability scan results, training completion records. This evidence serves double duty: it satisfies the auditor and it gives you visibility into your own program’s effectiveness.

Common mistake: Implementing controls for the audit and then letting them lapse. If you conduct a thorough access review before the Stage 2 audit but then skip the next three quarterly reviews, the surveillance auditor will find the gap. Controls must operate continuously, not just during audit preparation.

8.2 Information Security Risk Assessment

What the standard requires: Perform information security risk assessments at planned intervals or when significant changes are proposed or occur, retaining documented information of the results.

What auditors evaluate: Evidence that risk assessments are conducted at the frequency defined in your risk assessment process (typically at least annually) and whenever significant changes occur. The auditor checks dates, version history, and content to verify this.

SaaS implementation:

• Planned assessments. Conduct a comprehensive risk assessment at least annually. Review and update the risk register, reassess risk ratings, evaluate the effectiveness of existing treatments, and identify new risks.
• Change-triggered assessments. When significant changes occur — new product launches, major infrastructure migrations, entering new markets, organizational restructuring, new vendor relationships, significant security incidents — conduct a targeted risk assessment for the affected areas.
• Integration with operations. For SaaS companies, integrate risk assessment triggers into your development lifecycle. When a new feature handles sensitive data or a new third-party integration is proposed, a risk assessment should be part of the evaluation process.

For comprehensive guidance, see our ISO 27001 Risk Assessment guide.

8.3 Information Security Risk Treatment

What the standard requires: Implement the information security risk treatment plan and retain documented information of the results.

What auditors evaluate: Evidence that the risk treatment plan from 6.1.3 is being executed — controls are implemented, risk owners are tracking progress, and treatment activities are completed according to the plan.

SaaS implementation: Track risk treatment activities in your GRC platform. Each treatment action should have an owner, a deadline, a status, and evidence of completion. When a risk treatment is “implement MFA for all production access,” the evidence of completion is the MFA configuration records, policy documentation, and verification that all users have enrolled.

Common mistake: Having a risk treatment plan that shows “mitigate” for a risk, but no evidence that the mitigation controls are actually implemented. The gap between plan and execution is one of the most common sources of nonconformities.

Clause 9: Performance Evaluation

Clause 9 requires you to measure, monitor, and evaluate the effectiveness of your ISMS. This is the “check” phase of the Plan-Do-Check-Act cycle — and it’s where many SaaS teams are weakest, because measuring security program effectiveness is harder than implementing controls.

9.1 Monitoring, Measurement, Analysis, and Evaluation

What the standard requires: Determine what needs to be monitored and measured, the methods for monitoring and measurement, when monitoring and measurement shall be performed, who shall monitor and measure, when results shall be analyzed and evaluated, and who shall analyze and evaluate results. Retain documented information as evidence.

What auditors evaluate: Documented metrics, evidence that metrics are measured at the defined frequency, and evidence that results are analyzed and fed into improvement activities.

SaaS implementation:

Define ISMS performance metrics that are meaningful for a SaaS company:

• Incident response metrics. Mean time to detect (MTTD), mean time to respond (MTTR), number of incidents by severity, root cause categories.
• Vulnerability management metrics. Time to remediate critical/high/medium vulnerabilities, number of open vulnerabilities by severity, patch compliance rates.
• Access management metrics. Access review completion rates, percentage of access reviews completed on time, number of access exceptions identified and resolved.
• Training metrics. Security awareness training completion rates, phishing simulation click rates, time to complete training for new hires.
• Policy compliance metrics. Number of policy violations identified, corrective actions completed, policy review completion rates.
• Availability metrics. System uptime, number and duration of outages, recovery time after incidents.
• Risk metrics. Number of risks above tolerance, risk treatment plan completion rates, number of new risks identified per quarter.

Measurement frequency: Measure these metrics at intervals that allow you to detect trends and take action. Monthly or quarterly measurement for most metrics, with continuous monitoring for critical metrics (availability, incident detection).

Common mistake: Collecting metrics but not analyzing them. Raw numbers without analysis and action are useless. Your management review (9.3) should include analysis of trends, identification of problem areas, and decisions about improvement actions. If your MTTR is increasing quarter over quarter, what are you going to do about it?

9.2 Internal Audit

What the standard requires: Conduct internal audits at planned intervals to determine whether the ISMS conforms to the organization’s own requirements, conforms to the requirements of ISO 27001, and is effectively implemented and maintained. Establish an audit program, define audit criteria and scope for each audit, select auditors who ensure objectivity and impartiality, report results to relevant management, and retain documented information.

What auditors evaluate: The internal audit program, individual audit plans and reports, auditor competence records, evidence that findings were reported to management, and evidence that corrective actions were taken for identified nonconformities.

SaaS implementation:

The internal audit is a critical pre-certification activity and an ongoing requirement. For comprehensive guidance, see our ISO 27001 Internal Audit guide.

Key principles for SaaS companies:

• Audit frequency. Conduct a comprehensive internal audit at least annually, covering all ISMS requirements. Many organizations audit different areas on a rolling schedule — e.g., audit Clauses 4-6 in Q1, Clause 7 in Q2, Clause 8 in Q3, and Clauses 9-10 in Q4.
• Auditor independence. Internal auditors must not audit their own work. If the ISMS Manager built the risk assessment, someone else must audit it. In small SaaS companies, this can be challenging — consider using an external consultant for internal audits, or cross-train team members to audit areas outside their responsibility.
• Audit methodology. Use a systematic approach — review documentation, interview process owners, examine evidence, test controls, and compare findings against requirements. Document findings as conformities, observations (areas for improvement), or nonconformities (failures to meet requirements).
• Corrective actions. Every nonconformity identified in the internal audit must have a corrective action — a documented plan to fix the issue, prevent recurrence, and verify the fix was effective. Track corrective actions to completion.

Common mistake: Conducting a superficial internal audit that doesn’t identify any findings. An internal audit with zero findings is a red flag for the external auditor — it suggests the audit wasn’t thorough enough. Every ISMS has areas for improvement. A good internal audit finds them before the CB does.

9.3 Management Review

What the standard requires: Top management shall review the ISMS at planned intervals to ensure its continuing suitability, adequacy, and effectiveness. The review shall consider: the status of actions from previous management reviews, changes in external and internal issues relevant to the ISMS, feedback on ISMS performance (including nonconformities, monitoring results, audit results, and objective fulfillment), feedback from interested parties, risk assessment results and risk treatment plan status, and opportunities for continual improvement. Outputs shall include decisions related to continual improvement opportunities and any needs for changes to the ISMS.

What auditors evaluate: Management review meeting minutes (or records) showing that all required input topics were discussed, that decisions were made, and that actions were assigned with owners and deadlines. Auditors also check attendee lists to verify top management participation.

SaaS implementation:

• Frequency. At least annually, though many organizations conduct management reviews semi-annually or quarterly. More frequent reviews are better for maintaining management engagement and catching issues early.
• Attendees. CEO or equivalent, CTO, ISMS Manager, and other relevant leaders. This is a management meeting, not a security team meeting.
• Structured agenda. Follow the standard’s required inputs as your agenda template. For each item, present data, discuss implications, and document decisions.
• Documented outcomes. Record decisions, action items, responsible persons, and deadlines. Management review minutes are a mandatory documented record that auditors examine.

Management review template for SaaS companies:

1. Status of actions from previous review
2. Changes in context (new regulations, market changes, organizational changes)
3. Interested party feedback (customer security requirements, regulatory developments)
4. ISMS performance metrics (incident trends, vulnerability metrics, training completion)
5. Internal and external audit results
6. Risk assessment status and risk treatment progress
7. Opportunities for improvement
8. Resource needs
9. Decisions and action items

Common mistake: Skipping the management review or conducting it as a formality without meaningful discussion. The management review is where leadership demonstrates active engagement with the ISMS. If the minutes show a 15-minute meeting with no discussion and no decisions, the auditor will question whether leadership commitment (Clause 5.1) is genuine.

Clause 10: Improvement

Clause 10 closes the PDCA loop. It requires your organization to respond to problems (nonconformities) and proactively seek ways to improve the ISMS. This is the clause that separates a compliance-driven ISMS from a genuinely effective security program.

10.1 Continual Improvement

What the standard requires: Continually improve the suitability, adequacy, and effectiveness of the ISMS.

What auditors evaluate: Evidence that the ISMS is improving over time — not just maintaining the status quo, but actively getting better. Auditors look for improvement actions driven by risk assessment updates, internal audit findings, management review decisions, incident lessons learned, and performance metric trends.

SaaS implementation:

Continual improvement in a SaaS ISMS includes:

• Post-incident improvements. After every security incident, conduct a lessons-learned review and implement changes to prevent recurrence. Track these improvements as corrective or preventive actions.
• Audit-driven improvements. Internal and external audit findings should drive specific improvements. Track these through your corrective action process.
• Metric-driven improvements. When ISMS metrics show negative trends (increasing MTTR, declining training completion, growing vulnerability backlog), initiate improvement projects.
• Proactive improvements. Don’t wait for problems. Seek opportunities — new security technologies, better processes, industry best practices, feedback from your team — and implement them as planned improvements.
• Maturity progression. Document your ISMS maturity level and set targets for advancement. A first-year ISMS will have basic processes; by year 3, those processes should be optimized, automated where possible, and deeply embedded in operations.

For a comprehensive approach to building a sustainable improvement program, see our ISO 27001 Continuous Improvement guide.

Common mistake: Treating continual improvement as a vague aspiration rather than a managed process. Improvement should be tracked in your GRC platform — each improvement initiative has an owner, a description, a target date, and evidence of completion. When the auditor asks “how has your ISMS improved since last year?” you should have a concrete list.

10.2 Nonconformity and Corrective Action

What the standard requires: When a nonconformity occurs, react to it (control and correct it, deal with the consequences), evaluate the need for action to eliminate the cause so it does not recur, implement any action needed, review the effectiveness of the corrective action, and make changes to the ISMS if necessary. Retain documented information of the nature of nonconformities and actions taken, and the results of corrective actions.

What auditors evaluate: A corrective action process that’s documented and followed, plus records showing how specific nonconformities were handled — what the nonconformity was, what caused it, what corrective action was taken, and whether the corrective action was effective.

SaaS implementation:

Nonconformities come from multiple sources:

• Internal audit findings
• External (CB) audit findings
• Security incidents
• Customer complaints related to information security
• Process failures or control breakdowns
• Employee-reported issues

Corrective action process for SaaS companies:

1. Record the nonconformity. Document what happened, when, and the impact. Be specific — “access review not completed” is better than “process failure.”
2. Contain the immediate impact. If the nonconformity created a security risk, address it immediately. If an access review revealed unauthorized access, revoke the access first, then investigate.
3. Identify the root cause. Don’t just fix the symptom. If the access review wasn’t completed, why? Was the responsible person overloaded? Was there no reminder process? Was the procedure unclear? Root cause analysis prevents recurrence.
4. Implement corrective action. Design and implement a fix that addresses the root cause. If the root cause was “no reminder process,” implement automated reminders in your GRC platform.
5. Verify effectiveness. After implementing the corrective action, verify that it worked. Did the next access review complete on time? Has the root cause been eliminated?
6. Close the record. Document the resolution and close the corrective action in your tracking system.

Common mistake: Fixing symptoms without addressing root causes. If you keep finding the same types of nonconformities in successive audits, your corrective actions aren’t effective. Auditors specifically check for repeat findings — and repeat findings suggest your improvement process (Clause 10) isn’t working.

Common Implementation Mistakes Across All Clauses

Having examined each clause individually, here are the systemic mistakes that cause the most problems across the entire ISMS:

Paper ISMS

The most fundamental mistake is building an ISMS that exists on paper but not in practice. Policies that nobody follows, risk assessments that don’t reflect reality, controls that aren’t operating, metrics that aren’t measured. The auditor’s job is to verify that your ISMS is implemented and maintained — not just documented. If your policies say one thing and your operations do another, the auditor will identify nonconformities.

Fix: Write policies and procedures that reflect what you actually do (or what you can realistically commit to doing). Start with your current operations and formalize them, rather than writing aspirational policies and hoping operations catch up.

Treating ISO 27001 as an IT Project

ISO 27001 is a management system standard, not a technology standard. It requires leadership involvement (Clause 5), organizational awareness (Clause 7.3), management review (Clause 9.3), and continual improvement (Clause 10). Treating it as an IT project — delegating everything to the engineering team and expecting them to deliver a certificate — misses the management system requirements and results in weak clauses 5, 9, and 10.

Fix: Involve leadership from the start. Make the management review a genuine leadership activity. Ensure that the ISMS project has executive sponsorship, not just engineering resources.

Ignoring Clause 10

Most SaaS teams focus heavily on building the ISMS (Clauses 4-8) and measuring it (Clause 9), but underinvest in improvement (Clause 10). The auditor at your first surveillance audit will ask what has improved since certification. If the answer is “nothing,” that’s a problem.

Fix: Build improvement into your ISMS operations from the start. Track improvements explicitly. Set improvement objectives alongside your information security objectives (Clause 6.2).

Over-Engineering Documentation

Some organizations create hundreds of pages of documentation — detailed procedures for every conceivable scenario, complex policy hierarchies, elaborate process flows. This creates a documentation burden that’s impossible to maintain and often doesn’t match how the organization actually works.

Fix: Write the minimum documentation needed to meet the standard’s requirements and to support effective operations. ISO 27001:2022 is less prescriptive about documentation than previous versions — take advantage of this. A concise, accurate policy is better than a lengthy, outdated one.

Disconnected Risk Assessment

If your risk assessment was conducted as an isolated exercise (fill out a spreadsheet, file it away) rather than as the driver of your control selection and resource allocation, your ISMS lacks coherence. The auditor will trace from risks to controls to evidence — if the threads don’t connect, the ISMS doesn’t work as a system.

Fix: Make the risk assessment the central artifact of your ISMS. Every control in your SoA should trace back to a risk. Every risk should trace forward to controls and evidence. This traceability is what makes the ISMS a system, not a collection of documents.

How GRCTrail Helps

GRCTrail is built to help SaaS teams implement ISO 27001 requirements efficiently and maintain compliance with every clause.

• Structured clause-by-clause implementation workflows guide your team through each requirement in Clauses 4-10, providing templates, checklists, and examples specific to SaaS companies — so you build a compliant ISMS without needing deep ISO 27001 expertise on day one
• Integrated risk assessment and Statement of Applicability management ensures your risk register, treatment plans, and Annex A control selections stay connected and traceable — eliminating the disconnected spreadsheets that cause nonconformities during audits
• Automated evidence collection, internal audit tracking, and management review workflows handle the ongoing operational requirements of Clauses 8, 9, and 10 — so your ISMS runs continuously rather than coming alive only during audit preparation

Get started with GRCTrail →

Related Guides

• What Is ISO 27001? A Complete Guide for SaaS Companies
• ISO 27001 Certification Checklist
• ISO 27001 Risk Assessment Guide
• ISO 27001 Policies and Documentation Guide
• ISO 27001 Internal Audit Guide
• ISO 27001 Annex A Controls Explained
• ISO 27001 Continuous Improvement Guide