Almost every organisation we engage with has an information security policy framework. They have a set of documents — an information security policy, an acceptable use policy, a data protection policy, an access control policy — that were created at some point in the past, updated occasionally, and are technically available to employees somewhere on the intranet.
Almost none of them have a policy framework that actually works. The policies exist as compliance artefacts. They do not guide behaviour. They are not reviewed when the environment changes. They are not enforced when they are violated. Employees have not read them and could not locate them if asked.
This is a GRC failure with real consequences. Policies that exist on paper but not in practice create a compliance illusion — your certification audit may pass, but your actual security posture is not what your policy framework implies.
How to Tell If Your Policy Framework Is Broken
There are four questions that diagnose a broken policy framework quickly:
Can your employees find the policies? Not “do the policies exist somewhere” — can an employee who needs to know what the acceptable use policy says actually locate and read it? If the policies are buried in a SharePoint folder that most employees have never navigated to, they are not functioning policies.
When were the policies last reviewed? A policy last reviewed three years ago may predate cloud adoption, remote working, major platform changes, and significant regulatory developments. A policy that does not reflect the current operating environment is not governing the current operating environment.
Are the policies enforced? If the acceptable use policy prohibits certain activities and those activities are demonstrably occurring — shadow IT, personal device use without MDM, sharing credentials — without consequence, the policy is not functioning as a control. It may function as evidence for a certification audit, but it is not doing the governance work it is supposed to do.
Are the policies integrated with processes? Policies should connect to operational processes — the access request process should implement the access control policy; the change management process should implement the change management policy. If policies exist independently of the processes they are supposed to govern, the connection between policy intent and operational reality is broken.
What a Functional Policy Framework Looks Like
A functional policy framework has a defined hierarchy — a top-level information security policy that sets direction and principles, supported by topic-specific policies that address specific domains, further supported by procedures that provide operational guidance. The hierarchy is explicit: anyone in the organisation can understand the relationship between the overarching policy and the specific procedure they are following.
Policies are owned — specific individuals are accountable for each policy, responsible for keeping it current, and empowered to escalate violations. Review cycles are scheduled and evidenced. When significant changes occur — a new cloud platform, a new regulatory requirement, a significant incident — the relevant policies are reviewed and updated as a defined process, not as an ad hoc response.
Policies are communicated and acknowledged. Employees know what policies apply to them, where to find them, and that compliance is expected and monitored. New joiners receive policy training as part of onboarding. Annual acknowledgement is captured as evidence.
At Bitsecura, we design and implement policy frameworks that function — not policy libraries that exist to satisfy auditors. If your policy framework has drifted from the organisation’s current reality and you want to fix it properly, reach out here.
Bitsecura provides IT GRC programme design and implementation services. Learn more about our IT GRC services.