Combined Annotated document

Organisational Infrastructure

A1. Governance & organizational viability

Regardless of the size, scope, or nature of the digital preservation program, a trusted repository must demonstrate an explicit, tangible, and long-term commitment to compliance with prevailing standards, policies, and practices.

A1.1 Repository has a mission statement that reflects a commitment to the long-term retention of, management of, and access to digital information.

The mission statement of the repository must be clearly identified and accessible to depositors and other stakeholders and contain an explicit long-term commitment.

Evidence: Mission statement for the repository; mission statement for the organizational context in which the repository sits; legal or legislative mandate; regulatory requirements.

-- KatiaThomaz - 10 May 2007 - It lacks "and this mission statement complies with principles of security of information: awareness, responsability, response, ethics, democracy, risk assessment, security design and implementation, security management, reassessment"; (see OECD Guidelines).

A1.2 Repository has 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.

Part of the repository’s perpetual-care promise is a commitment to identify appropriate successors or arrangements should the need arise. Consideration needs to be given to this responsibility while the repository or data is viable—not when a crisis occurs—to avoid irreparable loss. Organizationally, the data in a repository can be at risk regardless of whether the repository is run by a commercial organization or a government entity (national library or archives). At government-managed repositories and archives, a change in government that significantly alters the funding, mission, collecting scope, or staffing of the institution may put the data at risk. These risks are similar to those faced by commercial and researchbased repositories and should minimally be addressed by succession plans for significant collections within the greater repository.

A formal succession plan should include the identification of trusted inheritors, if applicable, and the return of digital objects to depositors with adequate prior notification, etc. If a formal succession plan is not in place, the repository should be able to point to indicators that would form the basis of a plan, e.g., partners, commitment statements, likely heirs. Succession plans need not specify handoff of entire repository to a single organization if this is not feasible. Multiple inheritors are possible so long as the data remains accessible.

Evidence: Succession plan(s); escrow plan(s); explicit and specific statement documenting the intent to ensure continuity of the repository, and the steps taken and to be taken to ensure continuity; formal documents describing exit strategies and contingency plans; depositor agreements.

A2. Organizational structure & staffing

A repository must have designated staff with requisite skills and training and must provide ongoing development. The repository should be able to document efforts to define and maintain requisite skills, roles, job descriptions, and development plans.

A2.1 Repository has identified and established the duties that it needs to perform and has appointed staff with adequate skills and experience to fulfill these duties.

The repository must identify the competencies and skill sets required to operate the repository over time and demonstrate that the staff and consultants have the range of requisite skills—e.g., archival training, technical skills, and legal expertise.

Evidence: A staffing plan; competency definitions; job description; development plans; plus evidence that the repository review and maintains these documents as requirements evolve.

A2.2 Repository has the appropriate number of staff to support all functions and services.

Staffing for the repository must be adequate for the scope and mission of the archiving program. The repository should be able to demonstrate an effort to determine the appropriate number and level of staff that corresponds to requirements and commitments. (These requirements are related to the core functionality covered by a certification process. Of particular interest to repository certification is whether the organization has appropriate staff to support activities related to the long-term preservation of the data.) The accumulated commitments of the repository can be identified in deposit agreements, service contracts, licenses, mission statements, work plans, priorities, goals, and objectives. Understaffing or a mismatch between commitments and staffing indicates that the repository cannot fulfill its agreements and requirements.

Evidence: Organizational charts; definitions of roles and responsibilities; comparison of staffing levels to commitments and estimates of required effort.

-- KatiaThomaz - 10 May 2007 - It lacks “repository evaluate staff effectiveness and suitability” (see DCC/DPE DRAMBORA R24).

A2.3 Repository has an active professional development program in place that provides staff with skills and expertise development opportunities.

Technology will continue to change, so the repository must ensure that its staff’s skill sets evolve, ideally through a lifelong learning approach to developing and retaining staff. As the requirements and expectations pertaining to each functional area evolve, the repository must demonstrate that staff are prepared to face new challenges.

Evidence: Professional development plans and reports; training requirements and training budgets, documentation of training expenditures (amount per staff); performance goals and documentation of staff assignments and achievements, copies of certificates awarded.

A3. Procedural accountability & policy framework

A repository must provide clear and explicit documentation of its requirements, decisions, development, and actions to ensure long-term preservation and access to digital content in its care. This documentation assures consumers, management, producers, and certifiers that the repository is meeting its requirements and fully performing its role as a trusted digital repository. Certification, the clearest indicator of a repository’s sound and standards-based practice, is facilitated by procedural accountability that results in comprehensive and current policies, procedures, and practice.

A3.1 Repository has defined its designated community(ies) and associated knowledge base(s) and has publicly accessible definitions and policies in place to dictate how its preservation service requirements will be met.

The definition of the designated community(ies) (producer and user community) is arrived at through the planning processes used to create the repository and define its services. The definition will be drawn from various sources ranging from market research to service-level agreements for producers to the mission or scope of the institution within which the repository is embedded.

Meeting the needs of the designated community—the expected understandability of the information, not just access to it—will affect the digital object management, as well as the technical infrastructure of the overall repository. For appropriate long-term planning, the repository or organization must understand and institute policies to support these needs.

For a given submission of information, the repository must make clear the operational definition of understandability that is associated with the corresponding designated community(ies). The designated community(ies) may vary from one submission to another, as may the definition of understandability that establishes the repository’s responsibility in this area. This may range from no responsibility, if bits are only to be preserved, to the maintenance of a particular level of use, if understanding by the members of the designated community(ies) is determined outside the repository, to a responsibility for ensuring a given level of designated community(ies) human understanding, requiring appropriate Representation Information.

The documentation of understandability will typically include a definition of the applications the designated community(ies) will use with the information, possibly after transformation by repository services. For example, if a designated community is defined as readers of English with access to widely available document rendering tools, and if this definition is clearly associated with a given set of Content Information and Preservation Description Information, then the requirement is met.

Examples of designated community definitions include:

• General English-reading public educated to high school and above, with access to a Web Browser (HTML 4.0 capable).
• For GIS data: GIS researchers—undergraduates and above—having an understanding of the concepts of Geographic data and having access to current (2005, USA) GIS tools/computer software, e.g., ArcInfo (2005).
• Astronomer (undergraduate and above) with access to FITS software such as FITSIO, familiar with astronomical spectrographic instruments.
• Student of Middle English with an understanding of TEI encoding and access to an XML rendering environment.
• Variant 1: Cannot understand TEI
• Variant 2: Cannot understand TEI and no access to XML rendering environment
• Variant 3: No understanding of Middle English but does understand TEI and XML
• Two groups: the publishers of scholarly journals and their readers, each of whom have different rights to access material and different services offered to them.

Evidence: Mission statement; written definitions of the designated community(ies); documented policies; service-level agreements.

-- KatiaThomaz - 10 May 2007 - It lacks “repository has defined the external parties”; (see ISO27001 A.6.2).

-- KatiaThomaz - 10 May 2007 - It lacks “repository has defined its assets, owners and uses”; (see ISO27001 A.7). added

A3.2 Repository has procedures and policies in place, and mechanisms for their review, update, and development as the repository grows and as technology and community practice evolve.

The policies and procedures of the repository must be complete, written or available in a tangible form, remain current, and must evolve to reflect changes in requirements and practice. The repository must demonstrate that a policy and procedure audit and maintenance is in place and regularly applied. Policies and procedures should address core areas, including, for example, transfer requirements, submission, quality control, storage management, disaster planning, metadata management, access, rights management, preservation strategies, staffing, and security. High-level documents should make organizational commitments and intents clear. Lower-level documents should make day-to-day practice and procedure clear. Versions of these documents must be well managed by the repository (e.g., outdated versions are clearly identified or maintained offline) and qualified staff and peers must be involved in reviewing, updating, and extending these documents. The repository should be able to document the results of monitoring for relevant developments; responsiveness to prevailing standards and practice, emerging requirements, and standards that are specific to the domain, if appropriate; and similar developments. The repository should be able to demonstrate that it has defined “comprehensive documentation” for the repository. See Appendix 3: Minimum Required Documents for more information.

Evidence: Written documentation in the form of policies, procedures, protocols, rules, manuals, handbooks, and workflows; specification of review cycle for documentation; documentation detailing review, update, and development mechanisms. If documentation is embedded in system logic, functionality should demonstrate the implementation of policies and procedures.

A3.3 Repository maintains written policies that specify the nature of any legal permissions required to preserve digital content over time, and repository can demonstrate that these permissions have been acquired when needed.

Because the right to change or alter digital information is often restricted by law to the creator, it is important that digital repositories address the need to be able to work with and potentially modify digital objects to keep them accessible over time. Repositories should have written policies and agreements with depositors that specify and/or transfer certain rights to the repository enabling appropriate and necessary preservation actions to take place on the digital objects within the repository.

Because legal negotiations can take time, potentially slowing or preventing the ingest of digital objects at risk, a digital repository may take in or accept digital objects even with only minimal preservation rights using an open-ended agreement and address more detailed rights later. A repository’s rights must at least limit the repository’s liability or legal exposure that threatens the repository itself. A repository does not have sufficient control of the information if the repository itself is legally at risk.

Evidence: Deposit agreements; records schedule; digital preservation policies; records legislation and policies; service agreements.

-- KatiaThomaz - 10 May 2007 - It lacks “repository specify IPR, legislative requirements, and regulatory requirements” (see DCC/DPE DRAMBORA R15, R17, R18 and ISO27001 A15) [One must keep in mind that according to OAIS RM a producer-archive contract is NOT an obligation for an archive].

A3.4 Repository is committed to formal, periodic review and assessment to ensure responsiveness to technological developments and evolving requirements.

Long-term preservation is a shared and complex responsibility. A trusted digital repository contributes to and benefits from the breadth and depth of community-based standards and practice. Regular review is a requisite for ongoing and healthy development of the repository. The organizational context of the repository should determine the frequency of, extent of, and process for self-assessment. The repository must also be able to provide a specific set of requirements it has defined, is maintaining, and is striving to meet. (See also A3.9.)

Evidence: A self-assessment schedule, timetables for review and certification; results of self-assessment; evidence of implementation of review outcomes.

A3.5 Repository has policies and procedures to ensure that feedback from producers and users is sought and addressed over time.

The repository should be able to demonstrate that it is meeting explicit requirements, that it systematically and routinely seeks feedback from stakeholders to monitor expectations and results, and that it is responsive to the evolution of requirements.

Evidence: A policy that requires a feedback mechanism; a procedure that addresses how the repository seeks, captures, and documents responses to feedback; documentation of workflow for feedback (i.e., how feedback is used and managed); quality assurance records.

A3.6 Repository has a documented history of the changes to its operations, procedures, software, and hardware that, where appropriate, is linked to relevant preservation strategies and describes potential effects on preserving digital content.

The repository must document the full range of its activities and developments over time, including decisions about the organizational and technological infrastructure. If the repository uses software to document this history, it should be able to demonstrate this tracking.

Evidence: Policies, procedures, and results of changes that affect all levels of the repository: objects, aggregations of objects; object-level preservation metadata; repository’s records retention strategy document.

A3.7 Repository commits to transparency and accountability in all actions supporting the operation and management of the repository, especially those that affect the preservation of digital content over time.

Transparency is the best assurance that the repository operates in accordance with accepted standards and practice. Transparency is essential to accountability, and both are achieved through active, ongoing documentation. The repository should be able to document its efforts to make information about its development, implementation, evolution, and performance available and accessible to relevant stakeholders. The usual means of communication an organization uses to provide significant news and updates to stakeholders should suffice for meeting this requirement.

Evidence: Comprehensive documentation that is readily accessible to stakeholders; unhindered access to content and associated information within repository.

A3.8 Repository commits to defining, collecting, tracking, and providing, on demand, its information integrity measurements.

The repository must develop or adapt appropriate measures for ensuring the integrity of its holdings. The mechanisms to measure integrity will evolve as technology evolves, but currently include examples such as the use of checksums at ingest and throughout the preservation process. The chain of custody for all of its digital content from the point of deposit forward must be explicit, complete, correct, and current. The repository must demonstrate that the content it has matches the content it received, e.g., with an implemented registry function that documents content from submission onward. Losses associated with migration and other preservation actions should also be documented and made available to relevant stakeholders. (See C1.5 and C1.6.)

If protocols, rules, and mechanisms are embedded in the repository software, there should be some way to demonstrate the implementation of integrity measurements.

Evidence: An implemented registry system; a definition of the repository’s integrity measurements; documentation of the procedures and mechanisms for integrity measurements; an audit system for collecting, tracking, and presenting integrity measurements; procedures for responding to results of integrity measurements that indicate digital content is at risk; policy and workflow documentation.

A3.9 Repository commits to a regular schedule of self-assessment and certification and, if certified, commits to notifying certifying bodies of operational changes that will change or nullify its certification status.

A repository cannot self-certify because an objective, external measurement using a consistent and repeatable certification process is needed to ensure and demonstrate that the repository meets and will likely continue to meet preservation requirements. Therefore, certification is the best indicator that the repository meets its requirements, fulfills its role, and adheres to appropriate standards. The repository must demonstrate that it integrates certification preparation and response into its operations and planning. (See also A3.4.)

Evidence: Completed, dated audit checklists from self-assessment or objective audit; certificates awarded for certification; presence in a certification register (when available); timetable or budget allocation for future certification.

A4. Financial sustainability

A trusted digital repository should be able to prove its financial sustainability. Overall, a trusted repository adheres to all good business practices and should have a sustainable business plan—a general set of documents that reflect the past, present, and future of the repository and its activities. A business plan incorporates management plans and financial implications related to development and normal production activities, and may note the strategies and/or risks that would affect operations. Normal business and financial fitness should be reviewed at least annually. Standard accounting procedures should be used. Both short- and long-term financial planning cycles should demonstrate an ongoing balance of risk, benefit, investment, and expenditure. Operating budgets and reserves should be adequate.

A4.1 Repository has short- and long-term business planning processes in place to sustain the repository over time.

The repository must demonstrate that it has formal, cyclical, proactive business planning processes in place. A brief description of the repository’s business plan should show how the repository will generate income and assets through services, third-party partnerships, grants, and so forth. As for A1.2 (succession/ contingency/escrow planning), the repository must establish these processes when it is viable to avoid business crises.

These questions may be pertinent to this requirement:

• Under this plan, to what extent is the repository supported, or expected to be supported, by revenue from content-contributing organizations and agencies, such as publishers?
• To what extent is the repository supported, or expected to be supported, by revenue from subscribers or subscribing institutions?
• What measures are in place, if any, to limit access by nonsubscribing stakeholders?
• What financial incentives are offered, if any, to discourage subscribers from postponing their investment in the repository? From discontinuing investing in the repository?
• To what extent is the repository supported, or expected to be supported, by other kinds of parties?
• How will major future costs, such as migrations, capital improvements, enhancements, providing access in the event of publisher failure, etc., be distributed between publishers, subscribers, and other supporting parties?
• What contingency plans are in place to cover the loss of future revenue and/or outside funding?
• In the event of a catastrophic failure, are reserve assets sufficient to ensure the restoration of subscriber access to content reasonably quickly?
• If this is a national or government-sponsored repository, how is it insulated from political events, such as international conflicts or diplomatic crises, that might affect its ability to serve foreign constituencies?

Evidence: Operating plans; financial reports; budgets; financial audit reports; annual financial reports; financial forecasts; business plans; audit procedures and calendars; evidence of comparable institutions; exposure of business plan to scenarios.

DavidGiaretta - we should perhaps add here that there should be an evaluation of the risks implied by the business plans. Risk is mentioned in A4.4 but that seems rather vague.

A4.2 Repository has in place processes to review and adjust business plans at least annually.

The repository must demonstrate its commitment to proactive business planning by performing cyclical planning processes at least yearly. The repository should be able to demonstrate its responsiveness to audit results, for example.

Evidence: Business plans, audit planning (e.g., scope, schedule, process, and requirements) and results; financial forecasts; recent audits and evidence of impact on repository operating procedures.

A4.3 Repository’s financial practices and procedures are transparent, compliant with relevant accounting standards and practices, and audited by third parties in accordance with territorial legal requirements.

The repository cannot just claim transparency, it must show that it adjusts its business practices to keep them transparent, compliant, and auditable. Confidentiality requirements may prohibit making information about the repository’s finances public, but the repository should be able to demonstrate that it is as transparent as it needs to be and can be within the scope of its community.

Evidence: Demonstrated dissemination requirements for business planning and practices; citations to and/or examples of accounting and audit requirements, standards, and practice; evidence of financial audits already taking place.

A4.4 Repository has ongoing commitment to analyze and report on risk, benefit, investment, and expenditure (including assets, licenses, and liabilities).

The repository must commit to at least these categories of analysis and reporting, and maintain an appropriate balance between them. The repository should be able to demonstrate that it has identified and documented these categories, and actively manages them, including identifying and responding to risks, describing and leveraging benefits, specifying and balancing investments, and anticipating and preparing for expenditures.

Evidence: Risk management documents that identify perceived and potential threats and planned or implemented responses (a risk register); technology infrastructure investment planning documents; costbenefit analyses; financial investment documents and portfolios; requirements for and examples of licenses, contracts, and asset management; evidence of revision based on risk.

DavidGiaretta - should we require that the risk analysis be made available at least to those who deposit information?

A4.5 Repository commits to monitoring for and bridging gaps in funding.

The repository must recognize the possibility of gaps between funding and the costs of meeting the repository’s commitments to its stakeholders. It commits to bridging these gaps by securing funding and resource commitments specifically for that purpose; these commitments can come either from the repository itself or parent organizations, as applicable. Even with effective business planning procedures in place, any repository with long-term commitments will likely face some kind of resource gap in the future. The repository must provide essentially an insurance buffer as a first—and hopefully effective— line of defense, obviating the need to invoke a succession plan except in extreme situations, such as the repository ceasing operations permanently.

Evidence: Fiscal and fiduciary policies, procedures, protocols, requirements; budgets and financial analysis documents; fiscal calendars; business plan(s); any evidence of active monitoring and preparedness.

A5. Contracts, licenses, & liabilities

A repository’s contracts, licenses, and liabilities should be explicit. They should define clear and measurable terms; delineate roles, responsibilities, timeframes, and conditions; and be either readily accessible or available to stakeholders on demand. Contracts include those between the repository and content owners (depositors, publishers, etc) and those between the repository and its own service providers (system service/maintenance contracts), with system developers, etc. Regardless of the relationship, these contracts and licenses must be available for audits so that liabilities and risks can be evaluated.

A5.1 If repository manages, preserves, and/or provides access to digital materials on behalf of another organization, it has and maintains appropriate contracts or deposit agreements.

Repositories, especially those with third-party deposit arrangements, should guarantee that relevant contracts, licenses, or deposit agreements express rights, responsibilities, and expectations of each party. Contracts and formal deposit agreements should be countersigned and current.

When the relationship between depositor and repository is less formal (i.e., a faculty member depositing work in an academic institution’s preservation repository), documentation articulating the repository’s capabilities and commitments should be provided to each depositor.

Repositories engaged in Web archiving may find this requirement difficult because of how Web-based information is harvested/captured for long-term preservation. This kind of data is rarely acquired with contracts or deposit agreements. By its very nature, digital information on the Web is perceived to belong to “everyone and no one.” Some repositories capture, manage, and preserve access to this material without written permission from the content creators. Others go through the very time-consuming and costly process of contacting content owners before capturing and ingesting information. Regardless of process, repositories harvesting and ingesting Web-based materials must articulate their rights issues within publicly accessible policies, and have mechanisms to respond to content owners if the repository’s rights to collect and preserve certain information are challenged.

Ideally, these agreements will be tracked, linked, managed, and made accessible in a contracts database.

Evidence: Deposit agreements; policies on third-party deposit arrangements; contracts; definitions of service levels; Web archiving policies; procedure for reviewing and maintaining agreements, contracts, and licenses.

A5.2 Repository contracts or deposit agreements must specify and transfer all necessary preservation rights, and those rights transferred must be documented.

Because the right to change or alter digital information is often restricted by law to the creator, it is important that digital repository contracts and agreements address the need to be able to work with and potentially modify digital objects to keep them accessible. Repository agreements with depositors must specify and/or transfer certain rights to the repository enabling appropriate and necessary preservation actions for the digital objects within the repository. (This requirement is linked to A3.3.)

Because legal negotiations can take time, potentially preventing or slowing the ingest of digital objects at risk, it is acceptable for a digital repository to take in or accept digital objects even with only minimal preservation rights using an open-ended agreement and then deal with expanding to detailed rights later. A repository’s rights must at least limit the repository’s liability or legal exposure that threatens the repository itself.

Evidence: Contracts, deposit agreements; specification(s) of rights transferred for different types of digital content (if applicable); policy statement on requisite preservation rights.

A5.3 Repository has specified all appropriate aspects of acquisition, maintenance, access, and withdrawal in written agreements with depositors and other relevant parties.

The deposit agreement specifies all aspects of these issues that are necessary for the repository to carry out its function. There may be a single agreement covering all deposits, or specific agreements for each deposit, or a standard agreement supplemented by special conditions for some deposits. These special conditions may add to the standard agreement or override some aspects of the standard agreement. Agreements may need to cover restrictions on access and will need to cover all property rights in the digital objects. Agreements may place responsibilities on depositors, such as ensuring that Submission Information Packages (SIPs) conform to some pre-agreed standards, and may allow repositories to refuse SIPs that do not meet these standards. Other repositories may take responsibility for fixing errors in SIPs. The division of responsibilities must always be clear. Agreements, written or otherwise, may not always be necessary. The burden of proof is on the repository to demonstrate that it does not need such agreements—for instance, because it has a legal mandate for its activities.

An agreement should include, at a minimum, property rights, access rights, conditions for withdrawal, level of security, level of finding aids, SIP definitions, time, volume, and content of transfers. One example of a standard to follow for this is the CCSDS/ISO Producer-Archive Interface Methodology Abstract Standard.

Evidence: Submission agreements/deposit agreements/deeds of gift; written standard operating procedures.

A5.4 Repository tracks and manages intellectual property rights and restrictions on use of repository content as required by deposit agreement, contract, or license.

-- MarkConrad - 10 Sep 2007 Need to include a reference to the law as well. Have to be able to track legal requirements that impact the jurisdiction of the repository and the depositors (These may be a different set.).

The repository should have a mechanism for tracking licenses and contracts to which it is obligated. Whatever the format of the tracking system, it must be sufficient for the institution to track, act on, and verify rights and restrictions related to the use of the digital objects within the repository.

Evidence: A policy statement that defines and specifies the repository’s requirements and process for managing intellectual property rights; depositor agreements; samples of agreements and other documents that specify and address intellectual property rights; demonstrable way to monitor intellectual property; results from monitoring.

A5.5 If repository ingests digital content with unclear ownership/rights, policies are in place to address liability and challenges to those rights.

The repository’s policies and mechanisms must be vetted by appropriate institutional authorities and/or legal experts to ensure that responses to challenges adhere to relevant laws and requirements, and that the potential liability for the repository is minimized.

Evidence: A definition of rights; citations for relevant laws and requirements; policy on responding to challenges; documented track record for responding to challenges in ways that do not inhibit preservation; examples of legal advice sought and received.

-- DavidGiaretta - 09 May 2007

-- KatiaThomaz - 10 May 2007

-- SimonLambert - 21 Jun 2007

Digital Object Management

B1. Ingest: acquisition of content

Acquisition involves a crucial interaction between repository and depositor. Success in this phase of ingest indicates the repository’s ability to gain sufficient control over the content.

Repositories are likely to differ the most in this area of ingest processes, depending on the type of material they collect and their relationships with its producers. For any repository, it can be stated with some confidence that ingest finishes when an Archival Information Package (AIP) and its associated metadata are secure in the repository, including the creation of any security copies. It is more difficult to make a general statement about when ingest begins. Some repositories will have content submitted to them by producers, perhaps unexpectedly. Others will actively go out and seek content and request it from producers. Some producer-repository relationships will be more collaborative, making it less clearcut who initiates a particular transaction.

Relationships between producers and repositories that affect ingest can differ greatly in their formality and the extent to which obligations are placed on different parties. National archives, deposit (copyright) libraries, and institutional repositories may be able to compel their producers (government agencies and publishers) to provide content, but may have little or no control over its form. Other repositories may not be able to compel producers to offer content, but might be able to select the form of acceptable content, whether that applies to file formats or minimal metadata standards, for instance. Some repositories (Web archives, for example) may have little or no relationship with the producers of the content they preserve.

Given these differences, some of the requirements here are very general and require judgments about what is appropriate for a repository given its stated mission and the needs of its designated community(ies). But the result that all repositories are trying to achieve is the same: to preserve content that is understandable and usable in the long term. For more detailed information and thorough discussion of ingest and applicability, see Appendix 4: A Perspective on Ingest.

-- KatiaThomaz - 10 May 2007 - New item for “repository has developed criteria for the selection of its digital objects” (see NESTOR CCTDR 1.1). DonaldSawyer - This could be considered to be covered under B1.1 text, but B1.1 text could be expanded to make this clearer.

• KatiaThomaz - I don´t know if my English comprehension is not good, but I think digital object properties don´t include criteria for the selection of digital objects. DonaldSawyer - I now think it may be good to call this out as a separate item for clarity.

B1.1 Repository identifies properties it will preserve for digital objects.

This process begins in general with the repository's mission statement and may be further specified in pre-accessioning agreements with producers or depositors (e.g., producer-archive agreements) and made very specific in deposit or transfer agreements for specific digital objects and their related documentation. For example, one repository may only commit to preserving the textual content of a document and not its exact appearance on a screen. Another may wish to preserve the exact appearance and layout of textual documents, while others may choose to normalize the data during the ingest process. If unique identifiers are associated with digital objects before ingest, they may also be significant properties that need to be preserved.

Evidence: Mission statement; submission agreements/deposit agreements/deeds of gift; workflow and policy documents, including written definition of properties as agreed in the deposit agreement/deed of gift; written processing procedures; documentation of properties to be preserved.

B1.2 Repository clearly specifies the information that needs to be associated with digital material at the time of its deposit (i.e., SIP).

For most types of digital objects to be ingested, the repository should have written criteria, prepared by the repository on its own or in conjunction with other parties, that specify exactly what digital object(s) are transferred, what documentation is associated with the object(s), and any restrictions on access, whether technical, regulatory, or donor-imposed.

The level of precision in these specifications will vary with the nature of the repository's collection policy and its relationship with creators. For instance, repositories engaged in Web harvesting, or those that rescue digital materials long after their creators have abandoned them, cannot impose conditions on the creators of material, since they are not "depositors" in the usual sense of the word. But Web harvesters can, for instance, decide which metadata elements from the HTTP transactions that captured a site are to be preserved along with the site's files, and this still constitutes "information associated with the digital material." They may also choose to record the information or decisions -whether taken by humans or by automated algorithms- that led to the site being captured.

Evidence: Transfer requirements; producer-archive agreements.

B1.3 Repository has mechanisms to authenticatevalidate the source of all materials.

The repository's written standard operating procedures and actual practices must ensure the digital objects are obtained from the expected source, that the appropriate provenance has been maintained prior to submission, and that the objects are the expected objects. Confirmation can use various means including, but not limited to, digital processing and data verification and validation, and through exchange of appropriate instrument of ownership (e.g., submission agreements/deposit agreement/deed of gift).

Evidence: Submission agreements/deposit agreements/deeds of gift; workflow documents; evidence of appropriate technological measures; logs from procedures and authentications.

B1.4 Repository’s ingest process verifies each submitted object (i.e., SIP) for completeness and correctness as specified in B1.2.

Information collected during the ingest process must be compared with information from some other source --the producer or the repository's own expectations--to verify the correctness of the data transfer and ingest process. The extent to which a repository can determine correctness will depend on what it knows about the SIP and what tools are available for verifying correctness. It can mean simply checking that file formats are what they claim to be (TIFF files are valid TIFF format, for instance), or can imply checking the content. This might involve human checking in some cases, such as confirming that the description of a picture matches the image.

Repositories should have established procedures for handling incomplete SIPs. These can range from rejecting the transfer, to suspending processing until the missing information is received, to simply reporting the errors. Similarly, the definition of "completeness" should be appropriate to a repository's activities. If an inventory of files was provided by a producer as part of pre-ingest negotiations, one would expect checks to be carried out against that inventory. But for some activities such as Web harvesting, "complete" may simply mean "whatever we could capture in the harvest session." Whatever checks are carried out must be consistent with the repository's own documented definition and understanding of completeness and correctness.

Evidence: Appropriate policy documents and system log files from system performing ingest procedure; formal or informal "acquisitions register" of files received during the transfer and ingest process; workflow, documentation of standard operating procedures, detailed procedures; definition of completeness and correctness, probably incorporated in policy documents.

B1.5 Repository obtains sufficient physical control over the digital objects to preserve them.

The repository must obtain complete control of the bits of the digital objects conveyed with each SIP. For example, some SIPs may only reference digital objects and in such cases the repository must get the referenced digital objects if they constitute part of the object that the repository has committed to conserve. This willIt is not always be the case that referenced digital objects are preserved: scholarly papers in a repository may contain references to other papers that are held in a different repository, or not held anywhere at all, and harvested Web sites may contain references to material in the same site or different sites that the repository has chosen not to capture or was unable to capture.

Evidence: Submission agreements/deposit agreements/deeds of gift; workflow documents; system log files from the system performing ingest procedures; logs of files captured during Web harvesting.

B1.6 Repository provides producer/depositor with appropriate responses at predefinedagreed points during the ingest processes.

Based on the initial processing plan and agreement between the repository and the producer/depositor, the repository must provide the producer/depositor , if it is appropriate to have such a plan, with progress reports at agreedspecific, predetermined points throughout the ingest process. Responses can include initial ingest receipts, or receipts that confirm that the AIP has been created and stored. Repository responses can range from nothing at all to predetermined, periodic reports of the ingest completeness and correctness, error reports and any final transfer of custody document. Producers/Depositors can request further information on an ad hoc basis when the previously agreed upon reports are insufficient.

Evidence: Submission agreements/deposit agreements/deeds of gift; workflow documentation; standard operating procedures; evidence of "reporting back."

-- KatiaThomaz - 10 May 2007 - I doubt about the need of this item. Is it necessary for long-term preservation? DonaldSawyer - Some submissions, such as scientific data, may continue for months or years. However text says it is not mandatory to to provide intermediate responses. As regards the need for long term preservation, I think this is addressing good practice in relation to the Producers and thus may be looked at as engendering trust. Is it absolutely needed to actually do the preservation task? Probably not, but this raises the issue of scope as to what the ISO standard should cover. I belive discussion is needed on this issue. KatiaThomaz - If we decide keeping this I think it should be moved to A5 Contracts, licences & liabilities

B1.7 Repository can demonstratehas written policies that indicate when it accepts preservation responsibilityformally accepted for the contents of theeach set of submitted data objects (i.e., SIPs).

A key component of a repository's responsibility to gain sufficient control of digital objects is the point when the repository manages the bitstream. For some repositories this will occur when it first receives the SIP transformation, for others it may not occur until the ingested SIP is transformed into an AIP. At this point, the repository formally accepts preservation responsibility of digital objects from the depositor.

Repositories that report back to their depositors generally will mark this acceptance with some form of notification to the depositor. (This may depend on repository responsibilities as designated in the depositor agreement.) A repository may mark the transfer by sending a formal document, often a final signed copy of the transfer agreement, back to the depositor signifying the completion of the transformation from SIP to AIP process. Other approaches are equally acceptable. Brief daily updates may be generated by a repository that only provides annual formal transfer reports.

Evidence: Submission agreements/deposit agreements/deeds of gift; confirmation receipt sent back to producer.

B1.8 Repository has contemporaneous records of actions and administration processes that are relevant to preservation (Ingest: content acquisition).

These records must be created on or about the time of the actions they refer to and are related to actions taken during the Ingest: content acquisition process. The records may be automated or may be written by individuals, depending on the nature of the actions described. Where community or international standards are used, such as PREMIS (2005), the repository must demonstrate that all relevant actions are carried through.

Evidence: Written documentation of decisions and/or action taken; preservation metadata logged, stored, and linked to pertinent digital objects, confirmation receipts sent back to providers.

-- MarkConrad - 05 Nov 2007 I would remove the reference to PREMIS. PREMIS often does not list what the "relevant action" should be.

B2. Ingest: creation of the archivable package

Digital repositories must take actions to preserve the ingested information, and the things they disseminate to end users must be strongly linked to the original objects that were deposited. To paraphrase the OAIS, these requirements are meant to ensure that information (digital objects and all appropriate metadata) received and verified from each producer is put into the archival form (AIP) and is stored in archival storage for long-term preservation. More specifically, the repository must actually complete the ingest process, creating some appropriate form—identifiable as archival storage—in which to store the information. This includes addressing the linkage of appropriate metadata to meet the levels of understanding expected, the association of unique identifiers to be able to reference the digital content, the mapping from the submitted content to the AIP storage forms, and auditable provenance information ensuring no loss or corruption of content in developing the AIPs.

B2.1 Repository has an identifiable, written definition for each AIP or class of information preserved by the repository.

An AIP contains these key components: the primary data object to be preserved, its supporting Representation Information (format and meaning of the format elements), and the various categories of Preservation Description Information (PDI) that also need to be associated with the primary data object: Fixity, Provenance, Context, and Reference. There should be a definition of how these categories of information are bound together and/or related in such a way that they can always be found and managed within the archive.

It is merely necessary that definitions exist for each AIP, or class of AIP if there are many instances of the same type. Repositories that store a wide variety of object types may need a specific definition for each AIP they hold, but it is expected that most repositories will establish class descriptions that apply to many AIPs. It must be possible to determine which definition applies to which AIP.

While this requirement is primarily concerned with issues of identifying and binding key components of the AIP, B2.2 places more stringent conditions on the content of the key components to ensure that they are fit for the intended purpose. Separating the two criteria is important, particularly if a repository does not satisfy one of them. It is important to know whether some or all AIPs are not defined, or that the definitions exist but are not adequate.

Evidence: Documentation identifying each class of AIP and describing how each is implemented within the repository. Implementations may, for example, involve some combination of files, databases, and/or documents.

-- KatiaThomaz - 10 May 2007 - It seems that B2.1 could be combined with B2.2. DonaldSawyer - The TRAC document addresses the reason for separating them. Perhaps a discussion of the reasoning and examples given, for the split, is in order.

B2.2 Repository has a definition of each AIP (or class) that is adequate to fit long-term preservation needs.

In many cases, if the definitions required by B2.1 exist, this requirement is also satisfied, but it may also be necessary for the definitions to say something about the semantics or intended use of the AIPs if this could affect long-term preservation decisions. For example, say two repositories both only preserve digital still images, both using multi-image TIFF files as their preservation format. Repository 1 consists entirely of real-world photographic images intended for viewing by people and has a single definition covering all of its AIPs. (The definition may refer to a local or external definition of the TIFF format.) Repository 2 contains some images, such as medical x-rays, that are intended for computer analysis rather than viewing by the human eye, and other images that are like those in Repository 1. Repository 2 should perhaps define two classes of AIPs, even though it only uses one storage format for both. A future preservation action may depend on the intended use of the image—an action that changes the bit-depth of the image in a way that is not perceivable to the human eye may be satisfactory for real-world photographs but not for medical images, for example.

Evidence: Documentation that relates the AIP component’s contents to the related preservation needs of the repository, with enough detail for the repository's providers and consumers to be confident that the significant properties of AIPs will be preserved.

B2.3 Repository has a description of how AIPs are constructed from SIPs.

The repository must be able to show how the preserved object is constructed from the object initially submitted for preservation. In some cases, the AIP and SIP will be almost identical apart from packaging and location, and the repository need only state this. More commonly, complex transformations (e.g., data normalization) may be applied to objects during the ingest process, and a precise description of these actions (i.e., preservation metadata) may be necessary to ensure that the preserved object represents the information in the submitted object. The AIP construction description should include documentation that gives the provenance of the ingest process for each SIP to AIP transformation, typically consisting of an overview of general processing being applied to all such transformations, augmented with description of different classes of such processing and, when applicable, with special transformations that were needed.

Some repositories may need to produce these complex descriptions case by case, in which case diaries or logs of actions taken to produce each AIP will be needed. In these cases, documentation needs to be mapped between to individual AIPs, and the mapping needs to be available for examination. Other repositories that can run a more production-line approach may have a description for how each class of incoming object is transformed to produce the AIP. It must be clear which definition applies to which AIP. If, to take a simple example, two separate processes each produce a TIFF file, it must be clear which process was applied to produce a particular TIFF file.

Evidence: Process description documents; documentation of SIP relationship to AIP; clear documentation of how AIPs are derived from SIPs; documentation of standard/process against which normalization occurs; documentation of normalization outcome and how outcome is different from SIP.

B2.4 Repository can demonstrate that all submitted objects (i.e., SIPs) are either accepted as whole or part of an eventual archival object (i.e., AIP), or otherwise disposed of in a recorded fashion.

The timescale of this process will vary between repositories from seconds to many months, but SIPs must not remain in a limbo-like state forever. The accessioning procedures and the internal processing and audit logs should maintain records of all internal transformations of SIPs to demonstrate that they either become AIPs (or part of AIPs) or are disposed of. Appropriate descriptive information should also document the provenance of all digital objects.

Evidence: System processing files; disposal records; donor or depositor agreements/deeds of gift; provenance tracking system; system log files

B2.5 Repository has and uses a naming convention that generates visible, persistent, unique identifiers for all archived objects (i.e., AIPs ).

A repository needs to ensure that an accepted, standard naming convention is in place that identifies its materials uniquely and persistently for use both in and outside the repository. The “visibility” requirement here means “visible” to repository managers and auditors. It does not imply that these unique identifiers need to be visible to end users or that they serve as the primary means of access to digital objects.

Equally important is a system of reliable linking/resolution services in order to find the uniquely named object, no matter its physical location. This is so that actions relating to AIPs can be traced over time, over system changes, and over storage changes. Ideally, the unique ID lives as long as the AIP; if it does not, there must be traceability. The ID system must be seen to fit the repository’s current and foreseeable future requirements for things like numbers of objects. It must be possible to demonstrate that the identifiers are unique. Note that B2.1 requires that the components of an AIP be suitably bound and identified for long-term management, but places no restrictions on how AIPs are identified with files. Thus, in the general case, an AIP may be distributed over many files, or a single file may contain more than one AIP. Therefore identifiers and filenames may not necessarily correspond to each other.

Documentation must show how the persistent identifiers of the AIP and its components are assigned and maintained so as to be unique within the context of the repository. The documentation must also describe any processes used for changes to such identifiers. It must be possible to obtain a complete list of all such identifiers and do spot checks for duplications.

Evidence: Documentation describing naming convention and physical evidence of its application (e.g., logs)

DavidGiaretta: Should SIP's be assigned unique identifiers?

B2.6 (NOTE: THIS ITEM IS TO BE REMOVED BECAUSE IT HAS BEEN FOLDED INTO B1.1 AS AN EXAMPLE) If unique identifiers are associated with SIPs components before ingest, the repository preserves the identifiers in a way that maintains a persistent association with the resultant archived object (e.g., AIP).

SIPs will not always contain unique identifiers when the repository receives them. But where they do, and particularly where those identifiers were widely known before the objects were ingested, it is important that they are either retained as is, or that some mechanism allows the original identifier to be transformed into one used by the repository.

For example, consider an archival repository whose SIPs consist of file collections from electronic document management systems (EDMS). Each incoming SIP will contain a unique identifier for each file within the EDMS, which may just be the pathname to the file. The repository cannot use these as they stand, since two different collections may contain files with the same pathname. The repository may generate unique identifiers by qualifying the original identifier in some way (e.g., prefixing the pathname with a unique ID assigned to the SIP of which it was a part). Or it may simply generate new unique numeric identifiers for every file in each SIP. If it qualifies the original identifier, it must explain the scheme it uses. If it generates entirely new identifiers, it will probably need to maintain a mapping between original IDs and generated IDs, perhaps using object-level metadata.

Documentation must show the policy on handling the unique identification of SIP components as the objects to be preserved are ingested, preserved, and disseminated. Where special handling is Trustworthy Repositories Audit & Certification: Criteria and Checklist required, this must be documented for each SIP as a part of the provenance information capture (see B2.3).

Evidence: Workflow documents and evidence of traceability (e.g., SIP identifier embedded in AIP, mapping table of SIP IDs to AIPs)

-- KatiaThomaz - 10 May 2007 - I don’t see the need of putting the item in conditional once all SIPs have a unique identifier no matter if before, during or after the ingest process.

BarbaraSierman -This item is important when a producer sends a newer version of the object, the original unique identifier will help to refer to the right object. The same in case of delivery from the repository to the original deliverer.

DonaldSawyer - The text argues that not all SIP components (title should be clearer that this is addressing SIP components not identifiers of the SIPs themselves) will have unique identifiers. I believe this is true because SIP components may be simply put into generic containers within the SIP. However where the SIP components do have unique IDs, especially IDs that are widely recognized or are expected to be recognized by Repository users, the IDs need to be maintained and associated with relevant material in the AIP. Also, as Barbara points out, replacements may be facilitated by their retention. Therefore I believe the 'IF' is appropriate, and their retention is required.

DonaldSawyer - Upon further reflection, I recommend this be folded into requirement B 1.1 as an example because such identifiers would be significant properties that need to be preserved.

B2.7 Repository demonstrates that it has access to necessary tools and resources to establish authoritative semantic or technical context of the digital objects it contains. These tools and resources can be held internally or can be shared via, for example, a trusted set of registries.(i.e., access to appropriate international Representation Information and format registries).

The Global Digital Format Registry (GDFR), the UK National Archives’ file format registry PRONOM, and the UK Digital Curation Centre’s Registry Repository of Representation Information Registry(RRORI) are three emerging examples of potential international standardsexternal registries a repository might adopt. Whenever possible, tThe repository shouldmay use these types of standardized, authoritative information sources to identify and/or verify the Representation Information components of Content Information and PDI. This will reduce the long-term maintenance costs to the repository and improve quality control.

Any such registry is a specialised type of repository, which itself must be certified/trusted.

Most repositories will maintain format information locally to maintain their independent ability to verify formats or other technical or semantic details associated with each archival object. In these cases, the use of international format registries is not meant to replace local format registries but instead serve as a resource to verify or obtain independent, authoritative information about any and all file formats.

Good practice suggests that any locally held Representation Information should also be made available to other repositories via a trusted registry. In addition any item of Representation Information should itself have adequate Representation Information to ensure that the Designated Community can understand and use the data object being preserved

Evidence: Subscription or access to such registries; association of unique identifiers to format registries with digital objects; Viewable records in local format registry (with persistent links to digital objects); local metadata registry(ies); database records that include Representation Information and a persistent link to relevant digital objects.

MarkConrad - 25 May 2007 Can the GFDR, Pronom, and RepReg? truly be called standards? aren't they repositories?

• KatiaThomaz - I agree with Mark. They are repositories.
  • DavidGiaretta - not standards, I agree, but probably Registries of some sort. The important point is that whatever they are they must themselves be trusted to hold their digital information (in this case Representation Information) over the long term i.e. they must be trusted repositories.

• DavidGiaretta - I think that Representation Information (which is much more than format ) can be very large and the amount one needs does change. That is the reason to allow Repositories to refer to something outside themselves yet still be certifiable. Clearly we cannot force the use of such registries. The aim is just to make their use acceptable.

MarkConrad - 25 May 2007 Should this item reference ISO/IEC 11179, Information Technology -- Metadata Registries (MDR)?

• KatiaThomaz - Good point. I think it should.
• DavidGiaretta - yes, that is one type of system, but we should allow for others.
• DonaldSawyer - I would not include 11179. It has many components, and is a standard, which the others are not. I think the point was to give examples of registries and this doesn't fit that model.

INCORPORATED INTO B2.7
*B2.8 Repository records/registers Representation Information (including formats) ingested.*

When international standards for the associated Representation Information are not available, the repository needs to capture such information and register it so that it is readily findable and reusable. Some of it may be incorporated into software. The Representation Information is critical to the ability to turn bits into usable information and must be permanently associated with the Content Information.

Evidence: Viewable records in local format registry (with persistent links to digital objects); local metadata registry(ies); database records that include Representation Information and a persistent link to relevant digital objects.

B2.9 Repository acquires preservation metadata (i.e., PDI) for its associated Content Information. Proposed Revision: Repository has documented processes for acquiring preservation metadata (i.e., PDI) for its associated Content Information and acquires preservation metadata in accordance with the documented processes.

Preservation metadata (PDI) is needed not only by the repository to help ensure the Content Information is not corrupted (Fixity) and is findable (Reference Information), but to help ensure the Content Information is adequately understandable by providing a historical perspective (Provenance Information) and by providing relationships to other information (Context Information). The extent of such information needs is best addressed by members of the designated community(ies). The PDI must be permanently associated with Content Information.

Evidence: Viewable records in local format registry (with persistent links to digital objects); local metadata registry(ies); database records that include Representation Information and a persistent link to relevant digital objects. Proposed Revision: Viewable documentation on how the repository acquires and manages Preservation Description Information (PDI) for reference, provenance, fixity, and context and viewable PDI records that have been acquired and managed for the Content Information in accordance with the documentation.

DonaldSawyer: PDI is a required set of information to ensure adequate Content Information preservation. As such the above text appears to be inadequate. While I believe the extent of such information needs to be agreed between the Designated Communities AND the Repository, it seems that for audit purposes there should be a resulting documented policy within the Repository on how these various PDI information categories are obtained, their extent, and how they are managed. Then, the respositories holdings of such information can be compared against the documented policy. The evidence text above appears to be focused on Representation Information which is NOT a componenet of PDI, but rather is a part of Content Information and is addressed in other requirements. If there is general agreement on the above, then an effort to rewrite this requirement can be started.

BarbaraSierman: I wonder if there are not situations where an agreement about the PDI with the Designated Community is rather difficult, not to say hardly possible. Take for example the National Libraries, they have a broad idea about the Designated Community!

B2.10 Repository has a documented process for testing understandability of the information content and bringing the information content up to the agreed level of understandability.

If Content Information or Preservation Description Information (PDI) is not directly usable by the current application tools of the designated community(ies), the repository needs to have a defined process for giving it usable form or for making additional Representation Information available (see B3.2).

Repositories that share the burden of ensuring that adequate metadata or documentation is captured or generated to meet a required degree of understandability can implement any number of procedures to address this requirement. Such repositories typically have a narrowly defined designated community, such as a particular science discipline.

Evidence: Retention of individuals with the discipline expertise; periodic assembly of designated or outside community members to evaluate and identify additional required metadata.

B2.11 Repository verifies each AIP for completeness and correctness at the point it is generated.

The AIP can be verified by comparision to its definition (see B2.2).

An AIP may be constructed from the parts or the whole of one or more SIPs.

If the repository has a standard process to verify SIPs for either or both completeness and correctness and a demonstrably correct process for transforming SIPs into AIPs (see B2.3), then it simply needs to demonstrate that the initial checks were carried out successfully and that the transformation process was carried out without indicating errors. On the other hand Repositories that must create unique processes for many of their AIPs will also need to generate unique methods for validating the completeness and correctness of AIPs. This may include performing tests of some sort on the content of the AIP that can be compared with tests on the SIP. Such tests might be simple (counting the number of records in a file, or performing some simple statistical measure such as calculating the brightness histogram of an original and preserved image), but they might be complex or contain some subjective elements.

Documentation should describe how completeness and correctness of SIPs and AIPs are ensured, starting with ensuring receipt from the producer and continuing through AIP creation and supporting long-term preservation. Example approaches include the use of checksums, testing that checksums are still correct at various points during ingest and preservation, logs that such checks have been made, and any special tests that may be required for a particular SIP/AIP instance or class.

Evidence: Description of the procedure that verifies completeness and correctness of the AIPs; logs of the procedure.

-- KatiaThomaz - 10 May 2007 - I doubt about the need of this item; (see B1.4).

• DavidGiaretta - but B1.4 refers to SIP only whereas this refers to AIPs.
  • KatiaThomaz - but how could an AIP be uncomplete or uncorrect if its related SIPs were complete and correct?
• BarbaraSierman - and how could you proce that it is complete and correct?

-- KatiaThomaz - 03 Sep 2007 - I propose something like this: B2.11 Repository generates complete and correct AIPs - Repository can demonstrate each AIP conforms to its definition (see B2.2) and is compatible to its related SIPs (see B2.3). This may include performing tests of some sort on the content of the AIP that be compared with tests on the SIP. Such testes might be simple (counting the number of records in a file, or performing some statistical measure such as calculating the brightness histogram of an original and preserved image), but they might be complex or contain some subjective elements.

[Note: Here in Brazil, in the first case we say you "criticize" the data, and in the second case we say you "consist" the data.]

B2.12 Repository provides an independent mechanism for audit of the integrity of the repository collection/content.

In general, it is likely that a repository that meets all the previous criteria will satisfy this one without needing to demonstrate anything more. As a separate requirement, it demonstrates the importance of being able to audit the integrity of the collection as a whole.

For example, if a repository claims to have all e-mail sent or received by The Yoyodyne Corporation between 1985 and 2005, it has been required to show that:

• The content it holds came from Yoyodyne’s e-mail servers.
• It is all correctly transformed into a preservation format.
• Each monthly SIP of e-mail has been correctly preserved, including original unique identifiers such as Message-IDs.

However it may still have no way of showing whether this really represents all of Yoyodyne’s email. For example, if there is a three-day period with no messages in the repository, is this because Yoyodyne was shut down for those three days, or was the e-mail lost before the SIP was constructed? This case could be resolved by the repository amending its description of the collection, but other cases may not be so straightforward.

A familiar mechanism from the world of traditional materials in libraries and archives is an accessions or acquisitions register that is independent of other catalog metadata. A repository should be able to show, for each item in its accessions register, which AIP(s) contain content from that item. Alternatively, it may need to show that there is no AIP for an item, either because ingest is still in progress, or because the item was rejected for some reason. Conversely, any AIP should be able to be related to an entry in the acquisitions register.

Evidence: Documentation provided for B2.1 through B2.6; documented agreements negotiated between the producer and the repository (see B 1.1-B1.9); logs of material received and associated action (receipt, action, etc.) dates; logs of periodic checks.

B2.13 Repository has contemporaneous records of actions and administration processes that are relevant to preservation (AIP creation).

These records must be created on or about the time of the actions they refer to and are related to actions associated with AIP creation. The records may be automated or may be written by individuals, depending on the nature of the actions described. Where community or international standards are used, such as PREMIS (2005), the repository must demonstrate that all relevant actions are carried through.

Evidence: Written documentation of decisions and/or action taken; preservation metadata logged, stored, and linked to pertinent digital objects.

B3. Preservation planning

A repository or archiving system must have current, sound, and documented preservation strategies in place and demonstrably implemented. It is not enough simply to preserve information. A repository must do so in accordance with predefined, documented, preservation policies and procedures, and it must have identified mechanisms to update those policies and procedures in response to changing technologies. Without such documentation, a repository cannot pass an audit even if its work is otherwise exemplary.

Documentation need not be particularly complex. It also does not need to prescribe in detail how a repository will deal with the unknown. For instance, a repository cannot be required to document how it will preserve a file format, or information semantics e.g. terminology, that has not yet been invented. But it may be expected to describe what it will do when first presented with an object in a format or using a terminology dictionary that it has not encountered before. It may not have strategies for every single kind of file within the repository (especially important for institutions acquiring and ingesting the product of Web harvesting/archiving activities), but it needs to be able to articulate organizational awareness of the diversity of information within the repository as well as plans or assertions about the preservation strategies that will or will not be employed against certain files. Organizational policy may be to reject the object or to investigate the feasibility of dealing with it, or the decision may depend on other factors, such as who offered the object or what information it contains.

A trusted digital repository cannot simply say what it will do; it must demonstrate its policies, practices, and procedures. This documentation should be explicit, comprehensive, current, and available. For a detailed discussion of preservation planning, as well as examples of demonstrable policies, procedures, and practices required, see Appendix 5: Preservation Planning & Strategies.

-- MarkConrad - 29 Nov 2007 Why is the phrase "or archiving system" added to this requirement and several of its sub-requirements?

B3.1 Repository has documented preservation strategies.

A repository or archiving system must have current, sound, and documented preservation strategies. These will typically address the degradation of storage media, the obsolescence of media drives, and the obsolescence of Representation Information (including formats), safeguards against accidental or intentional digital corruption. For example, if migration is the chosen approach to some of these issues, there also needs to be policy on what triggers a migration and what types of migration are expected for the solution of each preservation issue identified.

Evidence: Documentation identifying each preservation issue and the strategy for dealing with that issue.

B3.2 Repository has mechanisms in place for monitoring and notification when Representation Information (including formats) approaches obsolescence or is no longer viable.

For most repositories, the concern will be with the Representation Information (including formats) used to preserve information, which may include information on how to deal with a file format or software that can be used to render or process it. Sometimes the format needs to change because the repository can no longer deal with it. Sometimes the format is retained and the information about what software is needed to process it needs to change. In all cases, the repository must show that it has some active mechanism to warn of impending obsolescence. Obsolescence is determined largely in terms of the knowledge base of the designated community(ies). This requirement ensures that the preserved information remains understandable and usable by the designated community(ies). If the mechanism depends on an external registry, the repository must demonstrate how it uses the information from that registry.

Evidence: Subscription to a format registry service; subscription to a technology watch service; percentage of at least one staff member dedicated to monitoring technological obsolescence issues and practices of the designated community.

DavidGiaretta - I suggest we add here the phrase "for the Designated Community" because that concept was introduced in order to allow these sort of evaluations to be made with reference to something which can be specified rather than be left to be open and general.

B3.3 Repository has mechanisms to change its preservation plans as a result of its monitoring activities.

The repository must demonstrate or describe how it reacts to information from monitoring, which sometimes requires a repository to change how it deals with the material it holds in unexpected ways in ways that could not have been anticipated at an earlier stage. Plans as simple as migrating from format X to format Y when the registries show that format X is no longer supported are not sufficiently flexible—other events may have made format Y a bad choice. The repository must be prepared for changes in the external environment that may make its current plan (to migrate from X to Y in 10 years) a bad choice as the time to implement draws near. The repository should be able to show that it can revise long-range plans in light of changing circumstances.

Another possible response to information gathered by monitoring is for the repository to create additional Representation Information and/or PDI.

Evidence: Preservation planning policies tied to formal or information technology watch(es); preservation planning or processes that are timed to shorter intervals (e.g., not more than five years); proof of frequent preservation planning/policy updates.

B3.4 Repository can provide evidence of the effectiveness of its preservation planningactivities.

DavidGiaretta - perhaps this would be clearer if it said "...effectiveness of its preservation activities" - DONE

• KatiaThomaz - I agree with David.

The repository should be able to demonstrate the continued preservation, including understandability, of its holdings over a number of years, given the age of the repository and its holdings.

This could be evaluated at a number of degrees and depends on the specificity of the designated community(ies). If a designated community is fairly broad, an auditor could represent the test subject in the evaluation. More specific designated communities could require significant efforts. If judgment must be exercised as to whether adequate efforts have been made, it must be justified in detail.

Evidence: Collection of appropriate preservation metadata; proof of usability of randomly selected digital objects held within the system; demonstrable track record for retaining usable digital objects over time.

B4. Archival storage & preservation/maintenance of AIPs

There is a minimal set of conditions for performing long-term preservation of AIPs. The system infrastructure (discussed in C1) must provide suitable services to allow higher-level repository (object management) functions operating on AIPs to perform their tasks reliably. But if the higher-level functions do not use these services, or do not use them properly, then preservation is not assured. The preservation of AIPs must follow the documented preservation strategies, typically including such topics as the use of migration, transformations, checksums, multiple copies, distributed storage, and tracking of processing history that might affect preservation confidence.

B4.1. Repository employs documented preservation strategies.

Documented preservation strategies include evidence of planning for strategies not yet employed against the repository’s digital objects. A repository is likely to employ multiple strategies. Different strategies may be employed by class (type) of digital object, and/or multiple strategies may be employed on a single object class. This will depend upon local repository policies and practices, though any such strategy decisions should be documented and should be based on sound community practice.

Minimally, documentation of preservation strategies must be included in repository policies and practices. Good repository practice also requires that preservation strategies employed against digital objects are recorded in the object’s preservation metadata. (See also B3.3.)

Evidence: Documentation of strategies and their appropriateness to repository objects; evidence of application (e.g., in preservation metadata); see B3.3.

B4.2. Repository implements/responds to strategies for archival object (i.e., AIP) storage and migration.

At least two aspects of the strategy must be acted upon: that which pertains to how AIPs are currently stored (including physical requirements, media requirements, location of copies, formats and metadata) and that which may require AIP migration of any form. For example, AIP migrations that result in transformations of content need to be tracked to allow subsequent users to understand the repository’s processing implications.

If a repository has not yet needed to carry out any sort of preservation strategy on AIP(s), it must demonstrate that its policy has not required it yet.

Evidence: Institutional technology and standards watch; demonstration of objects on which a preservation strategy has been performed; demonstration of appropriate preservation metadata for digital objects.

B4.3 Repository preserves the Content Information of archival objects (i.e., AIPs).

The repository must be able to demonstrate that the AIPs faithfully reflect what was captured during ingest and that any subsequent or future planned transformations will continue to preserve that aspect of the repository’s holdings.

One approach to this requirement assumes that the repository has a policy specifying that AIPs cannot be deleted at any time. This particularly simple and robust implementation preserves links between what was originally ingested, as well as new versions that have been transformed or changed in any way. Depending upon implementation, these newer objects may be completely new AIPs or merely updated AIPs. Either way, persistent links between the ingested object and the AIP should be maintained.

Evidence: Policy documents specifying treatment of AIPs and whether they may ever be deleted; ability to demonstrate the chain of AIPs for any particular digital object or group of objects ingested; workflow procedure documentation.

B4.4 Repository actively monitors integrity of archival objects (i.e., AIPs).

In OAIS terminology, this means that the repository must have Fixity Information for AIPs and must make some use of it. At present, most repositories deal with this at the level of individual information objects by using a checksum of some form, such as MD5. In this case, the repository must be able to demonstrate that the Fixity Information (checksums, and the information that ties them to AIPs) are stored separately or protected separately from the AIPs themselves, so that someone who can maliciously alter an AIP would not likely be able to alter the Fixity Information as well. A repository should have logs that show this check being applied and an explanation of how the two classes of information are kept separate.

AIP integrity also needs to be monitored at a higher level, ensuring that all AIPs that should exist actually do exist, and that the repository does not possess AIPs it is not meant to. Checksum information alone will not be able to demonstrate this.

Evidence: Logs of fixity checks (e.g., checksums); documentation of how AIPs and Fixity information are kept separate.

-- KatiaThomaz - 10 May 2007 - It lacks “repository actively monitors authenticity, storage and readability of archival objects” (see NESTOR CCTDR 7.2, 10.3).

-- KatiaThomaz - 17 Sep 2007 - Remember the archival object context (technological, administrative, ambiental etc.) can change and so the authenticity, storage and readability

-- KatiaThomaz - 24 Sep 2007 - B1.3 states "Repository has mechanisms to authenticate the source of all materials". After this repository only monitors the integrity, ok?

-- KatiaThomaz - 24 Sep 2007 - I insist that "preserve physical presence" is necessary. I think Bullock's nine actions can help us to cover all the issues, they are: I - Fixing the object as a discrete whole; II – Preserving the physical presence; III - Preserving the content; IV - Preserving the presentation; V - Preserving the functionality; VI - Preserving the authenticity; VII - Locating and referring to the original object over time; VIII - Preserving provenance; and IX - Preserving context. [Bullock, A. (1999). Preservation of digital information: Issues and current status. Ottawa: National Library of Canada. Retrieved November 25, 2003, from http://www.nlc-bnc.ca/publications/1/p1-259-e.html]

B4.5 Repository has contemporaneous records of actions and administration processes that are relevant to preservation (Archival Storage).

These records must be created on or about the time of the actions they refer to and are related to actions associated with archival storage. The records may be automated or may be written by individuals, depending on the nature of the actions described. Where community or international standards are used, such as PREMIS (2005), the repository must demonstrate that all relevant actions are carried through. Evidence: Written documentation of decisions and/or action taken; preservation metadata logged, stored, and linked to pertinent digital objects.

B5. Information management

A critical component of any repository is its information management functionality. Regardless of technical composition and regardless of whether it is considered a “light” repository or a “dark” one— holding material for access by future generations—the system needs to be able to store, track and use metadata which supports the core functionality of the digital repository. The OAIS (2002) describes this functionality within Data Management, but, practically, this information is critical to and is generated within other digital repository functions such as ingest, archival storage, preservation planning, and access. For that reason, this section, Information Management, addresses the remaining needs associated with descriptive metadata.

Regardless of system, descriptive information (metadata) will be acquired and maintained for access and retrieval. If people cannot find what they want, the repository is not serving the needs of its users. The minimum metadata requirements for data management may be very basic. In most cases, the minimum requirement for discovery may be nothing more than an identifier a designated community uses to request a deposited object, such as a catalog number or an archival reference. People also need to know whether they are permitted to get a usable copy of it and how.

A repository’s minimum descriptive metadata requirements must match the minimum needs of the repository’s designated community(ies). This does not mean the repository needs to be able to respond to every one of its users’ requests for additional catalog information. Rather, it must assess what it can provide to a representative member of its designated community(ies), based on utility and cost. If the repository serves multiple communities, each interested in different segments of its holdings, then the minimum requirements may vary from AIP to AIP. If a repository holds both digital films and digital music, the minimum descriptive elements for film and music will differ.

Descriptive information can include much more than the narrative description that might be familiar to the user of a traditional library or archive catalog. It may also include any information that the potential user may find helpful in assessing the appropriateness and ease of use of an object, including indications of types of tools needed for use. If a repository’s holdings vary greatly in size and the larger objects are not suitable for downloading over a network connection, for instance, information about size enables a user to choose an optimum delivery method, such as a tape to be delivered by mail. Or a repository’s holdings may require special software to be available to the user to allow an object to be interpreted. Users must be able to determine this in advance, rather than possibly paying to acquire material only to discover that they do not have the tools to use it.

A repository can address this need in the more general information it makes available to its users, rather than placing specific information in the descriptive information for each AIP. For instance, a repository that holds only PDF files can:

• State in the information for each AIP that it is a PDF file.
• Have general information on how to use the repository that states that you will need a PDF reader to use its holdings.
• Define its designated community(ies) as people with access to a PDF reader.

It is the repository’s job to ensure that each and every stored object has descriptive information associated with it. This audit checklist does not specify how the repository does this, only that it must be clear how it is done. The repository may shift the burden entirely to the producers of information by requiring that say that material offered to the repository must contain a minimum amount of metadata to enable storage of descriptive information. The repository may take on the task of producing the information itself. Or it may fill in the gaps in what producers provide—using their metadata when it is sufficient, and adding metadata when it is not. Whichever the repository does, it must set out in advance the minimum metadata requirements that enable material to be discovered and identified again.

-- KatiaThomaz - 10 May 2007 - New item for “repository captures or creates minimum packaging metadata and ensures that it is associated with the archived object (i.e., AIP)” (see OAIS RM).

• DavidGiaretta - I would have thought that this is implied by the AIP definition, but it may be a good idea to state this point explicitly.
  • KatiaThomaz - Now, I dont´t know if they mean descriptive metadata = packaging information + descriptive information, but I think it must be clear.

-- JohnGarrett - 17 Sep 2007 - Standards often have specific understandings that use of certain verbs (must, shall, may, etc.) introduce requirements or make actions suggested or optional. Do we intend to create requirements or make some actions optional in these introductions to sections? I don't think we do, but when we get to a standards document we probably need to mention that in "How to read document" section.

B5.1 Repository articulates minimum metadata requirements to enable the designated community to discover and identify material of interest.

DavidGiaretta - at several places there is a mention of "...minimum xxx...". Would it be clearer if instead we said "...at least minimum xxx...", otherwise in principle these metrics could be mis-interpreted!

• KatiaThomaz - I agree with David. It must be clear.
• JohnGarrett - I actually think we should drop word minimum. In any case it is only minimum in the sense that it is the minimum amount that the community is willing to accept.

-- JohnGarrett - 17 Sep 2007 - Should we break this into 2 items - one enabling identification and another enabling discovery?

-- BarbaraSierman - 24 Sep 2007 I think this is a good suggestion, as these are two different things.

-- KatiaThomaz - 24 Sep 2007 - I think we shouldn't break into two items. One relates to another.

Retrieval metadata is distinct from metadata that describes what has been found. For example, in a library we might say that a book’s title is mandatory, but its publisher is not, because people generally search on the title.

A repository does not necessarily have to satisfy every possible request, but must be able to deal with the types of request that will come from a typical user from the designated community(ies). The minimum requirements must be articulated. The minimum may be nothing more than an identifier the designated community(ies) would know and use to request a deposited object.

Evidence: Policy regarding minimum Descriptive metadata; persistent identifier/locator associated with AIP. -- BarbaraSierman - 24 Sep 2007 The evidence documents should be available for different kind of objects, as the set of descriptive metadata may be different for various kinds of objects (journals, audio, film, art etc.). Is it already possible to suggest which kind of persistent identifier is used in certain "designated communities"?

B5.2 Repository captures or creates minimum descriptive metadata and ensures that it is associated with the archived object (i.e., AIP).

The repository has to show how it gets its required metadata. Does it require the producers to provide it (refusing a deposit that lacks it) or does it supply some metadata itself during ingest?

Associating the metadata with the object is important, though it does not require a one-to-one correspondence, and metadata need not necessarily be stored with the AIP. Hierarchical schemes of description allow some descriptive elements to be associated with many items. The association should be unbreakable—it must never be lost even if other associations are created.

Evidence: Descriptive metadata; persistent identifier/locator associated with AIP; system documentation and technical architecture; depositor agreements; metadata policy documentation, incorporating details of metadata requirements and a statement describing where responsibility for its procurement falls; process workflow documentation.

B5.3 Repository can demonstrate that referential integrity is created between all archived objects (i.e., AIPs) and associated descriptive information.

Every AIP must have some descriptive information and all descriptive information must point tobe associated with at least one AIP, such that the integrity of the reference can be validated. This should be an easy requirement to satisfy and is a prerequisite for the next one.

-- JohnGarrett - 17 Sep 2007 - Isn't it possible to create descriptive information before the AIPs are in the archive? Or create a descriptive scheme with enumerated values of some parameters where there are not yet AIPs in the archive with those values? -- BarbaraSierman - 24 Sep 2007 Should not the term "all descriptive information" be more precise, as in B5.2 it is stated that the place of the descriptive metadata where they are stored, is not defined but up to the repository. It can be in a library catalogue with other descriptive metadata of other kinds of (non-digital) material. So it should say something like the descriptive metadata related to the objects stored.

Evidence: Descriptive metadata; persistent identifier/locator associated with AIP; documented relationship between AIP and metadata; system documentation and technical architecture; process workflow documentation.

B5.4 Repository can demonstrate that referential integrity is maintained between all archived objects (i.e., AIPs) and associated descriptive information.

Particular attention must be paid to operations that affect AIPs and their identifiers and how integrity is maintained during these operations. There may be times, depending on system design, when the repository cannot demonstrate referential integrity because some system component is out of action. However, repositories, must implement procedures that let them know when referential integrity is temporarily broken and ensure that it can be restored.

Evidence: Log detailing ongoing monitoring/checking of referential integrity, especially following repair/modification of AIP; legacy descriptive metadata; persistence of identifier/locator; documented relationship between AIP and metadata; system documentation and technical architecture; process workflow documentation.

MarkConrad - 22 May 2007 Do these items adequately cover the referential integrity of an AIC to the corresponding AIPs?

• DavidGiaretta - B2.11 refers to the completeness of an AIP (which includes AICs and AIUs) but perhaps we are missing something about the continued integrity of the collection. IN fact there is also an issue to do with an expanding collection -= how does one demonstrate completeness at any point?

-- JohnGarrett - 17 Sep 2007 - Is there a need to add checklist items for restricted access to and security of descriptive metadata?

B6. Access management

It must be understood that the capabilities and sophistication of the access system will vary depending on the repository’s designated community(ies) and the access mandates of the repository. Because of the variety of repositories, archives, and access mandates, these criteria may be subject to questions about applicability and interpretation at a local level. For in-depth discussion of access management issues, see Appendix 6: Understanding Digital Repositories & Access Functionality.

Repositories with a mandate to provide current access must be able to produce Dissemination Information Packages (DIPs) that meet the needs of their users or are appropriate to the levels of access they offer. “Dark” archives or national archives that may have mandates restricting access for a certain number of years will produce most DIPs for internal requirements, such as performing migrations, rather than for access. In any case, any repository must be able to produce a DIP, however primitive and whatever its purpose.

These requirements ensure that access is implemented according to the repository’s stated policies:

• B6.1 to B6.4 are primarily concerned with access conditions and actions related to the designated community(ies);
• B6.5 and B6.6 are primarily concerned with access security, with a focus on internal (staff) access;
• B6.7 to B6.9 ensure that the access function is implemented correctly. Access should always deliver what is required, or else make clear that it is not possible for whatever reason. Timeliness may be measured in seconds or weeks, since access may be an online function or a postal function or may be mediated through some other mechanism or a combination of them.
• B6.10 adds a specific requirement over and above the need to simply provide access to a repository’s holdings. For the repository to be trusted, it must be able to provide a copy of material that can be traced back to originals.

-- KatiaThomaz - 10 May 2007 - New item for “repository ensures access to digital objects by its designated community” (see NESTOR CCTDR 2.1)
-- MarkConrad - 28 Sep 2007 This is covered by B. 6.1. -- DavidGiaretta - 01 Oct 2007 B 6.1 allows the possibility that the Designated COmmunity does not actually have access e.g. data which is currently secret right now, therefore there is no access, but it will become available in a few years and should be understandable then.

-- KatiaThomaz - 10 May 2007 - New item for “repository defines its DIPs” (see NESTOR CCTDR 11.1)
-- MarkConrad - 28 Sep 2007 This is at least partially covered by B. 6.8.

-- KatiaThomaz - 10 May 2007 - New item for “repository ensures transformation of AIPs into DIPs” (see NESTOR CCTDR 11.2).

• An issue which several colleagues have spoken about is that of being able to demonstrate authenticity of the information. Perhaps when we speak about transfomrations we need to be clear that one should be able, if requested, to follow e.g. an audit trail in order to demonstrate authenticity.

-- MarkConrad - 28 Sep 2007 This is already covered in B. 6.10!

B6.1 Repository documents and communicates to its designated community what access and delivery options are available.

Repository policies should document the various aspects of access to and delivery of the preserved information. Generally, the designated community(ies) should know the policies or at least the consequences of them. The users should know what they can ask for, when, and how, and what it costs, among other things. See Appendix 6: Understanding Digital Repositories & Access Functionality for an in-depth review of digital repository access requirements.

Repositories might have to deal with a single, homogeneous community or with multiple or disparate communities. Different policies might be needed for different communities as well as for different collection types.

Evidence: Public Versions of access policies available to various designated communities; delivery policies; fee policies.

B6.2 Repository has implemented a policy for recording all access actions (includes requests, orders etc.) that meet the requirements of the repository and information producers/depositors.

A repository need only record the actions that meet the requirements of the repository and its information producers/depositors. This may mean that little or no information is recorded about access. That is acceptable if the repository can demonstrate that it does not need to do more. Some repositories may want information about what is being accessed, but not about the users. Others may need much more detailed information about access. A policy should be established and implemented that relates to demonstrable needs. Are these figures being monitored? Are statistics produced and made available?

Evidence: Access policies; use statements; access logs.

B6.3 Repository ensures that agreements applicable to access conditions are adhered to.

The repository must be able to show what producer/depositor agreements apply to which AIPs and must validate user identities in order to ensure that the agreements are satisfied. Although it is easy to focus on denying access when considering conditions of this kind (that is, preventing unauthorized people from seeing material), it is just as important to show that access is granted when the conditions say it should be.

Access conditions are often just about who is allowed to see things (including both data and metadata items), but they can be more complex. They may involve limits on quantities—all members of a certain community are permitted to access 10 items a year without charge, for instance. Or they may involve limits on usage or type of access—some items may be viewed but not saved for later reuse, or items may only be used for private research but not commercial gain, for instance.

Various scenarios may help illustrate what is required:

If a repository’s material is all open access, the repository can simply demonstrate that access is truly available to everyone.

If all material in the repository is available to a single, closed community, the repository must demonstrate that it validates that users are members of this community, perhaps by requesting some proof of identity before registering them, or just by restricting access by network addresses if the community can identified in that manner. It should also demonstrate that all members of the community can indeed gain access if they wish.

If different access conditions apply to different AIPs, the repository must demonstrate how these are realized.

If access conditions require users to make some declaration before receiving DIPs, the repository must show that the declarations have been made. These might be signed forms, or evidence that a statement has been viewed online and a button clicked to signify agreement. The declarations might involve nondisclosure or agreement to no commercial use, for instance.

Evidence: Access policies; logs of user access and user denials; access system mechanisms that prevent unauthorized actions (such as save, print, etc.); user compliance agreements.

B6.4 Repository has documented and implemented access policies (authorization rules, authentication requirements) consistent with deposit agreements for stored objects.

User credentials are only likely to be relevant for repositories that serve specific communities or that have access restrictions on some of their holdings. A user credential may be as simple as the IP address from which a request originates, or may be a username and password, or may be some more complex and secure mechanism. Thus, while this requirement may not apply to some repositories, it may require very formal validation for others. The key thing is that the access and delivery policies are reflected in practice and that the level of validation is appropriate to the risks of getting validation wrong. Some of the requirements may emerge from agreements with producers/depositors and some from legal requirements.

Repository staff will also need to access stored objects occasionally, whether to complete ingest functions, perform maintenance functions such as verification and migration, or produce DIPs. The repository must have policies and mechanisms to protect stored objects against deliberate or accidental damage by staff (see C3.3).

Evidence: Access validation mechanisms within system; documentation of authentication and validation procedures.

B6.5 Repository access management system fully implements access policy.

The repository must demonstrate that all access policies are implemented. Access may be managed partly by computers and partly by humans—checking passports, for instance, before issuing a user ID and password may be an appropriate part of access management for some institutions.

Evidence: Logs and audit trails of access requests; information about user capabilities (authentication matrices); explicit tests of some types of access.

B6.6 Repository logs all access management failures, and staff review inappropriate “access denial” incidents.

A repository should have some automated mechanism to note anomalous or unusual denials and use them to identify either security threats or failures in the access management system, such as valid users being denied access. This does not mean looking at every denied access. This requirement does not apply to repositories with unrestricted access.

Evidence: Access logs; capability of system to use automated analysis/monitoring tools and generate problem/error messages; notes of reviews undertaken or action taken as result of reviews.

B6.7 Repository can demonstrate that the process that generates the requested digital object(s) (i.e., DIP) is completed in relation to the request.

If a user expects a set, the user should get the whole set. If the user expects a file, the user should get the whole file. If the user’s request cannot be satisfied, the user should be told this; for instance, resource shortages may mean a valid request cannot be satisfied. Acceptable scenarios include:

The user receives the complete DIP asked for and it is clear to the user that this has happened.

The user is told that the request cannot be satisfied. Part of the request cannot be satisfied, the user receives a DIP containing the elements that can be provided, and the system makes clear that the request is only partially satisfied.

Unacceptable scenarios include:

The request can only be partially satisfied and a partial DIP is generated, but it is not clear to the user that it is partial.

The request is delayed indefinitely because something it requires, such as access to a particular AIP, is not available, but the user is not notified nor is there any indication as to when the conflict will be resolved.

The user is told the request cannot be satisfied, implying nothing can be delivered, but actually receives a DIP, and is left unsure of its validity or completeness.

Evidence: System design documents; work instructions (if DIPs involve manual processing); process walkthroughs; logs of orders and DIP production; test accesses to verify delivery of appropriate digital objects.

B6.8 Repository can demonstrate that the process that generates the requested digital object(s) (i.e., DIP) is correct in relation to the request.

The right material should be delivered and appropriate transformations should be applied, if necessary to generate the DIP. A simple example is that if the repository stores TIFF images but delivers JPEGS, the conversion should be shown to be correct to whatever standards seem appropriate. If the repository offers delivery as JPEG or PNG, the user should receive the format requested. Many repositories may apply more complex transformations to generate DIPs from AIPs.

Evidence: System design documents; work instructions (if DIPs involve manual processing); process walkthroughs; logs of orders and DIP production.

B6.9 Repository demonstrates that all access requests result in a response of acceptance or rejection.

Eventually a request must succeed or fail, and there must be limits on how long it takes for the user to know this. Access logs are the simplest way to demonstrate response time, even if the repository does not retain this information for long. However, a repository can demonstrate compliance if it can show that all failed requests result in an error log of some sort, and that requests are bounded in duration in some way.

Evidence: System design documents; work instructions (if DIPs involve manual processing); process walkthroughs; logs of orders and DIP production.

B6.10 Repository enables the dissemination of authentic copies of the original or objects traceable to originals.

Part of trusted archival management deals with the authenticity of the objects that are disseminated. A repository’s users must be confident that they have an authentic copy of the original object, or that it is traceable in some auditable way to the original object. This distinction is made because objects are not always disseminated in the same way, or in the same groupings, as they are deposited. A database may have subsets of its rows, columns, and tables disseminated so that the phrase “authentic copy” has little meaning. Ingest and preservation actions may change the formats of files, or may group and split the original objects deposited.

The distinction between authentic copies and traceable objects can also be important when transformation processes are applied. For instance, a repository that stores digital audio from radio broadcasts may disseminate derived text that is constructed by automated voice recognition from the digital audio stream. Derived text may be imperfect but useful to many users, though these texts are not authentic copies of the original audio. Producing an authentic copy means either handing out the original audio stream or getting a human to verify and correct the transcript against the stored audio.

This requirement ensures that ingest, preservation, and transformation actions do not lose information that would support an auditable trail between the original deposited object and the eventual disseminated object. For compliance, the chain of authenticity need only reach as far back as ingest, though some communities, such as those dealing with legal records, may require chains of authenticity that reach back further.

A repository should be able to demonstrate the processes to construct the DIP from the relevant AIP(s). This is a key part of establishing that DIPs reflect the content of AIPs, and hence of original material, in a trustworthy and consistent fashion. DIPs may simply be a copy of AIPs, or may result from a simple format transformation of an AIP. But in other cases, they may be derived in complex ways from a large set of AIPs. A user may request a DIP consisting of the title pages from all e-books published in a given period, for instance, which will require these to be extracted from many different AIPs. A repository that allows requests for such complex DIPs will need to put more effort into demonstrating how it meets this requirement than a repository that only allows requests for DIPs that correspond to an entire AIP.

A repository is not required to show that every DIP it provides can be verified as authentic at a later date; it must show that it can do this when it is required at the time of production of the DIP. The level of authentication is to be determined by the designated community(ies). This requirement is meant to enable high levels of authentication, not to impose it on all copies, since it may be an expensive process.

Evidence: System design documents; work instructions (if DIPs involve manual processing); process walkthroughs; production of a sample authenticated copy; documentation of community requirements for authentication.

-- KatiaThomaz - 10 May 2007 -- DonaldSawyer - 20 Jun 2007 -- SimonLambert - 21 Jun 2007

Technologies Technical Infrastructure and Security

DavidGiaretta - I assume that somewhere here we should state that these metrics are designed to be compatible with ISO 27001. ChrisRusbridge - 18 Jul 2007 - Are they? Not absolutely clear to me!

C1. System infrastructure

Without a secure and trusted [ChrisRusbridge - 18 Jul 2007 - trustworthy?] infrastructure, the functions carried out on AIPs cannot be trusted—they are built on a house of cards. Actions specified here are general enough to apply to systems other than repositories and archives.

ChrisRusbridge - 18 Jul 2007 - We might want to avoid the "trusted" word; don't want to get into Orange Book territory!

-- KatiaThomaz - 10 May 2007 - New item for “the IT infrastructure implements a procedure for documentation”; (see NESTOR CCTDR 5.2)

-- KatiaThomaz - 10 May 2007 - New item for “the IT infrastructure implements the object management demands”; (see NESTOR CCTDR 13.1)

-- KatiaThomaz - 10 May 2007 - New item for “the IT infrastructure monitors performance and service level”; (see DCC/DPE DRAMBORA R78).

MarkConrad - 24 May 2007 The repository system should be scalable. That is, it must be able to handle anticpated future volume (bytes and number of files) without a major disruption of the system.

MarkConrad - 24 May 2007 The repository system should be evolvable. That is, the system must be designed in such a way that major components of the system can be replaced with newer technologies without major disruption of the system as a whole.

MarkConrad - 24 May 2007 The repository system should be extensible. That is, the system should be designed to accomdate future formats (media and files) without major disruption of the system as a whole.

ChrisRusbridge - 18 Jul 2007 - I worry about the next two sections, C1.1 and C1.2 (and in fact much of this whole chapter). Aren't they really saying "This should be a really well-managed IT operation"? This could perhaps be better accomplished partly by referring to something like ITIL V3, or ISO 20000... I worry because these sections select out two specific parts of a well-managed IT operation, but ignore the rest. We could try to add lots more parts, but then we would end up attempting to duplicate (and worse, to keep up to date), these other standards. Just like OAIS Chapter 5 (I think it is!), we may be better off saying very little than making a hash of saying a few selective things. What I DO think we should say is anything that is significantly ABOVE the normal requirements for a well-managed IT operation.

C1.1 Repository functions on well supported operating systems and other core infrastructural software.

The requirement specifies “well-supported” as opposed to manufacturer-supported or other similar phrases. The level of support for these elements of the infrastructure must be appropriate to their uses; the repository must show that it understands where the risks lie. The degree of support required relates to the criticality of the subsystem involved. A repository may deliberately have an old system using out-of-date software to support some aspects of its ingest function. If this system fails, it may take some time to replace it, if it can be replaced at all. As long as its failure does not affect mission-critical functions, this is acceptable. Systems used for internal development may not be protected or supported to the same level as those for end-user service.

MarkConrad - 22 May 2007 - I do not understand the last 4 sentences of the paragraph above. Isn't the ingest function usually a mission-critical function?

ChrisRusbridge - 18 Jul 2007 - Mark, I assume that under the circumstances envisaged, this only applies to part of the ingest flow, ie specific older material, and so if the obsolete OS fails for a while that is not too critical!

Evidence: Software inventory; system documentation; support contracts; use of strongly community supported software (i.e., Apache).

MarkConrad - 22 May 2007 Should the above read (e.g., Apache) or is the document prescribing the use of Apache software? ChrisRusbridge - 18 Jul 2007 - Agreed re "eg".

MarkConrad - 22 May 2007 I believe that the Evidence: should include periodic market analyses.

C1.2 Repository ensures that it has adequate hardware and software support for backup functionality sufficient for the repository’s services and for the data held, e.g., metadata associated with access controls, repository main content.

The repository needs to be able to demonstrate the adequacy of the processes, hardware and software for its backup systems. Some will need much more elaborate backup plans than others.

Evidence: 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; “firedrills”—testing of backups; support contracts for hardware and software for backup mechanisms.

MarkConrad - 23 May 2007 I believe that we need a clear statement that backup alone is not sufficient for long term preservation.

MarkConrad - 23 May 2007 Do we also need a pointer to C3.4?

C1.3 Repository manages the number and location of copies of all digital objects.

The repository system must be able to identify the number of copies of all stored digital objects, and the location of each object and their copies. This applies to what are intended to be identical copies, not versions of objects or copies.

ChrisRusbridge - 18 Jul 2007 - Presumably this is OK on the aggregate, does not have to be per item! But if so, with the exception of Mark's next point, isn't it trivial for a well-managed IT operation? If you don't know where your backups and mirrors are, you are in trouble! Then again, does this require that you have to know at all times where every single digital copy of every object is? Because that is not possible! MarkConrad - 10 Sep 2007 This is not impossible. In fact it is necessary if we are going to be able to assert that we are providing an authentic copy of a particular digital object.

MarkConrad - 23 May 2007 Somewhere in this document we need an explicit statement that the repository must be able to distinquish between versions of objects or copies and identical copies so that a repository can assert that it is providing an authentic copy of the correct version of an object. ChrisRusbridge - 18 Jul 2007 - Agreed; version management is critical, although it should presumably be part of provenance management...

The location must be described such that the object can be located precisely, without ambiguity. It can be an absolute physical location or a logical location within a storage media or a storage subsystem. One way to test this would be to look at a particular object and ask how many copies there are, what they are stored on, and where they are.

MarkConrad - 23 May 2007 This test would be incomplete without retrieving all of the copies of the object and comparing them to ensure that they are identical copies. ChrisRusbridge - 18 Jul 2007 - Wouldn't a sample be enough?

A repository can have different policies for different classes of objects, depending on factors such as the producer, the information type, or its value. Some repositories may have only one copy (excluding backups) of everything, stored in one place, though this is definitely not recommended. There may be additional identification requirements if the data integrity mechanisms use alternative copies to replace failed copies.

ChrisRusbridge - 18 Jul 2007 - Surely the point is that a repository should have a policy!

Evidence: random retrieval tests; system test; location register/log of digital objects compared to the expected number and location of copies of particular objects.

MarkConrad - 23 May 2007 What is meant by system test?

MarkConrad - 23 May 2007 In the first paragraph of this item a distinction is made between a version or copy of an object and an identical copy of the object. Do we need to make that distinction here?

C1.4 Repository has mechanisms in place to ensure any/multiple copies of digital objects are synchronized.

If multiple copies exist, there has to be some way to ensure that intentional changes to an object are propagated to all copies of the object. There must be an element of timeliness to this. It must be possible to know when the synchronization has completed, and ideally to have some estimate beforehand as to how long it will take. Depending whether it is automated or requires manual action (such as the retrieval of copies from off-site storage), the time involved may be seconds or weeks. The duration itself is immaterial—what is important is that there is understanding of how long it will take.

MarkConrad - 23 May 2007 I would suggest changing the word intentional in the first sentence to authorized. You do not want the repository to replicate an unauthorized, but intentional change to a digital object. This could potentially result in the destruction of all authentic copies of the digital object in the repository.

ChrisRusbridge - 18 Jul 2007 - I think the paragraph above is either confusing or wrong. We need to be able to make changes to digital objects, but we will also want to preserve un-changed versions. The paragraph should really be replaced with something relating to provenance tracking of changes.

There must also be something that addresses what happens while the synchronization is in progress. This has an impact on disaster recovery: what happens if a disaster and an update coincide? If one copy of an object is altered and a disaster occurs while other copies are being updated, it is essential to be able to ensure later that the update is successfully propagated.

Evidence: Workflows; system analysis of how long it takes for copies to synchronize; procedures/documentation of operating procedures related to updates and copy synchronization; procedures/documentation related to whether changes lead to the creation of new copies and how those copies are propagated and/or linked to previous versions.

C1.5 Repository has effective mechanisms to detect bit corruption or loss.

The repository must detect data loss accurately to ensure that any losses fall within the tolerances established by policy (see A3.6). Data losses must be detected and detectable regardless of the source of the loss. This applies to all forms and scope of data corruption, including missing objects and corrupt or incorrect or imposter objects, corruption within an object, and copying errors during data migration or synchronization of copies. Ideally, the repository will demonstrate that it has all the AIPs it is supposed to have and no others, and that they and their metadata are uncorrupted.

MarkConrad - 24 May 2007 I do not understand what is being referenced at A3.6.

The approach must be documented and justified and include mechanisms for mitigating such common hazards as hardware failure, human error, and malicious action. Repositories that use well-recognized mechanisms such as MD5 signatures need only recognize their effectiveness and role within the overall approach. But to the extent the repository relies on homegrown schemes, it must provide convincing justification that data loss and corruption are detected within the tolerances established by policy.

ChrisRusbridge - 18 Jul 2007 - It's not enough to use MD5 signatures etc; you would have to have a trustable system for managing the MD5 signatures separately from the data files, so that deliberate attack on one cannot be accompanied by deliberate attack on the other. Isn't this really authenticity management?

Data losses must be detected promptly enough that routine systemic sources of failure, such as hardware failures, are unlikely to accumulate and cause data loss beyond the tolerances established by the repository’s policy or specified in any relevant deposit agreement. For example, consider a repository that maintains a collection on identical primary and backup copies with no other data redundancy mechanism. If the media of the two copies have a measured failure rate of 1% per year and failures are independent, then there is a 0.01% chance that both copies will fail in the same year. If a repository’s policy limits loss to no more than 0.001% of the collection per year, with a goal of course of losing 0%, then the repository would need to confirm media integrity at least every 72 days to achieve an average time to recover of 36 days, or about one tenth of a year. This simplified example illustrates the kind of issues a repository should consider, but the objective is a comprehensive treatment of the sources of data loss and their realworld complexity. Any data that is (temporarily) lost should be recoverable from backups.

MarkConrad - 24 May 2007 I do not understand what is meant by, maintains a collection on identical primary and backup copies.

ChrisRusbridge - 18 Jul 2007 - Note that independence of failures is a weak assumption; a stronger assumption is to assume that many failures will be correlated, see Rosenthal et al's papers on this... and also that for extremely large datasets (eg petabytes) the prompt assertion of authenticity is problematic!

Evidence: Documents that specify bit error detection and correction mechanisms used; risk analysis; error reports; threat analyses.

C1.6 Repository reports to its administration all incidents of data corruption or loss, and steps taken to repair/replace corrupt or lost data.

Having effective mechanisms to detect bit corruption and loss within a repository system is critical, but is only one important part of a larger process. As a whole, the repository must record, report, and repair as possible all violations of data integrity. This means the system should be able to notify system administrators of any logged problems. These incidents, recovery actions, and their results must be reported to administrators and should be available.

MarkConrad - 24 May 2007 For the last sentence in the paragraph above, what should be available and to whom should it be available?

ChrisRusbridge - 18 Jul 2007 - Good management again, eh ISO 20000-2:2005 sections 8.3.5 and 8.3.6...

For example, the repository should document procedures to take when loss or corruption is detected, including standards for measuring the success of recoveries. Any actions taken to repair objects as part of these procedures must be recorded. The nature of this recording must be documented by the repository, and the information must be retrievable when required. This documentation plays a critical role in the measurement of the authenticity and integrity of the data held by the repository.

MarkConrad - 24 May 2007 For the next to last sentence in the paragraph above, what information must be retrievable? required for what purpose(s)?

Evidence: Preservation metadata (e.g., PDI) records; comparison of error logs to reports to administration; escalation procedures related to data loss.

C1.7 Repository has defined processes for storage media and/or hardware change (e.g., refreshing, migration).

The repository should have triggers for initiating action and understanding of how long it will take for storage media migration, or “refreshing”—copying between media without reformatting the bitstream. Will it finish before the media is dead, for instance? Copying large quantities of data can take a long time and can affect other system performance. It is important that the process includes a check that the copying has happened correctly. (See B4.2.)

Repositories should also consider the obsolescence of any/all hardware components within the repository system as potential trigger events for migration. Increasingly, long-term, appropriate support for system hardware components is difficult to obtain, exposing repositories to risks and liabilities should they chose to continue to operate the hardware beyond the manufacturer or third-party support.

Evidence: Documentation of processes; policies related to hardware support, maintenance, and replacement; documentation of hardware manufacturers’ expected support life cycles.

C1.8 Repository has a documented change management process that identifies changes to critical processes that potentially affect the repository’s ability to comply with its mandatory responsibilities..

Examples of this would include changes in processes in data management, access, archival storage, ingest, and security. The really important thing is to be able to know what changes were made and when they were made. Traceability makes it possible to understand what was affected by particular changes to the systems.

Evidence: Documentation of change management process; comparison of logs of actual system changes to processes versus associated analyses of their impact and criticality.

MarkConrad - 22 May 2007 I believe that this requirement is actually referring to configuration management rather than change management. There are several relevant sets of best practices/standards. For example:

ISO 10007:2003 gives guidance on the use of configuration management within an organization. It is applicable to the support of products from concept to disposal. It first outlines the responsibilities and authorities before describing the configuration management process that includes configuration management planning, configuration identification, change control, configuration status accounting and configuration audit. Since ISO 10007:2003 is a guidance document, it is not intended to be used for certification/registration purposes.

See also:

U.S. DoD - MIL-HDBK-61A

ANSI/EIA 649A, Configuration Management

IEEE Std 828-1990, IEEE Standard for Software Configuration Management Plans. This plan establishes the minimum required contents of a Software Configuration Management Plan and defines the specific activities to be addressed and their requirements for any portion of a software product's life cycle.

IEEE1042-1987, Guide to Software Configuration Management

ISO/IEC 12207-1995 "Information technology -- Software life cycle processes

ChrisRusbridge - 18 Jul 2007 - See also ISO 20000-2:2005 section 9.2.

MarkConrad - 22 May 2007 I believe we need a separate item that states, Repository has the capability to identify critical processes that affect its ability to comply with its mandatory responsibilities.

MarkConrad - 22 May 2007 I believe we need a separate item that says, Configuration Management efforts should result in a complete audit trail of decisions and design modifications.

C1.9 Repository has a process for testing the effect of critical changes to the system.

Changes to critical systems should be, where possible, pre-tested separately, the expected behaviors documented, and roll-back procedures prepared. After changes, the systems should be monitored for unexpected and unacceptable behavior. If such behavior is discovered the changes and their consequences should be reversed.

Whole-system testing or unit testing can address this requirement; complex safety-type tests are not required. Testing can be very expensive, but there should be some recognition of the fact that a completely open regime where no changes are ever evaluated or tested will have problems.

Evidence: Documented testing procedures; documentation of results from prior tests and proof of changes made as a result of tests.

MarkConrad - 22 May 2007 Again, Repository must have the capability to identify what is and is not a critical change to the system.

C1.10 Repository has a process to react to the availability of new software security updates based on a risk-benefit assessment.

Decisions to apply security updates are likely to be the outcome of a risk-benefit assessment; security patches are frequently responsible for upsetting alternative aspects of system functionality or performance. It may not be necessary for a repository to implement all software patches, and the application of any must be carefully considered. Each security update implemented by the repository must be documented with details was about how it is completed; both automated and manual updates are acceptable. Significant security updates might pertain to software other than core operating systems, such as database applications and Web servers, and these should also be documented.

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

MarkConrad - 22 May 2007 I do not believe that this item should be limited to software security updates. It should include all software updates and any updates to a hardware system's firmware. Any of these updates has the potential to affect the repository's ability to carry out its responsibilities. ChrisRusbridge - 18 Jul 2007 - Yes, it's all part of change management...

C2. Appropriate technologies

A repository should use strategies and standards relevant to its designated community(ies) and its digital technologies.

C2.1 Repository has hardware technologies appropriate to the services it provides to its designated communities and has procedures in place to receive and monitor notifications, and evaluate when hardware technology changes are needed.

The repository needs to be aware of the types of access services expected by its designated community(ies), including, where applicable, the types of media to be delivered, and needs to make sure its hardware capabilities can support these services. For example, it may need to improve its networking bandwidth over time to meet growing access data volumes and expectations.

Evidence: Technology watch; documentation of procedures; designated community profiles; user needs evaluation; hardware inventory.

-- KatiaThomaz - 10 May 2007 - It could be separated in two items: “repository has hardware technologies appropriate to the services” and “repository has procedures to receive and monitor”

MarkConrad - 24 May 2007 I agree with Katia that this should be separated into multiple items, but I think that there should be 4 items. 1. repository has hardware technologies appropriate to the services 2. repository has procedures to receive and monitor notifications 3.repository has procedures to evaluate when changes are needed 4. repository has procedures to replace hardware when evaluation indicates the need to do so.

ChrisRusbridge - 18 Jul 2007 - Not sure what notifications are in this context! Mark's 3 & 4 are surely part of change and/or configuration management

C2.2 Repository has software technologies appropriate to the services it provides to its designated community(ies) and has procedures in place to receive and monitor notifications, and evaluate when software technology changes are needed.

The repository needs to be aware of the types of access services expected by its designated community(ies), and to make sure its software capabilities can support these services. For example, it may need to add format translations to meet the needs of currently widely used application tools, or it may need to add a data subsetting service for very large data objects.

Evidence: Technology watch; documentation of procedures; designated community profiles; user needs evaluation; software inventory.

-- KatiaThomaz - 10 May 2007 - It could be separated in two items: “repository has software technologies appropriate to the services” and “repository has procedures to receive and monitor”

MarkConrad - 24 May 2007 Again, I think that this item should be split into four items in the same manner proposed for C2.1

C3. Security

“System” here refers to more than IT systems, such as servers, firewalls, or routers. Fire protection and flood detection systems are also significant, as are systems that involve actions by people. The first two requirements here are general and the third addresses internal security, while the remainder address disaster recovery.

C3.1 Repository maintains a systematic analysis of such factors as data, systems, personnel, physical plant, and security needs.

Regular risk assessment should address external threats and denial of service attacks. These analyses are likely to be documented in several different places, and need not be comprehensively contained in a single document.

Evidence: ISO 17799 certification; documentation describing analysis and risk assessments undertaken and their outputs; logs from environmental recorders; confirmation of successful staff vetting.

-- KatiaThomaz - 10 May 2007 - It lacks “repository mantains a systematic analysis of such factors as third-partie”; (see ISO27001 A.10.2).

ChrisRusbridge - 18 Jul 2007 - Better surely to say that the repository maintains adequate security protection for the task in hand, following codes of practice such as ISO 27000 etc (plus perhaps the FIPS and other equivalents), with evidence being relevant certification...

C3.2 Repository has implemented controls to adequately address each of the defined security needs.

The repository must show how it has dealt with its security requirements. If some types of material are more likely to be attacked, the repository will need to provide more protection, for instance.

Evidence: ISO 17799 certification; system control list; risk, threat, or control analyses; addition of controls based on ongoing risk detection and assessment.

C3.3 Repository staff have delineated roles, responsibilities, and authorizations related to implementing changes within the system.

Authorizations are about who can do what—who can add users, who has access to change metadata, who can get at audit logs. It is important that authorizations are justified, that staff understand what they are authorized to do, and that there is a consistent view of this across the organization.

Evidence: ISO 17799 certification; organizational chart; system authorization documentation.

C3.4 Repository has 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).

The repository must have a written plan with some approval process for what happens in specific types of disaster (fire, flood, system compromise, etc.) and for who has responsibility for actions. The level of detail in a disaster plan, and the specific risks addressed need to be appropriate to the repository’s location and service expectations. Fire is an almost universal concern, but earthquakes may not require specific planning at all locations. The disaster plan must, however, deal with unspecified situations that would have specific consequences, such as lack of access to a building.

ChrisRusbridge - 18 Jul 2007 - See also ISO 20000-2:2005 section 6.3...

Evidence: ISO 17799 certification; disaster and recovery plans; information about and proof of at least one off-site copy of preserved information; service continuity plan; documentation linking roles with activities; local geological, geographical, or meteorological data or threat assessments.

-- DavidGiaretta - 09 May 2007

-- KatiaThomaz - 10 May 2007

-- SimonLambert - 21 Jun 2007