Skip to content

Instantly share code, notes, and snippets.

@ross-spencer

ross-spencer/2020-02-06-tdr-checklist.md

Last active July 14, 2021 09:38
Show Gist options
  • Save ross-spencer/c7493861798e8f030acd0c99f13625a4 to your computer and use it in GitHub Desktop.
Save ross-spencer/c7493861798e8f030acd0c99f13625a4 to your computer and use it in GitHub Desktop.
Download ZIP
TDR checklist in Markdown
Raw
2020-02-06-tdr-checklist.md

AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES RECOMMENDED PRACTICE

CCSDS 652.0-M-1

MAGENTA BOOK (Extract)

September 2011

Trusted Digital Repository Checklist

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.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.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.

  • 3.3.3 The repository shall have a documented history of the changes to its operations, procedures, software, and hardware.

  • 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.

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.1.1 The repository shall have a procedure(s) for identifying those Information Properties that it will preserve.
    • 4.1.1.2 The repository shall have a record of the Content Information and the Information Properties that it 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.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.

  • 4.2.3 The repository shall document the final disposition of all SIPs.

    • 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.

  • 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.5 The repository shall have access to necessary tools and resources to provide authoritative Representation Information for all of the digital objects it contains.

    • 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.

    • 4.2.6.1 The repository shall have documented processes for acquiring PDI.
    • 4.2.6.2 The repository shall execute its documented processes for acquiring PDI.
    • 4.2.6.3 The repository shall ensure that the PDI is persistently associated with the relevant Content Information.

  • 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.

    • 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.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.

  • 4.3.3 The repository shall have mechanisms to change its preservation plans as a result of its monitoring activities.

    • 4.3.3.1 The repository shall have mechanisms for creating, identifying or gathering any extra Representation Information required.

  • 4.3.4 The repository shall provide evidence of the effectiveness of its preservation activities.

4.4 AIP PRESERVATION

  • 4.4.1 The repository shall have specifications for how the AIPs are stored down to the bit level.

    • 4.4.1.1 The repository shall preserve the Content Information of AIPs.
    • 4.4.1.2 The repository shall actively monitor the integrity of AIPs.

  • 4.4.2 The repository shall have contemporaneous records of actions and administration processes that are relevant to storage and preservation of the AIPs.

    • 4.4.2.1 The repository shall have procedures for all actions taken 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.

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.5.3.1 The repository shall maintain the associations between its AIPs and their descriptive information over time.

4.6 ACCESS MANAGEMENT

  • 4.6.1 The repository shall comply with Access Policies.

    • 4.6.1.1 The repository shall log and review all access management failures and anomalies.

  • 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.

    • 4.6.2.1 The repository shall record and act upon problem reports about errors in data or responses from users.

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.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.

    • 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.2 The repository shall manage the number and location of copies of all digital objects.

      • 5.1.2.1 The repository shall have mechanisms in place to ensure any/multiple copies of digital objects are synchronized.

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).
@ross-spencer
Copy link
Author

Connected to nestor checklist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment