ISO 27001 Policies: Which Policies You Need and How to Write Them

Policies are the backbone of every ISO 27001 Information Security Management System (ISMS). They translate management’s security intentions into documented commitments that guide employee behavior, define control objectives, and give auditors something concrete to test against. Without well-structured, enforceable policies, your ISMS exists only in theory.

Many SaaS companies approach ISO 27001 policies the wrong way. They download generic templates, replace the company name, and assume they are done. This creates two problems. First, the policies do not reflect how the organization actually operates, which means employees ignore them. Second, certification auditors spot the disconnect immediately — they have seen the same templates hundreds of times, and they know when a policy was not written for the organization presenting it.

This guide covers the documented information requirements in ISO 27001, every mandatory and recommended policy, how to structure and write policies that work for SaaS companies, and how to manage the approval, communication, and review lifecycle that the standard demands.

What ISO 27001 Says About Documented Information

ISO 27001 uses the term “documented information” rather than “documents” or “records.” This is deliberate — the standard does not prescribe specific document formats, naming conventions, or structures. It requires that certain information be documented, maintained, and controlled, but how you organize that information is up to you.

Clause 7.5 establishes the overarching requirements for documented information. It states that your ISMS must include documented information required by the standard itself, plus any additional documented information your organization determines is necessary for ISMS effectiveness.

What the Standard Explicitly Requires

The following documented information is directly mandated by ISO 27001:2022 clauses:

• ISMS scope (Clause 4.3) — The boundaries and applicability of your ISMS
• Information security policy (Clause 5.2) — The top-level policy expressing management direction
• Risk assessment process (Clause 6.1.2) — How you identify, analyze, and evaluate information security risks
• Risk treatment process (Clause 6.1.3) — How you select and implement controls to address identified risks
• Information security objectives (Clause 6.2) — Measurable goals for your security program
• Evidence of competence (Clause 7.2) — Proof that people performing security-relevant work are competent
• Operational planning and control (Clause 8.1) — Documentation of processes needed to meet security requirements
• Risk assessment results (Clause 8.2) — Output from completed risk assessments
• Risk treatment results (Clause 8.3) — Output from risk treatment activities
• Monitoring and measurement results (Clause 9.1) — Evidence of performance evaluation
• Internal audit program and results (Clause 9.2) — Audit plans, criteria, scope, and findings
• Management review results (Clause 9.3) — Output from management review meetings
• Nonconformities and corrective actions (Clause 10.1) — Records of problems found and how they were addressed
• Statement of Applicability (Clause 6.1.3 d) — Listing of all Annex A controls with justification for inclusion or exclusion

This is the minimum set. Most organizations need significantly more documented information to demonstrate that their ISMS operates effectively.

The Statement of Applicability as a Policy Map

The Statement of Applicability (SoA) deserves special attention because it functions as the bridge between your risk treatment decisions and the policies that implement those decisions. For every Annex A control you declare applicable, you need documented information describing how that control is implemented. In practice, this means your SoA drives your policy list — each applicable control should trace to a policy, procedure, or standard that governs it.

Mandatory Policies

ISO 27001 does not provide a numbered list of required policy documents. Instead, certain clauses and Annex A controls implicitly or explicitly require policy-level documentation. The following policies are considered mandatory for certification.

1. Information Security Policy

Clause reference: 5.2, A.5.1

This is the apex document of your ISMS. It establishes the organization’s commitment to information security, sets the direction for all subordinate policies, and is signed by top management.

What it must contain:

• The purpose and scope of the ISMS
• A commitment to satisfying applicable security requirements
• A commitment to continual improvement of the ISMS
• A framework for setting information security objectives
• Assignment of overall responsibility for information security

What it should not contain: Detailed operational procedures, specific technical configurations, or control implementations. The information security policy is a strategic document. Keep it high-level enough that it does not need to change every time you modify a technical control.

SaaS example: Your information security policy states that the organization is committed to protecting customer data processed through its cloud platform, that security objectives are reviewed quarterly by the leadership team, and that the CTO is accountable for the information security program. It references the full suite of subordinate policies (access control, incident response, etc.) without duplicating their content.

Common audit finding: The policy exists but has never been reviewed or updated since initial creation. Auditors check review dates. If your policy is three years old and your company has changed significantly, they will flag it.

2. Risk Assessment and Treatment Methodology

Clause reference: 6.1.2, 6.1.3

This documented methodology defines how your organization identifies, analyzes, evaluates, and treats information security risks. It is not the risk register itself — it is the process description that ensures risk assessments are consistent and repeatable.

What it must contain:

• Risk identification criteria (what constitutes a risk, asset-based vs. scenario-based approach)
• Risk analysis method (qualitative, quantitative, or semi-quantitative)
• Likelihood and impact scales with clear definitions for each level
• Risk evaluation criteria (how you determine which risks are acceptable and which require treatment)
• Risk acceptance criteria and who has authority to accept residual risk
• Risk treatment options (mitigate, transfer, accept, avoid) and selection criteria

For a detailed walkthrough of the risk assessment process, see our ISO 27001 Risk Assessment guide.

SaaS example: You use a 5x5 qualitative risk matrix. Likelihood is rated from Rare (1) to Almost Certain (5) based on historical data and threat intelligence. Impact is rated from Negligible (1) to Critical (5) based on financial, operational, reputational, and regulatory consequences. Risks scoring 15 or above require treatment. Risks scoring 9-14 require documented justification if accepted. The CTO has authority to accept risks scoring 14 or below; risks scoring 15 or above require CEO approval.

3. Statement of Applicability

Clause reference: 6.1.3 d

The Statement of Applicability lists all 93 Annex A controls from ISO 27001:2022 with a determination of whether each is applicable, the justification for inclusion or exclusion, and a reference to how each applicable control is implemented.

The SoA is one of the most important documents in your ISMS. Auditors use it as their roadmap — they select controls from the SoA and test whether those controls are implemented and operating as described.

Common audit finding: The SoA says a control is implemented, but the referenced policy or procedure does not exist, or it exists but is not being followed. Every claim in your SoA must be verifiable.

4. Risk Treatment Plan

Clause reference: 6.1.3, 8.3

The risk treatment plan documents the specific actions you will take to address risks that exceed your acceptance criteria. For each risk requiring treatment, the plan identifies the controls to be implemented, the person responsible, the timeline, and the resources required.

What it must contain:

• Identified risks that require treatment (linked to the risk register)
• Selected treatment option for each risk
• Controls to be applied (referencing Annex A or other sources)
• Implementation owner and timeline
• Expected residual risk after treatment
• Status tracking

Recommended Policies for SaaS Companies

Beyond the mandatory documented information, SaaS companies pursuing ISO 27001 certification need additional policies to satisfy Annex A controls and demonstrate a mature ISMS. The exact set depends on your SoA, but the following policies are expected by virtually every certification auditor.

5. Access Control Policy

Annex A reference: A.5.15 (Access control), A.5.16 (Identity management), A.5.17 (Authentication information), A.5.18 (Access rights), A.8.2 (Privileged access rights), A.8.3 (Information access restriction), A.8.5 (Secure authentication)

Access control is one of the most heavily tested areas in any ISO 27001 audit. Your access control policy defines how the organization manages user identities, authentication, authorization, and the full lifecycle of access rights. For a deep dive into implementation, see our ISO 27001 Access Control guide.

What it covers:

• User registration and deregistration process
• Role-based access control (RBAC) or attribute-based access control (ABAC) model
• Principle of least privilege
• Multi-factor authentication (MFA) requirements
• Privileged access management (PAM)
• Service account and API key governance
• Periodic access review frequency and process
• Deprovisioning timeline upon role change or termination

SaaS example: All production environment access requires MFA. Service accounts are provisioned through Terraform with time-limited credentials. Access reviews are conducted quarterly using automated exports from your identity provider. Deprovisioning must occur within 24 hours of termination notification.

6. Asset Management Policy

Annex A reference: A.5.9 (Inventory of information and other associated assets), A.5.10 (Acceptable use), A.5.11 (Return of assets), A.5.12 (Classification of information), A.5.13 (Labeling of information)

This policy governs the identification, classification, labeling, and acceptable use of information assets. For SaaS companies, “assets” include cloud infrastructure, code repositories, databases, SaaS tools, and intellectual property.

What it covers:

• Asset inventory requirements and maintenance frequency
• Information classification scheme (e.g., Public, Internal, Confidential, Restricted)
• Labeling rules for each classification level
• Acceptable use rules for organizational assets (including BYOD)
• Asset return procedures upon employee departure

SaaS example: You classify data into four levels. Customer production data is Restricted. Internal business documents are Confidential. Company blog posts are Public. Each classification level maps to specific handling requirements — Restricted data must be encrypted at rest and in transit, access requires approval from the data owner, and it may not be stored outside approved production environments.

7. Human Resource Security Policy

Annex A reference: A.6.1 (Screening), A.6.2 (Terms and conditions of employment), A.6.3 (Information security awareness), A.6.4 (Disciplinary process), A.6.5 (Responsibilities after termination)

This policy covers the security aspects of the entire employee lifecycle — from pre-employment screening through onboarding, ongoing employment, and termination.

What it covers:

• Background check requirements (scope and frequency)
• Confidentiality and security obligations in employment contracts
• Security awareness training requirements (initial and recurring)
• Acceptable conduct expectations and disciplinary process for violations
• Termination and exit procedures (access revocation, asset return, knowledge transfer)

SaaS example: All employees undergo background screening before their start date. Security awareness training is completed within the first week of employment and annually thereafter. All employees sign a confidentiality agreement covering customer data. Upon termination, IT is notified within 4 hours, and all access is revoked before the end of the employee’s last working day.

8. Incident Management Policy

Annex A reference: A.5.24 (Information security incident management planning and preparation), A.5.25 (Assessment and decision on information security events), A.5.26 (Response to information security incidents), A.5.27 (Learning from information security incidents), A.5.28 (Collection of evidence), A.6.8 (Information security event reporting)

This policy defines how your organization detects, reports, assesses, responds to, and learns from information security incidents.

What it covers:

• Security event and incident definitions (and the distinction between them)
• Severity classification scheme (e.g., P1-P4)
• Reporting channels and responsibilities (who reports what, to whom, and how quickly)
• Escalation procedures based on severity
• Containment, eradication, and recovery steps
• Evidence preservation requirements
• Post-incident review process
• External notification obligations (regulators, customers, law enforcement)

SaaS example: Any employee who suspects a security event reports it immediately via the #security-incidents Slack channel. The on-call security engineer triages within 30 minutes. P1 incidents (confirmed data breach, active intrusion) trigger a war room and require customer notification within 72 hours. Every P1 and P2 incident receives a written post-mortem within five business days.

9. Business Continuity Policy

Annex A reference: A.5.29 (Information security during disruption), A.5.30 (ICT readiness for business continuity), A.8.13 (Information backup), A.8.14 (Redundancy of information processing facilities)

This policy establishes how the organization maintains information security during disruptive events and ensures the availability of critical services.

What it covers:

• Business impact analysis (BIA) requirements
• Recovery time objectives (RTO) and recovery point objectives (RPO) for critical services
• Backup policy (scope, frequency, retention, testing)
• Disaster recovery procedures
• Testing and exercise schedule
• Communication plan during disruptions

SaaS example: Production databases are backed up every hour with a 1-hour RPO and 4-hour RTO. Backups are stored in a separate AWS region and tested monthly through a full restoration to a staging environment. Disaster recovery tabletop exercises are conducted quarterly. The status page is updated within 15 minutes of any service disruption.

10. Supplier and Third-Party Policy

Annex A reference: A.5.19 (Information security in supplier relationships), A.5.20 (Addressing information security within supplier agreements), A.5.21 (Managing information security in the ICT supply chain), A.5.22 (Monitoring, review and change management of supplier services), A.5.23 (Information security for use of cloud services)

This policy governs how your organization evaluates, onboards, monitors, and offboards third-party suppliers that access, process, or store your data or your customers’ data.

What it covers:

• Supplier risk assessment methodology and frequency
• Security requirements for supplier agreements (data protection, incident notification, audit rights)
• Due diligence process for new suppliers (security questionnaires, SOC 2/ISO 27001 report review)
• Ongoing monitoring cadence (annual review, continuous monitoring for critical suppliers)
• Sub-processor management
• Cloud service provider security requirements

SaaS example: All suppliers that process customer data undergo a security assessment before onboarding. Critical suppliers (infrastructure, identity, payment processing) are reviewed annually and must provide a current SOC 2 Type II or ISO 27001 certificate. Supplier agreements include data processing clauses, breach notification within 48 hours, and the right to audit.

11. Cryptography Policy

Annex A reference: A.8.24 (Use of cryptography)

This policy defines the organization’s approach to using cryptographic controls to protect information confidentiality, integrity, and authenticity.

What it covers:

• Encryption requirements by data classification level
• Approved cryptographic algorithms and minimum key lengths
• Key management procedures (generation, distribution, storage, rotation, revocation, destruction)
• TLS/SSL requirements for data in transit
• Encryption at rest requirements
• Certificate management

SaaS example: All data in transit uses TLS 1.2 or higher. Customer data at rest is encrypted using AES-256. Database encryption keys are managed through AWS KMS with automatic annual rotation. SSH keys require ED25519 or RSA-4096. Certificates are managed through ACM with automated renewal.

12. Physical Security Policy

Annex A reference: A.7.1 through A.7.14

For SaaS companies operating entirely in the cloud, physical security policy is often scoped narrowly to office facilities and employee endpoints. Cloud infrastructure physical security is typically covered by the cloud provider’s own certifications.

What it covers:

• Office access control (badge access, visitor management)
• Secure areas (server rooms if applicable, restricted office zones)
• Equipment security (laptop encryption, screen lock, secure disposal)
• Remote working security requirements
• Clear desk and clear screen policy

SaaS example: Your physical security policy acknowledges that production infrastructure runs on AWS (physical security governed by AWS’s own ISO 27001 and SOC 2 certifications). The policy focuses on office access (badge entry required, visitors must be escorted and logged), endpoint security (FileVault/BitLocker encryption mandatory, screen lock after 5 minutes), and remote work (VPN required for internal tool access, work must not be performed on public computers).

13. Operations Security Policy

Annex A reference: A.8.6 (Capacity management), A.8.7 (Protection against malware), A.8.8 (Management of technical vulnerabilities), A.8.9 (Configuration management), A.8.15 (Logging), A.8.16 (Monitoring activities)

This policy covers day-to-day operational security controls that keep your systems secure and observable.

What it covers:

• Change management and deployment processes
• Capacity planning
• Separation of development, testing, and production environments
• Malware protection for endpoints
• Vulnerability management (scanning frequency, patching SLAs by severity)
• Logging and monitoring requirements
• Configuration management and hardening baselines

SaaS example: Critical vulnerabilities (CVSS 9.0+) must be patched within 72 hours. High vulnerabilities (CVSS 7.0-8.9) within 30 days. All production systems send logs to a centralized SIEM with 90-day retention. Development, staging, and production environments are isolated with separate AWS accounts. Endpoint detection and response (EDR) software runs on all employee laptops.

14. Communications Security and Data Transfer Policy

Annex A reference: A.5.14 (Information transfer), A.8.20 (Networks security), A.8.21 (Security of network services), A.8.22 (Segregation of networks), A.8.23 (Web filtering)

This policy governs how information is transferred within and outside the organization, and how network security is maintained.

What it covers:

• Approved channels for information transfer by classification level
• Email security requirements
• Network segmentation rules
• Wireless network security
• Remote access requirements (VPN, zero trust)
• Data transfer agreements with external parties

How to Structure an ISO 27001 Policy

Consistent policy structure is not a formal requirement, but it dramatically improves usability and demonstrates maturity. When every policy follows the same template, employees know where to find information and auditors can navigate your documentation efficiently.

Recommended Policy Sections

1. Document control block

Every policy should begin with metadata:

• Policy title and unique identifier (e.g., POL-ISP-001)
• Version number
• Policy owner (name and role)
• Approver (name and role)
• Effective date
• Next review date
• Classification level (typically Internal or Confidential)

2. Purpose

One to two paragraphs explaining why this policy exists and what problem it addresses. This should answer: “Why should I care about this policy?”

Example: “This Access Control Policy establishes the requirements for managing user access to information systems and data throughout the access lifecycle. It exists to prevent unauthorized access, maintain the principle of least privilege, and ensure that access rights remain appropriate as employees join, move within, or leave the organization.”

3. Scope

Define exactly who and what the policy applies to. Be specific about inclusions and exclusions.

Example: “This policy applies to all employees, contractors, and third-party users who access [Company] information systems. It covers all production systems, corporate applications, and cloud services within the ISMS scope as defined in the ISMS Scope Statement (DOC-ISMS-001). It does not cover physical access to office facilities, which is governed by the Physical Security Policy (POL-PHY-001).”

4. Policy statements

The core of the document. Each policy statement should be:

• Clear and unambiguous — No room for interpretation
• Measurable — You can objectively determine compliance
• Realistic — Achievable with current resources and technology
• Attributable — Someone is responsible for compliance

Write policy statements as requirements, not suggestions. Use “must” and “shall” for mandatory requirements, “should” for recommendations, and “may” for permissions.

5. Roles and responsibilities

Define who is responsible for what. Use role titles, not individual names, so the policy survives personnel changes.

Example:

• Information Security Manager: Maintains this policy, conducts annual reviews, and reports compliance status to leadership
• IT Operations Team: Implements technical controls defined in this policy
• People Operations: Notifies IT of employee terminations within 4 hours
• All employees: Comply with this policy and report suspected violations

6. Related documents

List the standards, procedures, and other policies that support or connect to this policy. This creates traceability across your documentation framework.

7. Definitions and abbreviations

Define any terms that might be ambiguous. This is especially important when technical and non-technical audiences both read the policy.

8. Review and revision history

A table showing each revision: date, version, author, and a brief description of changes.

Writing Policies for SaaS Companies

SaaS companies have distinct characteristics that should shape how policies are written. Ignoring these characteristics produces policies that are technically compliant but operationally useless.

Write for your actual workflow. If your engineering team deploys to production 20 times a day using a CI/CD pipeline, your change management policy should describe that process — not a traditional change advisory board that meets weekly. Auditors do not penalize modern practices. They penalize mismatches between what you document and what you do.

Be specific about cloud services. Generic references to “servers” and “data centers” signal that a policy was written for a different kind of company. Name your cloud providers. Reference specific services (AWS RDS, Azure AD, GCP Cloud Run). This specificity helps employees understand what the policy means in practice and helps auditors verify compliance.

Keep policies concise. A 50-page access control policy signals bureaucracy, not maturity. Auditors and employees both prefer documents that are thorough but not verbose. If a section is growing beyond a page, consider whether the detail belongs in a supporting procedure or standard rather than the policy itself.

Use language your team understands. If your team uses “deploy” instead of “release,” use “deploy.” If they say “repo” instead of “repository,” use “repo.” Policies that use unfamiliar language get ignored.

Set achievable commitments. Every policy statement becomes a testable obligation. If your policy says passwords must be rotated every 30 days, you must prove that they are. If your policy says access reviews happen quarterly, you need four completed reviews per year. The single most common audit finding across all ISO 27001 certifications is organizations not meeting their own stated requirements. Set standards you can consistently meet, then raise them over time through continual improvement.

Approval and Communication

Policy Approval

Clause 5.2 requires that the information security policy is approved by top management. In practice, auditors expect all ISMS policies to go through a formal approval process.

Who approves: The approver should be someone with sufficient authority to commit the organization to the requirements in the policy. For the top-level information security policy, this is typically the CEO, CTO, or a member of the executive team. For subordinate policies, the information security manager or CTO is usually appropriate.

How to document approval: Keep it simple. Options include:

• Digital signature on the policy document
• Approval recorded in your document management system (with timestamp and approver identity)
• Email or Slack confirmation captured and stored as evidence
• Approval via a GRC platform with audit trail

What matters is that you can demonstrate who approved the policy, when they approved it, and which version they approved.

Policy Communication

Clause 7.4 requires that you communicate relevant information about the ISMS to internal and, where appropriate, external parties. For policies, this means:

• All employees must be aware that the policies exist
• Employees must have access to the policies relevant to their roles
• New employees must receive policy information during onboarding
• Significant policy changes must be communicated when they occur

Practical approaches for SaaS teams:

• Store policies in a centralized, accessible location (Confluence, Notion, SharePoint, or a GRC platform)
• Send a notification when policies are created or significantly updated
• Include policy review in the onboarding checklist
• Require annual policy acknowledgment from all employees (documented with timestamps)

Common audit finding: Policies exist in a document management system, but employees did not know they existed or could not find them. Auditors may interview employees and ask where they would find the access control policy. If the employee cannot answer, that is a communication gap.

Policy Acknowledgment

While ISO 27001 does not explicitly require signed acknowledgments, they are a strong form of evidence that communication occurred. Most certification auditors expect to see some form of acknowledgment, especially for critical policies.

Implement a system where employees electronically acknowledge that they have read and understood each policy. Track completion dates, and follow up with employees who have not completed their acknowledgments. This evidence is directly useful during audits.

Review Cadence and Lifecycle

Mandatory Review Frequency

ISO 27001 requires that documented information be reviewed and updated as necessary (Clause 7.5.2). While the standard does not specify a minimum review frequency, the universal expectation is annual review at a minimum.

Recommended cadence:

• Annual review: Every policy should be reviewed at least once per year, even if no changes are needed. Document that the review occurred and the policy was confirmed as current.
• Triggered review: Review and update policies when significant changes occur — organizational restructuring, major technology changes, new regulatory requirements, or lessons learned from security incidents.
• Post-incident review: After significant security incidents, review relevant policies to determine whether changes are needed.

The Review Process

A policy review is not just re-reading the document and signing off. An effective review includes:

1. Relevance check: Does the policy still address current risks and business context?
2. Accuracy check: Do policy statements match actual practices? If practices have drifted from the policy, either update the policy or correct the practices.
3. Completeness check: Have new risks, technologies, or regulations emerged that the policy should address?
4. Stakeholder input: Consult the teams responsible for implementing the policy. They know where the gaps are.
5. Approval: Updated policies go through the same approval process as new policies.
6. Communication: If changes were made, notify affected employees and request updated acknowledgments.

Version Control

Maintain a clear version history for every policy. You must be able to show auditors which version was in effect during any given period. This is especially important during the transition when policies are updated — the auditor needs to verify that the version in effect during the audit period was the version being followed.

Use a consistent versioning scheme (e.g., 1.0, 1.1, 2.0) and store previous versions rather than overwriting them. A GRC platform or document management system with built-in version control eliminates the risk of losing historical versions.

Mapping Policies to Annex A Controls

One of the most useful things you can do when building your policy framework is to create an explicit mapping between your policies and the Annex A controls they address. This mapping serves three purposes:

1. Completeness assurance: You can verify that every applicable Annex A control is addressed by at least one policy
2. Audit efficiency: Auditors can quickly find the policy relevant to any control they want to test
3. Gap identification: You can identify controls that are declared applicable in your SoA but lack supporting documentation

Sample Mapping

Annex A Control	Control Title	Primary Policy	Supporting Procedure
A.5.1	Policies for information security	Information Security Policy	Policy Management Procedure
A.5.9	Inventory of information and other associated assets	Asset Management Policy	Asset Inventory Procedure
A.5.15	Access control	Access Control Policy	User Provisioning Procedure
A.5.24	Information security incident management planning	Incident Management Policy	Incident Response Procedure
A.5.29	Information security during disruption	Business Continuity Policy	Disaster Recovery Procedure
A.8.24	Use of cryptography	Cryptography Policy	Key Management Procedure

Maintain this mapping as a living document. When you add or modify Annex A control applicability in your SoA, update the policy mapping simultaneously. When you update a policy, verify that the mapping still accurately reflects the policy’s content.

Policies vs. Procedures vs. Standards

Understand the hierarchy and keep the layers distinct:

• Policies state what the organization will do and why. They are approved by management and set direction. They change infrequently.
• Standards define specific measurable requirements. They translate policy intent into concrete benchmarks. Example: “AES-256 for data at rest.”
• Procedures describe step-by-step how to perform a task. They are operational and may change as tools or processes evolve.

Auditors expect to see this hierarchy reflected in your documentation. When a policy references a procedure, the procedure should exist. When a procedure references a standard, the standard should be documented. Broken references — policies that point to procedures that do not exist — are a common finding.

Common Policy Mistakes and How to Avoid Them

Copying Templates Without Customization

The most pervasive mistake. Generic templates contain references to physical server rooms, tape backup rotations, and visitor logbooks that have nothing to do with a cloud-native SaaS company. Every policy statement should describe something your organization actually does or will do.

Fix: Use templates as a starting framework, then rewrite every section to match your actual environment, tools, and workflows. If a section does not apply, remove it rather than leaving it as aspirational text.

Over-Committing

Organizations write policies that describe an ideal state rather than their actual capability. A policy that requires security reviews of every line of code, weekly penetration testing, and real-time threat hunting sounds impressive but creates obligations that are nearly impossible to sustain.

Fix: Write policies that reflect your current capability, with a clear plan to raise the bar through continual improvement. It is far better to have achievable policies that you consistently meet than ambitious policies that you consistently violate.

Under-Documenting

The opposite extreme — policies so vague that they provide no actionable guidance. “The company will protect its data” is a vision statement, not a policy.

Fix: Every policy statement should be specific enough to test. Ask: “Could an auditor determine whether we are complying with this statement?” If the answer is no, the statement needs more specificity.

Ignoring the Review Cycle

Policies are written during the initial ISMS implementation and never revisited. Two years later, the company has migrated from AWS to GCP, doubled in size, and launched three new products, but the policies still describe the original environment.

Fix: Set calendar reminders for annual reviews. Assign a policy owner for each document who is responsible for keeping it current. Build policy review into your internal audit scope.

Not Connecting Policies to Evidence

A policy exists, but there is no mechanism to prove compliance. The access control policy requires quarterly access reviews, but no one runs the reviews, and there are no records.

Fix: For every policy statement, define what evidence will demonstrate compliance and ensure a process exists to generate and retain that evidence. When building your certification checklist, trace each policy requirement to its evidence source.

Siloing Policies From Operations

Policies live in a Confluence space that no one visits. The engineering team has never read the change management policy because it was written by the compliance team without their input.

Fix: Involve operational teams in policy creation. Write policies in language they use. Store policies where they already work. If your team lives in Notion, put policies in Notion. If they use GitHub, consider managing policies as Markdown in a repository with pull request-based review workflows.

Frequently Asked Questions

How many policies does ISO 27001 require?

ISO 27001 does not specify a number. The standard requires certain documented information, and how you organize that information into policies is your decision. A small SaaS company might have 10-15 policies covering all Annex A controls. A larger organization might have 30 or more. What matters is that every applicable Annex A control traces to documented policy coverage, not the document count.

Can I combine multiple policies into a single document?

Yes. Some organizations maintain a single “Information Security Manual” that contains all policies in one document. Others split each topic into a separate document. Both approaches are acceptable. The single-document approach is simpler to manage for small teams. The multi-document approach scales better as the organization grows and different teams own different policy areas.

Do policies need to be in a specific format?

No. ISO 27001 does not prescribe document formats. Policies can be in Word documents, PDF files, wiki pages, Markdown files, or managed through a GRC platform. What matters is that they are controlled (versioned, approved, accessible) and reviewed.

Who should write the policies?

The person who understands both the subject matter and the organization’s actual practices. In most SaaS companies, this means collaboration between the security/compliance team and the relevant operational team. The security team provides the framework and control objectives. The operational team provides the implementation reality. A compliance consultant can help bridge the two.

How long should a policy be?

As long as necessary and no longer. A typical well-written policy runs 3-8 pages. If a policy exceeds 10 pages, consider whether some content belongs in a supporting procedure or standard. Brevity improves readability and adoption. However, do not sacrifice clarity for conciseness — if a policy statement needs a paragraph of context to be understood, include the context.

What is the difference between ISO 27001 policies and SOC 2 policies?

The underlying controls overlap significantly, but the documentation framework differs. ISO 27001 policies support an ISMS and are organized around Annex A controls. SOC 2 policies support a system description and are organized around Trust Service Criteria. Many SaaS companies pursuing both frameworks maintain a single policy set that satisfies both standards, with a mapping document that shows how each policy addresses both ISO 27001 controls and SOC 2 criteria.

How GRCTrail Helps

GRCTrail provides SaaS teams with a complete policy management solution built for ISO 27001 certification:

• ISO 27001-aligned policy templates written specifically for SaaS companies, covering every Annex A control with language that reflects cloud-native operations — no references to tape backups or physical server rooms
• Automated policy-to-control mapping that traces every Annex A control in your Statement of Applicability to the policy that governs it, identifying gaps before your auditor does
• Built-in policy lifecycle management with version control, digital approval workflows, employee acknowledgment tracking, and automated review reminders that ensure your policies never go stale

Get started with GRCTrail

Related Guides

• What Is ISO 27001? A Practical Guide for SaaS Companies
• ISO 27001 Requirements: Understanding Clauses 4-10
• ISO 27001 Annex A Controls: The Complete Guide
• ISO 27001 Certification Checklist
• ISO 27001 Access Control: Requirements, Controls, and SaaS Implementation
• SOC 2 Policies and Procedures: What You Need to Document