ISO 27001 • Policies • Operating Controls • ISMS • Audit Readiness
Common Mistakes: Treating ISO 27001 Policies as Documents Instead of Operating Controls
ISO 27001 policies are not meant to sit in a folder until audit week. A good policy should drive real behavior, assign ownership, create evidence, and support control operation.
Quick Snapshot
| Policy Mistake | What Goes Wrong |
|---|---|
| Policies are written but not followed | Auditors ask for evidence, but the team cannot prove operation. |
| Policies have no owner | Nobody updates, reviews, or explains the policy. |
| Policies promise too much | The company creates audit gaps by overcommitting. |
| Policies are not linked to controls | The ISMS becomes document-heavy but weak in practice. |
| Outcome | Policies become operating controls that produce proof, not just paperwork. |
Introduction
ISO 27001 implementation often starts with policies.
That makes sense. Policies are visible. They feel concrete. They help show structure. They also make the ISMS look organized.
But policies can create a false sense of progress.
A company may have an Access Control Policy, Supplier Security Policy, Incident Response Plan, Backup Procedure, Risk Management Procedure, and Information Security Policy.
Everything may look good in SharePoint or a GRC platform.
Then the auditor asks:
- Can you show the last access review?
- Can you show the vendor approval record?
- Can you show the restore test?
- Can you show policy review evidence?
- Can you show management approval?
- Can you show exceptions and corrective actions?
That is when the problem becomes clear. The policy exists, but the control is not operating.
Need Help Turning Policies Into Working Controls?
Canadian Cyber helps organizations build practical ISO 27001 policy libraries, SharePoint ISMS workflows, evidence packs, control ownership models, and audit-ready operating procedures.
Why Policies Are Not Enough
A policy is a commitment.
It says what the organization expects, requires, or controls.
But ISO 27001 is not only about writing commitments. It is about managing information security through a working ISMS.
That means policies should connect to:
- risk
- ownership
- processes
- evidence
- reviews
- approvals
- exceptions
- corrective actions
| Policy as a Document | Policy as an Operating Control |
|---|---|
| Stored in a folder. | Assigned to an owner. |
| Written once. | Reviewed on schedule. |
| Uses generic wording. | Matches real operations. |
| Has no evidence. | Produces recurring evidence. |
| No exceptions tracked. | Exceptions are approved and reviewed. |
Practical rule: A policy should answer two questions. What do we require? How do we prove it happens?
Mistake 1: Writing Policies Before Understanding the Business
Many ISO 27001 projects begin with templates.
Templates can help. But they become risky when the company copies them without checking reality.
| Policy Says | Reality |
|---|---|
| All vendors are reviewed annually. | There is no vendor register. |
| Access is reviewed quarterly. | Access reviews only happen before audits. |
| Incidents are tested annually. | No tabletop exercise has happened. |
| Backups are restored quarterly. | Only backup jobs are monitored. |
| All staff use managed devices. | Contractors use personal laptops. |
Auditors compare policy commitments against evidence.
If the policy promises something your team does not do, the policy becomes a finding.
Better approach: Write policies based on your real operating model. Then improve the operating model over time.
Mistake 2: No Policy Owner
Every ISO 27001 policy needs an owner.
The owner does not need to write every word. But they must keep the policy accurate and ensure the related control operates.
| Policy | Likely Owner |
|---|---|
| Access Control Policy | IT Lead / Security Lead |
| Supplier Security Policy | Operations / Procurement / Compliance |
| Incident Response Plan | Security Lead / vCISO / IT Lead |
| Backup and Recovery Procedure | IT / DevOps |
| Risk Management Procedure | ISMS Owner / vCISO |
What the Owner Should Do
- review the policy
- confirm it matches real operations
- approve updates
- define evidence needed
- monitor exceptions
- support audits
Practical rule: If nobody owns the policy, nobody owns the control.
Need Policy Owners, Review Dates, and Evidence Links?
Canadian Cyber can help you turn your policy library into a working ISMS with owners, approval workflows, review reminders, evidence links, and audit-ready metadata.
Mistake 3: Policies Are Not Linked to Evidence
This is one of the biggest audit gaps.
A policy says what should happen. Evidence proves it did happen.
The connection must be clear.
| Policy Commitment | Evidence Needed |
|---|---|
| Access is reviewed quarterly. | User export, review sign-off, removals, and exceptions. |
| Vendors are reviewed before approval. | Vendor register, assurance review, and approval decision. |
| Incidents are logged and reviewed. | Incident log, investigation record, and lessons learned. |
| Backups are tested. | Restore test record and result. |
| Policies are reviewed annually. | Policy review record and approval history. |
Practical rule: For every major policy requirement, define the evidence source.
Mistake 4: Policies Are Too Generic
Generic policies are common.
They sound professional, but they do not tell teams what to do.
Generic wording:
“Access shall be controlled according to business requirements.”
Better wording:
“Access to Microsoft 365, Entra ID, SharePoint, production systems, source code repositories, and customer support tools must be assigned based on role and reviewed at least quarterly by the assigned system owner.”
| Generic Phrase | Better Direction |
|---|---|
| “Periodically reviewed” | Say monthly, quarterly, or annually. |
| “Appropriate access” | Define role-based or least privilege access. |
| “Vendors are assessed” | Define risk tier and review requirements. |
| “Logs are monitored” | Define log sources, alerts, and review cadence. |
| “Backups are tested” | Define restore test cadence and evidence. |
Mistake 5: Policies Are Not Reviewed After Business Changes
Businesses change. Policies must keep up.
Policy review should happen after major changes, such as:
- a new cloud provider
- a new product launch
- a new client portal
- a new vendor
- a new AI tool
- a new audit finding
- a new customer security requirement
| Policy Review Evidence | What It Proves |
|---|---|
| Review date | The policy was checked. |
| Review notes | Human review occurred. |
| Version history | Changes are controlled. |
| Approval record | Management or owner approved the update. |
| Next review date | The lifecycle is managed. |
Practical rule: Annual review is the minimum. Major business changes should trigger review sooner.
Mistake 6: Policies Are Approved but Not Communicated
A policy that nobody knows about is weak.
Some policies should be communicated to all staff. Others only need to be communicated to control owners.
| Audience | Policies They Need to Know |
|---|---|
| All Staff | Information Security, Acceptable Use, Remote Work, Incident Reporting, AI Use, and Client Data Handling. |
| Control Owners | Access Control, Supplier Security, Change Management, Backup, Logging, Risk Management, and Internal Audit. |
Communication Evidence
- policy acknowledgement report
- training completion report
- email announcement
- Teams announcement
- onboarding checklist
- control owner briefing notes
Mistake 7: Policies Have No Exception Process
Real life creates exceptions.
A vendor may not have SOC 2. A system may not support SSO yet. A user may need temporary admin access.
Exceptions are not automatically failures.
Unapproved exceptions are.
| Exception Register Field | Purpose |
|---|---|
| Exception ID | Tracks the exception. |
| Policy / Control | Shows what requirement is affected. |
| Risk | Shows business impact. |
| Approval | Shows who accepted it. |
| Expiry Date | Prevents permanent drift. |
Practical rule: Exceptions are acceptable when they are visible, approved, time-bound, and reviewed.
Mistake 8: Policies Are Stored but Not Controlled
Document control matters.
A policy library should show which version is current, who approved it, and when it must be reviewed again.
| Policy Library Field | Purpose |
|---|---|
| Policy Owner | Shows accountability. |
| Approver | Shows approval responsibility. |
| Version | Shows the current version. |
| Last Review Date | Shows review evidence. |
| Related Control | Supports audit traceability. |
Build a Better ISO 27001 Policy Library in SharePoint
Canadian Cyber’s ISMS SharePoint solution helps organizations manage policy owners, version history, approvals, review reminders, evidence links, and audit-ready metadata.
Mistake 9: Policies Do Not Feed Internal Audit
Internal audit should test whether policies are being followed.
But many organizations only check whether the document exists.
That is not enough.
| Policy | Internal Audit Should Ask |
|---|---|
| Access Control Policy | Were access reviews completed for critical systems? |
| Supplier Security Policy | Were critical vendors reviewed and approved? |
| Incident Response Plan | Was the plan tested through a tabletop or incident review? |
| Backup Procedure | Was restore testing completed and documented? |
| Change Management Procedure | Were sampled changes reviewed before deployment? |
Practical rule: Internal audit should test control operation, not only document existence.
Mistake 10: Policies Are Not Connected to Management Review
ISO 27001 expects leadership involvement.
Policies can create leadership decisions.
For example, leadership may need to:
- approve policy direction
- accept policy exceptions
- fund required controls
- review overdue actions
- support corrective actions
- review internal audit findings
| Management Review Input | Why It Matters |
|---|---|
| Overdue policy reviews | Shows governance gaps. |
| Major policy changes | Requires leadership awareness. |
| Policy exceptions | May need risk acceptance. |
| Control failures | May require resources. |
| Staff acknowledgement gaps | Shows awareness issues. |
Policy as Operating Control Checklist
Use this checklist for each ISO 27001 policy.
| Question | Yes / No |
|---|---|
| Does the policy have a named owner? | |
| Does the policy match current operations? | |
| Is the policy approved? | |
| Is approval evidence saved? | |
| Is there version history? | |
| Is the next review date defined? | |
| Is evidence defined for each major requirement? | |
| Are exceptions tracked and approved? | |
| Does internal audit test whether it is followed? | |
| Are major issues reported to management review? |
If several answers are no, the policy may be a document, not an operating control.
Example: Access Control Policy as an Operating Control
A weak version is simple. The company has an Access Control Policy saved in SharePoint.
But there is no:
- review schedule
- system list
- evidence folder
- exception register
- control owner sign-off
A strong version includes:
- owner
- approver
- version history
- review date
- scope of systems
- quarterly review requirement
- access review template
- exception process
| Evidence Produced | Why It Matters |
|---|---|
| MFA report | Shows authentication controls. |
| User access review | Shows access was reviewed. |
| Privileged access review | Shows admin access was checked. |
| Exception register | Shows exceptions were approved. |
| Offboarding tickets | Shows former users were removed. |
How to Fix Policy-Only ISO 27001 Programs
If your ISO 27001 program is document-heavy, do not panic.
You can fix it by connecting policies to ownership, evidence, and review.
| Step | What to Do |
|---|---|
| 1. Review commitments | Identify what each policy promises. |
| 2. Assign owners | Every policy and control requirement needs ownership. |
| 3. Create evidence links | Define where evidence will live. |
| 4. Add review dates | Set review cadence and automate reminders. |
| 5. Track exceptions | Create a simple exception register. |
| 6. Test through internal audit | Sample policies and check whether evidence exists. |
Turn Your ISO 27001 Policies Into Operating Controls
Canadian Cyber can help turn your ISO 27001 policy library into a working ISMS with owners, evidence, review workflows, exceptions, and audit-ready controls.
What Good Looks Like
A strong ISO 27001 policy program has:
- clear owners
- approved versions
- review dates
- version history
- specific control requirements
- evidence links
- exception process
- staff communication
- internal audit testing
- corrective action tracking
- management review visibility
The policies are not just stored. They are used.
Canadian Cyber’s Take
At Canadian Cyber, we often see ISO 27001 projects that look complete because the policy library is full.
But a full policy library does not equal a working ISMS.
Auditors and clients do not only care that policies exist. They care whether the organization follows them.
That means each policy must be connected to ownership, evidence, review, exceptions, and improvement.
The strongest ISO 27001 programs treat policies as operating controls. They are instructions for how the business protects information and proves it.
A policy should guide behavior, create evidence, and support continual improvement.
Takeaway
ISO 27001 policies should not sit in a folder waiting for audit week.
They should drive real control operation.
Before approving a policy, ask:
- Who owns it?
- What does it require?
- Can we prove it?
- Where is the evidence?
- How often is it reviewed?
- How are exceptions handled?
- How will internal audit test it?
If you can answer those questions, your policy is more than a document. It is part of a working ISMS.
How Canadian Cyber Can Help
Canadian Cyber helps organizations build ISO 27001 policies that work in practice, not just on paper.
- ISO 27001 policy library reviews
- policy-to-control mapping
- SharePoint ISMS policy workflows
- policy approval and review tracking
- evidence pack design
- access review workflows
- vendor review workflows
- risk register setup
- exception register design
- internal audit preparation
- management review reporting
- vCISO support for ISMS governance
Stay Connected With Canadian Cyber
Follow Canadian Cyber for practical guidance on ISO 27001, policy governance, SharePoint ISMS, audit readiness, risk management, evidence workflows, and vCISO support.
