What Is Security Policy?

A security policy is the documented statement of what an organisation requires regarding security. It establishes expectations, assigns responsibility and provides the basis for enforcement.

Its practical value depends on being short enough to read, specific enough to follow and current enough to be credible. Most policy sets fail at least one of those, which is why they are signed and ignored.

The document hierarchy

Policy — what is required and why, at a level that changes rarely. Standard — specific requirements, such as minimum configuration or authentication strength. Procedure — how a task is performed, step by step.

Guideline — recommended practice where judgement is permitted. Conflating these produces either a policy too detailed to remain accurate or a policy too vague to guide anything.

Why most policy sets fail

Length, which guarantees nobody reads them. Purchased templates describing controls the organisation does not operate, which makes the whole set non-credible. Requirements nobody can meet, which teaches people that policy is aspirational.

And staleness. A policy referencing systems that were decommissioned and roles nobody holds signals clearly that it is a document rather than a rule.

Policy that describes reality

Every requirement should be one somebody can actually satisfy, and one you are prepared to enforce. A policy requiring something the organisation cannot do creates a permanent audit finding and teaches staff to disregard the rest.

The honest alternative is a documented exception with an owner and a date, which is a defensible position. Silent non-compliance is not.

Approval, communication and acknowledgement

Policies need approval at a level that gives them authority, which for anything with employment consequences means senior management and frequently human resources and legal review.

They also need to reach people in a form they will absorb. A forty-page document acknowledged electronically has been consented to rather than read, which matters if the organisation ever needs to rely on it.

Maintenance, and making staleness visible

Annual review is the usual commitment and is frequently performed as a date change. Useful triggers for genuine review: a new system or platform, a regulatory change, an incident that revealed a gap, or an audit finding.

A visible owner, version and review date on the front page is what makes decay apparent. A policy with no date invites the assumption that it is current.

Exceptions are what keep it honest

Any policy applied across a real organisation will meet a case it cannot accommodate: a legacy system that cannot meet the standard, a business process that requires something the policy forbids, a supplier arrangement that predates the rule.

A documented exception with a stated compensating control, a named approver and an expiry date is a defensible position. Silent non-compliance is not, and it is what happens automatically where no exception route exists.

Where to start

Read your own acceptable use policy as a new employee would and note every requirement that is not actually enforced. That list is the credibility problem.

See acceptable use policy. GuardsArm delivers policy review.