In many SMEs, the information security management policy is only created when a customer requests it in a tender or when an ISO 27001 project is already underway. In such cases, the result often ends up as a high-level document that looks good during audits but doesn't guide daily decisions, responsibilities, or activities.
In this article, we'll review what ISO 27001 requires from the management policy, what should be included, and how to practically build a functional document. You’ll get a clear step-by-step model, a sample structure, responsibilities, and metrics to ensure the policy remains active even after publication.
Prerequisites
- Named owner of the policy, for example, CEO, information security officer, or quality/IT manager
- Defined scope, meaning which business areas, services, locations, and systems the ISO 27001 management system covers
- Basic understanding of the company’s 3–5 key information security risks
- Decision on who approves the policy and how often it is reviewed, e.g., every 12 months
What Does an Information Security Management Policy Mean in ISO 27001?
In ISO 27001, the policy is a leadership-approved statement that directs the organization’s information security management system. Practically, it explains what the company protects, why it protects it, and the principles on which the protection is based. It is not just a security guideline for employees but a guiding document for the entire system.
A good policy at least answers these questions:
- What information, services, and processes does the company protect?
- What are the information security objectives for the next 12 months?
- Who is responsible for decisions, monitoring, and handling deviations?
- How are risks assessed and controls selected?
- How is compliance with the policy monitored in practice?
In SMEs, the policy is often most effective when it is 1–3 pages long. If the document stretches to 8–10 pages, it tends to mix policies, procedures, and detailed instructions.
Note
ISO 27001 does not require the information security management policy to be long or juridical. What matters is that management approves it, the content suits the organization’s purpose, and the policy is maintained.
What Should the Policy Include at a Minimum?
ISO 27001 does not provide a single ready-made template, but in practice, the policy should be clear enough that the auditor, employee, and customer understand it in the same way. If the content is too general, the policy won't guide anything. If you add too many details, it will quickly become outdated.
A practical minimum content often looks like this:
| Section | What to Include | Practical Example |
|---|---|---|
| Purpose | Why the policy exists | The company protects customer, personnel, and business data to manage risks and ensure service continuity |
| Scope | Which operations, units, and systems the policy covers | The policy covers SaaS service, support service, internal IT systems, and remote work |
| Information Security Objectives | 3–5 measurable objectives | Critical access rights are reviewed quarterly |
| Principles | Core rules guiding information security management | Access rights are granted based on the principle of least privilege |
| Responsibilities | Who owns, approves, and monitors | CEO approves, IT manager maintains, supervisors oversee implementation |
| Monitoring and Improvement | How the policy is reviewed | The policy is reviewed every 12 months or after significant changes |
When writing objectives, avoid vague phrases like "improve information security." A better approach is to define objective, metric, and deadline:
- Multi-factor authentication is enabled for 100% of maintenance accounts within 3 months.
- Access rights of departing employees are revoked within 24 hours of termination.
- Security incidents are preliminarily handled within 1 business day of detection.
Policy is Not the Same as Instructions
This is one of the most common confusions. The management policy states the direction and principles. Procedures and instructions explain in detail how something is done.
Think of it like this:
- The policy says access rights are managed carefully.
- The procedure details who approves access requests.
- The work instruction tells which buttons to click in the system.
If you include, for example, a detailed backup schedule or exact ticketing process in the policy, the document becomes obsolete as soon as tools change. Therefore, keep the policy stable and move changeable details to separate documents.
Warning
A common mistake is copying a policy directly from a template without considering the company’s business, risks, and responsibilities. Auditors notice this quickly, but more importantly, employees don’t recognize the document as their own.
How to Link the Policy to Company Risks and Objectives?
The core idea of ISO 27001 is risk-based thinking. This means you don’t create a policy just because the standard says so, but because your company has real risks: customer data might leak, the service might be interrupted, or access rights might remain active too long.
Start by listing 3–5 key risks. Then ensure the policy principles and objectives align exactly to those. For example:
| Key Risk | Policy Principle | Metric |
|---|---|---|
| Departing employee’s credentials remain active | Access rights are removed in a controlled manner upon termination | Removal done within 24 h |
| Customer data handled with overly broad rights | Least privilege principle is followed | Access review 4 times per year |
| Service interruption halts customer work | Continuity requirements are defined for critical services | Recovery test done 2 times per year |
| Phishing causes credential leaks | Staff is trained and authentication strengthened | Training coverage 95% annually |
Linking the policy to risks makes it a management tool, not just a certification appendix. It also simplifies resource decisions: you know where to focus first.
Who Approves the Policy and How is it Maintained?
ISO 27001 emphasizes management’s role. Practically, this means the policy shouldn’t be published only as an internal IT document. Management must approve it visibly and show that information security relates to business objectives.
A clear responsibility model might look like this:
| Role | Responsibility |
|---|---|
| CEO | Approves policy and ensures resources |
| IT Manager / Security Officer | Prepares, updates, and monitors implementation |
| Supervisors | Ensure teams follow the policy |
| Employees | Follow instructions and report deviations |
Maintenance follows a simple rhythm:
- Review the policy at least annually.
- Update it after significant changes, such as company acquisition, new SaaS service, or outsourcing.
- Document approval date, version number, and owner.
- Communicate changes to staff within 7 days of approval.
Tip
Add a one-line version control at the end of the policy: owner, approver, approval date, and next review date. You can implement this immediately without a separate project.
Define the Policy Purpose and Scope
First write a paragraph about which business activities, services, data, and locations the policy covers. Keep the scope concrete: for example, SaaS service, customer support, internal IT, and remote work environment. If the scope is unclear, audit and responsibilities will also be unclear.
Select 3–5 Key Information Security Objectives
Formulate objectives measurable for the next 12-month period. Use the objective–metric–deadline model, like "revoke access rights within 24 hours" or "MFA coverage for maintenance accounts 100%." This way, the policy guides actions and doesn’t remain general.
Record Key Principles for Managing Information Security
Choose 5–7 principles that remain stable even if tools change. Good examples include least privilege, risk-based decision-making, incident reporting, and continuous improvement. Avoid too technical details at this stage.
Assign Responsibilities and Get Management Approval
Clearly document who owns the policy, who updates it, and who approves it. Ensure management officially approves the document, for example, in a leadership meeting or via electronic approval. Without this, the policy easily becomes just an IT department paper.
Publish, Communicate, and Monitor Implementation
Store the policy somewhere employees can find it in under 2 minutes, such as the intranet or the management system’s document repository. Inform staff of changes, include the policy in onboarding, and monitor at least 3 metrics monthly or quarterly. This way, the document becomes practical management.
Sample Structure for a Functional Information Security Management Policy
If you’re wondering where to start, use this structure. It’s sufficient for most SMEs and easy to keep updated.
- Purpose of the Policy
- Scope
- Information Security Objectives
- Information Security Principles
- Roles and Responsibilities
- Commitment to Laws, Contracts, and Requirements
- Monitoring, Review, and Continuous Improvement
- Approval and Version Control
You can test the structure with three questions:
- Can a new employee understand the policy content within 10 minutes?
- Can management identify their responsibilities without further explanation?
- Can an auditor link policy objectives to practical metrics?
If the answer is no, the policy needs condensing or concretizing.
Most Common Mistakes in SMEs
Most problems don’t arise from a missing policy but from not tying it to daily operations. Do you recognize any of these in your organization?
- The policy is copied from a template and lacks company-specific risks.
- Objectives are not measurable or lack deadlines.
- Responsibilities are written vaguely as "the organization is responsible."
- The document is stored where staff can’t find it.
- The policy is not reviewed after changes.
Fixing this is often quick. Reserve 60–90 minutes for a workshop, review risks, responsibilities, and metrics, and update the policy in one round. Often, this elevates the document significantly.
How Does Tietoturvapankki Simplify Policy Building?
When working on ISO 27001 amid a busy daily schedule, the biggest challenge is usually not writing but managing the entire system. The policy should connect to risks, objectives, control selection, documents, and reviews. If these are scattered across files and owners, maintenance quickly slows down.
Tietoturvapankki combines the application and expert support so the policy doesn’t remain a disconnected document. When management system parts are within a single framework, it’s easier to see how the policy links to risk assessments, responsibilities, and continuous improvement. This is especially beneficial for SMEs without a dedicated security team.
The thinking familiar from other standards also helps. If your organization already has experience with ISO 9001 management or Laatupankki solutions, the same basic logic applies in information security: clearly define objectives, responsibilities, monitoring, and improvement. Softapankki Oy and QMClouds Oy’s operational models have made this approach familiar to many companies.
Summary
- Information security management policy is a leadership-approved statement guiding the entire ISO 27001 management system.
- A functional policy is usually 1–3 pages and includes purpose, scope, objectives, principles, responsibilities, and review practices.
- Always record objectives as measurable: for example, access rights revoked within 24 hours or access reviews 4 times per year.
- Don’t confuse policy with instructions: policy states direction; procedures and work instructions detail the steps.
- When the policy ties to company risks and is reviewed regularly, it becomes a truly useful management tool.
Need help with information security management?
Our experts are here to assist you.