Policy element template

Introduction

For the description of the policy elements a template was designed, Each policy element is described by a standard set of characteristics. Together the characteristics should give the reader enough information about why and when the policy element is important. This chapter will explain the various boxes in the template.

In addition to the elements, the part “Further Reading” contains relevant literature. Although this report does not offer a complete set of relevant literature, for some policy elements, like for example authenticity, literature exists that might support the organisation further in defining their policy.

The policy element template

Preservation Procedure Policy: Name of the policy element
Related Guidance Policy	Because every policy element should be readable independently, the related higher level, the Guidance Policy, is mentioned.
Definition/ Description	Every policy element will have a description and, if applicable, a definition, based on existing glossaries in standards like the OAIS model or digital preservation glossaries, such as the APARSEN project or the InterPARES project. The source of the definition will be referenced.
Why	An explanation is given why it is important that an organization defines a policy related to this element.
Risks	Not having a written policy could imply various risks for the organization and in this box some examples will be given. Of course whether the risk will occur is dependent on several factors , the examples are added to stimulate further discussions.  Apart from general knowledge, also standard literature like DRAMBORA and ISO 16363 can be used in these internal discussions.
Life cycle stage	The intention of this box is to put the policy element in relation to the life cycle stages it might be relevant for and to achieve a coherence in policy elements for different life cycles. As the basis the DCC life cycle model is used.
Stakeholder	It is important that someone in the organisation will be responsible for describing the preservation policy, in relation to the processes the policy relate to and in coherence with the other processes in the organisation. This person is called a “stakeholder”. The SHAMAN project distinguished a set of stakeholders in relation to digital preservation and these are used where applicable.
Cross Reference	It is seldom that a policy element stands in isolation. More often a policy element is related to other policy elements, where applicable this relationship is mentioned.
Examples	To illustrate the policy element, one or more relevant examples of Preservation Policies were taken, based on the collected policies . This could be used as an inspiration for organisations to create their own version.
Control Policy	As mentioned before, we have related the control policies to two cases: Preservation Watch and Preservation Planning, as these are the areas in the SCAPE project where the control policies will be used.
Questions to foster discussions	If an organization wants to create preservation policies, it will be important to engage different people in the organization (the “stakeholders”) and together phrase the relevant policies. The set of questions for each element will help starting the discussions and highlight the various aspects of the policy element, like the risk of not having thought of the policy element.

DCC Life cycle model                    

The Digital Curation Centre (DCC) lifecycle model is used to help the users of the catalogue understand when  the policy is relevant.  The diagram, from the DCC, is shown below,  DCC Curation Life Cycle Model has the full details. 

Stakeholder

It is important that someone in the organisation will be responsible for describing the preservation policy, in relation to the processes the policy relate to and in coherence with the other processes in the organisation. This person is called in the catalogue the “stakeholder”. The SHAMAN project distinguished a set of stakeholders in relation to digital preservation in their Reference Architecture version 3.0 and this was the basis for the catalogue. In one case the SHAMAN list did not offer a right description of the role intended, namely in the occasions where a stakeholder with a thourough knowledge of the collection was needed to phrase the policy element, so a role of Collection Manager (someone with a thourough knowledge of and responsible for the preserved collection), was added.

For convenience of the reader a summary of the SHAMAN stakeholders is added here.

• Producer/Depositor:  The entity responsible for the ingestion of the objects to be preserved. It may be the owner of the object, but it also can be any other entity entitled to perform this action.

• Consumer: The entity representing the user accessing to the preserved objects, with a potential interest in its reuse and a certain background in terms of knowledge and technical environment.

• Management: This entity is essentially a generalization of all management stakeholders, i.e. Executive Management, Information Manager, Technology Manager and Operational Manager

• Executive Management: The entity responsible for strategic decision making on an organisation level, ensuring that the mandate is fulfilled. This entity defines strategic goals to be achieved by organization‟s systems and technology management.

•  Information Manager: The entity responsible for ensuring the organisation’s systems business continuity, defining business strategies in line with strategic goals and setting goals and objectives to be achieved by operational management. That means it defines ends to be achieved by the organization, which have to be fulfilled by deployment and operation of means, but it also will define means on a strategic level.

• Technology Manager The entity responsible for technological system continuity and the deployment of technological means to achieve the ends set by the preservation business. This entity effectively acts as a regulator to the operational manager, since the choice of technology limits the operational application of means to achieve ends.

• Operational Manager: The entity that is responsible for continuous policy-compliant operation of the systems, which involves balancing ends and means and resolving conflicts between them, i.e. constraints as set from Technology Management and Preservation Management.

• Regulator The entity responsible for external imposing rules concerning the preservation of digital assets, such as legislation and standards. Those can apply to the organisation, the system‟s technology, or the systems‟ usage

• Auditor The entity responsible for the certification if the organization practices, the system‟s properties and the operational environments are complying with established standards, rules and regulations.

• Information Operator The entity responsible for the preservation operations of the systems. This business worker may be aware of the details of the design and deployment of the system, but its mission is to assure the direct support to the business, with no concerns with the management of the infrastructure and no concerns about strategic alignment

• System Architect The entity responsible for the design and update of the architecture of the system, aligned with the business objectives

• Solution Provider The entity responsible for providing any kind of components of the architecture. This may include components, platforms and business services.

• Technology Operator The entity responsible for the regular operation and maintenance of the components of the technical infrastructure (hardware and software) and their interoperability, according to specified service levels