You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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.

Supporting Text

This is necessary to ensure a secure and trustworthy infrastructure.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Infrastructure inventory of system components; periodic technology assessments; estimates of system component lifetime; export of authentic records to an independent system; use of strongly community supported software .e.g., Apache, iRODS, Fedora); re-creation of archives from backups.

5.1.1.1       The repository shall employ technology watches or other technology monitoring notification systems.

Supporting Text

This is necessary to track when hardware or software components will become obsolete and migration is needed to new infrastructure.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Management of periodic technology assessment reports. Comparison of existing technology to each new assessment.

5.1.1.1.1       The repository shall have hardware technologies appropriate to the services it provides to its designated communities.

Supporting Text

This is necessary to provide expected, contracted, secure, and persistent levels of service including: ease of ingest and dissemination through appropriate depositor and user interfaces and technologies such as upload mechanisms; on-going digital object management; preservation approaches and solutions, such as migration; and system security.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Maintenance of up-to-date designated community technology, expectations, and use profiles; Provision of bandwidth adequate to support ingest and use demands; systematic elicitation of feedback regarding hardware and service adequacy; maintenance of a current hardware inventory.

5.1.1.1.2       The repository shall have procedures in place to monitor and receive notifications when hardware technology changes are needed.

Supporting Text

This is necessary to ensure expected, contracted, secure, and persistent levels of service.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Audits of capacity versus actual usage; audits of observed error rates; audits of performance bottlenecks that limit ability to meet user community access requirements; documentation of technology watch assessments; documentation of technology updates from vendors.

5.1.1.1.3       The repository shall have procedures in place to evaluate when changes are needed to current hardware.

Supporting Text

This is necessary to ensure that the repository has the capacity to make informed and timely decisions when information indicates the need for new hardware.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Evaluation procedures in place; documented staff expertise in each technology sub-system.

5.1.1.1.4       The repository shall have procedures, commitment and funding to replace hardware when evaluation indicates the need to do so.

Supporting Text

This is necessary to ensure hardware replacement in a timely fashion so as to avert system failure or performance inadequacy. Without such a commitment, and more importantly, without escrowed financial resources or a secure funding stream, technology watches and notifications are of little value. The repository must have mechanisms for evaluating the efficacy of the new systems before implementation in the production system.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Statement of commitment to provide expected and contracted levels of service; evidence of ongoing financial assets set aside for hardware procurement; demonstration of cost savings through amortized cost of new system.

5.1.1.1.5       The repository shall have software technologies appropriate to the services it provides to its designated communities.

Supporting Text

This is necessary to provide expected, contracted, secure, and persistent levels of service including: ease of ingest and dissemination through appropriate depositor and user interfaces and technologies such as upload mechanisms; on-going digital object management; preservation approaches and solutions, such as migration; and system security.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Maintenance of up-to-date designated community technology, expectations, and use profiles; Provision of software systems adequate to support ingest and use demands; systematic elicitation of feedback regarding software and service adequacy; maintenance of a current software inventory.

5.1.1.1.6       The repository shall have procedures in place to monitor and receive notifications when software changes are needed.

Supporting Text

This is necessary to ensure expected, contracted, secure, and persistent levels of service.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Audits of capacity versus actual usage; audits of observed error rates; audits of performance bottlenecks that limit ability to meet user community access requirements; documentation of technology watch assessments; documentation of software updates from vendors.

5.1.1.1.7       The repository shall have procedures in place to evaluate when changes are needed to current software.

Supporting Text

This is necessary to ensure that the repository has the capacity to make informed and timely decisions when information indicates the need for new software.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Evaluation procedures in place; documented staff expertise in each softare technology sub-system.

5.1.1.1.8       The repository shall have procedures, commitment and funding to replace software when evaluation indicates the need to do so.

Supporting Text

This is necessary to ensure software replacement in a timely fashion so as to avert system failure or performance inadequacy. Without such a commitment, and more importantly, without escrowed financial resources or a secure funding stream, technology watches and notifications are of little value. The repository must have mechanisms for evaluating the efficacy of the new systems before implementation in the production system.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Statement of commitment to provide expected and contracted levels of service; evidence of ongoing financial assets set aside for software procurement; demonstration of cost savings through amortized cost of new system.

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.

Supporting Text

This is necessary in order to ensure continued access to and tracking of preservation functions applied to the digital objects in their custody.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Documentation of what is being backed up and how often; audit log/inventory of backups; validation of completed backups; disaster recovery plan, policy and documentation; fire drills; testing of backups; support contracts for hardware and software for backup mechanisms; demonstrated preservation of system metadata such as access controls, location of replicas, audit trails, checksum values.

5.1.1.3       The repository shall have effective mechanisms to detect bit corruption or loss.

Supporting Text

This is necessary in order to ensure that AIPs and metadata are uncorrupted or any data losses are detected and fall within the tolerances levels established by repository policy (see 3.3.5).

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Documents that specify bit error detection and correction mechanisms used; risk analysis; error reports; threat analysis; periodic analysis of the integrity of repository holdings.

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.

Supporting Text

This is necessary in order to ensure the repository administration is being kept informed of incidents and recovery actions, and to enable identification of sources of data corruption or loss.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Procedures related to reporting incidents to administrators; Preservation metadata (e.g., PDI) records; comparison of error logs to reports to administration; escalation procedures related to data loss; tracking of sources of incidents; remediation actions taken to remove sources of incidents.

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.

Supporting Text

This is necessary in order to protect the integrity of the archival objects from unauthorized changes or deletions.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Risk register (list of all patches available and risk documentation analysis); evidence of update processes (e.g., server update manager daemon); documentation related to the update installations.

5.1.1.5       The repository shall have defined processes for storage media and/or hardware change (e.g., refreshing, migration).

Supporting Text

This is necessary in order to ensure that data is not lost when either the media fail or the supporting hardware can no longer be used to access the data.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Documentation of migration processes; policies related to hardware support, maintenance, and replacement; documentation of hardware manufacturer's expected support life cycles; policies related to migration of records to alternate hardware systems.

5.1.1.6       The repository shall have identified and documented critical processes that affect its ability to comply with its mandatory responsibilities.

Supporting Text

This is necessary in order to ensure that the critical processes can be monitored to ensure that they continue to meet the mandatory responsibilities and to ensure that any changes to those processes are examined and tested.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Traceability matrix between processes and mandatory requirements.

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.

Supporting Text

This is necessary in order to ensure that the repository can specify not only the current processes, but the prior processes that were applied to the repository holdings.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Documentation of change management process; assessment of risk associated with a process change; analysis of the expected impact of a process change; comparison of logs of actual changes to processes versus associated analyses of their impact and criticality.

1.1.1.6.2       The repository shall have a process for testing and evaluating the effect of changes to the repository's critical processes.

Supporting Text

This is necessary in order to protect the integrity of the repository's critical processes such that they continue in their ability to meet the repository's mandatory requirements.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Documented testing procedures; documentation of results from prior tests and proof of changes made as a result of tests; analysis of the impact of a process change.

  • No labels