aceability. Subsection 4.2.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 represent these relationships.
4.2.5 The repository shall have access to necessary tools and r


esources to provide
authoritative Representation Information for all of the digital objects it contains.
In particular the following aspects must be checked.
4.2.5.1 The repository shall have tools or methods to identify the file type of all
submitted Data Objects.
4.2.5.2 The repository shall have tools or methods to determine what Representation
Information is necessary to make each Data Object understandable to the Designated
Community.
4.2.5.3 The repository shall have access to the requisite Re


presentation Information.
4.2.5.4 The repository shall have tools or methods to ensure that the requisite
Representation Information is persistently associated with the relevant Data Objects.
Supporting Text
This is necessary in order to ensure that the repository’s digital objects are understandable to
the Designated Community.
Examples of Ways the Repository can Demonstrate it is Meeting these Requirements
Subscription or access to registries of Representation Information (including format
registr


ies); viewable records in local registries (with persistent links to digital objects);
database records that include Representation Information and a persistent link to relevant
digital objects.
Discussion
These tools and resources can be held internally or can be shared via, for example, a trusted
set of registries. However, this requirement does not demand that each repository has such
tools and resources, merely that it has access to them. For example a repository may access
AUDIT AND CERTIFICATIO


N OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-12
September 2011
external registries.1 Any such registry is a specialized type of repository, which itself must be
certified/trustworthy. The repository may 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. Sometimes there is bot


h general Representation
Information (e.g., format information) and specific Representation Information (e.g.,
meanings of individual fields within a dataset). Often the general information will be
available in an external repository, but the local repository may need to maintain the
instance-specific information. It is likely that many repositories would wish to keep local
copies of relevant Representation Information; however, this may not be practical in all
cases. Even where a repository strives t


o keep all such information locally there may be, for
example, a schedule of updates which means that until an update is performed, the local
Representation Information is incomplete. This may be regarded as a kind of local caching
of, for example, the Representation Information held in registries. Alternatively one may say
that in these cases, the use of international registries is not meant to replace local registries
but instead serve as a resource to verify or obtain independent, authoritative info


rmation
about any and all Representation Information. 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.
4.2.6 The repository shall have documented processes for acquiring Preservation
Description Informati


on (PDI) for its associated Content Information and acquire PDI
in accordance with the documented processes.
In particular the following aspects must be checked.
4.2.6.1 The repository shall have documented processes for acquiring PDI.
4.2.6.2 The repository shall execute its documented processes for acquiring PDI.
4.2.6.3 The repository shall ensure that the PDI is persistently associated with the
relevant Content Information.
Supporting Text
This is necessary in order to ensure that an auditable t


rail to support claims of authenticity is
available, that unauthorized changes to the digital holdings can be detected, and that the
digital objects can be identified and placed in their appropriate context.

1 The Unified Digital Formats Registry (UDFR, http://www.gdfr.info/udfr.html) and the UK
Digital Curation Centre’s Registry Repository of Representation Information (RRORI,
http://registry.dcc.ac.uk) are two emerging examples.
AUDIT AND CERTIFICATI


ON OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-13
September 2011
Examples of Ways the Repository can Demonstrate it is Meeting these Requirements
Standard operating procedures; manuals describing ingest procedures; viewable
documentation on how the repository acquires and manages Preservation Description
Information (PDI); creation of checksums or digests, consulting with Designated Community
about Context.
Discussion
PDI is needed not only by the repository to help ensure the Conte


nt 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.
4.2.7 The repository shall ensure that the Conten


t Information of the AIPs is
understandable for their Designated Community at the time of creation of the AIP.
In particular the following aspects must be checked.
4.2.7.1 Repository shall have a documented process for testing understandability for
their Designated Communities of the Content Information of the AIPs at their creation.
4.2.7.2 The repository shall execute the testing process for each class of Content
Information of the AIPs.
4.2.7.3 The repository shall bring the Content Information of


 the AIP up to the
required level of understandability if it fails the understandability testing.
Supporting Text
This is necessary in order to ensure that one of the primary tests of preservation, namely that
the digital holdings are understandable by their Designated Community, can be met. (See 4.3
for additional requirements for understandability beyond ingest.)
Examples of Ways the Repository can Demonstrate it is Meeting these Requirements
Test procedures to be run against the digital holdings t


o ensure their understandability to the
defined Designated Community; records of such tests being performed and evaluated;
evidence of gathering or identifying Representation Information to fill any intelligibility gaps
which have been found; retention of individuals with the discipline expertise.
Discussion
This requirement is concerned with the understandability of the AIP. If the ingested material
is not understandable, the repository needs to ingest or make available additional information
AUDIT


AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-14
September 2011
to make sure that the AIPs are understandable to the Designated Community(ies). For
example, if documents are written in a dying language and the Designated Community is no
longer able to understand the language the documents are written in, the repository would
need to provide additional documentation that would allow the Designated Community to
understand the documents (e.g., translations of the document


s in a language the Designated
Community could understand or dictionaries that would allow the Designated Communities
to translate the documents into a language its members understand).
4.2.8 The repository shall verify each AIP for completeness and correctness at the
point it is created.
Supporting Text
This is necessary in order to ensure that what is maintained over the long term is as it should
be and can be traced to the information provided by the Producers.
Examples of Ways the Repository Can


 Demonstrate It Is Meeting This Requirement
Description of the procedure that verifies completeness and correctness of the AIPs; logs of
the procedure.
Discussion
The repository should be sure that the AIPs it creates are as they are expected to be by
checking them against the associated definition for each AIP or class of AIP (see 4.2.1) and
the description of how AIPs are constructed from SIPs (see 4.2.2). If the repository has a
standard process to verify SIPs for both completeness and correctness


 and a demonstrably
correct process for transforming SIPs into AIPs, 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), but
they might be complex. Documentation should describe how the completeness and
correctness of AIPs is ensured, starting with 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
a


nd preservation, logs that such checks have been made, and any special tests that may be
required for a particular AIP instance or class.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-15
September 2011
4.2.9 The repository shall provide an independent mechanism for verifying the
integrity of the repository collection/content.
Supporting Text
This is necessary to enable the audit of the integrity of the collection as a whole.
Examples of Ways the Repository Can


Demonstrate It Is Meeting This Requirement
Documentation provided for 4.2.1 through 4.2.4; documented agreements negotiated between
the producer and the repository (see 4.1.1-4.1.8); logs of material received and associated
action (receipt, action, etc.) dates; logs of periodic checks.
Discussion
It is the responsibility of the repository to choose the appropriate mechanism for checking the
completeness and correctness of its collections. 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 because the e-
mail was lost before the SIP was constructed? This case could be resolved by the repository’s
amending its description of the collection, but o


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


onversely, any AIP should be able to be related to an entry in the acquisitions register.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-16
September 2011
4.2.10 The repository shall have contemporaneous records of actions and
administration processes that are relevant to AIP creation.
Supporting Text
This is necessary in order to ensure that there is omitted from the record nothing relevant that
might be needed to provide an independent means to verify that all


AIPs have been properly
created in accord with the documented procedures (see 4.2.1 through 4.2.9). It is the
responsibility of the repository to justify its practice in this respect.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Written documentation of decisions and/or action taken with timestamps; preservation
metadata logged, stored, and linked to pertinent digital objects.
Discussion
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, the repository must demonstrate that all relevant actions are
carried through.
4.3
PRESERVATION PLANNING
4.3.1  The repository shall have documented preservation strategies relevant to its
holdings.
Supporting Text
This is necessary in order that it is clear how the repository p


lans to ensure the information
will remain available and usable for future generations and to provide a means to check and
validate the preservation work of the repository.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Documentation identifying each preservation risk identified and the strategy for dealing with
that risk.
Discussion
These documented preservation strategies will describe how the repository will act upon
identified risks, as part of the preservation st


rategic plan. These preservation strategies and
the preservation strategic plan will typically address the degradation of storage media, the
obsolescence of media drives, and the obsolescence or inadequacy of Representation
Information (including formats) as the knowledge base of the Designated Community
changes, and safeguards against accidental or intentional digital corruption. For example, if
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-17
September 2011
mi


gration is the chosen approach to some of these issues, there also needs to be Preservation
Policies on what triggers a migration and what types of migration are expected to solve the
preservation risk identified. The preservation strategy will describe the range of activities
that need to be done in case of a migration.
4.3.2 The repository shall have mechanisms in place for monitoring its preservation
environment.
Supporting Text
This is necessary so that the repository can react to changes and the


reby ensure that the
preserved information remains understandable and usable by the Designated Community.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Surveys of the Designated Community of the repository.
Discussion
The repository should show that it has some active mechanism to ensure that the preserved
information remains understandable and usable by the Designated Community and that it has
mechanisms in place for monitoring and notification when Representation In


formation
(including formats) approaches obsolescence or is no longer viable. For most repositories,
the concern will be with the Representation Information 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.


 If the mechanism depends on an external
registry, the repository must demonstrate how it uses the information from that registry.
4.3.2.1 The repository shall have mechanisms in place for monitoring and notification
when Representation Information is inadequate for the Designated Community to
understand the data holdings.
Supporting Text
This is necessary in order to ensure that the preserved information remains understandable
and usable by the Designated Community.
Examples of Ways the Repository


Can Demonstrate It Is Meeting This Requirement
Subscription to a Representation Information registry service; subscription to a technology
watch service, surveys amongst its Designated Community members, relevant working
processes to deal with this information.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-18
September 2011
Discussion
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.
4.3.3 The repository shall have mechanisms to change its preservation plans as a
result of its monitoring activities.
Supporting Text
This is necessary in order for the repository to be prepared for changes in the external
environment that may make its current preservation plans a bad choice as the time to
implement draws near.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Preservation Plans tied to formal


 or informal technology watch(es); preservation planning or
processes that are timed to shorter intervals (e.g., not more than five years); proof of frequent
Preservation Policies and Preservation Plans updates; sections of Preservation Policies that
address how plans may be updated and that address how often the plans are required to be
reviewed and reaffirmed or updated.
Discussion
The repository should 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
ways that could not have been anticipated at an earlier stage. The repository should
periodically review its preservation plans and the technology environment and, if necessary,
makes changes to those plans to ensure their continued effectiveness. Another possible
response to information gathered by monitoring is for the repository to update and create
additional Representation Information and/or PDI.
4.3.3.1 The repository shall have me


chanisms for creating, identifying or gathering
any extra Representation Information required.
Supporting Text
This is necessary in order to ensure that the preserved information remains understandable
and usable by the Designated Community.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Subscription to a format registry service; subscription to a technology watch service;
preservation plans.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1


Page 4-19
September 2011
Discussion
The repository should have mechanisms in place for monitoring and notification when
Representation Information (including formats) approaches obsolescence or is no longer
viable, and it should be able to show that it has mechanisms to address such notifications.
4.3.4 The repository shall provide evidence of the effectiveness of its preservation
activities.
Supporting Text
This is necessary in order to assure the Designated Community that the repository will be


able to make the information available and usable over the mid-to-long-term.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
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; Designated Community polls.
Discussion
The repository should be able to demonstrate the continued preservation, including
understandability, of


its holdings. This could be evaluated at a number of degrees and
depends on the specificity of the Designated Community. 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.
4.4
AIP PRESERVATION
4.4.1 The repository shall have specifications for how the AIPs are stored down to the
bit level.
Supporting Text
This is necessary in order to ensure that the information can be extr


acted from the AIP over
the long-term.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Documentation of the format of AIPs; EAST and Data Entity Dictionary Specification
Language (DEDSL) descriptions of the data components (see references [B6] and [B7]).
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-20
September 2011
Discussion
The repository should specify the Representation information down to the bit level of each
AIP componen


t and must specify how the separate components are packaged together. The
Representation Information must be available for each AIP and must be appropriately linked
to the AIP. Often, repositories are tempted to describe AIP content only down to a level
where a program will then be used to convert the information to a form understandable to
their Designated Communities. However, if those programs ever fail to operate, then the
information would be lost in all the AIPs that relied on that program.
4.4.


1.1 The repository shall preserve the Content Information of AIPs.
Supporting Text
This is necessary because it is the fundamental mission of a repository to preserve the
Content Information for its Designated Communities.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Preservation workflow procedure documentation; workflow procedure documentation;
Preservation Policy documents specifying treatment of AIPs and under what circumstances
they may ever be deleted; ability


to demonstrate the sequence of conversions for an AIP for
any particular digital object or group of objects ingested; documentation linking ingested
objects and the current AIPs.
Discussion
The repository should be able to demonstrate that the AIPs faithfully reflect the information
that was captured during ingest and that any subsequent or future planned transformations
will continue to preserve all the required Information Properties of the Content Information.
One approach to this requirement assu


mes 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 resulting AIP should be maintained.
4.4.1.2 The repository shall active


ly monitor the integrity of AIPs.
Supporting Text
This is necessary in order to protect the integrity of the archival objects over time.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-21
September 2011
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Fixity information (e.g., checksums) for each ingested digital object/AIP; logs of fixity
checks; documentation of how AIPs and Fixity information are kept separate; documentation
of ho


w AIPs and accession registers are kept separate.
Discussion
A repository should have logs that show actions taken to check the integrity of archival
objects in order to assure funders, producers, and users—and to allow them to
audit/validate—that the repository is taking the necessary steps to ensure the long-term
integrity of the digital objects.  The repository should also document that integrity checks are
carried out on a regular basis, in order to catch any changes in AIPs as soon as possible so


that corrective action can be taken as soon as possible. The repository should allow interested
parties to verify that this is the case.
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 should be able,
and may want 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 accidental alteration of the AIP would not also damage the Fixity
Information. Also, someone who can maliciously alter an AIP would not likely be able as
easily to alter the Fixity Information as well.
4.4.2 The repository shall have contemporaneous records of actions and
administration processes that are relevant to storage and preservation of the AIPs.
Supporting Text
This is necessary in order to ensure documentation is not omitted or erroneous or of
questionable authenticity.
Examples


of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Written documentation of decisions and/or action taken; preservation metadata logged,
stored, and linked to pertinent digital objects.
Discussion
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, the repository
must demonstrate that all relevant actions are appropriately performed.
AUDIT AND CERTIFICATION OF TRUSTWORT


HY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-22
September 2011
4.4.2.1 The repository shall have procedures for all actions taken on AIPs.
Supporting Text
This is necessary in order to ensure that any actions performed against an AIP do not alter
the AIP information in a manner unacceptable to its Designated Communities.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Written documentation describing all actions that can be performed against an AIP.
Discussion
Thi


s documentation is normally created during design of the repository. It should detail the
normal handling of AIPs, all actions that can be performed against the AIPs, including
success and failure conditions and details of how these processes can be monitored.
4.4.2.2 The repository shall be able to demonstrate that any actions taken on AIPs
were compliant with the specification of those actions.
Supporting Text
This is necessary in order to ensure that any actions performed against an AIP do not alte


r
the AIP information in a manner unacceptable to its Designated Communities.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Preservation metadata logged, stored, and linked to pertinent digital objects and
documentation of that action; procedural audits of the repository showing that all actions
conform to the documented processes.
Discussion
Successful preservation of information in the archive is strongly linked to following
established and documented procedures to


 complete any actions that affect the repository
data. The more often ‘special handling’ of repository data occurs and the more often this
‘special handling’ is not overseen in a consistent manner, the more likely that the data held
by the repository will be compromised. When procedures are regularly followed, any
deviation from procedures that would be likely to cause an alteration in the data will more
likely be noticed or, if not noticed, may more likely be able to be corrected, or the timing and
l


ikely change could be identified in the future.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-23
September 2011
4.5
INFORMATION MANAGEMENT
4.5.1 The repository shall specify minimum information requirements to enable the
Designated Community to discover and identify material of interest.
Supporting Text
This is necessary in order to enable discovery of the repository’s holdings.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Re


trieval and descriptive information, discovery metadata, such as Dublin Core, and other
documentation describing the object.
Discussion
The repository should be able to deal with the types of requests that will come from a typical
user from the Designated Community. A repository does not necessarily have to satisfy every
possible request. Retrieval metadata is distinct from descriptive information that describes
what has been found.
4.5.2 The repository shall capture or create minimum descriptive inf


ormation and
ensure that it is associated with the AIP.
Supporting Text
This is required in order to ensure that descriptive information is associated with the AIP.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Descriptive metadata; internal or external persistent, unique identifier or locator that is
associated with the AIP (see also 4.2.4 about persistent, unique identifier); system
documentation and technical architecture; depositor agreements; metadata policy
doc


umentation, incorporating details of metadata requirements and a statement describing
where responsibility for its procurement falls; process workflow documentation.
Discussion
The repository should show that it associates with each AIP, minimum descriptive
information that was either received from the producer or created by the repository.
Associating the descriptive information with the object is important, although it does not
require one-to-one correspondence, and may not necessarily be stored wit


h the AIP.
Hierarchical schemes of description can allow some descriptive elements to be associated
with many items.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-24
September 2011
4.5.3 The repository shall maintain bi-directional linkage between each AIP and its
descriptive information.
Supporting Text
This is necessary to ensure that all AIPs can be located and retrieved.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Descri


ptive metadata; unique, persistent identifier or locator associated with the AIP;
documented relationship between the AIP and its metadata; system documentation and
technical architecture; process workflow documentation.
Discussion
Repositories must implement procedures to establish and maintain relationships to associate
descriptive information for each AIP, and should ensure that every AIP has some descriptive
information associated with it and that all descriptive information must point to at least


 one
AIP.
4.5.3.1 The repository shall maintain the associations between its AIPs and their
descriptive information over time.
Supporting Text
This is necessary to ensure that all AIPs can continue to be located and retrieved.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Log detailing ongoing maintenance or checking of the integrity of the data and its
relationships to the associated descriptive information, especially following repair or
modification of the AIP; l


egacy descriptive information; persistence of identifier or locator;
documented relationship between AIP and its descriptive information; system documentation
and technical architecture; process workflow documentation.
Discussion
Repositories must implement procedures that let them know when the relationship between
the data and the associated descriptive information is temporarily broken to ensure that it can
be restored.
4.6
ACCESS MANAGEMENT
The term ‘access’ has a number of different senses, in


cluding access by users to the
repository system, for example, physical security and user authentication, and the different
stages of accessing records (making a request, verifying the rights of the requester, and
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-25
September 2011
preparing and sending a Dissemination Information Package [DIP]). This subsection is
concerned with all of these. It is divided into two main requirements, one concerned with the
existence


 and implementation of access policies, and one with the capacity of the repository
to provide demonstrably authentic objects as DIPs. Thus the first requirement relates to
requests initiated by a user and how the repository handles them to ensure that rights and
agreements are respected, that security is monitored, that requests are fulfilled, etc. The
second requirement relates to what is delivered to the Consumer and the trust that can be
placed in it.
It must be understood that the capabilities an


d sophistication of the access system will vary
depending on the repository’s Designated Community and the access mandates of the
repository. Because of the variety of repositories and access mandates, these criteria may be
subject to questions about applicability and interpretation at a local level.
4.6.1 The repository shall comply with Access Policies.
Supporting Text
This is necessary in order to ensure the repository has fully addressed all aspects of usage
which might affect the trustworthiness


 of the repository, particularly with reference to
support of the user community.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Statements of policies that are available to the user communities; information about user
capabilities (authentication matrices); logs and audit trails of access requests; explicit tests of
some types of access.
Discussion
Depending on the nature of the repository, the Access Policies may cover:
– statements of what is accessible to which co


mmunity, and on what conditions;
– requirements for authentication and authorization of accessors;
– enforcement of agreements applicable to access conditions;
– recording of access actions.
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.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-26
September 2011
4.


6.1.1 The repository shall log and review all access management failures and
anomalies.
Supporting Text
This is necessary in order to identify security threats and access management system failures.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Access logs, capability of the system to use automated analysis/monitoring tools and
generate problem/error messages; notes of reviews undertaken or action taken as a result of
reviews.
Discussion
A repository should have som


e 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.
4.6.2 The repository shall follow policies and procedures that enable the dissemination
of digital objects that are traceable to the originals, with evidence supporting their
authenticity.
Supporting Text
This is necessary to establish an auditable chain of a


uthenticity from the AIP to disseminated
digital objects.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
System design documents; work instructions (if DIPs involve manual processing); process
walkthroughs; production of a sample copy with evidence of authenticity; documentation of
community requirements for evidence of authenticity.
Discussion
Authenticity is not an ‘all or nothing’ concept, but is a matter of degree, judged on the basis
of evidence. Thus the adequac


y of the evidence is of key importance in assessing this
requirement.
This requirement ensures that ingest, preservation, and transformation actions do not lose
information that would support an auditable trail of authenticity between the original
deposited object and the eventual disseminated object.
A repository should record the processes to construct the DIPs from the relevant AIPs. This
is a key part of establishing that DIPs reflect the content of AIPs, and hence of original
material, in a trus


tworthy and consistent fashion. DIPs may simply be a copy of AIPs, or may
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-27
September 2011
result from a simple format transformation of an AIP. But in other cases, they may be derived
in complex ways. 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. Or a repository may disseminate auto


matically generated transcripts of voice
recordings. 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.
This requirement is concerned only with the relation between DIPs and the AIPs from which
they are derived; elsewhere the link between the originals SIPs and the AIPs is considered.
4.6.2.1 The repository shall record and act upon p


roblem reports about errors in data
or responses from users.
Supporting Text
This is necessary in order for the users to consider the repository to be a trustworthy source
of information.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
System design documents; work instructions (if DIPs involve manual processing); process
walkthroughs; logs of orders and DIP production; documentation of error reports and the
actions taken.
Discussion
The objective of access managemen


t is to ensure that a user receives a usable and correct
version of the digital object(s) (i.e., DIP) that he or she requested. A repository should show
that any problems that do occur and are brought to its attention are investigated and acted on.
Such responsiveness is essential for the repository to be considered trustworthy.

AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 5-1
September 2011
5 INFRASTRUCTURE AND SECURITY RISK MANAGEMENT
5.1
TECHNICAL INFRASTRU


CTURE RISK MANAGEMENT
5.1.1 The repository shall identify and manage the risks to its preservation operations
and goals associated with system infrastructure.
Supporting Text
This is necessary to ensure a secure and trustworthy infrastructure.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Infrastructure inventory of system components; periodic technology assessments; estimates
of system component lifetime; export of authentic records to an independent system; use of


strongly community supported software e.g., Apache, iRODS, Fedora); re-creation of
archives from backups.
Discussion
The repository should conduct or contract assessments of the risks related to hardware and
software infrastructure, and operational procedures. The repository should provide
mechanisms that minimize risk from dependencies on proprietary or obsolete system
infrastructure and from operational error. The degree of support required relates to the
criticality of the subsystem(s) involved in


 long-term preservation. The repository should
maintain a system that is scalable (e.g., able to handle anticipated future volumes of both
bytes and files) without a major disruption of the system. The repository should maintain a
system that is evolvable. That is, the system should 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. The repository system should be extensible. That is, the system
shoul


d be designed to accommodate future formats (media and files) without major
disruption of the system as a whole. The repository should be able to export its holdings to a
future custodian. The repository should be able to re-create the archives after an operational
error that overwrites or deletes digital holdings.
5.1.1.1 The repository shall employ technology watches or other technology
monitoring notification systems.
Supporting Text
This is necessary to track when hardware or software components


will become obsolete and
migration is needed to new infrastructure.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Management of periodic technology assessment reports. Comparison of existing technology
to each new assessment.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 5-2
September 2011
Discussion
The objective is to understand when any subsystem poses a risk of obsolescence, and enable
planning migration to new technology bef


ore interoperability mechanisms are no longer
available. This can be driven by proprietary software dependencies (the vendor no longer
supports the subsystem component), and by emergence of new protocols (the mechanism for
accessing the system has become obsolete and is no longer supported).
5.1.1.1.1 The repository shall have hardware technologies appropriate to the services
it provides to its designated communities.
Supporting Text
This is necessary to provide expected, contracted, secure, and pers


istent levels of service
including: ease of ingest and dissemination through appropriate depositor and user interfaces
and technologies such as upload mechanisms; on-going digital object management;
preservation approaches and solutions, such as migration; and system security.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Maintenance of up-to-date Designated Community technology, expectations, and use
profiles; provision of bandwidth adequate to support ingest and use


demands; systematic
elicitation of feedback regarding hardware and service adequacy; maintenance of a current
hardware inventory.
Discussion
The repository should be aware of the types of storage, file management, preservation and
access services expected by its Designated Community, including where applicable, the
types of media to be delivered, and needs to make sure its hardware capabilities can support
these services. The objective is to track when changes in service requirements by the
designat


ed communities require a corresponding change in the hardware technology, when
changes in ingestion policies require expanded capabilities, and when changes in
preservation policies require new preservation capabilities. This can be driven by changes in
capacity requirements (the time needed to read all media is longer than the media lifetime),
by changes in delivery mechanisms (new clients for displaying authentic records), and
changes in the number and size of archived records.
5.1.1.1.2 The reposit


ory shall have procedures in place to monitor and receive
notifications when hardware technology changes are needed.
Supporting Text
This is necessary to ensure expected, contracted, secure, and persistent levels of service.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 5-3
September 2011
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Audits of capacity versus actual usage; audits of observed error rates; audits of performance
bott


lenecks that limit ability to meet user community access requirements; documentation of
technology watch assessments; documentation of technology updates from vendors.
Discussion
The repository should conduct or contract frequent environmental scans regarding hardware
status, sources of failure, and interoperability among hardware components. The repository
should also be in contact with its hardware vendors regarding technology updates, points of
likely failure, and how new components may affect syst


em integration and performance. The
objective is to track when changes in service requirements by the designated communities
require a corresponding change in the hardware technology, when changes in ingestion
policies require expanded capabilities, and when changes in preservation policies require
new preservation capabilities. This can be driven by changes in capacity requirements (the
time needed to read all media is longer than the media lifetime), by changes in delivery
mechanisms (new clients fo


r displaying authentic records), and changes in the number and
size of archived records.
5.1.1.1.3 The repository shall have procedures in place to evaluate when changes are
needed to current hardware.
Supporting Text
This is necessary to ensure that the repository has the capacity to make informed and timely
decisions when information indicates the need for new hardware.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Evaluation procedures in place; documented staff e


xpertise in each technology subsystem.
Discussion
Given information from technology watches or other technology monitoring notification
systems, the repository should have procedures and expertise to evaluate this data and make
sound decisions regarding the need for new hardware. The objective is to track when
technology providers have developed subsystems that minimize risk, or that minimize cost,
or that improve performance. This is necessary to track emerging technologies and plan for
upgrades bef


ore capacity limits occur. The evaluation should identify when the risk of using
new technology outweighs the expected benefit, and when the new technology is sufficiently
mature to minimize risk.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 5-4
September 2011
5.1.1.1.4 The repository shall have procedures, commitment and funding to replace
hardware when evaluation indicates the need to do so.
Supporting Text
This is necessary to ensure hardware replacement in a


 timely fashion so as to avert system
failure or performance inadequacy. Without such a commitment, and more importantly,
without escrowed financial resources or a secure funding stream, technology watches and
notifications are of little value. The repository must have mechanisms for evaluating the
efficacy of the new systems before implementation in the production system.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Statement of commitment to provide expected and con


tracted levels of service; evidence of
ongoing financial assets set aside for hardware procurement; demonstration of cost savings
through amortized cost of new system.
Discussion
The objective is to demonstrate that the repository has the ability to incorporate new
technology, both financially through funding commitments or cost reduction, and
operationally through verification of the capabilities of the new systems.
5.1.1.1.5 The repository shall have software technologies appropriate to the service


s it
provides to its designated communities.
Supporting Text
This is necessary to provide expected, contracted, secure, and persistent levels of service
including: ease of ingest and dissemination through appropriate depositor and user interfaces
and technologies such as upload mechanisms; on-going digital object management;
preservation approaches and solutions, such as migration; and system security.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Maintenance of up-t


o-date Designated Community technology, expectations, and use
profiles; provision of software systems adequate to support ingest and use demands;
systematic elicitation of feedback regarding software and service adequacy; maintenance of a
current software inventory.
Discussion
The objective is to track when changes in service requirements by the designated
communities require a corresponding change in the software components, when changes in
ingestion policies require support for new data formats and


 when changes in software
technology require new format migration capabilities. This can be driven by changes in
access requirements (new clients that require new data formats become preferred), by
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 5-5
September 2011
changes in delivery mechanisms (new data transfer mechanisms), and changes in the number
and size of archived records that require more scalable software.
5.1.1.1.6 The repository shall have procedures in


place to monitor and receive
notifications when software changes are needed.
Supporting Text
This is necessary to ensure expected, contracted, secure, and persistent levels of service.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Audits of capacity versus actual usage; audits of observed error rates; audits of performance
bottlenecks that limit ability to meet user community access requirements; documentation of
technology watch assessments; documentation of software


 updates from vendors.
Discussion
The objective is to track when changes in service requirements by the designated
communities require a corresponding change in the software technology, when changes in
ingestion policies require expanded capabilities, and when changes in preservation policies
require new preservation capabilities. This can be driven by security updates (vendor
supplied corrections to newly identified vulnerabilities), by changes in delivery mechanisms
(new software clients for displa


ying authentic records), and changes in the number and size
of archived records (expanded database requirements). The repository should conduct or
contract frequent environmental scans regarding software evolution, likely points of failure,
and interoperability among the software and hardware components. The repository should
also be in contact with its software vendors regarding technology updates, points of likely
failure, and how new programs may affect system integration and performance.
5.1.1.1.7


 The repository shall have procedures in place to evaluate when changes are
needed to current software.
Supporting Text
This is necessary to ensure that the repository has the capacity to make informed and timely
decisions when information indicates the need for new software.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Evaluation procedures in place; documented staff expertise in each software technology
subsystem.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REP


OSITORIES
CCSDS 652.0-M-1
Page 5-6
September 2011
Discussion
Given information from technology watches or other technology monitoring notification
systems, the repository should have procedures and expertise to evaluate this data and make
sound decisions regarding the need for new software. The objective is to track when
technology providers have developed software infrastructure that minimizes risk, or that
minimizes cost, or that improves performance. This is necessary to track emerging
technolo


gies, and plan for upgrades before capacity limits occur. The evaluation should
identify when the risk of using new technology outweighs the expected benefit, and when the
new technology is sufficiently mature to minimize risk.
5.1.1.1.8 The repository shall have procedures, commitment, and funding to replace
software when evaluation indicates the need to do so.
Supporting Text
This is necessary to ensure software replacement in a timely fashion so as to avert system
failure or performance inadequacy


. Without such a commitment, and more importantly,
without escrowed financial resources or a secure funding stream, technology watches and
notifications are of little value. The repository must have mechanisms for evaluating the
efficacy of the new systems before implementation in the production system.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Statement of commitment to provide expected and contracted levels of service; evidence of
ongoing financial assets set asi


de for software procurement; demonstration of cost savings
through amortized cost of new system.
Discussion
The objective is to demonstrate that the repository has the ability to incorporate new
technology, both financially through funding commitments or cost reduction, and
operationally through verification of the capabilities of the new systems.
5.1.1.2 The repository shall have adequate hardware and software support for backup
functionality sufficient for preserving the repository content and trac


king repository
functions.
Supporting Text
This is necessary in order to ensure continued access to and tracking of preservation
functions applied to the digital objects in their custody.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 5-7
September 2011
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Documentation of what is being backed up and how often; audit log/inventory of backups;
validation of completed backups; disaster reco


very plan, policy and documentation; fire
drills; testing of backups; support contracts for hardware and software for backup
mechanisms; demonstrated preservation of system metadata such as access controls, location
of replicas, audit trails, checksum values.
Discussion
The repository should be able to demonstrate the adequacy of the processes, hardware, and
software for its backup systems and the full range of ingest, preservation, and dissemination
functions required of a repository entrusted with


long-term preservation. Simple backup
mechanisms must preserve not only the repository main content, but also the system
metadata generated by the preservation functions. Repositories need to develop backup plans
that ensure their continuity of operations across all failure modes.
5.1.1.3 The repository shall have effective mechanisms to detect bit corruption or loss.
Supporting Text
This is necessary in order to ensure that AIPs and metadata are uncorrupted or any data
losses are detected and fall w


ithin the tolerances established by repository policy (see 3.3.5).
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Documents that specify bit error detection and correction mechanisms used; risk analysis;
error reports; threat analysis; periodic analysis of the integrity of repository holdings.
Discussion
The objective is a comprehensive treatment of the sources of data loss and their real-world
complexity. Any data or metadata that is (temporarily) lost should be recove


rable from
backups. Routine systematic failures must not be allowed to accumulate and cause data loss
beyond the tolerances established by the repository policies. Mechanisms such as checksums
(MD5 signatures) or digital signatures should be recognized for their effectiveness in
detecting bit loss and incorporated into the overall approach of the repository for validating
integrity.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 5-8
September 2011
5.1.1.3.1 The re


pository shall record and report to its administration all incidents of
data corruption or loss, and steps shall be taken to repair/replace corrupt or lost data.
Supporting Text
This is necessary in order to ensure the repository administration is being kept informed of
incidents and recovery actions, and to enable identification of sources of data corruption or
loss.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Procedures related to reporting incidents to administra


tors; preservation metadata (e.g., PDI)
records; comparison of error logs to reports to administration; escalation procedures related
to data loss; tracking of sources of incidents; remediation actions taken to remove sources of
incidents.
Discussion
Having effective mechanisms to detect bit corruption and loss within a repository system is
critical but it is only the initial step of a larger process. In addition to recording, reporting,
and repairing as soon as possible all violations of data integr


ity, these incidents and the
recovery actions and their results must be reported to administrators and made available to all
relevant staff. Given identification of the sources of data loss, an assessment of revisions to
software and hardware systems, or operational procedures, or management policies is needed
to minimize future risk of data loss.
5.1.1.4 The repository shall have a process to record and react to the availability of
new security updates based on a risk-benefit assessment.
Supporting


Text
This is necessary in order to protect the integrity of the archival objects from unauthorized
changes or deletions.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Risk register (list of all patches available and risk documentation analysis); evidence of
update processes (e.g., server update manager daemon); documentation related to the update
installations.
Discussion
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 about how it is
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 5-9
September 2011
completed; both automated and manual updates are accep


table. 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. Security updates are not limited to
software security updates. Updates to actual hardware or to the hardware system’s firmware
are included. Over time it is likely that security updates will also be needed for the repository
processes and for its physical security. Although security updates can be considered as a part
of th


e change control, they are identified separately here because there are often outside
services that compile and circulate information on security issues and updates. At a
minimum, repositories should be monitoring these services to ensure that repository-held
data is not subject to compromise by identified threats.
5.1.1.5 The repository shall have defined processes for storage media and/or
hardware change (e.g., refreshing, migration).
Supporting Text
This is necessary in order to ensure that data i


s not lost when either the media fail or the
supporting hardware can no longer be used to access the data.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Documentation of migration processes; policies related to hardware support, maintenance,
and replacement; documentation of hardware manufacturer’s expected support life cycles;
policies related to migration of records to alternate hardware systems.
Discussion
The repository should have estimates of the access speed an


d the quantity of information for
each type of storage media. Then with estimates of the reliable lifetime of the storage media
and information of system loading, etc., the repository can estimate the time required for
storage media migration, or refreshing or copying between media without reformatting the
bit stream. The repository can then set triggers for initiating the action at an appropriate time
so the actions will be completed before data is lost. Copying large quantities of data can take
a lo


ng time and can affect other system performance metrics. Repositories should also
consider the obsolescence of any and 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 choose to continue to operate the hardware beyond the manufacturer or
third-party support warranties. Repositories will likely need t


o perform media migration off
of some types of media onto better supported media based on the estimated lifetime of
hardware support rather than on the longer life expected from the media. It is important that
the process include a check that the copying has happened correctly.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 5-10
September 2011
5.1.1.6 The repository shall have identified and documented critical processes that
affect its ability to comply with its m


andatory responsibilities.
Supporting Text
This is necessary in order to ensure that the critical processes can be monitored to ensure that
they continue to meet the mandatory responsibilities and to ensure that any changes to those
processes are examined and tested.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Traceability matrix between processes and mandatory requirements.
Discussion
Examples of critical processes include data management, access, archival storage


, ingest, and
security processes. Traceability makes it possible to understand which repository processes
are required to meet each of the mandatory responsibilities.
5.1.1.6.1 The repository shall have a documented change management process that
identifies changes to critical processes that potentially affect the repository’s ability to
comply with its mandatory responsibilities.
Supporting Text
This is necessary in order to ensure that the repository can specify not only the current
processes, but


 the prior processes that were applied to the repository holdings.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Documentation of change management process; assessment of risk associated with a process
change; analysis of the expected impact of a process change; comparison of logs of actual
changes to processes versus associated analyses of their impact and criticality.
Discussion
Examples of this would include changes to processes for 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. If unintended consequences are later
discovered, then having this record may make it possible to reverse the changes or at least to
document the changes that were introduced. Change management is a component of the
broader topic of configuration management described by ISO 10


007:2003 which includes
configuration
management
planning,
configuration
identification,
change
control,
configuration status accounting and configuration audit. Configuration Management efforts
should result in a complete audit trail of decisions and design modifications.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 5-11
September 2011
5.1.1.6.2 The repository shall have a process for testing and evaluating the effect of
changes to the repository’s critica


l processes.
Supporting Text
This is necessary in order to protect the integrity of the repository’s critical processes such
that they continue in their ability to meet the repository’s mandatory requirements.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Documented testing procedures; documentation of results from prior tests and proof of
changes made as a result of tests; analysis of the impact of a process change.
Discussion
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
w


here no changes are ever evaluated or tested will have problems.
5.1.2 The repository shall manage the number and location of copies of all digital
objects.
Supporting Text
This is necessary in order to assert that the repository is providing an authentic copy of a
particular digital object.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Random retrieval tests; validation of object existence for each registered location; validation
of a registered location for each ob


ject on storage systems; provenance and fixity checking
information; location register/log of digital objects compared to the expected number and
location of copies of particular objects.
Discussion
A repository can have different preservation policies for different classes of objects,
depending on factors such as the producer, the information type, or its value. Repositories
may require a different number of copies for each class, or manage versions needed to meet
access requirements. There may be a


dditional identification requirements if the data integrity
mechanisms use alternative copies to replace failed copies. The location of each digital
object must be described such that the object can be located precisely, without ambiguity.
The location can be an absolute physical location or a logical location within a storage media
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 5-12
September 2011
or a storage subsystem. Provenance information about copying and mov


ing the data must be
maintained/updated, including the identification of those responsible. This is necessary in
order to track chain of custody and assert that the repository is providing an authentic copy of
a particular digital object. The repository must be able to distinguish between versions of
objects or copies and identical copies. This is necessary in order that a repository can assert
that it is providing an authentic copy of the correct version of an object.
5.1.2.1 The repository shall hav


e mechanisms in place to ensure any/multiple copies of
digital objects are synchronized.
Supporting Text
This is necessary in order to ensure that multiple copies of a digital object remain identical,
within a time established as acceptable by the repository, and that a copy can be used to
replace a corrupted copy of the object.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Synchronization workflows; system analysis of how long it takes for copies to synchronize;
pro


cedures/documentation of synchronization processes.
Discussion
The disaster recovery plan should address what to do should a disaster and an update
coincide. For example, if one copy of an object is altered and a disaster occurs while the
second is being updated, there needs to be a mechanism to assure that the copy will be
updated at the first available opportunity. The mechanisms to synchronize copies of digital
objects should be able to detect bit corruption and validate fixity checks before
synch


ronization is attempted.
5.2
SECURITY RISK MANAGEMENT
5.2.1 The repository shall maintain a systematic analysis of security risk factors
associated with data, systems, personnel, and physical plant.
Supporting Text
This is necessary to ensure ongoing and uninterrupted service to the Designated Community.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Repository employs the codes of practice found in the ISO 27000 series of standards system
control list; risk, threat,


 or control analysis.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 5-13
September 2011
Discussion
The repository should conduct regular risk assessments and maintain adequate security
protection in order to provide expected and contracted levels of service, following codes of
practice such as ISO 27000.
‘System’ here refers to more than IT systems, such as hardware, software, communications
equipment and facilities, and firewalls. Fire protection and flood detec


tion systems are also
significant, as are means to assess personnel, management, and administration procedures,
resources, as well as operations and service delivery. Loss of income, budget and reputation
are significant threats to overall operations as is loss of mandate. On-going internal and
external evaluation should be conducted to assess quality of service and relevance to user
community served and periodic financial audits should be secured to ascertain ethical and
legal practice and maintenanc


e of required operating funds. Intellectual property rights
practices should also be reviewed regularly as well as the repository’s liability for regulatory
non-compliance as applicable. The repository should assess its staff’s skills against those
required in the evolving digital repository environment and ensure acquisition of new staff or
retraining of existing staff as necessary. Regular risk assessment should also address external
threats and denial of service attacks and loss of or unacceptable q


uality of third party
services. The repository may conduct overall risk assessments with tools such as
DRAMBORA.2
5.2.2 The repository shall have implemented controls to adequately address each of
the defined security risks.
Supporting Text
This is necessary in order to ensure that controls are in place to meet the security needs of the
repository.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Repository employs the codes of practice found in the ISO 27000 series of


 standards; system
control list; risk, threat, or control analyses; and addition of controls based on ongoing risk
detection and assessment. Repository maintains ISO 17799 certification.
Discussion
The repository should 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. Repositories that have experienced incidents could record such instances,
including the times when systems


 or content were affected and describe procedures that have
been put in place to prevent similar occurrences in the future. Repositories may also conduct

2 See http://www.repositoryaudit.eu/.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 5-14
September 2011
a variety of disaster drills that may involve their parent organization or the community at
large. Contingency plans are especially important and need to be test


ed, updated, and revised
on a regular basis.
5.2.3 The repository staff shall have delineated roles, responsibilities, and
authorizations related to implementing changes within the system.
Supporting Text
This is necessary in order to ensure that individuals have the authority to implement changes,
that adequate resources have been assigned for the effort, and that the responsible individuals
will be accountable for implementing such changes.
Examples of Ways the Repository Can Demonstrate It Is Mee


ting This Requirement
Repository employs the codes of practice found in the ISO 27000 series of standards;
organizational chart; system authorization documentation. Repository maintains ISO 17799
certification.
Discussion
Authorizations are about who can do what: who can add users, who has access to change
metadata, who can access audit logs. It is important that authorizations are justified, that staff
understand what they are authorized to do, that staff have required skills associated with
variou


s roles and authorizations, and that there is a consistent view of this across the
organization.
5.2.4 The repository shall have suitable written disaster preparedness and recovery
plan(s), including at least one off-site backup of all preserved information together with
an offsite copy of the recovery plan(s).
Supporting Text
This is necessary in order to ensure that sufficient backup and recovery capabilities are in
place to facilitate continuing preservation of and access to systems and their cont


ent with
limited disruption of services.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Repository employs the codes of practice found in the ISO 27000 series of standards; 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. Repository maintains
ISO 17799 certific


ation.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 5-15
September 2011
Discussion
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 or widespread illness among critical staff. In the event of a
disaster at the repository, the repository may want to contact local and/or national disaster
recovery bodies for assistance. Repositories may also conduct a variety of disaster drills that
may involve their parent organization or the community at large.

AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page A-1
September 2011
ANNEX A

SECURITY CONSIDERATIONS

(INFORMATIVE)
A1 INTRODUCTION


The use of the Audit and Certification Recommended Practice has several potential areas of
security concern.
One security concern is the possibility that the repository is fooled into undergoing an audit
by someone unqualified or even malicious.
Another concern involves the possible release of confidential information which is collected
as evidence by the auditor.
A2 SECURITY CONCERNS WITH RESPECT TO THE CCSDS DOCUMENT
The repository may ask someone to perform an audit using this Recommended Practic


e.
There is a possibility that the person contacted is not in fact the person that the repository
believes him or her to be.  Alternatively the correct person may be contacted but in fact
another, possibly malicious, person may turn up to perform the audit.
In the process of collecting evidence for the various metrics the auditor may collect
information which is confidential or sensitive, for example details of security weaknesses.
There is a danger that such information may fall into the wrong hands


 and expose the
repository to increased risk. Alternatively in the process of collecting evidence the repository
system may be damaged.
While these are all valid security concerns, they fall outside the purview of this
Recommended Practice, which applies only to the metrics which an auditor should use for
auditing a repository.
A3 POTENTIAL THREATS AND ATTACK SCENARIOS
Impersonation of an auditor and/or release of confidential information could both result in
exposing the repository and its holdings


 to increased risk and loss of reputation of the
repository.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page A-2
September 2011
A4 CONSEQUENCES OF NOT APPLYING SECURITY TO THE TECHNOLOGY
While these security issues are of concern, they are out of scope with respect to this
document. This document aims to provide the basis for an audit and certification process for
assessing the trustworthiness of digital repositories. Providing protection against false
auditors mus


t rely on the repository’s identification and authorization systems.  Protection
against loss of confidential information in the possession of the auditor must be provided by
the security system of that auditor and the method of transmission of information which is
agreed between the repository and auditor.  Protection against damage to the repository or its
holdings during an audit must rely on the security and safety systems of the repository.

AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITO


RIES
CCSDS 652.0-M-1
Page B-1
September 2011
ANNEX B

REFERENCES

(INFORMATIVE)
[B1] D. Waters and J. Garrett.  Preserving Digital Information.  Report of the Task Force
on Archiving of Digital Information.  Washington, DC: CLIR, May 1996.
[B2] Trusted Digital Repositories: Attributes and Responsibilities.  An RLG-OCLC Report.
Mountain View, CA: RLG, May 2002.
[B3] Trustworthy Repositories Audit & Certification: Criteria and Checklist.  Version 1.0.
Chicago: CRL, February 2007.
[B4] Produce


r-Archive Interface Methodology Abstract Standard.  Recommendation for
Space Data System Standards, CCSDS 651.0-M-1.  Magenta Book.  Issue 1.
Washington, D.C.: CCSDS, May 2004.
[B5] XML
Formatted
Data
Unit
(XFDU)
Structure
and
Construction
Rules.
Recommendation for Space Data System Standards, CCSDS 661.0-B-1.  Blue Book.
Issue 1.  Washington, D.C.: CCSDS, September 2008.
[B6] The Data Description Language EAST Specification (CCSD0010).  Recommendation
for Space Data System Standards, CCSD


S 644.0-B-3.  Blue Book.  Issue 3.
Washington, D.C.: CCSDS, July 2009.
[B7] Data Entity Dictionary Specification Language (DEDSL)—Abstract Syntax
(CCSD0011).  Recommendation for Space Data System Standards, CCSDS 647.1-B-
1.  Blue Book.  Issue 1.  Washington, D.C.: CCSDS, June 2001.
[B8] “Digital Preservation Management: Implementing Short-Term Strategies for Long-
Term Problems.”  Digital Preservation Management Resources.  Cornell University.
[B9] Quality Management Systems—Fundamentals and Vocabula


ry.  International
Standard, ISO 9000:2005.  3rd edition.  Geneva:  ISO, 2005.
[B10] Information Technology—Security Techniques—Code of Practice for Information
Security Management.  International Standard, ISO/IEC 17799:2005.  2nd edition.
Geneva:  ISO, 2005.
[B11] Information
and
Documentation—Records
Management—Part
1:
General.
International Standard, ISO 15489-1:2001.  Geneva:  ISO, 2001.
[B12] Information and Documentation—Records Management—Part 2: Guidelines.
International Standard, I


SO/TR 15489-2:2001.  Geneva:  ISO, 2001.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page B-2
September 2011
[B13] Trustworthy Information Systems Handbook.  Version 4.  Saint Paul, Minnesota:
Minnesota Historical Society, July 2002.
[B14] Ron Ross, et al.  Guide for Assessing the Security Controls in Federal Information
Systems.  National Institute of Standards and Technology Special Publication 800-
53A.  Gaithersburg, Maryland: NIST, July 2008.
[B15] Susanne Dobra


tz, Astrid Schoger, and Stefan Strathmann.  “The nestor Catalogue of
Criteria for Trusted Digital Repository Evaluation and Certification.”  Journal of
Digital Information 8, no. 2  (2007).