Policy & Documentation

Policies that describe how you actually work, so people can follow them.

The problem

You downloaded a policy pack, changed the company name, and now hold 40 documents that describe an organisation that does not exist. The auditor will read them, then ask your engineers what they do, and the gap will become a finding.

The method.

Document the process that exists

Before writing anything, we sit with the people doing the work: how does a joiner get access, who really approves a production deploy, what happens today when a laptop is lost. The policy is written from observed practice, then tightened to meet the control, not invented and imposed.

Write to a control map

Each policy and procedure states which Annex A controls and SOC 2 criteria it satisfies. Nothing is written because a template contained it. If no control requires a document, it does not get written. A smaller set that is actually followed beats a complete set that is not.

Separate policy from procedure

Policies are short, stable and approved by management. Procedures are operational, live where the work lives, and change often. Merging the two produces documents that either go stale or cannot be approved. Access control, change management, incident response, backup, secure development, supplier security, acceptable use, cryptography and data retention are the load-bearing set for most companies.

Run the document lifecycle

Version control, approver, effective date and review date on every document, as ISO 27001 Clause 7.5 requires. Annual review is scheduled, and change is triggered by events: new system, new regulation, incident lessons learned.

Close the acknowledgement loop

Policies are published where staff read things, assigned for acknowledgement, and tracked to completion, including for joiners, who are the group most often missed and the group an auditor most often samples.

A policy is a promise about behaviour. Business Process Monitoring in the ROC tests whether the promise is being kept (whether access really is reviewed quarterly, whether changes really are approved) and reports the gap while it is still small.

Which security policies does ISO 27001 require?

ISO 27001 requires a top-level information security policy plus documented information covering the topics in Annex A that apply to your scope: typically access control, acceptable use, cryptography, secure development, change management, incident response, business continuity, supplier security, and data retention and disposal. The exact set is determined by your Statement of Applicability, not by a template.

Are template security policies acceptable to an auditor?

Only if they are true. Auditors test policies against practice: they read the document, then interview the engineer and sample the records. A downloaded policy describing an approval workflow that nobody performs produces a nonconformity faster than having no policy at all, because it demonstrates that the management system is not operating.

How often should security policies be reviewed?

At least annually, with the review recorded: reviewer, date, outcome, next review date. In addition, policies should be reviewed on events: a significant change to systems or organisation, a new regulatory obligation, or lessons learned from an incident. Review records are one of the first things an auditor samples.