A policy suite written to reflect how your company actually operates — and the governance framework that ensures people follow it, exceptions are managed, and the whole thing stays current as the business changes.
Security policies are easy to produce. Templates exist, compliance frameworks provide lists, and most organisations can assemble a policy suite in a matter of weeks. What is much harder is producing policies that people actually follow — because the policies describe how the company actually works, not how it should work in theory.
The gap between having policies and having governance is not a document gap. It is an ownership gap. When policies have no named owner, no review date, and no exception process, they are not a governance framework — they are a folder that gets referenced when something goes wrong and cited as evidence that something was in place.
Security governance is the difference between policies that change behaviour and policies that demonstrate intent. The first protects the business. The second protects the appearance of the business — until an auditor, a customer, or an incident tests whether the policies reflect reality.
The policy stated that access reviews were conducted quarterly, approvals were documented, and terminated employees were removed within 24 hours. The auditor asked the IT lead to walk through the most recent review. There was no record of it. The previous one was fourteen months ago. Three accounts belonging to people who had left the company were still active. The policy was current, signed off, and completely disconnected from the way access was actually managed.
Annual acknowledgement completion was tracked at 97%. The security team reported it confidently. During a post-incident review, it emerged that the incident involved a behaviour the acceptable use policy explicitly prohibited. When asked, the employee said they had clicked through the acknowledgement without reading it — and so had most of their team. Acknowledgement rates measure whether the email was received. They do not measure whether the policy changed anything.
The exception process existed. Requests were submitted. Approvals were granted. Nobody reviewed whether temporary exceptions had been resolved, whether the risk had changed, or whether the business still needed the exception at all. Forty-seven open items. No review dates. No escalation path. An exception register that is never reviewed is not risk management — it is a permanent record of deferred decisions.
A well-governed policy programme has three properties that most policy suites lack: the policies reflect operational reality, so people can actually follow them; ownership is clear, so someone is accountable when they are not followed; and the programme stays current, so the policies describe the business as it is today — not as it was when they were written.
The test of a policy is not whether it was approved. It is whether an auditor could walk into the business tomorrow, pick any policy at random, and verify that what it describes is what actually happens.
A policy and governance engagement delivers the written framework and the operating infrastructure to maintain it — not a document drop that starts drifting the moment it is handed over.
Policies written to reflect how the company actually operates — not adapted from a template designed for a different industry, a different size, or a different risk profile. Each policy is reviewed against current operational practice before it is written, so it describes something the business can actually follow.
Governance is not the policies themselves — it is the structure that ensures the policies are followed, reviewed, and enforced. A governance framework assigns ownership to named individuals, defines the review cadence, establishes the escalation path when policies are breached, and makes the whole programme auditable.
Every organisation has exceptions. The question is whether they are managed or just accumulated. An exception management process gives the business a formal route for legitimate exceptions — with a defined approval authority, a time limit, a review date, and a closure requirement. Exceptions that are never closed are not exceptions — they are permanent policy gaps.
Policy awareness that measures acknowledgement rates is measuring the wrong thing. The question is not whether people clicked the link — it is whether they know what the policies require of them and could demonstrate it if asked. The awareness programme is designed around behaviour change, with role-specific content for the teams whose behaviour matters most.
Most policy engagements end with a document drop. This one ends with a programme the business can run — because the policies were written with the people who will follow them, and the governance structure is embedded before the engagement closes.
An assessment of the existing policy suite against operational reality — not just checking whether policies exist, but whether what they describe matches how the business actually works. Every policy that describes a process that is not followed is a liability, not an asset. Policies that pass an audit but fail an incident review are worse than no policy at all — they establish an expectation the business cannot meet.
Week 1Policies are drafted in collaboration with the teams they govern — not written in isolation and handed down. The access control policy is drafted with the people who manage access. The acceptable use policy is reviewed by the people whose use it governs. A policy that a team helped write is a policy they understand. A policy that was sent to them is a policy they will click through.
Weeks 2–5The governance framework is built alongside the policies — not added as an afterthought. Policy owners are identified and confirmed. The review cadence is agreed and calendared. The exception process is documented, the approval authority defined, and the register established. The governance infrastructure is in place before the policies go live — not six months later when the first exception request arrives and nobody knows what to do with it.
Weeks 4–6The policy programme is launched with role-specific awareness content and a communication plan that explains what has changed, why it matters, and what each team is expected to do differently. The first annual review is scheduled before the engagement closes. A policy programme that goes live without an embedded review cadence will drift. The first review date is the most important date in the programme — it is what turns a document into a governance function.
Weeks 6–8The companies that need this engagement most are often the ones who believe their policies are in reasonable shape — until an auditor, a customer review, or an incident tests whether the policies describe what actually happens.
Every compliance framework requires a policy suite. Auditors test not just whether the policies exist but whether they are current, whether they have named owners, and whether there is evidence that the procedures they describe are actually followed. A policy suite written for the audit rather than for the business will satisfy a Type I and struggle at a Type II.
At 20 people, security behaviours were managed by proximity and trust. At 80 people, the founding team's informal understanding of how things should be done is not reaching the people who joined after them. Policies are how security norms scale — but only if they are written in a way that the people who need to follow them can actually understand and apply.
The policies were written when the company used a different cloud provider, had a different approach to remote work, and operated a different set of third-party integrations. The business has changed. The policies have not. A policy that described the business accurately twelve months ago and has not been reviewed since is, at best, partially current — and the parts that are wrong are the ones most likely to cause a problem.
Exceptions were approved but never closed. The register grew. Nobody reviewed whether the risk had changed, whether the compensating control was still in place, or whether the business still needed the exception. The register is now a list of accumulated risk decisions that nobody owns. Clearing it, establishing an ongoing process, and preventing recurrence is a governance problem — not a technical one.
The engagement ends with a programme the business owns and can run — not a document set that requires an external consultant to maintain.
A full set of information security policies covering the controls your framework, customers, and risk profile require. Each policy has a named owner, a review date, and version history. Written to describe how the business operates — so the person responsible for following it can actually do so.
A documented governance structure: who owns each policy, when it is reviewed, who approves changes, and what happens when a policy is breached. The governance framework is what turns a policy suite into a security programme — the document is the what; the framework is the who and the when.
An exception register with all current exceptions documented, time-limited, and assigned. An exception management process with defined approval authority, compensating control requirements, and a quarterly review cadence. Exceptions are managed, not accumulated.
An awareness programme that goes beyond acknowledgement rates — with role-specific content for the teams whose behaviour the policies most directly govern, and a measurement approach that tests understanding rather than completion. Refreshed annually as policies are reviewed, not just when the year turns.
When an auditor picks a policy at random and asks for evidence that it is being followed, the evidence exists. When a customer asks for your information security policies in a security review, they are current and the person sending them has read them. When an exception is approved, it has a close date. When a policy is breached, someone is accountable. The programme runs without external support — because it was built to.