The information security policy answers one question with authority: what is the security of its information worth to this organisation, and who enforces that. Everything else belongs in documents further down: password rules, approval processes, technical specifications. That division of labour is why a good policy is short and still carries weight.
The three levels
| Level | Question | Approved by | Rate of change |
|---|---|---|---|
| Information security policy | Why, and with what binding force? | Top management | Rarely |
| Topic-specific policy | What applies in this subject area? | Subject owner, released by management | Medium term |
| Procedure, work instruction, concept | How exactly, in which system? | Business unit or IT | Continuously |
The most common structural mistake is a policy containing operational detail. It then has to go back to top management for approval at every technical change, and either becomes a permanent building site or quietly goes out of date.
A note worth having if you work with German counterparties: German practice distinguishes the Leitlinie from the Richtlinie, and both come back into English as "policy". A German customer or auditor asking for your Leitlinie wants the top-level document in the first row of that table, not the whole policy set. Sending the entire library in reply is a common and avoidable misfire.
What belongs in it
- Standing and objectives of information security, derived from business objectives, legal requirements and customer expectations
- Scope: organisational units, sites, processes and systems, expressly including its application to external parties and service providers
- Principles: a risk-based approach; confidentiality, integrity and availability as protection goals; the duty to report security incidents
- Organisation and roles: management's responsibility, the tasks of the information security officer, the responsibility of managers and of staff
- Binding force and consequences in the event of breaches
- A commitment to resources and to continual improvement
- A pointer to the body of rules below it, without repeating its content
The normative requirement
ISO/IEC 27001 requires in clause 5.2 that top management establish an information security policy that is appropriate to the purpose of the organisation, provides a framework for setting information security objectives, and includes a commitment to satisfy applicable requirements and to continual improvement. It has to be available as documented information, communicated within the organisation, and made available to interested parties as appropriate.
The BSI's IT-Grundschutz knows the same document under the name Leitlinie zur Informationssicherheit and describes its creation as one of the first steps in the security process.
Regulatory catalogues of measures likewise presuppose documented policies for risk analysis and information security. The policy is the usual entry point for that, but it does not replace the individual concepts.
Putting it into force, and communicating it
Three characteristics decide whether the policy has any effect in operations:
- Visible adoption by management, with a date, a version and a signature. A policy with no discernible author is read as a recommendation.
- Active communication rather than filing on the intranet: inclusion in onboarding, periodic re-acknowledgement, reference in training.
- Demonstrable acknowledgement, particularly for roles with elevated rights and for external parties.
Maintenance
An annual check for currency is customary; changing it makes sense only on a trigger: an altered scope, new legal requirements, a reorganisation, material incidents, or findings from audit and management review. Every edition should be versioned and the predecessor archived. In an audit, the question about how the policy has developed comes up more often than the question about what it says.
Where it usually goes wrong
The policy is drafted so generally that it could apply to any organisation. It names roles that do not exist in the company. External parties and service providers are not covered by the scope, and there is no pointer to where the concrete rules can be found.
Where the policy's scope becomes concrete
What is interesting is one particular passage of the policy, its scope, because over the years it is the most frequently interpreted part of the document.
In Rizzqo that scope has a second, checkable form: a set of objects. The primary assets, meaning information, processes and services, and the systems, sites, providers and people-functions that carry them. Whether a particular system belongs inside is therefore no longer a matter of reading. And an object outside the boundary that carries an asset inside it stands out in the links rather than disappearing into a footnote. The policy keeps its role as the document put into force; it simply gains an implementation to refer to.