Policy and Procedure Development
Policies fail when they are written to satisfy an auditor rather than to be followed. The result is a document nobody reads, describing a process nobody performs, which then becomes a finding in its own right because practice departs from the stated policy. A policy that people actually follow is shorter, plainer and mapped to a control that matters.
1
Audit
What exists already
2
Rationalise
Cut and merge
3
Draft
Language people read
4
Map
Policy to control
5
Implement
Approve and train
How We Deliver It
01
Policy Audit
We inventory what exists, when it was approved and whether anybody follows it. Organisations frequently have three overlapping documents on the same subject, two of them unapproved and none of them current.
- Inventory of existing policies with approval dates
- Overlaps and contradictions between documents
- Policies referencing systems or roles no longer in use
- Gaps where a required policy does not exist
02
Rationalisation
Fewer, better documents. A suite of forty policies guarantees nobody reads any of them, and merging related documents usually removes contradictions that nobody had noticed.
- Related documents merged where sensible
- Obsolete policies withdrawn formally
- Required policy set defined against obligations
- Hierarchy set: policy, procedure, work instruction
03
Drafting
Written in language the intended reader will actually understand, describing what people should do rather than restating legislation. A procedure a new employee can follow on their first week is the standard.
- Plain language aimed at the actual reader
- Procedures written as steps rather than principles
- Responsibility stated per step
- Length kept to what will realistically be read
04
Control Mapping
Each policy mapped to the control it is meant to enforce and the evidence that control will generate. A policy requiring something that produces no artefact cannot be tested and will be reported as ineffective.
- Each policy mapped to its underlying control
- Evidence the control will generate specified
- Alignment to prior audit findings
- Cross references between related documents
05
Approval and Implementation
Approval through the right structure, then the training and communication that turns a document into practice. Acknowledgement records matter because auditors test awareness, not just existence.
- Approval routed through the correct structure
- Version control and review dates set
- Training delivered to affected staff
- Acknowledgement records retained
What You Receive
- Inventory of existing policies with gaps and overlaps identified
- Rationalised policy set with obsolete documents withdrawn
- Drafted policies and procedures in plain language
- Each policy mapped to its control and expected evidence
- Approval routing and version control arrangements
- Training delivery and acknowledgement records
Indicative Timeline
A policy audit takes one to two weeks. Drafting depends on volume, typically one to two weeks per substantial policy including consultation, and approval is governed by your committee cycle rather than by us.
- Policy audit and inventory: one to two weeks
- Rationalisation and gap analysis: one week
- Drafting and consultation: one to two weeks per policy
- Approval and training: governed by your meeting cycle
What We Draft
Documents across the governance and operational stack, sized to what the organisation will actually use.
Financial Policies
Delegation, expenditure, procurement, asset management and petty cash.
ICT Policies
Acceptable use, access control, change management, backup and AI use.
HR Policies
Recruitment, leave, disciplinary, and the joiner mover leaver process.
Operating Procedures
Step by step procedures a new employee could follow unaided.
Delegation Frameworks
Written decision rights and thresholds, which prevent both paralysis and overreach.
Policy Registers
A register with owners and review dates, so the suite stays current.
Frequently Asked Questions
How many policies should we have?
Fewer than most organisations do. The test is whether a policy prevents something specific that would otherwise go wrong. If it exists because a template listed it, it is dilution rather than governance.
Can you use a template?
As a starting structure, yes, but templates produce documents describing an organisation you are not. The value is in the parts specific to how you actually operate, and those cannot be templated.
Our staff never read the policies. How do we fix that?
Shorten them, write them for the reader, and train rather than circulate. A twelve page procurement policy will not be read. A two page procedure with a one page checklist will be.
Will this close our audit findings?
Where the finding was an absent or non compliant policy, yes. Where the finding was that practice departed from policy, a new document alone changes nothing, and the work is implementation rather than drafting.
Who should approve policies?
It depends on the policy and your delegation framework. Financial and governance policies usually need board or council approval; operational procedures can normally be approved by management. Getting the level wrong is itself a finding.
How often should policies be reviewed?
Set a review date on each, typically two to three years, and earlier where legislation or systems change. A policy register with owners and dates is what stops the whole suite ageing at once.
Related Services
This sits inside our Consulting practice. Related work: IT Governance Assessment where the ICT policy framework is assessed, and Supply Chain Management for procurement policy specifically.
