IT Policies and Procedures

Why most policy sets fail an audit

The typical policy suite we inherit was downloaded, lightly renamed, and approved without anyone checking whether the organisation could actually comply with it. It fails on audit for predictable reasons: it commits to controls that do not exist, it contradicts itself between documents, it has no version control or review evidence, and no one below the CIO has read it.

A policy you cannot evidence compliance with is worse than no policy — it converts an operational gap into a documented control failure.

What we produce

• Policy — the board-approved statement of intent and mandatory requirement. Short. Rarely changes.
• Standards — the specific, measurable technical requirements. Testable. Changes with technology.
• Procedures — the step-by-step operational instructions for the people doing the work.
• Records and templates — the forms and registers that generate the evidence an auditor will ask for.

Typical policy suite

Scoped to your regulatory obligations, but usually covering: information security policy; acceptable use; access control and identity management; change management; asset management and classification; cryptography and key management; physical and environmental security; operations security including backup, logging and malware; network security; secure development; supplier and third-party security; incident management; business continuity; data protection and privacy; and human resources security.

Traceability

Every requirement in the suite is mapped back to its source — an ISO 27001 Annex A control, a COBIT objective, a regulatory clause, or an internal risk decision. When an auditor asks why a control exists, the answer is in the document. When a framework changes, you can see exactly which policies are affected.