ISO 16363 certification guide
By: David Giaretta (head of the OAIS and ISO 16363 working group)
What is certification and Why is it Important?
When one buys a house one normally wants to make sure that what we are buying is adequate for its purpose, and that we are not being cheated in some way. No matter what the claims of the seller, one normally employs an independent building inspector, not connected to the seller, to perform an inspection and certify that the house is OK, is safe to live in and will not fall down.
The same is true for many things we depend on in life and work, whether it is the airplanes we fly on, the banks to which we entrust our money, the medical instruments which our surgeon may use to operate on us or our loved ones or the food we eat. However in these cases we do not employ the inspector ourselves, instead we rely on the organisation or manufacturer to have checks done by some trusted, knowledgeable, third party who will provide a certificate which we and others can check. This type of inspection is called an third-party audit, carried out by an audit organisation.
In principle we can look at the certificate and then also check the audit organisation who provided it and even the organisation which accredit them i.e. tell us that the audit organisation is trustworthy and knowledgeable in the relevant field.
If the certificate is 10 years old then we might be somewhat suspicious because many things can change over that time. Organisations can lose key staff or the staff may not keep up with the latest techniques in that field and may not understand the risks that need to be checked. Therefore we would really expect the certificate to be a recent one - maybe a year or so old, and the same would apply to the organisation which had provided the certificate - somehow they must also be certified, by some other organisation.
These same considerations apply to our digitally encoded information which is valuable to us and that we want to be preserved. Any archive to which we entrust our digital capital will no doubt tell us that they are perfectly able to preserve the information over years or decades or centuries. How can we be sure? How can they be sure?
The answer is that we would expect the archive to be certified.
Self-certification, where the archive audits itself is a necessary first step. However this is normally done for the benefit of the archive itself, just as the seller of a house is likely to inspect the house before selling, correcting any problems he/she finds, before putting the house on the market. However just as that self-certification is not likely to be accepted by a prospective house purchaser, neither should self-certification of an archive be accepted by funders or those who deposit their valuable holdings into the archive.
There are several "standards" available against which an archive may be judged. Some are community documents such as CoreTrustSeal which are essentially self-governing.
The other type is ISO 16363, which is an ISO standard and for which the full ISO process of accreditation and certification applies. The point is that the ISO process aims at ensuring consistency of audits across organisations and countries by making sure that everyone and every organisation is inspected every year, using a tried and tested process set out in ISO 17021.
Any third-party audit requires the archive to collect evidence to present to the auditors. Much of this evidence may be collected in a self-audit. The ISO process requires a Stage 1, in which this evidence is inspected off-site, followed by an on-site Stage 2.
A well organised repository should have most of the material needed to present as evidence. The main effort will be to find and organise that material. Some aspects of the repository may be tacitly agreed within the repository and so a small number of new documents may need to be written for example to document procedures and make specific policies, or definitions such as that for the Designated Communities, explicit.
A summary of the preparations for an ISO 16363 audit is included in the next section, with full details in the following section.
Summary of documents and procedures required
Evidence of commitment to preservation e.g. mission statement of repository
Preservation Strategic Plan and Collection policy with Preservation policies and review schedule, including Collection and individual objects Integrity checks
Funding projections with Business/funding plans and Succession plan
Staff duties, job descriptions training record and plans
Definition of the Designated Community(ies) and documentation of Transformational Information Properties and Preservation aims.
Change history of repository operations, procedures, software and hardware
Transparency, with explanations where restrictions are applicable
Audit history – internal and external audits
Risk register(s) covering finances, hardware, software, staffing
Contracts and agreements which apply to the repository’s holdings, including IPR and access restrictions
Descriptions of the SIPs it expects and how these are checked, including their origin, and how they are processed
Descriptions of the AIPs it creates (which are likely to be logical) including the way in which these may be shown to be adequate for preservation
Description of the identifier system used, any limitations on the number of identifiers, and how identifiers are maintained
Description of Preservation Strategies for the collections including how Representation Information is maintained and how the repository ensures that it has enough Representation Information
Description of how Provenance is collected
Description of search capabilities with discussion of the requirements for these
Disaster recovery plans
Detailed table of preparatory work
Metric No | Metric | Details and actions needed from the data stewards | Details on preparation needed |
3.1.1 | THE REPOSITORY SHALL HAVE A MISSION STATEMENT THAT REFLECTS A COMMITMENT TO THE PRESERVATION OF, LONG TERM RETENTION OF, MANAGEMENT OF, AND ACCESS TO DIGITAL INFORMATION. | Data Stewards must ensure mission statement or equivalent is in place. | The mission statement is not required to be a single document. What is needed is to show that there is a commitment to preservation, retention, management and access at the repository’s highest administrative level. Evidence to support this may be distributed in several documents, for example charter of the repository or its parent organization that specifically addresses or implicitly calls for the preservation of information and/or other resources under its purview; a legal, statutory, or government regulatory mandate applicable to the repository that specifically addresses or implicitly requires the preservation. |
3.1.2 | THE REPOSITORY SHALL HAVE A PRESERVATION STRATEGIC PLAN THAT DEFINES THE APPROACH THE REPOSITORY WILL TAKE IN THE LONG-TERM SUPPORT OF ITS MISSION. | Data Stewards must ensure that there is a Preservation Strategic Plan in place. | The aim here is to show that the repository has guidance to make administrative decisions, shape policies, and allocate resources in order to successfully preserve its holdings |
3.1.2.1 | The repository shall have an appropriate, formal succession plan, contingency plans, and/or escrow arrangements in place in case the repository ceases to operate or the governing or funding institution substantially changes its scope. | Data Stewards must have plans in place in case the repository ceases to operate or funding substantially changes. | The aim should be to show that, if the repository does cease to function then the decision about who to hand over to is not a last minute choice, and that the hand-over process is not rushed. One question is how formal the plans need to be; the answer depends upon the funding horizon i.e. for how much into the future is funding certain. If it is five years then less formality is needed than if it is 1 year. |
3.1.2.2 | The repository shall monitor its organizational environment to determine when to execute its formal succession plan, contingency plans, and/or escrow arrangements. | Data stewards must be able to know when it must put its succession plans into operation. | The repository should be able to show that it has a reasonable idea about how long it can be sure of funding. Of course in many cases repositories have rolling funding, which is reviewed and renewed periodically. |
3.1.3 | THE REPOSITORY SHALL HAVE A COLLECTION POLICY OR OTHER DOCUMENT THAT SPECIFIES THE TYPE OF INFORMATION IT WILL PRESERVE, RETAIN, MANAGE AND PROVIDE ACCESS TO. | Data stewards must have documentation about what types of information it will preserve. | The intention here is to ensure that the repository has guidance on acquisition of digital content it will preserve, retain, manage and provide access to. In the past repositories have had problem when tapes and documents were dumped at the door. The collection policy (or its equivalent) makes it clear that the repository is not committed to preserving items outside that policy. |
3.2.1 | THE REPOSITORY SHALL HAVE IDENTIFIED AND ESTABLISHED THE DUTIES THAT IT NEEDS TO PERFORM AND SHALL HAVE APPOINTED STAFF WITH ADEQUATE SKILLS AND EXPERIENCE TO FULFIL THESE DUTIES. | Data stewards must have specified the duties and have appropriately skilled staff. | The repository should be able to present documents about development plans, organizational charts, job descriptions, and related policies and procedures that the repository is defining and maintaining the skills and roles that are required for the sustained operation of the repository. |
3.2.1.1 | The repository shall have identified and established the duties that it needs to perform. | Data stewards must have defined the duties. | Job descriptions should be presented to show that the repository can complete all tasks associated with the long-term preservation and management of the data objects |
3.2.1.2 | The repository shall have the appropriate number of staff to support all functions and services. | Data stewards must ensure there are appropriate numbers of staff. | The repository should be able to show that its staffing plans are adequate for preserving the digital content. |
3.2.1.3 | The repository shall have in place an active professional development program that provides staff with skills and expertise development opportunities. | Data stewards must ensure that staff skills develop as required. | As time passes things such as software, hardware, legal environments, state of the art digital preservation practices,all change. The repository should be able to show that it should not be taken by surprise by such changes by, for example, holding regular reviews of training needs. |
3.3.1 | THE REPOSITORY SHALL HAVE DEFINED ITS DESIGNATED COMMUNITY AND ASSOCIATED KNOWLEDGE BASE(S) AND SHALL HAVE THESE DEFINITIONS APPROPRIATELY ACCESSIBLE. | Data stewards must have defined its designated community(ies). | The repository may provide many services to the general public but the repository is guaranteeing that the Designated Community(ies) it has defined will be able to understand/use the holdings it is preserving. The Designated Community(ies) should be explicitly defined so that in principle it should be possible to test that the repository meets the needs of its Designated Community. |
3.3.2 | THE REPOSITORY SHALL HAVE PRESERVATION POLICIES IN PLACE TO ENSURE ITS PRESERVATION STRATEGIC PLAN WILL BE MET. | Data stewards must have appropriate preservation policies. | The policies show how the repository fulfills the requirements of the repository’s Preservation Strategic Plan. For example, a Preservation Strategic Plan may contain a requirement that the repository ‘comply with current preferred preservation standards’. The preservation policy might then require that the repository ‘monitor current preservation standards and ensure repository compliance with the preferred preservation standards’ |
3.3.2.1 | The repository shall have mechanisms for review, update, and ongoing development of its Preservation Policies as the repository grows and as technology and community practice evolve. | Data stewards must ensure the preservation policies are reviewed and updated regularly. | A simple schedule of reviews of the policies should be adequate. |
3.3.3 | THE REPOSITORY SHALL HAVE A DOCUMENTED HISTORY OF THE CHANGES TO ITS OPERATIONS, PROCEDURES, SOFTWARE, AND HARDWARE. | Data stewards use the software to record changes to its operation, procedures, software and hardware. | The aim is to provide an ‘audit trail’ through which stakeholders can identify and trace decisions made by the repository. |
3.3.4 | THE REPOSITORY SHALL COMMIT TO TRANSPARENCY AND ACCOUNTABILITY IN ALL ACTIONS SUPPORTING THE OPERATION AND MANAGEMENT OF THE REPOSITORY THAT AFFECT THE PRESERVATION OF DIGITAL CONTENT OVER TIME. | Data stewards must demonstrate transparency and accountability. | Note that this is transparency, in the sense of being available to anyone who is authorized to know. This could include everybody, but may be restricted, for example by legal, commercial or security concerns. |
3.3.5 | THE REPOSITORY SHALL DEFINE, COLLECT, TRACK, AND APPROPRIATELY PROVIDE ITS INFORMATION INTEGRITY MEASUREMENTS. | Data stewards must configure the software appropriately. | The LABDRIVE configuration should show the frequency of the hash calculations and the security measures taken to ensure the values against which the hashes are checked. |
3.3.6 | THE REPOSITORY SHALL COMMIT TO A REGULAR SCHEDULE OF SELF-ASSESSMENT AND EXTERNAL CERTIFICATION. | Data stewards must arrange regular (at least annual) management reviews and internal audits, as well as third party audits. | The audit itself is evidence of this. |
3.4.1 | THE REPOSITORY SHALL HAVE SHORT- AND LONG-TERM BUSINESS PLANNING PROCESSES IN PLACE TO SUSTAIN THE REPOSITORY OVER TIME. | Data stewards must have appropriate business plans. | The broad financial/business plans of the parent can be presented, plus the budget of the repository itself. Clearly funding may not be guaranteed forever. Often the funding is reviewed and commitments are made periodically. At least a good idea of the funding horizon should be provided i.e for how much longer does the repository definitely have funding. If the repository is run on a commercial basis then the business planning may be more detailed. |
3.4.2 | THE REPOSITORY SHALL HAVE FINANCIAL PRACTICES AND PROCEDURES WHICH ARE TRANSPARENT, COMPLIANT WITH RELEVANT ACCOUNTING STANDARDS AND PRACTICES, AND AUDITED BY THIRD PARTIES IN ACCORDANCE WITH TERRITORIAL LEGAL REQUIREMENTS. | Data stewards must have appropriate financial practices in place. | Evidence should show that its business practices are transparent, compliant, and auditable, bearing in mind that onfidentiality requirements may prohibit making information about the repository’s finances public |
3.4.3 | THE REPOSITORY SHALL HAVE AN ONGOING COMMITMENT TO ANALYZE AND REPORT ON RISK, BENEFIT, INVESTMENT, AND EXPENDITURE (INCLUDING ASSETS, LICENSES, AND LIABILITIES). | Data steward must keep an adequate risk register. | The risk register and medium term financial planning that an organisation would be expected to keep would normally be available to be presented as evidence. |
3.5.1 | THE REPOSITORY SHALL HAVE AND MAINTAIN APPROPRIATE CONTRACTS OR DEPOSIT AGREEMENTS FOR DIGITAL MATERIALS THAT IT MANAGES, PRESERVES, AND/OR TO WHICH IT PROVIDES ACCESS. | Data stewards must maintain the contracts and agreements and record them in the database. | As part of normal business processes the repository and/or its parent organisation should keep records that can be presented as evidence. Normally an auditor will inspect a sample of the contracts. In most cases deposit agreements should be available from the time that material has been accepted for preservation. For example this should show that multiple copies may be made. In cases such as web harvesting there may not be such agreements but alternatives such as a strategy for dealing with objections. The deposit agreements and other documentation about procedures should be available. The policies should be explicit in the documentation. The policies should make it clear that the repository is not likely to be put out of operation by legal challenges. AT the very least the repository should have time to hand over its holdings to a successor.. |
3.5.1.1 | The repository shall have contracts or deposit agreements which specify and transfer all necessary preservation rights, and those rights transferred shall be documented. | Data stewards must ensure that the contracts and deposit agreements ensure the necessary rights have been transferred. | |
3.5.1.2 | The repository shall have specified all appropriate aspects of acquisition, maintenance, access, and withdrawal in written agreements with depositors and other relevant parties. | Data stewards must ensure that there are appropriate written agreements in place. | |
3.5.1.3 | The repository shall have written policies that indicate when it accepts preservation responsibility for contents of each set of submitted data objects. | Data stewards must have policies in place to ensure that it is clear when preservation responsibility has been handed over. | |
3.5.1.4 | The repository shall have policies in place to address liability and challenges to ownership/rights. | Data stewards must have created policies to make it clear how they will address such challenges. | |
3.5.2 | THE REPOSITORY SHALL TRACK AND MANAGE INTELLECTUAL PROPERTY RIGHTS AND RESTRICTIONS ON USE OF REPOSITORY CONTENT AS REQUIRED BY DEPOSIT AGREEMENT, CONTRACT, OR LICENSE. | Data stewards must configure LABDRIVE access restrictions appropriately. Restrictions on use must also be made clear by the data stewards. | As part of the deposit agreement, any restrictions on use or access to the objects should be clear. |
4.1.1 | THE REPOSITORY SHALL IDENTIFY THE CONTENT INFORMATION AND THE INFORMATION PROPERTIES THAT THE REPOSITORY WILL PRESERVE. | Data stewards must identify information properties and arrange for them to be imported into LABDRIVE. | The Information Properties to be preserved include the Transformational Information Properties (TIPs) defined in OAIS, which includes examples. There should be written procedures which describe how these should be created, reviewed and tested. Of course the repository should now where these TIPs are preserved, bearing in mind that these may not be needed for many years. |
4.1.1.1 | The repository shall have a procedure(s) for identifying those Information Properties that it will preserve. | Data stewards must have created, and follow, the appropriate procedures. | |
4.1.1.2 | The repository shall have a record of the Content Information and the Information Properties that it will preserve. | Data stewards must use LABDRIVE to record the information. | |
4.1.2 | THE REPOSITORY SHALL CLEARLY SPECIFY THE INFORMATION THAT NEEDS TO BE ASSOCIATED WITH SPECIFIC CONTENT INFORMATION AT THE TIME OF ITS DEPOSIT. | Data stewards must specify and configure LABDRIVE appropriately. | The repository procedures should make it clear that the object to be preserved is accompanied by as much of each of the components of the OAIS Information Model as is required. For example the amount of Representation Information depends upon the definition of the Designated Community.. |
4.1.3 | THE REPOSITORY SHALL HAVE ADEQUATE SPECIFICATIONS ENABLING RECOGNITION AND PARSING OF THE SIPS. | Data stewards must be able to specify the structure of the SIPs appropriately. | In whatever way the repository received the information to be preserved, the repository must be able to show that it knows how to extract the various components. |
4.1.4 | THE REPOSITORY SHALL HAVE MECHANISMS TO APPROPRIATELY VERIFY THE DEPOSITOR OF ALL MATERIALS. | Data stewards must specify how depositors can be verified, and configure LABDRIVE appropriately. | One would expect the repository to ensure that it can be sure where the objects it is asked to preserve come from. For example there may be password protected areas into which the objects are deposited. Documentation describing these procedures should be presented as evidence. |
4.1.5 | THE REPOSITORY SHALL HAVE AN INGEST PROCESS WHICH VERIFIES EACH SIP FOR COMPLETENESS AND CORRECTNESS. | Data stewards must configure LABDRIVE to verify SIPs. | There must be a way in which the repository can ensure that it does have all the required pieces needed for preservation. The way in which this is done should be documented and the documents presented as evidence. |
4.1.6 | THE REPOSITORY SHALL OBTAIN SUFFICIENT CONTROL OVER THE DIGITAL OBJECTS TO PRESERVE THEM. | Data stewards must ensure that sufficient control is obtained. | The deposit agreements should contain the evidence required. |
4.1.7 | THE REPOSITORY SHALL PROVIDE THE PRODUCER/DEPOSITOR WITH APPROPRIATE RESPONSES AT AGREED POINTS DURING THE INGEST PROCESSES. | Data stewards must configure LABDRIVE appropriately. | During the ingestion the repository must fulfil the arrangements made for the deposit, for example sending responses at the appropriate times. This may be done automatically by the software. |
4.1.8 | THE REPOSITORY SHALL HAVE CONTEMPORANEOUS RECORDS OF ACTIONS AND ADMINISTRATION PROCESSES THAT ARE RELEVANT TO CONTENT ACQUISITION. | Data stewards must ensure that actions are recorded. | The events recorded in LABDRIVE can be extracted and presented as evidence. Events not recorded by the software automatically should be recorded in other ways, for example administrative activities. |
4.2.1 | THE REPOSITORY SHALL HAVE FOR EACH AIP OR CLASS OF AIPS PRESERVED BY THE REPOSITORY AN ASSOCIATED DEFINITION THAT IS ADEQUATE FOR PARSING THE AIP AND FIT FOR LONG-TERM PRESERVATION NEEDS. | If the AIP is structured using the OAIS AIP Schema then that structure can be provided, for example as a downloaded XML schema, or as a BAGIT. Additional evidence should be presented to describe how the various components are judged to be adequate for long term preservation. | |
4.2.1.1 | The repository shall be able to identify which definition applies to which AIP. | ||
4.2.1.2 | The repository shall have a definition of each AIP that is adequate for long term preservation, enabling the identification and parsing of all the required components within that AIP. | ||
4.2.2 | THE REPOSITORY SHALL HAVE A DESCRIPTION OF HOW AIPS ARE CONSTRUCTED FROM SIPS. | Data stewards must ensure that LABDRIVE is configured appropriately. | The repository must have a process for creating AIPs, and this should be documented in a way which can be presented as evidence. |
4.2.3 | THE REPOSITORY SHALL DOCUMENT THE FINAL DISPOSITION OF ALL SIPS. | Data stewards must ensure that LABDRIVE is configured appropriately. | Records should be kept of all the activities related to each SIP. |
4.2.3.1 | The repository shall follow documented procedures if a SIP is not incorporated into an AIP or discarded and shall indicate why the SIP was not incorporated or discarded. | Data stewards must configure LABDRIVE appropriately and, if required, insert explanations about specific SIPs which have not been accepted. | |
4.2.4 | THE REPOSITORY SHALL HAVE AND USE A CONVENTION THAT GENERATES PERSISTENT, UNIQUE IDENTIFIERS FOR ALL AIPS. | If required data stewards must arrange to map the internal unique identifiers to other identifiers such as DOIs. | LABDRIVE maintains URLs as persistent identifiers. |
4.2.4.1 | The repository shall uniquely identify each AIP within the repository. | ||
4.2.4.1.1 | The repository shall have unique identifiers. | ||
4.2.4.1.2 | The repository shall assign and maintain persistent identifiers of the AIP and its components so as to be unique within the context of the repository. | ||
4.2.4.1.3 | Documentation shall describe any processes used for changes to such identifiers. | ||
4.2.4.1.4 | The repository shall be able to provide a complete list of all such identifiers and do spot checks for duplications. | ||
4.2.4.1.5 | The system of identifiers shall be adequate to fit the repository’s current and foreseeable future requirements such as numbers of objects. | ||
4.2.4.2 | The repository shall have a system of reliable linking/resolution services in order to find the uniquely identified object, regardless of its physical location. | ||
4.2.5 | THE REPOSITORY SHALL HAVE ACCESS TO NECESSARY TOOLS AND RESOURCES TO PROVIDE AUTHORITATIVE REPRESENTATION INFORMATION FOR ALL OF THE DIGITAL OBJECTS IT CONTAINS. | Data stewards must ensure that Representation Information is collected from data creators. | As described in the “OAIS and ISO 16363” section of the manual, if the data is organised in folders and contains appropriately, one should be able to use inheritance to minimise duplication of the Representation Information. The amount of Representation Information needed for a given object depends upon the repository’s definition of the Designated Community (DC). Depending upon the definition, the DC may not, at this moment, need any Representation Information to be supplied because they know how to use the Data Objects. However as time passes things like the software, hardware and even the tacit knowledge that is generally available will change. The repository should prepare, as much as it can, for these changes. The obvious activity will be to collect, from the DC and also from the data creators, details of the software and hardware that the DC and others currently use, and take steps to preserve them. Tools related to PRONOM provide a level of identification of the file format, but sometimes that is not very useful except if the requirement is to render the object. Scientific data normally requires further details. PRONOM does not provide details of the software. One useful preparatory activity would be to draw out a Representation Information Network (RIN) to help decide what Representation Information to collect now. The Archival Information Package (AIP) should contain at least enough Representation Information for the DC to understand/use the objects. |
4.2.5.1 | The repository shall have tools or methods to identify the file type of all submitted Data Objects. | ||
4.2.5.2 | The repository shall have tools or methods to determine what Representation Information is necessary to make each Data Object understandable to the Designated Community. | ||
4.2.5.3 | The repository shall have access to the requisite Representation Information. | Data stewards must ensure that the required Representation Information is available. | |
4.2.5.4 | The repository shall have tools or methods to ensure that the requisite Representation Information is persistently associated with the relevant Data Objects. | ||
4.2.6 | THE REPOSITORY SHALL HAVE DOCUMENTED PROCESSES FOR ACQUIRING PRESERVATION DESCRIPTION INFORMATION (PDI) FOR ITS ASSOCIATED CONTENT INFORMATION AND ACQUIRE PDI IN ACCORDANCE WITH THE DOCUMENTED PROCESSES. | Data stewards create documentation to describe how the PDI is collected, and must follow these procedures. | The components of PDI may be considered in turn. As described in the “OAIS and ISO 16363” section of the manual, if the data is organised in folders and contains appropriately, one should be able to use inheritance to minimise duplication of the PDI elements. Fixity: This could be as simple as a pointer to the LABDRIVR manual should the data objects are protected, one part of which is the calculation and re-calculation of hashes. Details of the hash checks re maintained by LABDRIVE, and listed for example using api/file/60736/even Reference: The identifier for the object within LABDRIVE is a URL, for example http://dev.archiver.libnova.com/containers/133/file/60736 Access Rights: The access rights may be specific to an object but the objects may be more conveniently organised so that Context: The context for data from an experiment, observatory, instrument etc may well be the same. Some specific context may apply to data in a particular folder, which should supplement the more general contxet. Provenance: There may be a general statement of the Provenance e.g. this data came from CERN etc, but one might expect that set-sets of data, which may be collected in sub-folders, may have additiona provenance, for example about specific processing applied to the data. Thus the Provenance of a sub-sub-folder may need to collect items of provenance from, the olject itself, its folder, the parent folder , etc, up to the container. |
4.2.6.1 | The repository shall have documented processes for acquiring PDI. | As 4.2.6. | |
4.2.6.2 | The repository shall execute its documented processes for acquiring PDI. | As 4.2.6. | |
4.2.6.3 | The repository shall ensure that the PDI is persistently associated with the relevant Content Information. | As 4.2.6. | |
4.2.7 | THE REPOSITORY SHALL ENSURE THAT THE CONTENT INFORMATION OF THE AIPS IS UNDERSTANDABLE FOR THEIR DESIGNATED COMMUNITY AT THE TIME OF CREATION OF THE AIP. | Data stewards must ensure that the amount of Representation Information is adequate for the Designated Community(ies) | The test depends upon the definition of the Designated Community (DC) which the repository has defined. The question to ask is whether a selected member of the DCcan understand/use the object. Preservation Objectives may be defined by the repository, perhaps in association with other stakeholders. These may be used to allow more specific checks on understandability/usability by the member of the DC. The testing should be conducted periodically, depending upon the changes in the software, hardware or tacit knowledge. If required, additional Representation Information should be added to the Representation Information Network. If that is not possible then the object may be Transformed, maintaining the Transformational Information Properties. |
4.2.7.1 | Repository shall have a documented process for testing understandability for their Designated Communities of the Content Information of the AIPs at their creation. | Data stewards must document these checks. | |
4.2.7.2 | The repository shall execute the testing process for each class of Content Information of the AIPs. | Data stewards must execute these processes. | |
4.2.7.3 | The repository shall bring the Content Information of the AIP up to the required level of understandability if it fails the understandability testing. | Data Stewards must collect Representation Information required to ensure understandability by the Designated Community(ies). | |
4.2.8 | THE REPOSITORY SHALL VERIFY EACH AIP FOR COMPLETENESS AND CORRECTNESS AT THE POINT IT IS CREATED. | Data stewards must configure LABDRIVE to perform the checks, and ensure AIP correctness. | |
4.2.9 | THE REPOSITORY SHALL PROVIDE AN INDEPENDENT MECHANISM FOR VERIFYING THE INTEGRITY OF THE REPOSITORY COLLECTION/CONTENT. | Data stewards must be able to list what SHOULD be in LABDRIVE. | Examples of lists of what should be in a specific collection, to be compared with what is actually in the collection, should be available. |
4.2.10 | THE REPOSITORY SHALL HAVE CONTEMPORANEOUS RECORDS OF ACTIONS AND ADMINISTRATION PROCESSES THAT ARE RELEVANT TO AIP CREATION. | Data stewards must record appropriate actions in LABDRIVE. | LABDRIVE itself records many events, but these may need to be supplemented by written records. |
4.3.1 | THE REPOSITORY SHALL HAVE DOCUMENTED PRESERVATION STRATEGIES RELEVANT TO ITS HOLDINGS. | Data stewards must document the preservation strategies to be used. | The repository should have one or more documents which describe the strategies to be used for preserving the objects. |
4.3.2 | THE REPOSITORY SHALL HAVE MECHANISMS IN PLACE FOR MONITORING ITS PRESERVATION ENVIRONMENT. | Data stewards must have appropriate mechanisms to monitor its preservation environment. | As noted above, there should be periodic tests of understandability of the objects by the DC. In addition the hand-drawn RIN, suggested above, should be reviewed periodically in order to check if the preservation environment is changing. |
4.3.2.1 | The repository shall have mechanisms in place for monitoring and notification when Representation Information is inadequate for the Designated Community to understand the data holdings. | Data stewards must have mechanisms in place to add Representation Information if/when required. | |
4.3.3 | THE REPOSITORY SHALL HAVE MECHANISMS TO CHANGE ITS PRESERVATION PLANS AS A RESULT OF ITS MONITORING ACTIVITIES. | Data stewards must review its preservation plans and update then as a result of monitoring. | If required, Representation Information should be added. Otherwise the alternative preservation strategies may need to come into play. |
4.3.3.1 | The repository shall have mechanisms for creating, identifying or gathering any extra Representation Information required. | Data stewards must be able to create/identify or gather Representation Information required. | |
4.3.4 | THE REPOSITORY SHALL PROVIDE EVIDENCE OF THE EFFECTIVENESS OF ITS PRESERVATION ACTIVITIES. | Data stewards must collect evidence to show that its preservation activities are effective. | This evidence may simply be proof that the objects are understandable/usable to members of the DC. |
4.4.1 | THE REPOSITORY SHALL HAVE SPECIFICATIONS FOR HOW THE AIPS ARE STORED DOWN TO THE BIT LEVEL. | If the OAIS AIP Schema is used then it is unreasonable to have to describe the underlying database structures, but an exported XML schema should be adequate. If external AIPs, such as BAGIT or XFDU AIPs are available then it should be possible to describe their details. | |
4.4.1.1 | The repository shall preserve the Content Information of AIP’s. | This is simply a restatement of the aim of the repository. | |
4.4.1.2 | The repository shall actively monitor the integrity of AIPs. | Data stewards must ensure that LABDRIVE is configured to perform the checks sufficiently regularly. | There should be evidence that the AIPs have the required components i.e. all the different types of metadata and enough of each type. |
4.4.2 | THE REPOSITORY SHALL HAVE CONTEMPORANEOUS RECORDS OF ACTIONS AND ADMINISTRATION PROCESSES THAT ARE RELEVANT TO STORAGE AND PRESERVATION OF THE AIPS. | Data stewards must ensure that actions are recorded contemporaneously. | The LABDRIVE system records appropriate events, and those events may be downloaded as evidence. These may be supplemented by events documented outside the LABDDRIVE software. The procedures, such as the frequency of fixity hash checks, or checks on the understandability/usability should be available to check against the events. |
4.4.2.1 | The repository shall have procedures for all actions taken on AIPs. | Data stewards must have documented procedures for all actions on AIPs. | |
4.4.2.2 | The repository shall be able to demonstrate that any actions taken on AIPs were compliant with the specification of those actions. | Data stewards must ensure the configuration is consistent with the specified procedures. | |
4.5.1 | THE REPOSITORY SHALL SPECIFY MINIMUM INFORMATION REQUIREMENTS TO ENABLE THE DESIGNATED COMMUNITY TO DISCOVER AND IDENTIFY MATERIAL OF INTEREST. | Data stewards must determine what the search capabilities must be available to the Designated Community(ies). | The comprehensive search capabilities associated with LABDRIVE can be checked against the documented requirements. |
4.5.2 | THE REPOSITORY SHALL CAPTURE OR CREATE MINIMUM DESCRIPTIVE INFORMATION AND ENSURE THAT IT IS ASSOCIATED WITH THE AIP. | Data stewards must configure LABDRIVE to the capture or create the descriptive information for the objects. | |
4.5.3 | THE REPOSITORY SHALL MAINTAIN BI-DIRECTIONAL LINKAGE BETWEEN EACH AIP AND ITS DESCRIPTIVE INFORMATION. | ||
4.5.3.1 | The repository shall maintain the associations between its AIPs and their descriptive information over time. | ||
4.6.1 | THE REPOSITORY SHALL COMPLY WITH ACCESS POLICIES. | Data stewards must configure LABDRIVE access appropriately. | The access controls configured for some example objects should be checked against the appropriate access policies. |
4.6.1.1 | The repository shall log and review all access management failures and anomalies. | Data stewards must review access failures. | Access logs should be presented. |
4.6.2 | THE REPOSITORY SHALL FOLLOW POLICIES AND PROCEDURES THAT ENABLE THE DISSEMINATION OF DIGITAL OBJECTS THAT ARE TRACEABLE TO THE ORIGINALS, WITH EVIDENCE SUPPORTING THEIR AUTHENTICITY. | Data stewards must create policies and procedures which determine the configuration of LABDRIVE. | Not all accesses should result in objects that have their full provenance, but, if required, the full trace should be available. The system for capturing complaints/problems must be described. XXXXCHECK THIS |
4.6.2.1 | The repository shall record and act upon problem reports about errors in data or responses from users. | Data stewards must review and act on problem reports. | |
5.1.1 | THE REPOSITORY SHALL IDENTIFY AND MANAGE THE RISKS TO ITS PRESERVATION OPERATIONS AND GOALS ASSOCIATED WITH SYSTEM INFRASTRUCTURE. | Data stewards must identify and manage the risks, taking into account the information provided by LABDRIVE. | A well run repository should have a Risk Register. The risk register should address risks to information preservation. It can be presented as evidence. |
5.1.1.1 | The repository shall employ technology watches or other technology monitoring notification systems. | Data stewards must have access to technology watches. | LABDRIVE provides support for a variety of technologies. LINBOVA and partners maintain a watch on technologies. The contracts with LIBNOVA can be used as evidence. Evidence for funding is associated with earlier metrics. |
5.1.1.1.1 | The repository shall have hardware technologies appropriate to the services it provides to its designated communities. | Data stewards must ensure that it is aware of the hardware technologies required for the services provided to its designated communities. | |
5.1.1.1.2 | The repository shall have procedures in place to monitor and receive notifications when hardware technology changes are needed. | Data stewards have procedures in place to ensure it receives appropriate notifications. | |
5.1.1.1.3 | The repository shall have procedures in place to evaluate when changes are needed to current hardware. | Data stewards must have procedures in place to evaluate when hardware changes are required. | |
5.1.1.1.4 | The repository shall have procedures, commitment and funding to replace hardware when evaluation indicates the need to do so. | Data stewards ensure that procedures and funding are available to ensure that hardware replacement takes place as required. | |
5.1.1.1.5 | The repository shall have software technologies appropriate to the services it provides to its designated communities. | Data stewards must ensure that it is aware of the software technologies required for the services provided to its designated communities. | |
5.1.1.1.6 | The repository shall have procedures in place to monitor and receive notifications when software changes are needed. | Data stewards have procedures in place to ensure it receives appropriate notifications. | |
5.1.1.1.7 | The repository shall have procedures in place to evaluate when changes are needed to current software. | Data stewards must have procedures in place to evaluate when software changes are required. | |
5.1.1.1.8 | The repository shall have procedures, commitment and funding to replace software when evaluation indicates the need to do so. | Data stewards ensure that procedures and funding are available to ensure that software replacement takes place as required. | |
5.1.1.2 | The repository shall have adequate hardware and software support for backup functionality sufficient for preserving the repository content and tracking repository functions. | Data stewards must ensure that the backup configuration satisfies its requirements e.g. location and number of backups | The configuration of the placement of backups can be presented. |
5.1.1.3 | The repository shall have effective mechanisms to detect bit corruption or loss. | Data stewards must ensure that the number and frequency of checks are carried out, and periodic checks are made. | Evidence for the periodic hash checks can be presented from LABSAFE. |
5.1.1.3.1 | The repository shall record and report to its administration all incidents of data corruption or loss, and steps shall be taken to repair/replace corrupt or lost data. | Data stewards must respond to error reports and confirm that corrections have been made. | The repository should have a procedure to describe how errors are dealt with. |
5.1.1.4 | The repository shall have a process to record and react to the availability of new security updates based on a risk-benefit assessment. | Data stewards have a procedure to ensure that security updates are installed safely. | The LABDRIVE contract should include details of this. |
5.1.1.5 | The repository shall have defined processes for storage media and/or hardware change (e.g., refreshing, migration). | Data stewards must have defined processes on how/when refreshment, replication and repackaging should be carried out. | The configuration of the storage systems should make this clear. |
5.1.1.6 | The repository shall have identified and documented critical processes that affect its ability to comply with its mandatory responsibilities. | Data stewards must ensure, and collect evidence to support claims, that the mandatory responsibilities are complied with. | This can be part of the Risk Register or may be a separate document addressing the Mandatory Responsibilities, including testing procedures. |
5.1.1.6.1 | The repository shall have a documented change management process that identifies changes to critical processes that potentially affect the repository's ability to comply with its mandatory responsibilities. | Data stewards must document its change management processes and must identify the changes which affect the repository's preservation capabilities. | |
5.1.1.6.2 | The repository shall have a process for testing and evaluating the effect of changes to the repository's critical processes. | ||
5.1.2 | THE REPOSITORY SHALL MANAGE THE NUMBER AND LOCATION OF COPIES OF ALL DIGITAL OBJECTS. | Data stewards must configure LABDRIVE to ensure that the number of copies required are maintained. | The configuration of the storage options in LABDRIVE make this clear. Status reports on the synchronisation status should be available. There may be delays in synchronisation with very large collections. |
5.1.2.1 | The repository shall have mechanisms in place to ensure any/multiple copies of digital objects are synchronized. | ||
5.2.1 | THE REPOSITORY SHALL MAINTAIN A SYSTEMATIC ANALYSIS OF SECURITY RISK FACTORS ASSOCIATED WITH DATA, SYSTEMS, PERSONNEL, AND PHYSICAL PLANT. | Data stewards maintain an analysis of security risks. | This may be part of the Risk Register. |
5.2.2 | THE REPOSITORY SHALL HAVE IMPLEMENTED CONTROLS TO ADEQUATELY ADDRESS EACH OF THE DEFINED SECURITY RISKS. | Data stewards must ensure that security risks are addressed adequately. | |
5.2.3 | THE REPOSITORY STAFF SHALL HAVE DELINEATED ROLES, RESPONSIBILITIES, AND AUTHORIZATIONS RELATED TO IMPLEMENTING CHANGES WITHIN THE SYSTEM. | Data stewards must ensure that people are assigned to their correct roles and that the authorizations associated with each role is appropriate. | |
5.2.4 | THE REPOSITORY SHALL HAVE SUITABLE WRITTEN DISASTER PREPAREDNESS AND RECOVERY PLAN(S), INCLUDING AT LEAST ONE OFF-SITE BACKUP OF ALL PRESERVED INFORMATION TOGETHER WITH AN OFFSITE COPY OF THE RECOVERY PLAN(S). | Data stewards must create and maintain a disaster management plan, keeping at least one copy off-site. Data stewards must also configure LABDRIVE to support that plan. | The disaster recovery plan should be available. |
Last updated