itpolicycontent

Definitions

Policy	A collection of ideas and plans outlining how the organisation would expect to deal with a (typically new) challenge, opportunity, or event.
Standard	Details of how a policy is implemented. For example, by implementing the standard tool or process X, or by performing standard task Y, we demonstrate compliance with policy aspect Z.
Guidance	Advice or recommendations on how to resolve or clarify a problem or misunderstanding.

Policy, standard, and guidance content should be written for a clearly defined audience. The context is explained, and the language used is appropriate, to ensure the audience understands the content.
The content should be published in HTML, and accessible easily by the intended audience.
The content should make good use of links to other content that helps explain terms, or to provide further optional reading.
The content should be subject to a robust approvals process to ensure that all stakeholders have been considered.
The content should be unique; if another part of government has published suitable material, link to it and avoid re-inventing or duplicating material:
- Agencies should use (‘inherit’) central MOJ content directly and unchanged unless there is a clear and valid reason for separate material.

Policy content should have a clearly defined scope explaining when it applies and who it applies to.
Policy should be integrated into governance, commercial or HR standards and processes.
Policy should be minimal; having too much policy makes it difficult to:
- Find the appropriate policy.
- Avoid duplicating policy.
- Maintain and sustain policy.
Policy should be realistic; it must consider the constraints and behaviours of users alongside the needs of the policy maker, making it practical for the audience to adhere to.
Policy should be open source, allowing others to share and use it.
Policy should be assumed to need to change regularly, keeping pace with technology, culture and practice:
- Roles and processes must exist to support regular change.

A standard provides clear ‘do this’ or ‘do this in this way’ statements.
By implementing the standard, and performing tasks as the standard requires, all aspects of the corresponding policy are met.
A standard can require associated sub-documents. For example, a backup standard might require a backup plan for system X, and a different plan for system Y. The standard indicates what is required for a plan, but each plan can be different.
Standards should be precise, and unambiguous.
Standards should prefer open or established solutions, rather than creating or defining new ones.

Guidance content should be more informal and ‘relaxed’. It provides easy-to-understand help and clarification regarding policies, standards and processes.
Guidance should be ‘promoted’ into more formal content (policies, standards or processes) where possible. This means that the formal content is updated and improved to make the guidance unnecessary.
Guidance should take one of the following forms:
- Sustained or ‘long term’ guidance: This is content that will be used repeatedly over an extended period, for example a list of ‘frequently asked questions’. It is published at a fixed location (URL). An owner is assigned and has the responsibility for maintaining it, changing it and updating it as necessary. It is reviewed on a regular basis.
- Ephemeral or ‘of the moment’ guidance, such as a ‘blogpost’. This is content that might be used intensively or widely, but for a limited amount of time, for example an article introducing a new development or initiative. Its identification and location information must include the publication date, to help establish its period of relevance. There is no expectation that the content will be updated.

These principles are dated October 2017.