ing / Security Policy
CCM DG-07: Data Governance - Information Leakage
CCM FS-02: Facility Security - User Access
CCM FS-05: Facility Security - Unauthorized Persons Entry
CCM FS-06: Facility Security - Off-Site Authorization
CCM HR-01: Human Resources Security - Background Screening
CCM IS-06: Information Security - Policy Enforcement
CCM IS-08: Information Security - User Access Restriction / Authorization
CCM IS-10: Information Security - User Access Reviews
CCM IS-13: Information Security - Rol


es / Responsibilities
CCM IS-15: Information Security - Segregation of Duties
CCM IS-18: Information Security - Encryption

1 http://www.cert.org/insider_threat/
RISK ANALYSIS
STRIDE: Spoofing, Tampering,
Information Disclosure
IS THREAT STILL RELEVANT?

TOP THREAT RANKING

SERVICE MODEL

IaaS
PaaS
SaaS
RISK MATRIX

Perceived Risk
Actual Risk

© 2013, Cloud Security Alliance.  All rights reserved.
17

CLOUD SECU


RITY ALLIANCE The Notorious Nine: Cloud Computing Top Threats in 2013
CCM IS-19: Information Security - Encryption Key Management
CCM IS-29: Information Security - Audit Tools Access
CCM RI-02: Risk Management - Assessments
CCM SA-09: Security Architecture - Segmentation
6.3 Links
1.        Insider threats to cloud computing
http://www.cloudtweaks.com/2012/10/insider-threats-to-cloud-computing/
2.        Cloud’s privileged identity gap intensifies insider threats
http://www.darkreading.com/insider-


threat/167801100/security/news/240146276/cloud-s-privileged-identity-gap-
intensifies-insider-threats.html

CSA REFERENCE
Domain 2: Governance and
Enterprise Risk Management
Domain 5: Information
Management and Data Security
Domain 11: Encryption and Key
Management
Domain 12: Identity, Entitlement
and Access Management

© 2013, Cloud Security Alliance.  All rights reserved.
18

CLOUD SECURITY ALLIANCE The Notorious Nine: Cloud Computing Top Threats in 2013
7.0 Top Threat: Abuse of Cl


oud Services
One of cloud computing’s greatest benefits is that it allows even small
organizations access to vast amounts of computing power.  It would be difficult
for most organizations to purchase and maintain tens of thousands of servers,
but renting time on tens of thousands of servers from a cloud computing
provider is much more affordable.  However, not everyone wants to use this
power for good.  It might take an attacker years to crack an encryption key
using his own limited hardware, but usi


ng an array of cloud servers, he might
be able to crack it in minutes.  Alternately, he might use that array of cloud
servers to stage a DDoS attack, serve malware or distribute pirated software.
7.1 Implications
This threat is more of an issue for cloud service providers than cloud
consumers, but it does raise a number of serious implications for those
providers.  How will you detect people abusing your service?  How will you
define abuse?  How will you prevent them from doing it again?
7.2 Control


s
CCM IS-24: Information Security - Incident Response Legal Preparation
CCM IS-26: Information Security - Acceptable Use
7.3 Links
1.       Cross-VM Side Channels and Their Use to Extract Private Keys
http://www.cs.unc.edu/~yinqian/papers/crossvm.pdf
2.       Pirate Bay Ditches Servers and Switches to the Cloud
http://news.cnet.com/8301-1023_3-57534707-93/pirate-bay-ditches-servers-
and-switches-to-the-cloud/

RISK ANALYSIS
CIANA: N/A
STRIDE: N/A
CSA REFERENCE
Domain 2: Governance and
Ente


rprise Risk Management
Domain 9: Incident Response

IS THREAT STILL RELEVANT?

TOP THREAT RANKING

RISK MATRIX
N/A

SERVICE MODEL

IaaS
PaaS
SaaS

© 2013, Cloud Security Alliance.  All rights reserved.
19

CLOUD SECURITY ALLIANCE The Notorious Nine: Cloud Computing Top Threats in 2013
8.0 Top Threat: Insufficient Due
Diligence
Cloud computing has brought with it a gold rush of sorts, with many
organizations rushing into the promise of cost reductions, operational
efficiencies and


improved security.  While these can be realistic goals for
organizations that have the resources to adopt cloud technologies properly,
too many enterprises jump into the cloud without understanding the full scope
of the undertaking.
Without a complete understanding of the CSP environment, applications or
services being pushed to the cloud, and operational responsibilities such as
incident response, encryption, and security monitoring, organizations are
taking on unknown levels of risk in ways they ma


y not even comprehend, but
that are a far departure from their current risks.
8.1 Implications
An organization that rushes to adopt cloud technologies subjects itself to a
number of issues.  Contractual issues arise over obligations on liability,
response, or transparency by creating mismatched expectations between the
CSP and the customer.  Pushing applications that are dependent on “internal”
network-level security controls to the cloud is dangerous when those controls
disappear or do not match th


e customer’s expectation.  Unknown operational
and architectural issues arise when designers and architects unfamiliar with
cloud technologies are designing applications being pushed to the cloud.
The bottom line for enterprises and organizations moving to a cloud
technology model is that they must have capable resources, and perform
extensive internal and CSP due-diligence to understand the risks it assumes by
adopting this new technology model.
8.2 Controls
CCM DG-08: Data Governance - Risk Assess


ments
CCM IS-04: Information Security - Baseline Requirements
CCM IS-12: Information Security - Industry Knowledge / Benchmarking
CCM OP-03: Operations Management - Capacity / Resource Planning
CCM RI-01: Risk Management - Program
CCM RI-02: Risk Management - Assessments
CCM RS-01: Resiliency - Management Program
CCM RS-02: Resiliency - Impact Analysis
CCM RS -03: Resiliency - Business Continuity Planning
CCM SA-03: Security Architecture - Data Security / Integrity
CCM SA-04: Security Architecture


 - Application Security
RISK ANALYSIS
STRIDE: All
CSA REFERENCE
Domain 2: Governance and
Enterprise Risk Management
Domain 3: Legal and Electronic
Discovery
Domain 8: Data Center
Operations
Domain 9: Incident Response,
Notification and Remediation
IS THREAT STILL RELEVANT?

TOP THREAT RANKING

SERVICE MODEL

IaaS
PaaS
SaaS
RISK MATRIX

Perceived Risk
Actual Risk

© 2013, Cloud Security Alliance.  All rights reserved.
20

CLOUD SECURITY ALLIANCE The Notorious Nine: C


loud Computing Top Threats in 2013
CCM SA-08: Security Architecture - Network Security
CCM SA-09: Security Architecture - Segmentation
8.3 Links
1.       Perfecting the unknown: Cloud Computing
http://www.mysanantonio.com/business/article/Perfecting-the-Unknown-
Cloud-Computing-4157844.php

© 2013, Cloud Security Alliance.  All rights reserved.
21

CLOUD SECURITY ALLIANCE The Notorious Nine: Cloud Computing Top Threats in 2013
9.0 Top Threat: Shared Technology
Vulnerabilities
Cloud servi


ce providers deliver their services in a scalable way by sharing
infrastructure, platforms, and applications.  Whether it’s the underlying
components that make up this infrastructure (e.g. CPU caches, GPUs, etc.) that
were not designed to offer strong isolation properties for a multi-tenant
architecture (IaaS), re-deployable platforms (PaaS), or multi-customer
applications (SaaS), the threat of shared vulnerabilities exists in all delivery
models.  A defensive in-depth strategy is recommended and shou


ld include
compute, storage, network, application and user security enforcement, and
monitoring, whether the service model is IaaS, PaaS, or SaaS.  The key is that a
single vulnerability or misconfiguration can lead to a compromise across an
entire provider’s cloud.
9.1 Implications
A compromise of an integral piece of shared technology such as the hypervisor,
a shared platform component, or an application in a SaaS environment exposes
more than just the compromised customer; rather, it exposes the


entire
environment to a potential of compromise and breach.  This vulnerability is
dangerous because it potentially can affect an entire cloud at once.
9.2 Controls
CCM DG-03: Data Governance - Handling / Labeling / Security Policy
CCM IS-04: Information Security - Baseline Requirements
CCM IS-07: Information Security - User Access Policy
CCM IS-15: Information Security - Segregation of Duties
CCM IS-18: Information Security - Encryption
CCM IS-20: Information Security - Vulnerability / Patch Manag


ement
CCM SA-02: Security Architecture - User ID Credentials
CCM SA-09: Security Architecture - Segmentation
CCM SA-11: Security Architecture - Shared Networks
CCM SA-14: Security Architecture - Audit Logging / Intrusion Detection
9.3 Links
1.    New virtualization vulnerability allows escape to hypervisor attacks
http://www.informationweek.com/security/application-security/new-
virtualization-vulnerability-allows/240001996
RISK ANALYSIS
STRIDE: Information Disclosure,
Elevation of Privilege
CSA


 REFERENCE
Domain 1: Cloud computing
architectural framework
Domain 5: Information
management and data security
Domain 11: Encryption and key
management
Domain 12: Identity, entitlement,
and access management
Domain 13: Virtualization
IS THREAT STILL RELEVANT?

TOP THREAT RANKING

SERVICE MODEL

IaaS
PaaS
SaaS
RISK MATRIX

Perceived Risk
Actual Risk


Recommendation for Space Data System Practices
MAGENTA BOOK
AUDIT AND
CERTIFICATION OF
TRUSTWORTHY DIGITAL
REPOSITORIES
RECOMMENDED PRACTICE
CCSDS 652.0-M-1
September 2011

Recommendation for Space Data System Practices
AUDIT AND
CERTIFICATION OF
TRUSTWORTHY DIGITAL
REPOSITORIES
RECOMMENDED PRACTICE
CCSDS 652.0-M-1
MAGENTA BOOK
September 2011
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page i
September 2011
AUTHORITY

Issue:
Recommended Pract


ice, Issue 1

Date:
September 2011

Location:
Washington, DC, USA

This document has been approved for publication by the Management Council of the
Consultative Committee for Space Data Systems (CCSDS) and represents the consensus
technical agreement of the participating CCSDS Member Agencies.  The procedure for
review and authorization of CCSDS documents is detailed in the Procedures Manual for the
Consultative Committee for Space Data Systems, and the record of Agency participation


 in
the authorization of this document can be obtained from the CCSDS Secretariat at the
address below.

This document is published and maintained by:

CCSDS Secretariat
Space Communications and Navigation Office, 7L70
Space Operations Mission Directorate
NASA Headquarters
Washington, DC 20546-0001, USA
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page ii
September 2011
STATEMENT OF INTENT
The Consultative Committee for Space Data Systems (CCSDS) is an organ


ization officially
established by the management of its members. The Committee meets periodically to address
data systems problems that are common to all participants, and to formulate sound technical
solutions to these problems. Inasmuch as participation in the CCSDS is completely
voluntary, the results of Committee actions are termed Recommendations and are not in
themselves considered binding on any Agency.
CCSDS Recommendations take two forms: Recommended Standards that are prescriptive
and are


the formal vehicles by which CCSDS Agencies create the standards that specify how
elements of their space mission support infrastructure shall operate and interoperate with
others; and Recommended Practices that are more descriptive in nature and are intended to
provide general guidance about how to approach a particular problem associated with space
mission support. This Recommended Practice is issued by, and represents the consensus of,
the CCSDS members.  Endorsement of this Recommended Practice is


entirely voluntary
and does not imply a commitment by any Agency or organization to implement its
recommendations in a prescriptive sense.
No later than five years from its date of issuance, this Recommended Practice will be
reviewed by the CCSDS to determine whether it should: (1) remain in effect without change;
(2) be changed to reflect the impact of new technologies, new requirements, or new
directions; or (3) be retired or canceled.
In those instances when a new version of a Recommended Practi


ce is issued, existing
CCSDS-related member Practices and implementations are not negated or deemed to be non-
CCSDS compatible. It is the responsibility of each member to determine when such Practices
or implementations are to be modified.  Each member is, however, strongly encouraged to
direct planning for its new Practices and implementations towards the later version of the
Recommended Practice.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page iii
September 2011


FOREWORD
This document is a technical Recommendation to use as the basis for providing audit and
certification of the trustworthiness of digital repositories.  It provides a detailed specification
of criteria by which digital repositories shall be audited.
The OAIS Reference Model (reference [1]) contained a roadmap which included the need for
a certification standard.  The initial work was to be carried out outside CCSDS and then
brought back into CCSDS to take into the standard.
In 2003, Research


Libraries Group (RLG) and the National Archives and Records
Administration (NARA) created a joint task force to specifically address digital repository
certification. That task force published Trustworthy Repositories Audit & Certification:
Criteria and Checklist  (TRAC—reference [B3]), on which this Recommended Practice is
based.
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur.  This Recommended Practice is therefore subject


to CCSDS document management and change control procedures, which are defined in the
Procedures Manual for the Consultative Committee for Space Data Systems.  Current
versions of CCSDS documents are maintained at the CCSDS Web site:
http://www.ccsds.org/
Questions relating to the contents or status of this document should be addressed to the
CCSDS Secretariat at the address indicated on page i.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page iv
September 2011
At


time of publication, the active Member and Observer Agencies of the CCSDS were:
Member Agencies
– Agenzia Spaziale Italiana (ASI)/Italy.
– Canadian Space Agency (CSA)/Canada.
– Centre National d’Etudes Spatiales (CNES)/France.
– China National Space Administration (CNSA)/People’s Republic of China.
– Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)/Germany.
– European Space Agency (ESA)/Europe.
– Federal Space Agency (FSA)/Russian Federation.
– Instituto Nacional de Pesquisas Espaciais (INPE)/B


razil.
– Japan Aerospace Exploration Agency (JAXA)/Japan.
– National Aeronautics and Space Administration (NASA)/USA.
– UK Space Agency/United Kingdom.
Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– Belgian Federal Science Policy Office (BFSPO)/Belgium.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– China Satellite Launch and Tracking Control General, Beijing Institute of Tracking
and Telecommunications Technology (CLTC/BITTT)/China.
– Chinese Academ


y of Sciences (CAS)/China.
– Chinese Academy of Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– CSIR Satellite Applications Centre (CSIR)/Republic of South Africa.
– Danish National Space Center (DNSC)/Denmark.
– Departamento de Ciência e Tecnologia Aeroespacial (DCTA)/Brazil.
– European Organization for the Exploitation of Meteorological Satellites
(EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Eu


rope.
– Geo-Informatics and Space Technology Development Agency (GISTDA)/Thailand.
– Hellenic National Space Committee (HNSC)/Greece.
– Indian Space Research Organization (ISRO)/India.
– Institute of Space Research (IKI)/Russian Federation.
– KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.
– Korea Aerospace Research Institute (KARI)/Korea.
– Ministry of Communications (MOC)/Israel.
– National Institute of Information and Communications Technology (NICT)/Japan.
– National Ocea


nic and Atmospheric Administration (NOAA)/USA.
– National Space Agency of the Republic of Kazakhstan (NSARK)/Kazakhstan.
– National Space Organization (NSPO)/Chinese Taipei.
– Naval Center for Space Technology (NCST)/USA.
– Scientific and Technological Research Council of Turkey (TUBITAK)/Turkey.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
– United States Geological Survey (USGS)/USA.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL RE


POSITORIES
CCSDS 652.0-M-1
Page v
September 2011
DOCUMENT CONTROL

Document
Title
Date
Status
CCSDS
652.0-M-1
Audit and Certification of
Trustworthy Digital Repositories,
Recommended Practice,
Issue 1
September
2011
Original issue

AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page vi
September 2011
CONTENTS
Section
Page
1 INTRODUCTION
..................................................................................................


........ 1-1

1.1
PURPOSE AND SCOPE
........................................................................................ 1-1
1.2
APPLICABILITY
................................................................................................... 1-1
1.3
RATIONALE
.......................................................................................................... 1-1
1.4
STRUCTURE OF THIS DOCUMENT.................................................................. 1-2
1.5
DEFINITIONS
....


.................................................................................................... 1-3
1.6
CONFORMANCE
.................................................................................................. 1-6
1.7
REFERENCES ....................................................................................................... 1-6

2 OVERVIEW OF AUDIT AND CERTIFICATION CRITERIA .............................. 2-1

2.1
A TRUSTWORTHY DIGITAL REPOSITORY
.................................


................... 2-1
2.2
EVIDENCE ............................................................................................................ 2-1
2.3
RELEVANT STANDARDS, BEST PRACTICES, AND CONTROLS ............... 2-1

3 ORGANIZATIONAL INFRASTRUCTURE
.............................................................. 3-1

3.1
GOVERNANCE AND ORGANIZATIONAL VIABILITY ................................. 3-1
3.2
ORGANIZATIONAL STRUCTURE AND STAFFING
....................................... 3-3
3.3
P


ROCEDURAL ACCOUNTABILITY AND PRESERVATION POLICY
FRAMEWORK ...................................................................................................... 3-5
3.4
FINANCIAL SUSTAINABILITY ....................................................................... 3-10
3.5
CONTRACTS, LICENSES, AND LIABILITIES................................................ 3-11

4 DIGITAL OBJECT MANAGEMENT
......................................................................... 4-1

4.1
INGEST: ACQUISITION OF


CONTENT
............................................................. 4-1
4.2
INGEST: CREATION OF THE AIP
...................................................................... 4-6
4.3
PRESERVATION PLANNING ........................................................................... 4-16
4.4
AIP PRESERVATION ......................................................................................... 4-19
4.5
INFORMATION MANAGEMENT
.....................................................................


4-23
4.6
ACCESS MANAGEMENT ................................................................................. 4-24

5 INFRASTRUCTURE AND SECURITY RISK MANAGEMENT ........................... 5-1

5.1
TECHNICAL INFRASTRUCTURE RISK MANAGEMENT
.............................. 5-1
5.2
SECURITY RISK MANAGEMENT ................................................................... 5-12

ANNEX A SECURITY CONSIDERATIONS  (NORMATIVE) ................................. A-1
ANNEX B REFERENCES  (INFORMATIVE)
....


..........................................................B-1
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 1-1
September 2011
1 INTRODUCTION
1.1
PURPOSE AND SCOPE
The main purpose of this document is to define a CCSDS Recommended Practice on which
to base an audit and certification process for assessing the trustworthiness of digital
repositories. The scope of application of this document is the entire range of digital
repositories.
1.2
APPLICABILITY
This do


cument is meant primarily for those responsible for auditing digital repositories and
also for those who work in or are responsible for digital repositories seeking objective
measurement of the trustworthiness of their repository. Some institutions may also choose to
use these metrics during a design or redesign process for their digital repository.
1.3
RATIONALE
In 1996 the Task Force on Archiving of Digital Information (reference [B1]) declared, ‘a
critical component of digital archiving infrastruc


ture is the existence of a sufficient number
of trusted organizations capable of storing, migrating, and providing access to digital
collections’. The task force saw that ‘trusted’ or trustworthy organizations could not simply
identify themselves. To the contrary, the task force declared, ‘a process of certification for
digital archives is needed to create an overall climate of trust about the prospects of
preserving digital information’.
Work in articulating responsible digital archiving infrastructu


re was furthered by the
development of the Open Archival Information System (OAIS) Reference Model
(reference [1]). Designed to create a consensus on ‘what is required for an archive to provide
permanent or indefinite long-term preservation of digital information’, the OAIS addressed
fundamental questions regarding the long-term preservation of digital materials that cut
across domain-specific implementations. The reference model (ISO 14721) provides a
common conceptual framework describing the enviro


nment, functional components, and
information objects within a system responsible for the long-term preservation of digital
materials. Long before it became an approved standard in 2002, many in the cultural heritage
community had adopted OAIS as a model to better understand what would be needed from
digital preservation systems.
Institutions began to declare themselves ‘OAIS-compliant’ to underscore the trustworthiness
of their digital repositories. However, there was no established understanding of


‘OAIS-
compliance’ beyond being able to apply OAIS terminology to describe their archive, despite
there being a compliance section in OAIS which specifies the need to support the model of
information and fulfilling the mandatory responsibilities.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 1-2
September 2011
Claims of trustworthiness are easy to make but are thus far difficult to justify or objectively
prove. Establishing more clear criteria detailing what a trus


tworthy repository is and is not
has become vital.
In 2002, Research Libraries Group (RLG) and Online Computer Library Center (OCLC)
jointly
published
Trusted
Digital
Repositories:
Attributes
and
Responsibilities
(reference [B2]), which further articulated a framework of attributes and responsibilities for
trusted, reliable, sustainable digital repositories capable of handling the range of materials
held by large and small cultural heritage and research institutions. The framework was broad
en


ough to accommodate different situations, technical architectures, and institutional
responsibilities while providing a basis for the expectations of a trusted repository. The
document has proven to be useful for institutions grappling with the long-term preservation
of cultural heritage resources and has been used in combination with the OAIS as a digital
preservation planning tool. As a framework, this document concentrated on high-level
organizational and technical attributes and discussed potential


 models for digital repository
certification. It refrained from being prescriptive about the specific nature of rapidly
emerging digital repositories and archives and instead reiterated the call for certification of
digital repositories, recommending the development of certification program and articulation
of auditable criteria.
OAIS included a Roadmap for follow-on standards which included ‘standard(s) for
accreditation of archives’. It was agreed that RLG and National Archives and Records
Administ


ration (NARA) would take this particular topic forward and the later published the
TRAC (reference [B3]) document which combined ideas from OAIS (reference [1]) and
Trusted Digital Repositories: Attributes and Responsibilities (TDR—reference [B2]).
The current document follows on from TRAC in order to produce an ISO standard.
1.4
STRUCTURE OF THIS DOCUMENT
This document is divided into informative and normative sections and annexes.
Sections 1-2 of this document are informative and give a high-level


view of the rationale, the
conceptual environment, some of the important design issues, and an introduction to the
terminology and concepts.
– Section 1 gives purpose and scope, rationale, a view of the overall document
structure, and the acronym list, glossary, and reference list for this document.
– Section 2 provides an overview of audit and certification criteria, ideas about
evidence to support claims, and a discussion of related standards.

Metrics are empirically derived and consistent measur


es of effectiveness.  When
evaluated together, metrics can be used to judge the overall suitability of a repository
to be trusted to provide a preservation environment that is consistent with the goals of
the OAIS. Separately, individual metrics or measures can be used to identify possible
weaknesses or pending declines in repository functionality.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 1-3
September 2011
– Sections 3 to 5 provide the normative metrics agai


nst which a digital repository may
be judged. These sections provide metrics grouped as follows:
•
covers Organizational Infrastructure;
•
covers Digital Object Management;
•
covers Infrastructure and Security Risk Management.

Each section groups metrics into one or more subsections.
– Security considerations are discussed in annex A.
– Annex B provides Informative References.
1.5
DEFINITIONS
1.5.1 ACRONYMS AND ABBREVIATIONS
AIP
Archival Information Package (defined in reference [1])
CCSDS


Consultative Committee for Space Data Systems
DEDSL
Data Entity Specification Language (see reference [B7])
DIP
Dissemination Information Package (defined in reference [1])
FITS
Flexible Image Transport System
GIS
Geographic Information System
ISO
International Organization for Standardization
OAIS
Open Archival Information System (see reference [1])
PDI
Preservation Description Information (defined in reference [1])
SIP
Submission Information Package (defined in reference [1])
TEI
Text


Encoding Initiative
UML
Unified Modeling Language
XML
Extensible Markup Language
1.5.2 TERMINOLOGY
Digital preservation interests a range of different communities, each with a distinct
vocabulary and local definitions for key terms. A glossary is included in this document, but it
is important to draw attention to the usage of several key terms.
In general, key terms in this document have been adopted from the OAIS Reference Model.
One of the great strengths of the OAIS Reference Model has been to


provide a common
terminology made up of terms ‘not already overloaded with meaning so as to reduce
conveying unintended meanings’ (reference [1]). Because the OAIS has become a
foundational document for digital preservation, the common terms are well understood and
are therefore used within this document.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 1-4
September 2011
The OAIS Reference Model uses ‘digital archive’ to mean the organization responsible for
digita


l preservation. In this document, the term ‘repository’ or phrase ‘digital repository’ is
used to convey the same concept in all instances except when quoting from the OAIS. It is
important to understand that in all instances in this document, ‘repository’ and ‘digital
repository’ are used to convey digital repositories and archives that have, or contribute to,
long-term preservation responsibilities and functionality. This document uses the OAIS
concept of the ‘Designated Community’. A repository may


have a single, generalized
‘Designated Community’ (e.g., every citizen of a country), while other repositories may have
several, distinct Designated Communities with highly specialized needs, each requiring
different functionality or support from the repository; this document uses the term
Designated Community to cover this second case also.
Finally, this document names criteria that, combined, evaluate the trustworthiness of digital
repositories and archives.
1.5.2.1 Glossary
Unless otherwise indic


ated, other definitions are taken from the OAIS Reference Model
(reference [1]).
Access Policy: Written statement, authorized by the repository management, that describes
the approach to be taken by the repository for providing access to objects accessioned into
the repository. The Access Policy may distinguish between different types of access rights,
for example between system administrators, Designated Communities, and general users.
Practice: Actions conducted to execute procedures. Practices are


measured by logs or other
evidence that record actions completed.
Preservation Implementation Plan: A written statement, authorized by the management of
the repository, that describes the services to be offered by the repository for preserving
objects accessioned into the repository in accordance with the Preservation Policy.
NOTE – The relationship between these terms is motivated as follows.  A repository is
assumed to have an overall Repository Mission Statement, part of which will be
concerned wi


th preservation.  The Preservation Strategic Plan states how the
mission will be achieved, in general terms with goals and objectives.  The
Preservation Policy then declares the range of approaches that the repository will
employ to ensure preservation (that is, to implement the Preservation Strategic
Plan), and finally the Preservation Implementation Plan translates those into
services that the repository must carry out.  This is an abstract documentary
model that, in reality, can result in different


 documents, a different distribution of
subjects between documents, different document names, etc.
Preservation Policy: Written statement, authorized by the repository management, that
describes the approach to be taken by the repository for the preservation of objects
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 1-5
September 2011
accessioned into the repository. The Preservation Policy is consistent with the Preservation
Strategic Plan.
Preservation Strategic


Plan: A written statement, authorized by the management of the
repository, that states the goals and objectives for achieving that part of the mission of the
repository concerned with preservation. Preservation Strategic Plans may include long-term
and short-term plans.
Procedure: A written statement that specifies actions required to complete a service or to
achieve a specific state or condition. Procedures specify how various aspects of the relevant
Preservation Implementation Plans are to be fulfil


led.
Provider (or Submitter): A person or system that submits a digital object to the repository.
The Provider can be the Producer.
Repository Mission Statement: A written statement, authorized by the management of the
repository, that, among other things, describes the commitment of the organization for the
stewardship of digital objects in its custody.
1.5.3 NOMENCLATURE
The following conventions apply for the normative specifications in this Recommended
Practice:
a) the words ‘shall’ and ‘must’


imply a binding and verifiable specification;
b) the word ‘should’ implies an optional, but desirable, specification;
c) the word ‘may’ implies an optional specification;
d) the words ‘is’, ‘are’, and ‘will’ imply statements of fact.
NOTE – These conventions do not imply constraints on diction in text that is clearly
informative in nature.
1.5.4 CONVENTIONS
The following conventions apply:
– The term Designated Community may include multiple Designated Communities.
– Sub-metrics for any section are


 intended to help clarify and elucidate their superior
item. Satisfaction of the sub-metrics provides evidence supporting a claim of
compliance with the hierarchically superior items.
– Each metric has one or more of the following informative pieces of text associated
with it:
•
Supporting Text: giving an explanation of why the metric is important;
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 1-6
September 2011
•
Examples of Ways the Repository Can Demonstrate


 It Is Meeting This
Requirement:  providing examples of the evidence which might be examined to
test whether the repository satisfies the metric;
•
Discussion: clarifications about the intent of the metric.
1.6
CONFORMANCE
An archive that conforms to this Recommended Practice shall have satisfied the auditor on
each of the requirements.
Conformance to these metrics, as with all other such standards, is a matter of judgment. The
supporting organization and practice of auditing will lead to the crea


tion of auditors’
guidelines, as described in the draft ISO 16919.
As described in the referenced ISO documents, the aim of the audit process is to create a
process of continuous improvement. Thus the outcome of the audit will not be a simple
yes/no but rather a judgment about areas that need improvement.
1.7
REFERENCES
The following documents contain provisions which, through reference in this text, constitute
provisions of this Recommended Practice.  At the time of publication, the editions indica


ted
were valid.  All documents are subject to revision, and users of this Recommended Practice
are encouraged to investigate the possibility of applying the most recent editions of the
documents indicated below.  The CCSDS Secretariat maintains a register of currently valid
CCSDS documents.
[1]
Reference Model for an Open Archival Information System (OAIS).  Recommendation
for Space Data System Standards, CCSDS 650.0-B-1.  Blue Book.  Issue 1.
Washington, D.C.: CCSDS, January 2002.  [Also published


 as ISO 14721:2003.]
NOTE – Informative references are listed in annex B.

AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 2-1
September 2011
2 OVERVIEW OF AUDIT AND CERTIFICATION CRITERIA
This section provides an overview of some of the key concepts that are incorporated in the
design of the metrics in this Recommended Practice.
2.1
A TRUSTWORTHY DIGITAL REPOSITORY
At the very basic level, the definition of a trustworthy digital repository must start with ‘a
mi


ssion to provide reliable, long-term access to managed digital resources to its Designated
Community, now and into the future’ (reference [B2]). Expanding the definition has caused
great discussion both within and across various groups, from the broad digital preservation
community to the data archives or institutional repository communities.
A trustworthy digital repository will understand threats to and risks within its systems.
Constant monitoring, planning, and maintenance, as well as conscious act


ions and strategy
implementation will be required of repositories to carry out their mission of digital
preservation. All of these present an expensive, complex undertaking that depositors,
stakeholders, funders, the Designated Community, and other digital repositories will need to
rely on in the greater collaborative digital preservation environment that is required to
preserve the vast amounts of digital information generated now and into the future.
Communicating audit results to the public—transpa


rency—will engender more trust, and
additional objective audits, potentially leading towards certification, will promote further
trust in the repository and the system that supports it. Finally, attaining trustworthy status is
not a one-time accomplishment, achieved and forgotten. To retain trustworthy status, a
repository will need to undertake a regular cycle of audit and/or certification.
2.2
EVIDENCE
As noted in 1.5.4 each metric has associated with it informative text under the heading
Examples


 of Ways the Repository Can Demonstrate It Is Meeting This Requirement:
providing examples of the evidence which might be examined to test whether the repository
satisfies the metric. These examples are illustrative rather than prescriptive, and the lists of
possible evidence are not exhaustive.
2.3
RELEVANT STANDARDS, BEST PRACTICES, AND CONTROLS
Numerous documents and standards include pieces that are applicable or related to this work.
These standards are important to acknowledge and embrace as c


omplementary audit tools. A
few examples:
– The ISO 9000 family of standards (e.g., Quality Management Systems—
Fundamentals and Vocabulary—reference [B9]) addresses quality assurance
components within an organization and system management that, while valuable,
were not specifically developed to gauge the trustworthiness of organizations
operating digital repositories.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 2-2
September 2011
– Similarly, ISO 17799:2005 (r


eference [B10]) was developed specifically to address
data security and information management systems. Like ISO 9000, it has some very
valuable components to it but it was not designed to address the trustworthiness of
digital repositories. Its requirements for information security seek data security
compliance to a very granular level, but do not address organizational, procedural,
and preservation planning components necessary for the long-term management of
digital resources.
– ISO 15489-1:2001 a


nd ISO 15489-2:2001 (references [B11] and [B12]) define a
systematic and process-driven approach that governs the practice of records managers
and any person who creates or uses records during their business activities, treats
information contained in records as a valuable resource and business asset, and
protects/preserves records as evidence of actions. Conformance to ISO 15489
requires an organization to establish, document, maintain, and promulgate policies,
procedures, and practices for records m


anagement, but, by design, addresses records
management specifically rather than applying to all types of repositories and archives.
– Finally, ISO 14721:2003, the Open Archival Information System Reference Model,
provides a high-level reference model or framework identifying the participants in
digital preservation, their roles and responsibilities, and the kinds of information to be
exchanged during the course of deposit and ingest into and dissemination from a
digital repository.
It is important t


o acknowledge that there is real value in knowing whether an institution is
certified to related standards or meets other controls that would be relevant to an audit.
Certainly, an institution that has undertaken any kind of certification process—even if none
of the evaluated components overlap with a digital repository audit—will be better prepared
for digital repository certification. And those that have achieved certification in related
standards will be able to use those certifications as evidence


during the digital repository
audit.

AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 3-1
September 2011
3 ORGANIZATIONAL INFRASTRUCTURE
3.1
 GOVERNANCE AND ORGANIZATIONAL VIABILITY
3.1.1 The repository shall have a mission statement that reflects a commitment to the
preservation of, long term retention of, management of, and access to digital
information.
Supporting Text
This is necessary in order to ensure commitment to preservation, retention, management and


access at the repository’s highest administrative level.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Mission statement or charter of the repository or its parent organization that specifically
addresses or implicitly calls for the preservation of information and/or other resources under
its purview; a legal, statutory, or government regulatory mandate applicable to the repository
that specifically addresses or implicitly requires the preservation, retention, managem


ent and
access to information and/or other resources under its purview.
Discussion
The repository’s or its parent organization’s mission statement should explicitly address
preservation. If preservation is not among the primary purposes of an organization that
houses a digital repository then preservation may not be essential to the organization’s
mission. In some instances a repository pursues its preservation mission as an outgrowth of
the larger goals of an organization in which it is housed, such


 as a university or a government
agency, and its narrower mission may be formalized through policies explicitly adopted and
approved by the larger organization. Government agencies and other organizations may have
legal mandates that require they preserve materials, in which case these mandates can be
substituted for mission statements, as they define the purpose of the organization. Mission
statements should be kept up to date and continue to reflect the common goals and practices
for preservation.


3.1.2 The repository shall have a Preservation Strategic Plan that defines the
approach the repository will take in the long-term support of its mission.
Supporting Text
This is necessary in order to help the repository make administrative decisions, shape
policies, and allocate resources in order to successfully preserve its holdings.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Preservation Strategic Plan; meeting minutes; documentation of administrative decisions


which have been made.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 3-2
September 2011
Discussion
The strategic plan should be based on the organization’s established mission, and on its
defined values, vision and goals. Strategic plans typically cover a particular finite time
period, normally in the 3-5 year range.
3.1.2.1 The repository shall have an appropriate succession plan, contingency plans,
and/or escrow arrangements in place in case the repository cease


s to operate or the
governing or funding institution substantially changes its scope.
Supporting Text
This is necessary in order to preserve the information content entrusted to the repository by
handing it on to another custodian in the case that the repository ceases to operate.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Written and credible succession and contingency plan(s); explicit and specific statement
documenting the intent to ensure continuity of the repo


sitory, and the steps taken and to be
taken to ensure continuity; escrow of critical code, software, and metadata sufficient to
enable reconstitution of the repository and its content in the event of repository failure;
escrow and/or reserve funds set aside for contingencies; explicit agreements with successor
organizations documenting the measures to be taken to ensure the complete and formal
transfer of responsibility for the repository’s digital content and related assets, and granting
the requisit


e rights necessary to ensure continuity of the content and repository services.
Discussion
A repository’s failure threatens the long-term sustainability of a repository’s information
content. It is not sufficient for the repository to have an informal plan or policy regarding
where its data goes should a failure occur. A formal plan with identified procedures needs to
be in place.
3.1.2.2 The repository shall monitor its organizational environment to determine
when to execute its succession plan, con


tingency plans, and/or escrow arrangements.
Supporting Text
This is necessary in order to ensure that the repository can recognize when it is necessary to
execute those plans.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Administrative policies, procedures, protocols, requirements; budgets and financial analysis
documents; fiscal calendars; business plan(s); any evidence of active monitoring and
preparedness.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORI


ES
CCSDS 652.0-M-1
Page 3-3
September 2011
Discussion
The management of a repository should have formal procedures in place to periodically
check on the viability of the repository. This periodic check should be used to determine if,
or when, to execute the repository’s formal succession plan, contingency plans, and/or
escrow arrangements.
3.1.3 The repository shall have a Collection Policy or other document that specifies
the type of information it will preserve, retain,  manage, and provide acce


ss to.
Supporting Text
This is necessary in order that the repository has guidance on acquisition of digital content it
will preserve, retain, manage and provide access to.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Collection policy and supporting documents; Preservation Policy, mission, goals and vision
of the repository.
Discussion
The collection policy can be used to understand what the repository holds, what it does not
hold, and why.  The collection policy


supports the broader mission of the repository. Without
such a policy the repository is likely to collect in a haphazard manner, or store large amounts
of low-value digital content. The collection policy helps the organization to identify what
digital content it will and will not accept for ingestion. In an organization with a broader
mission than preservation of digital content the collection policy helps to define the role of
the repository within the larger organizational context.
3.2
ORGANIZATION


AL STRUCTURE AND STAFFING
3.2.1 The repository shall have identified and established the duties that it needs to
perform and shall have appointed staff with adequate skills and experience to fulfill
these duties.
Discussion
Staffing of the repository should be by personnel with the required training and skills to carry
out the activities of the repository. The repository should be able to document through
development plans, organizational charts, job descriptions, and related policies and
procedures


 that the repository is defining and maintaining the skills and roles that are
required for the sustained operation of the repository.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 3-4
September 2011
3.2.1.1 The repository shall have identified and established the duties that it needs to
perform.
Supporting Text
This is necessary in order to ensure that the repository can complete all tasks associated with
the long-term preservation and management of the data obj


ects.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
A staffing plan; competency definitions; job descriptions; staff professional development
plans; certificates of training and accreditation; plus evidence that the repository reviews and
maintains these documents as requirements evolve.
Discussion
Preservation depends upon a range of activities from maintaining hardware and software to
migrating content and storage media to negotiating intellectual property rights ag


reements. In
order to ensure long-term sustainability, a repository must be aware of all required activities
and demonstrate that it can successfully complete them. The repository can achieve these
aims by, for example, identifying the competencies and skill sets required to carry out its
activities over time—e.g., archival training, technical skills, and legal expertise.
3.2.1.2 The repository shall have the appropriate number of staff to support all
functions and services.
Supporting Text
This is


necessary in order to ensure repository staffing levels are adequate for preserving the
digital content and providing a secure, quality repository.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Organizational charts; definitions of roles and responsibilities; comparison of staffing levels
to industry benchmarks and standards.
Discussion
The repository should determine the appropriate number and level of staff that corresponds
to requirements and commitments. The repos


itory should also demonstrate how it evaluates
staff effectiveness and suitability to support its functions and services.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 3-5
September 2011
3.2.1.3 The repository shall have in place an active professional development program
that provides staff with skills and expertise development opportunities.
Supporting Text
This is necessary to ensure that staff skill sets evolve as the repository technology and
preservation pr


ocedures change.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
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.
Discussion
Technology and general practices for digital preservation will continue to change, as will the
requirements of its Designated Community, so the


repository must ensure that its staff’s skill
sets evolve.  Ideally the repository will meet this requirement through a lifelong learning
approach to developing and retaining staff.
3.3
PROCEDURAL ACCOUNTABILITY AND PRESERVATION POLICY
FRAMEWORK
Documentation assures stakeholders (consumers, producers, and contributors of digital
content) that the repository is meeting its requirements and fully performing its role as a
trustworthy digital repository. A repository must create documentation that refl


ects its
Mission Statement and Strategic Plan and captures its normal activities. This entails
documenting all repository processes, decision-making, and goal setting. Documentation is
provided so that the activities of the repository will be understood by stakeholders and
management. It ensures that repository policies and procedures are carried out in approved,
consistent ways, resulting in long-term preservation and access to digital content in its care.
Certification, the clearest indicator of a r


epository’s sound and standards-based practice, is
facilitated by procedural accountability and documentation.
3.3.1 The repository shall have defined its Designated Community and associated
knowledge base(s) and shall have these definitions appropriately accessible.
Supporting Text
This is necessary in order that it is possible to test that the repository meets the needs of its
Designated Community.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
A written definition


of the Designated Community.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 3-6
September 2011
Discussion
The Designated Community is defined as ‘an identified group of potential Consumers who
should be able to understand a particular set of information.  The Designated Community
may be composed of multiple user communities. A Designated Community is defined by the
archive and this definition may change/evolve over time’ (OAIS Glossary, reference [1]).
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 Geographic Information System (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 Flexible Image Transport
System (FITS) software suc


h as FITSIO, familiar with astronomical spectrographic
instruments.
– Student of Middle English with an understanding of Text Encoding Initiative (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.
– The repository has defined the external parties, and its assets, owners, and uses.  Two
groups: t


he publishers of scholarly journals and their readers, each of whom have
different rights to access material and different services offered to them.
Some repositories may call themselves, for example, a ‘dark archive’, an archive that has a
policy not to allow consumers to get access to its contents for a certain period of time, but
they would nevertheless need a Designated Community.
3.3.2 The repository shall have Preservation Policies in place to ensure its
Preservation Strategic Plan will be met.


Supporting Text
This is necessary in order to ensure that the repository can fulfill that part of its mission
related to preservation.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Preservation Policies; Repository Mission Statement.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 3-7
September 2011
Discussion
Repository policies show how the repository fulfills the requirements of the repository’s
preservation strategic plan. For


 example, a preservation strategic plan may contain a
requirement that the repository ‘comply with current preferred preservation standards’. The
preservation policy might then require that the repository ‘monitor current preservation
standards and ensure repository compliance with the preferred preservation standards’. In
another example the repository may be required by the strategic plan to keep its data
understandable. The preservation policy might then include information about the expected
level


 of understandability by the repository’s Designated Community for each Archival
Information Package.
3.3.2.1 The repository shall have mechanisms for review, update, and ongoing
development of its Preservation Policies as the repository grows and as technology and
community practice evolve.
Supporting Text
This is necessary in order that the repository has up-to-date, complete policies and
procedures in place that reflect the current requirements and practices of its community(ies)
for preservation


.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Current and past written documentation in the form of Preservation Policies, Preservation
Strategic Plans and Preservation Implementation Plans, procedures, protocols, and
workflows; specifications of review cycles for documentation; documentation detailing
reviews, surveys and feedback. If documentation is embedded in system logic, functionality
should demonstrate the implementation of policies and procedures.
Discussio


n
Preservation Policies capture organizational commitments and intents for staffing, security
and other preservation-related concerns. Preservation Implementation Plans address
preservation activities and practices such as transfer, submission, quality control, storage
management, metadata management, and access and rights management.  The repository may
find it beneficial to maintain all versions of the preservation policies (e.g., outdated versions
are clearly identified and maintained in some organ


ized way) in order to document the results
of monitoring for new developments, showing the repository’s responsiveness to prevailing
standards and practice, emerging requirements, and standards that are specific to the domain,
if appropriate, and similar developments. Qualified staff and peers are an important part of
the review process, as they help to update and expand these documents.  The policies should
be understandable by the repository staff in order for them to carry out their work.
Preservat


ion Policies and procedures must be demonstrated to be understandable and
implementable.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 3-8
September 2011
3.3.3 The repository shall have a documented history of the changes to its operations,
procedures, software, and hardware.
Supporting Text
This is necessary in order to provide an ‘audit trail’ through which stakeholders can identify
and trace decisions made by the repository.
Examples of Ways the Repository Ca


n Demonstrate It Is Meeting This Requirement
Capital equipment inventories; documentation of the acquisition, implementation, update,
and retirement of critical repository software and hardware; file retention and disposal
schedules and policies, copies of earlier versions of policies and procedures; minutes of
meetings.
Discussion
This documentation may include decisions about the organizational and technical
infrastructure. Documentation of or interviews with appropriate staff who can explain
repo


sitory practices and workflow should be available.
3.3.4 The repository shall commit to transparency and accountability in all actions
supporting the operation and management of the repository that affect the preservation
of digital content over time.
Supporting Text
This is necessary because transparency, in the sense of being available to anyone who wishes
to know, is the best assurance that the repository operates in accordance with accepted
standards and practices.
Examples of Ways the Repositor


y Can Demonstrate It Is Meeting This Requirement
Reports of financial and technical audits and certifications; disclosure of governance
documents, independent program reviews, and contracts and agreements with providers of
funding and critical services.
Discussion
If the repository uses software to capture information about its history, it should be able to
demonstrate these tracking tools. Where appropriate, the history is linked to relevant
preservation strategies and describes potential effects on


 preserving digital content. This
requirement does not mean that the organization must make information which would make
it vulnerable to competitors available, but rather that the organization commits to disclosing
its methods for preserving digital content at least to the Designated Community or other
appropriate stakeholder in order to demonstrate that it is meeting all current preservation
requirements.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 3-9
Septemb


er 2011
3.3.5 The repository shall define, collect, track, and appropriately provide its
information integrity measurements.
Supporting Text
This is necessary in order to provide documentation that it has developed or adapted
appropriate measures for ensuring the integrity of its holding.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Written definition or specification of the repository’s integrity measures (for example,
computed checksum or hash value); documentatio


n of the procedures and mechanisms for
monitoring integrity measurements and for responding to results of integrity measurements
that indicate digital content is at risk; an audit process for collecting, tracking, and presenting
integrity measurements; Preservation Policy and workflow documentation.
Discussion
The mechanisms to measure integrity will evolve as technology evolves. The repository may
provide documentation that it has developed or adapted appropriate measures for ensuring
the integrity


of its holdings. If protocols, rules and mechanisms are embedded in the
repository software, there should be some way to demonstrate the implementation of
integrity measures.
3.3.6 The repository shall commit to a regular schedule of self-assessment and
external certification.
Supporting Text
This is necessary in order to ensure the repository continues to be trustworthy and there is no
threat to its content.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Completed,


dated checklists from self-assessments and/or third-party audits; certificates
awarded for compliance with relevant ISO standards; timetables and evidence of adequate
budget allocations for future certification.
Discussion
A one-time check on trustworthiness is not adequate because many things will change over
time.  A longer term commitment should be demonstrated.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 3-10
September 2011
3.4
FINANCIAL SUSTAINABILITY
3.


4.1 The repository shall have short- and long-term business planning processes in
place to sustain the repository over time.
Supporting Text
This is necessary in order to ensure the viability of the repository over the period of time it
has promised to provide access to its contents for its Designated Community.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Up-to-date, multi-year strategic, operating and/or business plans; audited annual financial
statements; financia


l forecasts with multiple budget scenarios; contingency plans; market
analysis.
Discussion
An annual business planning process is commonly accepted as the standard for most
organizations.
3.4.2 The repository shall have financial practices and procedures which are
transparent, compliant with relevant accounting standards and practices, and audited
by third parties in accordance with territorial legal requirements.
Supporting Text
This is necessary in order to guard against malfeasance or other unto


ward activity that might
threaten the economic viability of the repository.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Demonstrated dissemination requirements for business planning and practices; citations to
and/or examples of accounting and audit requirements, standards, and practice; audited
annual financial statements.
Discussion
The repository cannot simply claim transparency, but should show that it adjusts its business
practices to keep them transparent, co


mpliant, 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 satisfying the needs of its Designated Community.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 3-11
September 2011
3.4.3 The repository shall have an ongoing commitment to analyze and report on
financial risk, benefit, investment, and expenditure (including assets, licenses, and
li


abilities).
Supporting Text
This is necessary in order to demonstrate that the repository 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.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Risk management documents that identify perceived and potential threats and planned or
imp


lemented responses (a risk register); technology infrastructure investment planning
documents; cost/benefit analyses; financial investment documents and portfolios;
requirements for and examples of licenses, contracts, and asset management; evidence of
revision based on risk.
Discussion
The repository should have a goal of maintaining an appropriate balance between risk and
benefits, investment and return.
3.5
CONTRACTS, LICENSES, AND LIABILITIES
3.5.1 The repository shall have and maintain appropr


iate contracts or deposit
agreements for digital materials that it manages, preserves, and/or to which it provides
access.
Supporting Text
This is necessary in order to ensure that the repository has the rights and authorizations
needed to enable it to collect and preserve digital content over time, make that information
available to its Designated Community, and defend those rights when challenged.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Properly signed and ex


ecuted deposit agreements and licenses in accordance with local,
national, and international laws and regulations; policies on third-party deposit arrangements;
definitions of service levels and permitted uses; repository policies on the treatment of
‘orphan works’ and copyright dispute resolution; reports of independent risk assessments of
these policies; procedures for regularly reviewing and maintaining agreements, contracts, and
licenses.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES


CCSDS 652.0-M-1
Page 3-12
September 2011
Discussion
Repositories may need to show evidence that their contracts are being followed. This is
especially important for those with third-party deposit arrangements. These arrangements
may require the repository to guarantee that relevant contracts, licenses, or deposit
agreements express rights, responsibilities, and expectations of each party. Contracts and
formal deposit agreements should be legitimate; that is, they need to be countersigned and
curr


ent. When the relationship between depositor and repository is less formal (e.g., 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 harvesting may find this requirement
difficult because of the way in which Web-based information is harvested/captured for long-
term preservation, and so contracts or deposit agreements are rarely r


equired. 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. Ideally, agreements
are tracked, linked, managed, and made accessible in a contracts database.
3.5.1.1 The repository shall have contracts or deposit agreements which specify and
transfer all necessary preservation rights, and those righ


ts transferred shall be
documented.
Supporting Text
This is necessary in order to have sufficient control of the information for preservation and
limit the repository’s exposure to liability or legal and financial harm.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Contracts, deposit agreements; specification(s) of rights transferred for different types of
digital content (if applicable); policy statements on requisite preservation rights.
Discussion
Because the rig


ht 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 to the repository certain rights
enabling appropriate and necessary preservation actions for the digital objects within the
repository. Because legal negotiations can take time, potenti


ally 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.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 3-13
September 2011
3.5.1.2 The repository shall have specified all appropriate aspects of acquisition,
maintenance, access, and withdrawal in writte


n agreements with depositors and other
relevant parties.
Supporting Text
This is necessary in order to ensure that the respective roles of repository, producers, and
contributors in the depositing of digital content and transfer of responsibility for preservation
are understood and accepted by all parties.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Properly executed submission agreements, deposit agreements, and deeds of gift; written
standard operating procedures


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


perty 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
demonstra


te that it does not need such agreements because, for instance, 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
(reference [B4]).
3.5.1.3 The repository shall have written policies that indic


ate when it accepts
preservation responsibility for contents of each set of submitted data objects.
Supporting Text
This is necessary in order to avoid misunderstandings between the repository and
producer/depositor as to when and how the transfer of responsibility for the digital content
occurs.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 3-14
September 2011
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Properly executed submi


ssion agreements, deposit agreements, and deeds of gift;
confirmation receipt sent back to producer/depositor.
Discussion
If this requirement is not met, there is a risk that, for example, the original is erased before
the repository has taken responsibility for the submitted data objects. Without the
understanding that the repository has already taken preservation responsibility for the SIP,
there is the risk that the producer/depositor may make changes to the data and these would
not be properly pr


eserved since they had already been ingested by the repository. For
example, for convenience the repository could receive a copy of raw science data from the
instrument at the same time the science team gets it, but the science team would have
responsibility for it until they turn over responsibility to the final repository. Repositories
that report back to their depositors generally will mark this acceptance with some form of
notification (for example, confirmation receipts) to the depositor. (This ma


y 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.
3.5.1.4 The repository shall have policies in place to address li


ability and challenges to
ownership/rights.
Supporting Text
This is necessary in order to minimize potential liability and challenges to the rights of the
repository.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
A definition of rights, licenses, and permissions to be obtained from producers and
contributors of digital content; citations to relevant laws and regulations; policy on
responding to challenges; documented track record for responding to challenges in ways


that
do not inhibit preservation; records of relevant legal advice sought and received.
Discussion
The repository’s Preservation Policies and Preservation Implementation Plans and
mechanisms should 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.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 3-15


September 2011
3.5.2 The repository shall track and manage intellectual property rights and
restrictions on use of repository content as required by deposit agreement, contract, or
license.
Supporting Text
This is necessary in order to allow the repository to track, act on, and verify rights and
restrictions related to the use of the digital objects within the repository.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
A Preservation 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;
documentation of monitoring by repository over time of changes in status and ownership of
intellectual property in digital content held by the repository; results from monitoring,
metadata that captures rights information.
Discussion
The repository should have a mechanism for tracking licen


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

AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-1
September 2011
4 DIGITAL OBJECT MANAGEMENT
4.1
INGEST: ACQUISITION OF CONTENT
4.1.1 The repository shall identify the Content Information and the Information
Propert


ies that the repository will preserve.
Supporting Text
This is necessary in order to make it clear to funders, depositors, and users what
responsibilities the repository is taking on and what aspects are excluded. It is also a
necessary step in defining the information which is needed from the information producers or
depositors.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Mission statement; submission agreements/deposit agreements/deeds of gift; workflow and
Prese


rvation 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.
Discussion
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 keep the units of the measurement of data fields and to normalize the
data during the ingest process. If unique identifiers are associated with digital objects before
ingest, they may also be properties that need to be preserved.
4.1.1.1 The repos


itory shall have a procedure(s) for identifying those Information
Properties that it will preserve.
Supporting Text
This is necessary to establish a clear understanding with depositors, funders, and the
repository’s Designated Communities how the repository determines and checks what the
characteristics and properties of preserved items will be over the long term. These procedures
will be necessary to confirm authenticity or to identify erroneous claims of authenticity of the
preserved digital record


.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-2
September 2011
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Definitions of the Information Properties which should be preserved; submission
agreements/deposit agreements, Preservation Policies, written processing procedures,
workflow documentation.
Discussion
These procedure(s) document the methods and factors a repository uses to determine the
aspects of different types of Con


tent Information for which it accepts preservation
responsibility to its designated communities. For example, a repository’s procedure may be
to use file formats in order to determine the properties it will preserve unless otherwise
specified in a deposit agreement. In this case, the repository would be able to demonstrate
provenance for objects that may have been the same file format when received but are
preserved differently over the long term.
4.1.1.2 The repository shall have a record of the Cont


ent Information and the
Information Properties that it will preserve.
Supporting Text
This is necessary in order to identify in writing the Content Information of the records for
which it has taken preservation responsibility and the Information Properties it has
committed to preserve for those records based on their Content Information.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Preservation Policies, processing manuals, collection inventories or surveys, logs of


Content
Information types, acquired preservation strategies, and action plans.
Discussion
The repository must demonstrate that it establishes and maintains an understanding of its
digital collections sufficient to carry out the preservation necessary to persist the properties
to which it has committed. The repository can use this information to determine the
effectiveness of its preservation activities over time.
4.1.2 The repository shall clearly specify the information that needs to be associated


with specific Content Information at the time of its deposit.
Supporting Text
This is necessary in order that there is a clear understanding of what needs to be acquired
from the Producer.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-3
September 2011
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Transfer requirements; producer-archive agreements; workflow plans to produce the AIP.
Discussion
For most types of digital objects t


o 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.
These criteria document what information the repository and its designated communities may
expect for digital object(s) upon deposit.  The depositor may be a harvesting process


 created
by the repository. 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’s being captured. The repository can
check what it receives from the producer based on the specifications.
4.1.3 The repository shall have adequate specifications enabling recognition and
parsing of the


 SIPs.
Supporting Text
This is necessary in order to be sure that the repository is able to extract information from the
SIPs.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Packaging Information for the SIPs; Representation Information for the SIP Content Data,
including documented file format specifications; published data standards; documentation of
valid object construction.
Discussion
The repository must be able to determine what the contents of a SIP are with r


egard to the
technical construction of its components. For example, the repository needs to be able to
recognize a TIFF file and confirm that it is not simply a file with a filename ending in
‘TIFF’. Another example, would be a website for which the repository would need to be able
to recognize and test the validity of the variety of file types (e.g., HTML, images, audio,
video, CSS, etc.) that are part of the website. This is necessary in order to confirm: 1) the SIP
AUDIT AND CERTIFICATION OF TRUSTW


ORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-4
September 2011
is what the repository expected; 2) the Content Information is correctly identified; and 3) the
properties of the Content Information to be preserved have been appropriately selected.
4.1.4 The repository shall have mechanisms to appropriately verify the identity of the
Producer of all materials.
Supporting Text
This is necessary in order to avoid providing erroneous provenance to the information which
is preserved.
Examples of Wa


ys the Repository Can Demonstrate It Is Meeting This Requirement
Legally binding submission agreements/deposit agreements/deeds of gift, evidence of
appropriate technological measures; logs from procedures and authentications.
Discussion
The repository’s written standard operating procedures and actual practices must ensure the
digital objects are obtained from the expected depositor. Examples of a Producer include
persons, organizations, corporate entities, or harvesting processes.  Different reposit


ories will
adopt different levels of proof needed; the Designated Community should have the
opportunity to review the evidence.
4.1.5 The repository shall have an ingest process which verifies each SIP for
completeness and correctness.
Supporting Text
This is necessary in order to detect and correct errors in the SIP when created and potential
transmission errors between the depositor and the repository.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Appropriate Pres


ervation Policy and Preservation Implementation Plan documents and
system log files from system(s) performing ingest procedure(s); logs or registers of files
received during the transfer and ingest process;  documentation of standard operating
procedures, detailed procedures, and/or workflows; format registries; definitions of
completeness and correctness.
Discussion
Information collected during the ingest process must be compared with information from
some other source to verify the correctness of t


he data transfer and ingest process. Other
sources will include technical and descriptive metadata obtained prior to ingest and may also
include expectations set by the depositor, the object producer, a format registry, or the
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-5
September 2011
repository’s own expectations. 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. This allows the repository to demonstrate that its preserved objects have
completely and correctly copied what it intended to copy from the SIPs. It also allows the
repository to document reasons for other SIP-relate


d actions such as rejecting the transfer,
suspending processing until the missing information is received, or 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. Whatever
checks are carried out must be consistent with the repository’s own documented definition
and understanding


of completeness and correctness. One thing that a repository might want
to do is check for network drop out or other corruption during the transmission process.
4.1.6 The repository shall obtain sufficient control over the Digital Objects to preserve
them.
Supporting Text
This is necessary in order to ensure that the preservation  can be accomplished, with physical
control, and is authorized, with legal control.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Documents


 showing the level of physical control the repository actually has. A separate
database/metadata catalog listing all of the digital objects in the repository and metadata
sufficient to validate the integrity of those objects (file size, checksum, hash, location,
number of copies, etc.)
Discussion
The repository must obtain complete control of the bits of the digital objects conveyed with
each SIP. Sufficient physical and legal control is necessary for the archives to make any
changes required by thei


r Preservation Implementation Plan for that data and to distribute it
to their consumers.  For example, in cases where SIPs only reference digital objects, the
repository must also reference the digital objects or preserve them if the current repository is
not committed to such preservation.
4.1.7 The repository shall provide the producer/depositor with appropriate responses
at agreed points during the ingest processes.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page


 4-6
September 2011
Supporting Text
This is necessary in order to ensure that the producer can verify that there are no inadvertent
lapses in communication which might otherwise allow loss of SIPs.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Submission agreements/deposit agreements/deeds of gift; workflow documentation; standard
operating procedures; evidence of ‘reporting back’ such as reports, correspondence, memos,
or emails.
Discussion
Based on the initial pr


ocessing plan and agreement between the repository and the
producer/depositor, the repository must provide the producer/depositor with progress reports
at agreed points throughout the ingest process. 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 ins


ufficient.
4.1.8 The repository shall have contemporaneous records of actions and
administration processes that are relevant to content acquisition.
Supporting Text
This is necessary to ensure that such documentation, which may be needed in an audit, is
captured and is accurate and authentic.
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 objec


ts, confirmation receipts sent back to providers.
Discussion
These records should be created on or about the time of the actions they refer to and are
related to actions taken during the Ingest: Acquisition of Content process (4.1). 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.2
INGEST: CREATION OF TH


E AIP
4.2.1 The repository shall have for each AIP or class of AIPs preserved by the
repository an associated definition that is adequate for parsing the AIP and fit for long-
term preservation needs.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-7
September 2011
Supporting Text
This is necessary to ensure that the AIP and its associated definition, including appropriate
Packaging Information, can always be found, processed and managed within the archive.
4.2.1


.1 The repository shall be able to identify which definition applies to which AIP.
Supporting Text
This is necessary to ensure that the appropriate definition is used when parsing/interpreting
an AIP.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Documentation clearly linking each AIP, or class of AIPs, to its definition.
Discussion
The repository may use any method for associating the definitions and the AIPs that provides
for the continued and continuous linkage of


 the two entities.
4.2.1.2 The repository shall have a definition of each AIP that is adequate for long-
term preservation, enabling the identification and parsing of all the required
components within that AIP.
Supporting Text
This is necessary in order to explicitly show that the AIPs are fit for their intended purpose,
that each component of an AIP has been adequately conceived and executed and the plans for
the maintenance of each AIP are in place. (See 4.3, Preservation Planning, below.)
Example


s of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Demonstration of the use of the definitions to extract Content Information and PDI
(Provenance, Access Rights, Context, Reference, and Fixity Information) from AIPs. It
should be noted that the Provenance of a digital object, for example, may be extended over
time to reflect additional preservation actions.
Discussion
Documentation should identify each class of AIP and describe how each is implemented
within the repository. Imple


mentations may, for example, involve some combination of files,
databases, and/or documents. Documentation shall relate 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. Documentation should clearly show that AIP components such as Representation
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-8
S


eptember 2011
Information and Provenance can be managed and kept up to date. The repository should
clearly identify when new versions of AIPs need to be created in order to keep them fit for
purpose. The external dependencies of the AIP should also be recorded.
Definitions should 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 repo


sitories will establish class descriptions
that apply to many AIPs. It must be possible to determine which definition applies to which
AIP. 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,
two repositories might both preserve only digital still images, both using multi-image TIFF
files as their preservation format. Repository 1 consists entirely of real-world photographic
im


ages 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 de


pend 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. 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 linked.
4.2.2 The repository shall have a description of how AIPs are constructed from SIPs.
Supporting Text
This is necessary in order to ensure that the AIP(s) adequately represents the information in
the SIP(s).
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Process description documents; documentation of the SIP-AIP relationship;


clear
documentation of how AIPs are derived from SIPs.
Discussion
In some cases, the AIP and SIP will be almost identical apart from packaging and location,
and the repository need only state this. In other cases, complex transformations (e.g., data
normalization) may be applied to objects during the ingest process, and a precise description
of these actions may be necessary to reflect how the AIP(s) has been adequately transformed
from the information in the SIP(s). The AIP construction description


should include
documentation that gives a detailed description of the ingest process for each SIP to AIP
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-9
September 2011
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 c


omplex descriptions case by case. Under such
circumstances case diaries or logs of actions taken to produce each AIP should be created
and maintained. In these cases, documentation should be mapped to individual AIPs, and the
mapping should be available for examination. Other repositories that can run a more
production-line approach may have a description for how each class of incoming objects is
transformed to produce the AIP. It must be clear which definition applies to which AIP. If, to
take a simp


le example, two separate processes each produce a TIFF file, it must be clear
which process was applied to produce a particular TIFF file.
4.2.3 The repository shall document the final disposition of all SIPs.
In particular the following aspect must be checked.
4.2.3.1 The repository shall follow documented procedures if a SIP is not incorporated
into an AIP or discarded and shall indicate why the SIP was not incorporated or
discarded.
Supporting Text
This is necessary in order to ensure that the SI


Ps received have been dealt with appropriately,
and in particular have not been accidentally lost.
Examples of Ways the Repository can Demonstrate it is Meeting these Requirements
System processing files; disposal records; donor or depositor agreements/deeds of gift;
provenance tracking system; system log files; 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 oc


curs; documentation of
normalization outcome and how the resulting AIP is different from the SIP(s).
Discussion
The timescale of this process will vary between repositories from seconds to many months,
but SIPs must not remain in an unprocessed 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 descr


iptive information should also document the provenance of all
digital objects.
4.2.4 The repository shall have and use a convention that generates persistent, unique
identifiers for all AIPs.
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-10
September 2011
In particular the following aspects must be checked.
4.2.4.1 The repository shall uniquely identify each AIP within the repository.
4.2.4.1.1 The repository shall have unique identifiers.
4.2.4.1.2 The reposi


tory shall assign and maintain persistent identifiers of the AIP and
its components so as to be unique within the context of the repository.
4.2.4.1.3 Documentation shall describe any processes used for changes to such
identifiers.
4.2.4.1.4 The repository shall be able to provide a complete list of all such identifiers
and do spot checks for duplications.
4.2.4.1.5 The system of identifiers shall be adequate to fit the repository’s current and
foreseeable future requirements such as numbers of objec


ts.
Supporting Text
This is necessary in order to ensure that each AIP can be unambiguously found in the future.
This is also necessary to ensure that each AIP can be distinguished from all other AIPs in the
repository.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Documentation describing naming convention and physical evidence of its application (e.g.,
logs).
4.2.4.2 The repository shall have a system of reliable linking/resolution services in
order to find the un


iquely identified object, regardless of its physical location.
Supporting Text
This is necessary in order that actions relating to AIPs can be traced over time, over system
changes, and over storage changes.
Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement
Documentation describing naming convention and physical evidence of its application (e.g.,
logs).
Discussion
A repository needs to ensure that there is in place an accepted, standard naming convention
that identifies


 its materials uniquely and persistently for use both in and outside the
AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES
CCSDS 652.0-M-1
Page 4-11
September 2011
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. Ideally, the unique ID lives as
long as the AIP; if it does not, there must be tr