BLOG

By David Chernitzky, Co-Founder and CEO, Armour Cybersecurity  |  Serving organizations across Canada, the US, and beyond  |  Last updated August 18, 2026

Quick answer: Most organizations have cybersecurity policies, but most have cybersecurity policy gaps that quietly leave the business exposed. The gap between a written policy and an operational control is where auditors find failures and attackers find opportunity. Policies fail for three predictable reasons: they are written to satisfy a framework requirement rather than to reflect how the organization actually operates, they are not tied to procedures that document how the policy is implemented in practice, and nobody is accountable for enforcing them or reviewing them as the business evolves. A policy library that works is current, specific, grounded in operational reality, and owned by people who are responsible for its enforcement.

Key Takeaways

• A policy that has not been reviewed in the past year is likely out of date. Organizational changes, technology changes, regulatory updates, and changes in the threat landscape all affect whether a policy remains accurate and enforceable. Most organizations update their policies in response to audits rather than as part of a defined governance cadence.
• The policy-procedure distinction is critical. A policy states what must be done or not done. A procedure documents how the policy is implemented in practice: the specific steps, the responsible parties, the tooling used, and the evidence produced. Auditors reviewing a policy that has no accompanying procedure cannot verify that the policy is followed; they can only verify that it was written.
• Generic policies that could apply to any organization regardless of industry, size, or technology environment are a common output of template-based policy development. They satisfy the existence requirement of framework audits while providing no operational guidance to the employees who are supposed to follow them.
• Policy ownership is the accountability mechanism that keeps policies current and enforced. Every policy should have a named owner who is responsible for reviewing it on the defined cadence, updating it when the organizational reality it describes changes, and reporting on compliance with it to the governance committee.
• The most valuable test of whether a policy is working is whether the employees it applies to know what it requires of them. A policy that employees have never read, cannot locate, and have not been trained on is not a control; it is a document in a shared drive.

How Policies Get Written and Why They Usually Fail

The most common origin of a cybersecurity policy library is a compliance engagement. An organization faces an audit, certification requirement, or customer security questionnaire that asks whether it has specific policies in place. A consultant or internal resource locates a policy template, customizes the organization name and a handful of specific details, and publishes the policy to satisfy the requirement. The policy satisfies the checkbox; it does not create an operational control.

The problem with this origin is that policies written to satisfy a framework requirement are written from the framework’s perspective, not the organization’s. They use the framework’s language, address the framework’s control domains, and satisfy the framework’s documentation requirements. They do not necessarily describe how the organization actually manages access, how it actually classifies data, how it actually handles incidents, or how it actually makes security decisions. The gap between the policy and the operational reality means that the policy cannot be enforced because enforcement would require employees to change how they work, not just to acknowledge that they have read a document. This is the core of most cybersecurity policy gaps, and it is a governance problem that a governance, risk and compliance program is built to close.

A second common failure mode is policy proliferation without maintenance. Over multiple audit cycles, an organization accumulates policies: an access control policy from 2019, an incident response policy from 2021, a remote work policy from 2020, a data classification policy from 2022. Each was written for the audit cycle during which it was produced. None has been reviewed against the others for consistency. Together they may contain contradictory requirements, reference systems or processes that no longer exist, and describe roles or organizational structures that have changed significantly. An auditor reviewing this library will note the inconsistencies; an employee trying to follow the policies will be confused by them.

What a Working Policy Library Contains

Policies grounded in operational reality

A policy that works describes how the organization actually manages the relevant control, not how a generic organization theoretically should. The access control policy should describe the actual process by which access is provisioned, reviewed, and revoked in the organization’s specific identity and access management environment. The incident response policy should describe the actual escalation chain, the actual communication protocols, and the actual tools used by the organization’s security and IT teams. The data classification policy should describe the actual data categories relevant to the organization’s business, using terminology that employees in the business units that handle that data will recognize.

Writing policies grounded in operational reality is what separates real information security policy development from template editing: it requires engaging the people who run the controls, not just the people who own the policies. The IT administrator who provisions access knows how access requests are actually submitted and approved; the CISO who owns the access control policy may not. The incident response policy written by a consultant without interviewing the security operations team will describe a generic incident response process, not the organization’s actual one. Structured interviews with the people who implement the controls are the essential input to operationally realistic policy development.

Procedures tied to every policy

Every policy should be accompanied by at least one procedure that documents how the policy is implemented. If the access control policy requires that access to sensitive systems is reviewed quarterly, the access review procedure documents who conducts the review, using which system or tool, with what evidence produced, stored where, and reviewed by whom. Without the procedure, the policy is a statement of intent. With the procedure, it is an operational control with a documented implementation path that auditors can evaluate and that employees can follow.

The procedure is also what makes a policy survivable through staff changes. When the IT administrator who conducted access reviews leaves the organization, their replacement can follow the procedure without having to invent a new process or ask the departing employee how things were done. The institutional knowledge embedded in undocumented processes is a significant governance risk; procedures are the mechanism that converts institutional knowledge into organizational capability.

A defined ownership and review cadence

Every policy should have a named owner: the individual who is accountable for the policy’s accuracy, responsible for reviewing it on the defined cadence, and empowered to update it when the organizational reality it describes changes. Policy owners should not all be the CISO or IT director; they should be the business owners of the processes and controls the policy describes. The incident response policy owner is typically the CISO or head of security. The data protection policy owner may be the Chief Privacy Officer. The acceptable use policy owner may be the HR director in collaboration with IT and security.

The review cadence for most policies is annual at minimum, with trigger-based reviews when material changes occur: a significant technology change that affects how a control is implemented, a regulatory update that changes what the policy must require, an organizational restructuring that changes who is accountable for a control, or an incident that reveals a gap between the policy and the operational reality. The annual review is documented with a version history showing the review date, the reviewer, and any changes made. This version history is audit evidence that the policy is actively maintained rather than static.

Alignment across the policy library

A cybersecurity policy framework is internally consistent when the terms, definitions, roles, and requirements in each policy do not contradict those in other policies. The data classification categories defined in the data classification policy should be used consistently in the data handling procedures, the acceptable use policy, the vendor management policy, and the incident response policy. The role titles used in escalation procedures should match the actual organizational structure. The system names referenced in access control procedures should match current system inventory. Inconsistency across a policy library is one of the most common findings in policy reviews and one that creates practical problems for employees trying to follow the policies and audit problems for organizations trying to defend them.

Armour Cybersecurity reviews existing policy libraries for completeness, currency, operational grounding, and cross-policy consistency as part of its GRC engagement, modernizing existing documentation and drafting new policies where gaps exist. This sits inside the broader governance function rather than being treated as a standalone documentation cleanup.

Testing Whether Your Policies Are Actually Working

The most reliable test of whether a policy is working is direct: ask the employees it applies to what it requires of them. Employees who know what the policy requires, who know where to find it, and who know how to follow the procedure it describes are indicators of a functioning policy. Employees who have never heard of the policy, cannot locate it, or describe practices that contradict it are indicators that the policy exists in a governance document rather than in organizational practice.

A structured policy awareness assessment, in which a sample of employees across relevant functions are asked about specific policy requirements, is a form of security policy audit that identifies gaps between the documented policy position and the operational reality faster than a documentation review alone. It also surfaces training needs: if employees are not following a policy because they do not know it exists, the intervention is communication and training; if they are not following it because the procedure is impractical, the intervention is procedure redesign.

Frequently Asked Questions

How many policies should an organization have?

The right number of policies is the number needed to cover every material control domain relevant to the organization, without creating policy sprawl that becomes unmanageable. ISO 27001 Annex A covers 93 controls organized across four themes; a policy library that supports ISO 27001 typically contains 15 to 25 distinct policies covering the major control domains: access control, asset management, cryptography, physical security, operations security, communications security, system acquisition and development, supplier relationships, incident management, business continuity, and compliance. Some organizations consolidate related domains into fewer, broader policies; others separate them more granularly. The determining factors are the size and complexity of the organization, the number of applicable frameworks, and the practical manageability of the policy library. A 50-policy library that nobody maintains is worse than a 20-policy library that is current and actively enforced.

Do we need separate policies for each regulatory framework we must comply with?

No, and maintaining separate policy libraries for different frameworks is one of the most inefficient approaches to multi-framework compliance. A single policy library, designed to satisfy the requirements of all applicable frameworks simultaneously, is more maintainable, less confusing to employees, and equally effective for audit purposes. The compliance mapping matrix that maps each policy to the specific control requirements it satisfies across all applicable frameworks is the mechanism that demonstrates to auditors how the single policy library addresses multiple regulatory obligations. This approach is standard practice in mature GRC programs and is explicitly anticipated by most major frameworks, which recognize that organizations typically must satisfy multiple regulatory requirements with a unified control set.

What should we do with outdated policies that conflict with current operations?

Outdated policies that conflict with current operations should be updated to reflect current reality, not maintained as written with the expectation that operations will adjust to match them. A policy that requires quarterly access reviews but that the organization has never actually conducted is not a compliant control with a compliance gap; it is an undocumented risk acceptance that auditors will find and that leadership should be aware of. The update process should begin with an interview of the people who run the control to understand how it actually works, followed by a policy revision that accurately describes the actual process, a review by the policy owner and legal or compliance counsel, and publication with version history updated. If the actual process does not meet the framework requirement the policy is supposed to satisfy, the gap should be documented in the security risk register and a remediation plan should address it.

How do we handle employees who do not follow security policies?

Policy compliance requires three elements working together: awareness (employees know the policy exists and understand what it requires), capability (employees can follow the policy with available tools and reasonable effort), and accountability (there are consequences for non-compliance that are applied consistently). Most policy compliance failures are awareness or capability failures, not willful non-compliance. Employees who do not know a policy exists cannot follow it. Employees who find the policy procedure impractical will work around it. The intervention for awareness failures is communication and training. The intervention for capability failures is procedure redesign or tooling changes. When willful non-compliance occurs despite awareness and capability, the accountability mechanism of the conduct and disciplinary framework applies. Documenting which policies employees have acknowledged and completed training on is the evidence base that supports accountability actions when needed.

How do customer security questionnaires relate to our policy library?

Customer security questionnaires ask about the existence and content of specific policies as a standard component of vendor security assessment. A well-organized, current policy library is the primary source for answering the policy-related questions on these questionnaires. Organizations with maintained policy libraries can answer questionnaires faster, more accurately, and more consistently than those without, because the answer to a questionnaire question about the access control policy is simply what the access control policy says. Organizations without maintained policies either answer based on what they believe is true (which may not match documented practice and creates misrepresentation risk) or answer slowly because they need to research the actual situation before they can respond. Understanding what security questionnaires miss is useful on both sides of this exchange, and a policy library organized to support questionnaire responses, with consistent terminology, clear policy statements, and current review dates, is a competitive advantage in enterprise sales processes where vendor security questionnaires are a procurement requirement.

The Bottom Line

A cybersecurity policy protects you only when it describes what the organization actually does, is backed by a procedure someone can follow, has an owner accountable for keeping it current, and is known to the employees it governs. Most policies fail one or more of those tests, which is why so many organizations carry a shared drive full of documents that satisfy an auditor’s existence check while doing nothing to change behavior. Closing cybersecurity policy gaps is not a writing exercise; it is a governance exercise: interview the people who run the controls, tie every policy to a procedure, assign owners, align the library, and review on a real cadence. A structured governance, risk and compliance program is what turns a policy library from a checkbox into a working control set.