Difference between revisions of "PD:CCSDS 652.0-M-1 audit template"
From MUSICAL HERITAGE ORGANIZATION
(created template for CCSDS 652-M-1 audit) |
(→DEFINITIONS: Changed "Some requirements are not fulfilled" with more precise "Minor requirements...") |
||
| Line 39: | Line 39: | ||
* <span style="color:green">Requirements fulfilled</span> | * <span style="color:green">Requirements fulfilled</span> | ||
| − | * <span style="color:orange"> | + | * <span style="color:orange">Minor requirements are not fulfilled</span> |
* <span style="color:red">Essential requirements not fulfilled</span> | * <span style="color:red">Essential requirements not fulfilled</span> | ||
| Line 110: | Line 110: | ||
|Extensible Markup Language | |Extensible Markup Language | ||
|} | |} | ||
| − | |||
=== [[PD:CCSDS_652.0-M-1#REFERENCES|REFERENCES]] === | === [[PD:CCSDS_652.0-M-1#REFERENCES|REFERENCES]] === | ||
Latest revision as of 14:55, 26 July 2016
REMOVE THIS HEADER
This is an empty template to do an audit according to CCSDS 652.0-M-1 the chapter structure is identical to the original so chapter numbering is consistent. Each title in this template is linked to the according title in the original text, to have fast access to the relevant information needed to answer the criterions.
Date of audit report: <insert date>
Version of audit report: 1.0
This audit was done according to the recommended practice 652.0-M-1 AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES from 2011 published by the Consultative Committee for Space Data Systems (CCSDS). The same committee that published the Reference Model for an Open Archival Information System (OAIS).
<insert introduction>
This audit documentation is structured in a similar way as the CCSDS 652.0-M-1 Recommended Practice document:
- introduction
- overview of audit and certification criteria
- conclusion
- catalog of requirements
Contents
- 1 OVERVIEW OF AUDIT AND CERTIFICATION CRITERIA
- 2 CONCLUSION AND FIELDS OF NON CONFORMANCE
- 3 ORGANIZATIONAL INFRASTRUCTURE
- 3.1 GOVERNANCE AND ORGANIZATIONAL VIABILITY
- 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.
- 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.
- 3.1.2.1 The repository shall have an appropriate 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.
- 3.1.2.2 The repository shall monitor its organizational environment to determine when to execute its succession plan, contingency plans, and/or escrow arrangements.
- 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.
- 3.2 ORGANIZATIONAL STRUCTURE AND STAFFING
- 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 fulfill these duties.
- 3.2.1.1 The repository shall have identified and established the duties that it needs to perform.
- 3.2.1.2 The repository shall have the appropriate number of staff to support all functions and services.
- 3.2.1.3 The repository shall have in place an active professional development program that provides staff with skills and expertise development opportunities.
- 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 fulfill these duties.
- 3.3 PROCEDURAL ACCOUNTABILITY AND PRESERVATION POLICY FRAMEWORK
- 3.3.1 The repository shall have defined its Designated Community and associated knowledge base(s) and shall have these definitions appropriately accessible.
- 3.3.2 The repository shall have Preservation Policies in place to ensure its Preservation Strategic Plan will be met.
- 3.3.3 The repository shall have a documented history of the changes to its operations,
- 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.
- 3.3.5 The repository shall define, collect, track, and appropriately provide its information integrity measurements.
- 3.3.6 The repository shall commit to a regular schedule of self-assessment and external certification.
- 3.4 FINANCIAL SUSTAINABILITY
- 3.4.1 The repository shall have short- and long-term business planning processes in place to sustain the repository over time.
- 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.
- 3.4.3 The repository shall have an ongoing commitment to analyze and report on financial risk, benefit, investment, and expenditure (including assets, licenses, and liabilities).
- 3.5 CONTRACTS, LICENSES, AND LIABILITIES
- 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.
- 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.
- 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.
- 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.
- 3.5.1.4 The repository shall have policies in place to address liability and challenges to ownership/rights.
- 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.
- 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.
- 3.1 GOVERNANCE AND ORGANIZATIONAL VIABILITY
- 4 DIGITAL OBJECT MANAGEMENT
- 4.1 INGEST: ACQUISITION OF CONTENT
- 4.1.1 The repository shall identify the Content Information and the Information Properties that the repository will preserve.
- 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.
- 4.1.3 The repository shall have adequate specifications enabling recognition and parsing of the SIPs.
- 4.1.4 The repository shall have mechanisms to appropriately verify the identity of the Producer of all materials.
- 4.1.5 The repository shall have an ingest process which verifies each SIP for completeness and correctness.
- 4.1.6 The repository shall obtain sufficient control over the Digital Objects to preserve them.
- 4.1.7 The repository shall provide the producer/depositor with appropriate responses at agreed points during the ingest processes.
- 4.1.8 The repository shall have contemporaneous records of actions and administration processes that are relevant to content acquisition.
- 4.2 INGEST: CREATION OF THE AIP
- 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.
- 4.2.2 The repository shall have a description of how AIPs are constructed from SIPs.
- 4.2.3 The repository shall document the final disposition of all SIPs. In particular the following aspect must be checked.
- 4.2.4 The repository shall have and use a convention that generates persistent, unique identifiers for all AIPs.
- 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.4.1 The repository shall uniquely identify each AIP within the repository.
- 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. In particular the following aspects must be checked.
- 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.
- 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. In particular the following aspects must be checked.
- 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. In particular the following aspects must be checked.
- 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.
- 4.2.7.2 The repository shall execute the testing process for each class of Content Information of the AIPs.
- 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.
- 4.2.8 The repository shall verify each AIP for completeness and correctness at the point it is created.
- 4.2.9 The repository shall provide an independent mechanism for verifying the integrity of the repository collection/content.
- 4.2.10 The repository shall have contemporaneous records of actions and administration processes that are relevant to AIP creation.
- 4.3 PRESERVATION PLANNING
- 4.3.1 The repository shall have documented preservation strategies relevant to its holdings.
- 4.3.2 The repository shall have mechanisms in place for monitoring its preservation environment.
- 4.3.3 The repository shall have mechanisms to change its preservation plans as a result of its monitoring activities.
- 4.3.4 The repository shall provide evidence of the effectiveness of its preservation activities.
- 4.4 AIP PRESERVATION
- 4.5 INFORMATION MANAGEMENT
- 4.5.1 The repository shall specify minimum information requirements to enable the Designated Community to discover and identify material of interest.
- 4.5.2 The repository shall capture or create minimum descriptive information and ensure that it is associated with the AIP.
- 4.5.3 The repository shall maintain bi-directional linkage between each AIP and its descriptive information.
- 4.6 ACCESS MANAGEMENT
- 4.1 INGEST: ACQUISITION OF CONTENT
- 5 INFRASTRUCTURE AND SECURITY RISK MANAGEMENT
- 5.1 TECHNICAL INFRASTRUCTURE RISK MANAGEMENT
- 5.1.1 The repository shall identify and manage the risks to its preservation operations and goals associated with system infrastructure.
- 5.1.1.1 The repository shall employ technology watches or other technology monitoring notification systems.
- 5.1.1.1.1 The repository shall have hardware technologies appropriate to the services it provides 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.
- 5.1.1.1.3 The repository shall have procedures in place to evaluate when changes are needed to current hardware.
- 5.1.1.1.4 The repository shall have procedures, commitment and funding to replace hardware when evaluation indicates the need to do so.
- 5.1.1.1.5 The repository shall have software technologies appropriate to the services it provides 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.
- 5.1.1.1.7 The repository shall have procedures in place to evaluate when changes are needed to current software.
- 5.1.1.1.8 The repository shall have procedures, commitment, and funding to replace software when evaluation indicates the need to do so.
- 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.
- 5.1.1.3 The repository shall have effective mechanisms to detect bit corruption or loss.
- 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.
- 5.1.1.5 The repository shall have defined processes for storage media and/or hardware change (e.g., refreshing, migration).
- 5.1.1.6 The repository shall have identified and documented critical processes that affect its ability to comply with its mandatory responsibilities.
- 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.
- 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.1.1 The repository shall employ technology watches or other technology monitoring notification systems.
- 5.1.2 The repository shall manage the number and location of copies of all digital objects.
- 5.1.1 The repository shall identify and manage the risks to its preservation operations and goals associated with system infrastructure.
- 5.2 SECURITY RISK MANAGEMENT
- 5.2.1 The repository shall maintain a systematic analysis of security risk factors associated with data, systems, personnel, and physical plant.
- 5.2.2 The repository shall have implemented controls to adequately address each of the defined security risks.
- 5.2.3 The repository staff shall have delineated roles, responsibilities, and authorizations related to implementing changes within the system.
- 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).
- 5.1 TECHNICAL INFRASTRUCTURE RISK MANAGEMENT
OVERVIEW OF AUDIT AND CERTIFICATION CRITERIA
A TRUSTWORTHY DIGITAL REPOSITORY
Definition of a trustworthy digital repository as given in the CCSDS 652.0-M-1 Recommended Practice document:
A trustworthy digital repository will understand threats to and risks within its systems. Constant monitoring, planning, and maintenance, as well as conscious actions and strategy implementation will be required of repositories to carry out their mission of digital preservation. All of these present an expensive, complex undertaking that depositors, stakeholders, funders, the Designated Community, and other digital repositories will need to rely on in the greater collaborative digital preservation environment that is required to preserve the vast amounts of digital information generated now and into the future.
DEFINITIONS
Each requirement is marked with a color, to show its status of fulfillment:
- Requirements fulfilled
- Minor requirements are not fulfilled
- Essential requirements not fulfilled
These definitions from the original audit document all apply to this internal audit:
For a better understanding some paragraphs of the CCSDS 652.0-M-1 Recommended Practice are reproduced here.
CONFORMANCE
Original text: An archive that conforms to this Recommended Practice shall have satisfied the auditor on each of the requirements.
EVIDENCE
Each metric in the Recommended Practice has associated with it informative text under the heading Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement providing examples of the evidence which might be examined to test whether the repository satisfies the metric. These examples are illustrative rather than prescriptive, and the lists of possible evidence are not exhaustive.
NOMENCLATURE
The following conventions apply for the normative specifications in this Recommended Practice:
- a) the words ‘shall’ and ‘must’ imply a binding and verifiable specification;
- b) the word ‘should’ implies an optional, but desirable, specification;
- c) the word ‘may’ implies an optional specification;
- d) the words ‘is’, ‘are’, and ‘will’ imply statements of fact.
ACRONYMS AND ABBREVIATIONS
| AIP | Archival Information Package (defined in reference [1]) |
| CCSDS | Consultative Committee for Space Data Systems |
| DEDSL | Data Entity Specification Language |
| DIP | Dissemination Information Package (defined in reference [1]) |
| FITS | Flexible Image Transport System |
| GIS | Geographic Information System |
| ISO | International Organization for Standardization |
| OAIS | Open Archival Information System (see reference [1]) |
| PDI | Preservation Description Information (defined in reference [1]) |
| SIP | Submission Information Package (defined in reference [1]) |
| TEI | Text Encoding Initiative |
| UML | Unified Modeling Language |
| XML | Extensible Markup Language |
REFERENCES
[1] Reference Model for an Open Archival Information System (OAIS).
For convenience the full text of the recommended practice CCSDS 652.0-M-1 AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES is readable on this wiki page: PD:CCSDS_652.0-M-1. Every requirement is directly linked to the corresponding explanation in the CCSDS 652.0-M-1 Recommended Practice.
The original document is published on the CCSDS Website: CCSDS Recommended Practices (Magenta Books)
CONCLUSION AND FIELDS OF NON CONFORMANCE
OVERVIEW
Of the 108 normative metrics the final status is the following:
Metrics with all requirements fulfilled: XX
Metrics where Some requirements are not fulfilled: XX
Metrics with essential requirements not fulfilled: XX
FIELDS OF NON CONFORMANCE
CONCLUSION
ORGANIZATIONAL INFRASTRUCTURE
With this chapter the catalog of requirements starts. Every requirement is explained in the CCSDS 652.0-M-1 document, this explanation can be reached directly by clicking on the heading of the requirement.
