Difference between revisions of "User:Nuess0r/Internal CCSDS 652.0-M-1 audit"

Revision as of 16:39, 23 January 2017 (view source) Nuess0r (talk | contribs) (copied the current audit report to do an update)		Revision as of 16:42, 23 January 2017 (view source) Nuess0r (talk | contribs) m Newer edit →
Line 1:		Line 1:
−	This is the full text of the [[wikipedia:CCSDS|CCSDS]] recommended practice [http://public.ccsds.org/publications/archive/652x0m1.pdf 652.0-M-1].	+	'''WARNING'''
−	The Public Domain Project is using this recommended practice to do internal audits of the project. This text is presented here as full quote to make direct links to the supporting text of a given requirement from the audit report. This makes it possible to write a much more compact and readable report without loosing any information for the interested reader.	+	'''This is only a working draft. This audit is not finished and does not represent the current state of the Public Domain Project!'''
		+	'''Date of audit report: June 2016'''
−	----	+	'''Version of audit report: 1.0'''
−	'''''Recommendation for Space Data System Practices'''''
−	'''''AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES RECOMMENDED PRACTICE CCSDS 652.0-M-1 MAGENTA BOOK'''''	+	This is the first audit of the [[PD:About|public domain project]]. This audit is the starting point for a long term program to develop and install the required organizational and technical methods to fulfill the requirements for a long term digital archive.
−	September 2011	+	This audit was done according to the recommended practice [[PD:CCSDS_652.0-M-1|652.0-M-1]] ''AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES'' from 2011 published by the Consultative Committee for Space Data Systems (CCSDS). The same committee that published the [http://public.ccsds.org/publications/archive/650x0m2.pdf Reference Model for an Open Archival Information System (OAIS)].
−	'''AUTHORITY'''	+	It was clear from the beginning, that this first audit will show a lot of weak points, not addressed problems and essential requirements that are not fulfilled.
−	: Issue:        Recommended Practice, Issue 1	+	Therefor the huge amount of requirements marked as not fulfilled (red) should not lead to the verdict that the public domain project is completely not trustworthy. The existence of this audit is more than many other archives provide as publicly available information source to evaluate the trustworthiness.
−	: Date:        September 2011
−	: Location:    Washington, DC, USA
−	This document has been approved for publication by the Management Council of the	+	The result of this first audit is the fundamental work for the development of requirements for future processes, technical methods and investments. It helps also to manage this development projects as it provides a metric to measure the impact of a proposal.
−	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:	+	This audit will be replaced by a more recent audit after the implementation of serious improvements. So it is possible to track the efforts the project invests into the longterm preservation and its trustworthiness.
−	: CCSDS Secretariat
−	: Space Communications and Navigation Office, 7L70
−	: Space Operations Mission Directorate
−	: NASA Headquarters
−	: Washington, DC 20546-0001, USA
−	'''STATEMENT OF INTENT'''	+	This audit documentation is structured in a similar way as the [[PD:CCSDS_652.0-M-1_AUDIT_AND_CERTIFICATION_OF_TRUSTWORTHY_DIGITAL_REPOSITORIES#STRUCTURE_OF_THIS_DOCUMENT|CCSDS 652.0-M-1 Recommended Practice]] document:
−	The Consultative Committee for Space Data Systems (CCSDS) is an organization officially	+	* introduction
−	established by the management of its members. The Committee meets periodically to address	+	* overview of audit and certification criteria
−	data systems problems that are common to all participants, and to formulate sound technical	+	* conclusion
−	solutions to these problems. Inasmuch as participation in the CCSDS is completely	+	* catalog of requirements
−	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	+	== [[PD:CCSDS_652.0-M-1#OVERVIEW OF AUDIT AND CERTIFICATION CRITERIA|OVERVIEW OF AUDIT AND CERTIFICATION CRITERIA]] ==
−	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	+	=== [[PD:CCSDS_652.0-M-1#A TRUSTWORTHY DIGITAL REPOSITORY|A TRUSTWORTHY DIGITAL REPOSITORY]] ===
−	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 Practice is issued, existing	+	Definition of a trustworthy digital repository as given in the CCSDS 652.0-M-1 Recommended Practice document:
−	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.
−	'''FOREWORD'''	+	''A trustworthy digital repository will understand threats to and risks within its systems.
		+	Constant monitoring, planning, and maintenance, as well as conscious actions 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.''
−	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	+	=== [[PD:CCSDS_652.0-M-1#DEFINITIONS|DEFINITIONS]] ===
−	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	+	Each requirement is marked with a color, to show its status of fulfillment:
−	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	+	* <span style="color:green">Requirements fulfilled</span>
−	modification of this document may occur. This Recommended Practice is therefore subject	+	* <span style="color:orange">Minor requirements are not fulfilled</span>
−	to CCSDS document management and change control procedures, which are defined in the	+	* <span style="color:red">Essential requirements not fulfilled</span>
−	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	+	These definitions from the original audit document all apply to this internal audit:
−	CCSDS Secretariat at the address indicated on page i.	+	* [[PD:CCSDS_652.0-M-1#TERMINOLOGY|TERMINOLOGY]]
		+	* [[PD:CCSDS_652.0-M-1#Glossary|Glossary]]
		+	* [[PD:CCSDS_652.0-M-1#CONVENTIONS|CONVENTIONS]]
−	'''DOCUMENT CONTROL'''	+	For a better understanding some paragraphs of the CCSDS 652.0-M-1 Recommended Practice are reproduced here.
−	Document    Title                              Date      Status	+	==== [[PD:CCSDS_652.0-M-1#CONFORMANCE|CONFORMANCE]] ====
−	CCSDS        Audit and Certification of        September Original issue	+	Original text: ''An archive that conforms to this Recommended Practice shall have satisfied the auditor on
−	652.0-M-1   Trustworthy Digital Repositories,  2011	+	each of the requirements.''
−	Recommended Practice,
−	Issue 1
−	----	+	==== [[PD:CCSDS_652.0-M-1#EVIDENCE|EVIDENCE]] ====
−	== INTRODUCTION ==	+	Each metric in the Recommended Practice 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.
−	=== PURPOSE AND SCOPE ===	+	==== [[PD:CCSDS_652.0-M-1#NOMENCLATURE|NOMENCLATURE]] ====
−	The main purpose of this document is to define a CCSDS Recommended Practice on which	+	The following conventions apply for the normative specifications in this Recommended Practice:
−	to base an audit and certification process for assessing the trustworthiness of digital	+	:a) the words ‘shall’ and ‘must’ imply a binding and verifiable specification;
−	repositories. The scope of application of this document is the entire range of digital	+	:b) the word ‘should’ implies an optional, but desirable, specification;
−	repositories.	+	:c) the word ‘may’ implies an optional specification;
−		+	:d) the words ‘is’, ‘are’, and ‘will’ imply statements of fact.
−	=== APPLICABILITY ===
−	This document 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.
−
−	=== RATIONALE ===
−	In 1996 the Task Force on Archiving of Digital Information (reference [B1]) declared, ‘a
−	critical component of digital archiving infrastructure 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 infrastructure 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 environment, 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.
−	Claims of trustworthiness are easy to make but are thus far difficult to justify or objectively	+	==== [[PD:CCSDS_652.0-M-1#ACRONYMS AND ABBREVIATIONS|ACRONYMS AND ABBREVIATIONS]] ====
−	prove. Establishing more clear criteria detailing what a trustworthy 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
−	enough 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
−	Administration (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.
−
−	=== 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 measures 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.
−	* Sections 3 to 5 provide the normative metrics against 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.
−
−	=== DEFINITIONS ===
−
−	==== ACRONYMS AND ABBREVIATIONS ====
	{|		{|
Line 193:		Line 84:
	|-		|-
	|DEDSL		|DEDSL
−	|Data Entity Specification Language (see reference [B7])	+	|Data Entity Specification Language
	|-		|-
	|DIP		|DIP
Line 225:		Line 116:
	|Extensible Markup Language		|Extensible Markup Language
	|}		|}
−
−	==== 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.
−
−	The OAIS Reference Model uses ‘digital archive’ to mean the organization responsible for
−	digital 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.
−
−	===== Glossary =====
−	Unless otherwise indicated, 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 with 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
−	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 fulfilled.
−
−	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.
−
−	==== 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.
−
−	==== 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;
−	** 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.
−
−	=== 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 creation 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.
−
−	=== 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 indicated
−	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.
−
−	: 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.
−
−
−	== 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.
−
−	=== A TRUSTWORTHY DIGITAL REPOSITORY ===
−	At the very basic level, the definition of a trustworthy digital repository must start with ‘a
−	mission 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 actions 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—transparency—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.
−
−	=== 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.
−
−	=== 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 complementary 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.
−	* Similarly, ISO 17799:2005 (reference [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 and 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 management, 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 to 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.
−
−	== ORGANIZATIONAL INFRASTRUCTURE ==
−	=== GOVERNANCE AND ORGANIZATIONAL VIABILITY ===
−	==== 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''<br \>
−	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''<br \>
−	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, management and
−	access to information and/or other resources under its purview.
−
−	''Discussion''<br \>
−	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.
−
−	==== 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''<br \>
−	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''<br \>
−	Preservation Strategic Plan; meeting minutes; documentation of administrative decisions
−	which have been made.
−
−	''Discussion''<br \>
−	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.
−
−	===== The repository shall have an appropriate succession plan, contingency plans, and/or escrow arrangements in place in case the repository ceases to operate or the governing or funding institution substantially changes its scope. =====
−
−	''Supporting Text''<br \>
−	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''<br \>
−	Written and credible succession and contingency plan(s); explicit and specific statement
−	documenting the intent to ensure continuity of the repository, and the steps taken and to be
−	taken to ensure continuity; 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 requisite rights necessary to ensure continuity of the content and repository services.
−
−	''Discussion''<br \>
−	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.
−
−	===== The repository shall monitor its organizational environment to determine when to execute its succession plan, contingency plans, and/or escrow arrangements. =====
−
−	''Supporting Text''<br \>
−	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''<br \>
−	Administrative policies, procedures, protocols, requirements; budgets and financial analysis
−	documents; fiscal calendars; business plan(s); any evidence of active monitoring and
−	preparedness.
−
−	''Discussion''<br \>
−	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.
−
−	==== The repository shall have a Collection Policy or other document that specifies the type of information it will preserve, retain, manage, and provide access to. ====
−
−	''Supporting Text''<br \>
−	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''<br \>
−	Collection policy and supporting documents; Preservation Policy, mission, goals and vision
−	of the repository.
−
−	''Discussion''<br \>
−	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.
−
−
−	=== ORGANIZATIONAL STRUCTURE AND STAFFING ===
−	==== 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''<br \>
−	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.
−
−
−	===== The repository shall have identified and established the duties that it needs to perform. =====
−
−	''Supporting Text''<br \>
−	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 objects.
−
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>
−	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''<br \>
−	Preservation depends upon a range of activities from maintaining hardware and software to
−	migrating content and storage media to negotiating intellectual property rights agreements. 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.
−
−	===== The repository shall have the appropriate number of staff to support all functions and services. =====
−
−	''Supporting Text''<br \>
−	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''<br \>
−	Organizational charts; definitions of roles and responsibilities; comparison of staffing levels
−	to industry benchmarks and standards.
−
−	''Discussion''<br \>
−	The repository should determine the appropriate number and level of staff that corresponds
−	to requirements and commitments. The repository should also demonstrate how it evaluates
−	staff effectiveness and suitability to support its functions and services.
−
−	===== The repository shall have in place an active professional development program that provides staff with skills and expertise development opportunities. =====
−
−	''Supporting Text''<br \>
−	This is necessary to ensure that staff skill sets evolve as the repository technology and
−	preservation procedures change.
−
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>
−	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''<br \>
−	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.
−
−
−	=== 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 reflects 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 repository’s sound and standards-based practice, is
−	facilitated by procedural accountability and documentation.
−
−	==== The repository shall have defined its Designated Community and associated knowledge base(s) and shall have these definitions appropriately accessible. ====
−
−	''Supporting Text''<br \>
−	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''<br \>
−	A written definition of the Designated Community.
−
−	''Discussion''<br \>
−	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 such 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: the 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.
−
−	==== The repository shall have Preservation Policies in place to ensure its Preservation Strategic Plan will be met. ====
−
−	''Supporting Text''<br \>
−	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''<br \>
−	Preservation Policies; Repository Mission Statement.
−
−	''Discussion''<br \>
−	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.
−
−	===== 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''<br \>
−	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''<br \>
−	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.
−
−	''Discussion''<br \>
−	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 organized 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.
−	Preservation Policies and procedures must be demonstrated to be understandable and
−	implementable.
−
−	==== The repository shall have a documented history of the changes to its operations, ====
−	procedures, software, and hardware.
−
−	''Supporting Text''<br \>
−	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 Can Demonstrate It Is Meeting This Requirement''<br \>
−	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''<br \>
−	This documentation may include decisions about the organizational and technical
−	infrastructure. Documentation of or interviews with appropriate staff who can explain
−	repository practices and workflow should be available.
−
−	==== 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''<br \>
−	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 Repository Can Demonstrate It Is Meeting This Requirement''<br \>
−	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''<br \>
−	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.
−
−	==== The repository shall define, collect, track, and appropriately provide its information integrity measurements. ====
−
−	''Supporting Text''<br \>
−	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''<br \>
−	Written definition or specification of the repository’s integrity measures (for example,
−	computed checksum or hash value); documentation 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''<br \>
−	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.
−
−	==== The repository shall commit to a regular schedule of self-assessment and external certification. ====
−
−	''Supporting Text''<br \>
−	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''<br \>
−	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''<br \>
−	A one-time check on trustworthiness is not adequate because many things will change over
−	time. A longer term commitment should be demonstrated.
−	=== FINANCIAL SUSTAINABILITY ===	+	=== [[PD:CCSDS_652.0-M-1#REFERENCES|REFERENCES]] ===
−	==== The repository shall have short- and long-term business planning processes in place to sustain the repository over time. ====
−	''Supporting Text''<br \>	+	[1] [http://public.ccsds.org/publications/archive/650x0m2.pdf Reference Model for an Open Archival Information System (OAIS)].
−	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''<br \>	+	For convenience the full text of the recommended practice CCSDS 652.0-M-1 AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES is readable on this wiki page: [[PD:CCSDS_652.0-M-1]]. Every requirement is directly linked to the corresponding explanation in the CCSDS 652.0-M-1 Recommended Practice.
−	Up-to-date, multi-year strategic, operating and/or business plans; audited annual financial
−	statements; financial forecasts with multiple budget scenarios; contingency plans; market
−	analysis.
−	''Discussion''<br \>	+	The original document is published on the CCSDS Website: [http://public.ccsds.org/publications/MagentaBooks.aspx CCSDS Recommended Practices (Magenta Books)]
−	An annual business planning process is commonly accepted as the standard for most
−	organizations.
−	==== 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''<br \>	+	== CONCLUSION AND FIELDS OF NON CONFORMANCE ==
−	This is necessary in order to guard against malfeasance or other untoward activity that might
−	threaten the economic viability of the repository.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	=== OVERVIEW ===
−	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''<br \>	+	Of the 108 normative metrics the final status is the following:
−	The repository cannot simply claim transparency, but should show that it adjusts its business
−	practices to keep them transparent, compliant, and auditable. Confidentiality requirements
−	may prohibit making information about the repository’s finances public, but the repository
−	should be able to demonstrate that it is satisfying the needs of its Designated Community.
		+	Metrics with all requirements fulfilled (green): 16<br/>
		+	Metrics where Minor requirements are not fulfilled (orange): 15<br/>
		+	Metrics with essential requirements not fulfilled (red): 77
−	==== The repository shall have an ongoing commitment to analyze and report on financial risk, benefit, investment, and expenditure (including assets, licenses, and liabilities). ====
−	''Supporting Text''<br \>	+	=== FIELDS OF NON CONFORMANCE ===
−	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''<br \>	+	==== ESSENTIAL DEFINITIONS ====
−	Risk management documents that identify perceived and potential threats and planned or
−	implemented 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''<br \>	+	In the project and between the project members there is a mutual understanding of the designated communities but it is not precisely defined and therefor the knowledge base of these communities is not known.
−	The repository should have a goal of maintaining an appropriate balance between risk and
−	benefits, investment and return.
−	=== CONTRACTS, LICENSES, AND LIABILITIES ===	+	The same is true for the definition of the content information that has to be preserved.
−	==== The repository shall have and maintain appropriate contracts or deposit agreements for digital materials that it manages, preserves, and/or to which it provides access. ====
−	''Supporting Text''<br \>	+	==== REPRESENTATION INFORMATION ====
−	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''<br \>	+	An example of an underdeveloped area is the field of representation information, because the awareness of the underlying problems and the concepts to handle them was missing in the project at the beginning of this audit. The consequent use of open standards and open source software makes it a bit less critical. But because any representation information is missing, it still creates a large long term risk for the repository.
−	Properly signed and executed 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.
−	''Discussion''<br \>	+	This whole topic has to be addressed in the near future.
−	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
−	current. 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 required. 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.
−	===== The repository shall have contracts or deposit agreements which specify and transfer all necessary preservation rights, and those rights transferred shall be documented. =====	+	==== MANAGEMENT AND PRESERVATION PLANNING ====
−	''Supporting Text''<br \>	+	The area of management tasks, strategic planning, development of policies and tracking is also underdeveloped. Also, there is no risk assessment installed and consequently there are no processes to observe the technical and legal environment of the repository on a regular basis.
−	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''<br \>	+	Also missing is a system to plan, manage and track work packages, milestones, issues etc. to support the further development of management and preservation planning.
−	Contracts, deposit agreements; specification(s) of rights transferred for different types of
−	digital content (if applicable); policy statements on requisite preservation rights.
−	''Discussion''<br \>	+	Furthermore a system which enables end users and producers to submit feedback and where submitters can observe the reactions and actions in response to their feedback is missing.
−	Because the right to change or alter digital information is often restricted by law to the
−	creator, it is important that digital repository contracts and agreements address the need to be
−	able to work with and potentially modify digital objects to keep them accessible. Repository
−	agreements with depositors must specify and/or transfer to the repository certain rights
−	enabling appropriate and necessary preservation actions for the digital objects within the
−	repository. Because legal negotiations can take time, potentially preventing or slowing the
−	ingest of digital objects at risk, it is acceptable for a digital repository to take in or accept
−	digital objects even with only minimal preservation rights using an open-ended agreement
−	and then deal with expanding to detailed rights later.
−	===== The repository shall have specified all appropriate aspects of acquisition, maintenance, access, and withdrawal in written agreements with depositors and other relevant parties. =====	+	==== DIGITAL OBJECT MANAGEMENT ====
−	''Supporting Text''<br \>	+	It was already known that the handling of the digital objects in the repository has its risks that have not been addressed yet.
−	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''<br \>	+	The digital objects are at risk because there is no system to prevent unintended deletion of objects, there is no off-site backup and there is no system and associated monitoring to guarantee the bit-level correctness of the digital objects now and in the future.
−	Properly executed submission agreements, deposit agreements, and deeds of gift; written
−	standard operating procedures.
−	''Discussion''<br \>	+	Also the system to create identifiers for AIPs is not documented and is not ideal for the scalability of the repository.
−	The deposit agreement specifies all aspects of these issues that are necessary for the
−	repository to carry out its function. There may be a single agreement covering all deposits, or
−	specific agreements for each deposit, or a standard agreement supplemented by special
−	conditions for some deposits. These special conditions may add to the standard agreement or
−	override some aspects of the standard agreement. Agreements may need to cover restrictions
−	on access and will need to cover all property rights in the digital objects. Agreements may
−	place responsibilities on depositors, such as ensuring that Submission Information Packages
−	(SIPs) conform to some pre-agreed standards, and may allow repositories to refuse SIPs that
−	do not meet these standards. Other repositories may take responsibility for fixing errors in
−	SIPs. The division of responsibilities must always be clear. Agreements, written or
−	otherwise, may not always be necessary. The burden of proof is on the repository to
−	demonstrate that it does not need such agreements 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]).
−	===== The repository shall have written policies that indicate when it accepts preservation responsibility for contents of each set of submitted data objects. =====
−	''Supporting Text''<br \>	+	=== CONCLUSION ===
−	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.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	As it was expected a lot of requirements are not fulfilled. However, the value of this audit is high because it detected very underdeveloped areas inside the project and as such raises the awareness of these problems. Twelve issues them can easily be fixed by documenting what is currently implemented.
−	Properly executed submission agreements, deposit agreements, and deeds of gift;
−	confirmation receipt sent back to producer/depositor.
−	''Discussion''<br \>	+	It is of high importance to fix the lack of the essential definitions about content information and designated community.
−	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 preserved 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 may depend on
−	repository responsibilities as designated in the depositor agreement.) A repository may mark
−	the transfer by sending a formal document, often a final signed copy of the transfer
−	agreement, back to the depositor signifying the completion of the transformation from SIP to
−	AIP process. Other approaches are equally acceptable. Brief daily updates may be generated
−	by a repository that only provides annual formal transfer reports.
−	===== The repository shall have policies in place to address liability and challenges to ownership/rights. =====	+	A large field to work on are the regular maintenance and observation tasks of the management and preservation planning. They have to be defined, documented, executed and reviewed.
−	''Supporting Text''<br \>	+	On the technical side, the completely missing representation information is a substantial shortcoming for a longterm repository. If this information is collected in the near future and maintained thereafter, the real risk of losing understandability is relatively low.
−	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''<br \>	+	== [[PD:CCSDS_652.0-M-1#ORGANIZATIONAL INFRASTRUCTURE|ORGANIZATIONAL INFRASTRUCTURE]] ==
−	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''<br \>	+	With this chapter the catalog of requirements starts. Every requirement is explained in the CCSDS 652.0-M-1 document, this explanation can be reached directly by clicking on the heading of the requirement.
−	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.
−	==== 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''<br \>	+	=== [[PD:CCSDS_652.0-M-1#GOVERNANCE AND ORGANIZATIONAL VIABILITY|GOVERNANCE AND ORGANIZATIONAL VIABILITY]] ===
−	This is necessary in order to allow the repository to track, act on, and verify rights and	+	==== [[PD:CCSDS_652.0-M-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.|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.]] ====
−	restrictions related to the use of the digital objects within the repository.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	<span style="color:green">Requirements fulfilled</span>
−	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''<br \>	+	[[:de:Statuten#Art._2_Zweck|Bylaws §2 of the Swiss Foundation Public Domain]]
−	The repository should have a mechanism for tracking licenses and contracts to which it is
−	obligated. Whatever the format of the tracking system, it must be sufficient for the institution
−	to track, act on, and verify rights and restrictions related to the use of the digital objects
−	within the repository.
		+	==== [[PD:CCSDS_652.0-M-1#The repository shall have a Preservation Strategic Plan that defines the approach the repository will take in the long-term support of its mission.|The repository shall have a Preservation Strategic Plan that defines the approach the repository will take in the long-term support of its mission.]] ====
−	== DIGITAL OBJECT MANAGEMENT ==	+	<span style="color:red">Essential requirements not fulfilled</span>
−	=== INGEST: ACQUISITION OF CONTENT ===
−	==== The repository shall identify the Content Information and the Information Properties that the repository will preserve. ====
−	''Supporting Text''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have an appropriate succession plan, contingency plans, and/or escrow arrangements in place in case the repository ceases to operate or the governing or funding institution substantially changes its scope.|The repository shall have an appropriate succession plan, contingency plans, and/or escrow arrangements in place in case the repository ceases to operate or the governing or funding institution substantially changes its scope.]] =====
−	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''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Mission statement; submission agreements/deposit agreements/deeds of gift; workflow and
−	Preservation 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''<br \>	+	There is no succession plan to address the case the repository ceases to operate or the governing or funding institution substantially changes its scope.
−	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.
−	===== The repository shall have a procedure(s) for identifying those Information Properties that it will preserve. =====	+	Escrow arrangements are not needed because of the consequent use of free and open source software.
−	''Supporting Text''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall monitor its organizational environment to determine when to execute its succession plan, contingency plans, and/or escrow arrangements.|The repository shall monitor its organizational environment to determine when to execute its succession plan, contingency plans, and/or escrow arrangements.]] =====
−	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.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	<span style="color:orange">Minor requirements are not fulfilled</span>
−	Definitions of the Information Properties which should be preserved; submission
−	agreements/deposit agreements, Preservation Policies, written processing procedures,
−	workflow documentation.
−	''Discussion''<br \>	+	Financial monitoring is done every year in retrospect to fulfill the accounting requirements for a charity foundation in Switzerland.
−	These procedure(s) document the methods and factors a repository uses to determine the	+	This includes an external audit by certified layers and is supervised by the [https://www.edi.admin.ch/edi/de/home/fachstellen/eidgenoessische-stiftungsaufsicht.html Eidgenössische Stiftungsaufsicht].
−	aspects of different types of Content 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.
−	===== The repository shall have a record of the Content Information and the Information Properties that it will preserve. =====	+	Monitoring the organizational environment is not in place and fiscal planning is underdeveloped.
−	''Supporting Text''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have a Collection Policy or other document that specifies the type of information it will preserve, retain, manage, and provide access to.|The repository shall have a Collection Policy or other document that specifies the type of information it will preserve, retain, manage, and provide access to.]] ====
−	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''<br \>	+	<span style="color:green">Requirements fulfilled</span>
−	Preservation Policies, processing manuals, collection inventories or surveys, logs of Content
−	Information types, acquired preservation strategies, and action plans.
−	''Discussion''<br \>	+	[[:de:Statuten#Art._2_Zweck|Bylaws §2 of the Swiss Foundation Public Domain]]
−	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.
−	==== The repository shall clearly specify the information that needs to be associated with specific Content Information at the time of its deposit. ====
−	''Supporting Text''<br \>	+	=== [[PD:CCSDS_652.0-M-1#ORGANIZATIONAL STRUCTURE AND STAFFING|ORGANIZATIONAL STRUCTURE AND STAFFING]] ===
−	This is necessary in order that there is a clear understanding of what needs to be acquired	+	==== [[PD:CCSDS_652.0-M-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.|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.]] ====
−	from the Producer.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Transfer requirements; producer-archive agreements; workflow plans to produce the AIP.
−	''Discussion''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have identified and established the duties that it needs to perform.|The repository shall have identified and established the duties that it needs to perform.]] =====
−	For most types of digital objects to be ingested, the repository should have written criteria,
−	prepared by the repository on its own or in conjunction with other parties, that specify
−	exactly what digital object(s) are transferred, what documentation is associated with the
−	object(s), and any restrictions on access, whether technical, regulatory, or donor-imposed.
−	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.
−	==== The repository shall have adequate specifications enabling recognition and parsing of the SIPs. ====	+	<span style="color:red">Essential requirements not fulfilled</span>
−	''Supporting Text''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have the appropriate number of staff to support all functions and services.|The repository shall have the appropriate number of staff to support all functions and services.]] =====
−	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''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	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''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have in place an active professional development program that provides staff with skills and expertise development opportunities.|The repository shall have in place an active professional development program that provides staff with skills and expertise development opportunities.]] =====
−	The repository must be able to determine what the contents of a SIP are with regard 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
−	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.
−	==== The repository shall have mechanisms to appropriately verify the identity of the Producer of all materials. ====	+	<span style="color:red">Essential requirements not fulfilled</span>
−	''Supporting Text''<br \>
−	This is necessary in order to avoid providing erroneous provenance to the information which
−	is preserved.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	=== [[PD:CCSDS_652.0-M-1#PROCEDURAL ACCOUNTABILITY AND PRESERVATION POLICY FRAMEWORK|PROCEDURAL ACCOUNTABILITY AND PRESERVATION POLICY FRAMEWORK]] ===
−	Legally binding submission agreements/deposit agreements/deeds of gift, evidence of
−	appropriate technological measures; logs from procedures and authentications.
−	''Discussion''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have defined its Designated Community and associated knowledge base(s) and shall have these definitions appropriately accessible.|The repository shall have defined its Designated Community and associated knowledge base(s) and shall have these definitions appropriately accessible.]] ====
−	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 repositories will
−	adopt different levels of proof needed; the Designated Community should have the
−	opportunity to review the evidence.
−	==== The repository shall have an ingest process which verifies each SIP for completeness and correctness. ====	+	<span style="color:red">Essential requirements not fulfilled</span>
−	''Supporting Text''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have Preservation Policies in place to ensure its Preservation Strategic Plan will be met.|The repository shall have Preservation Policies in place to ensure its Preservation Strategic Plan will be met.]] ====
−	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''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Appropriate Preservation 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''<br \>	+	===== [[PD:CCSDS_652.0-M-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.|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.]] =====
−	Information collected during the ingest process must be compared with information from
−	some other source to verify the correctness of the 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
−	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-related 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.
−	==== The repository shall obtain sufficient control over the Digital Objects to preserve them. ====	+	<span style="color:red">Essential requirements not fulfilled</span>
−	''Supporting Text''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have a documented history of the changes to its operations,|The repository shall have a documented history of the changes to its operations,]] ====
−	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''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	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''<br \>	+	==== [[PD:CCSDS_652.0-M-1#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.|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.]] ====
−	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 their 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.
−	==== The repository shall provide the producer/depositor with appropriate responses at agreed points during the ingest processes. ====	+	<span style="color:orange">Minor requirements are not fulfilled</span>
−	''Supporting Text''<br \>	+	'''Reports of financial and technical audits:'''<br/>
−	This is necessary in order to ensure that the producer can verify that there are no inadvertent	+	[[:de:Publikationen#Stiftung|Publications of the Foundation]] do not include yet financial reports because the foundation is quite new and the first report covering 2014 is just finished. But it is planned to publish them.
−	lapses in communication which might otherwise allow loss of SIPs.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	The first technical audit is the one that is presented in this document. It is published publicly on this page: [[:en:PD:Internal_Audit_(CCSDS_652.0-M-1)|Internal Audit (CCSDS_652.0-M-1)]]
−	Submission agreements/deposit agreements/deeds of gift; workflow documentation; standard
−	operating procedures; evidence of ‘reporting back’ such as reports, correspondence, memos,
−	or emails.
−	''Discussion''<br \>	+	'''Disclosure of governance documents:'''<br/>
−	Based on the initial processing plan and agreement between the repository and the	+	As can be seen from other requirements there are no governance documents yet, so there is nothing to be publicly available.
−	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 insufficient.
−	==== The repository shall have contemporaneous records of actions and administration processes that are relevant to content acquisition. ====	+	'''Contracts and agreements with providers of funding and critical services:'''<br/>
		+	They are not publicly available yet.
−	''Supporting Text''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall define, collect, track, and appropriately provide its information integrity measurements.|The repository shall define, collect, track, and appropriately provide its information integrity measurements.]] ====
−	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''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Written documentation of decisions and/or action taken; preservation metadata logged,
−	stored, and linked to pertinent digital objects, confirmation receipts sent back to providers.
−	''Discussion''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall commit to a regular schedule of self-assessment and external certification.|The repository shall commit to a regular schedule of self-assessment and external certification.]] ====
−	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.
		+	<span style="color:red">Essential requirements not fulfilled</span>
−	=== INGEST: CREATION OF THE AIP ===
−	==== 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. ====
−	''Supporting Text''<br \>	+	=== [[PD:CCSDS_652.0-M-1#FINANCIAL SUSTAINABILITY|FINANCIAL SUSTAINABILITY]] ===
−	This is necessary to ensure that the AIP and its associated definition, including appropriate	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have short- and long-term business planning processes in place to sustain the repository over time.|The repository shall have short- and long-term business planning processes in place to sustain the repository over time.]] ====
−	Packaging Information, can always be found, processed and managed within the archive.
−	===== The repository shall be able to identify which definition applies to which AIP. =====	+	<span style="color:red">Essential requirements not fulfilled</span>
−	''Supporting Text''<br \>	+	==== [[PD:CCSDS_652.0-M-1#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.|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.]] ====
−	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''<br \>	+	<span style="color:green">Requirements fulfilled</span>
−	Documentation clearly linking each AIP, or class of AIPs, to its definition.
−	''Discussion''<br \>	+	The auditor has witnessed audited annual financial statements for the year 2014 and 2015. As shown above, these statements are not publicly available which should be changed.
−	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.
−	===== 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. =====	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have an ongoing commitment to analyze and report on financial risk, benefit, investment, and expenditure (including assets, licenses, and liabilities).|The repository shall have an ongoing commitment to analyze and report on financial risk, benefit, investment, and expenditure (including assets, licenses, and liabilities).]] ====
−	''Supporting Text''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	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.)
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>
−	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''<br \>	+	=== [[PD:CCSDS_652.0-M-1#CONTRACTS, LICENSES, AND LIABILITIES|CONTRACTS, LICENSES, AND LIABILITIES]] ===
−	Documentation should identify each class of AIP and describe how each is implemented	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have and maintain appropriate contracts or deposit agreements for digital materials that it manages, preserves, and/or to which it provides access.|The repository shall have and maintain appropriate contracts or deposit agreements for digital materials that it manages, preserves, and/or to which it provides access.]] ====
−	within the repository. Implementations 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
−	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	+	<span style="color:red">Essential requirements not fulfilled</span>
−	type. Repositories that store a wide variety of object types may need a specific definition for
−	each AIP they hold, but it is expected that most repositories will establish class descriptions
−	that apply to many AIPs. It must be possible to determine which definition applies to which
−	AIP. 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
−	images intended for viewing by people and has a single definition covering all of its AIPs.
−	(The definition may refer to a local or external definition of the TIFF format.) Repository 2
−	contains some images, such as medical x-rays, that are intended for computer analysis rather
−	than viewing by the human eye, and other images that are like those in Repository 1.
−	Repository 2 should perhaps define two classes of AIPs, even though it only uses one storage
−	format for both. A future preservation action may depend on the intended use of the image—
−	an action that changes the bit-depth of the image in a way that is not perceivable to the
−	human eye may be satisfactory for real-world photographs but not for medical images, for
−	example. 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.
−	==== The repository shall have a description of how AIPs are constructed from SIPs. ====	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have contracts or deposit agreements which specify and transfer all necessary preservation rights, and those rights transferred shall be documented.|The repository shall have contracts or deposit agreements which specify and transfer all necessary preservation rights, and those rights transferred shall be documented.]] =====
−	''Supporting Text''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	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''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have specified all appropriate aspects of acquisition, maintenance, access, and withdrawal in written agreements with depositors and other relevant parties.|The repository shall have specified all appropriate aspects of acquisition, maintenance, access, and withdrawal in written agreements with depositors and other relevant parties.]] =====
−	Process description documents; documentation of the SIP-AIP relationship; clear
−	documentation of how AIPs are derived from SIPs.
−	''Discussion''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	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
−	transformation, typically consisting of an overview of general processing being applied to all
−	such transformations, augmented with description of different classes of such processing and,
−	when applicable, with special transformations that were needed.
−	Some repositories may need to produce these complex descriptions case by case. Under such	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have written policies that indicate when it accepts preservation responsibility for contents of each set of submitted data objects.|The repository shall have written policies that indicate when it accepts preservation responsibility for contents of each set of submitted data objects.]] =====
−	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 simple example, two separate processes each produce a TIFF file, it must be clear
−	which process was applied to produce a particular TIFF file.
−	==== The repository shall document the final disposition of all SIPs. In particular the following aspect must be checked. ====	+	<span style="color:red">Essential requirements not fulfilled</span>
−	===== 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. =====	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have policies in place to address liability and challenges to ownership/rights.|The repository shall have policies in place to address liability and challenges to ownership/rights.]] =====
−	''Supporting Text''<br \>	+	<span style="color:green">Requirements fulfilled</span>
−	This is necessary in order to ensure that the SIPs 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''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall track and manage intellectual property rights and restrictions on use of repository content as required by deposit agreement, contract, or license.|The repository shall track and manage intellectual property rights and restrictions on use of repository content as required by deposit agreement, contract, or license.]] ====
−	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 occurs; documentation of
−	normalization outcome and how the resulting AIP is different from the SIP(s).
−	''Discussion''<br \>	+	<span style="color:green">Requirements fulfilled</span>
−	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 descriptive information should also document the provenance of all
−	digital objects.
−	==== The repository shall have and use a convention that generates persistent, unique identifiers for all AIPs. ====	+	The goal of the Public Domain Project is to make accessible digitized audio content. This requires a thoroughly checking of the intellectual property rights of each work.
−	In particular the following aspects must be checked.	+	The result of this effort can be seen on every detail information page like this [[:pool:Gramophone-14678-b45142| example (Gramophone-14678-b45142)]]. Every work includes information about the copyright status in Switzerland, the European Union and the United States including the year when the work enters the public domain. With this information it is possible to track once a year which works entered the public domain (Relevant is only the year, so once a year is enough) and can be made accessible.
−	===== The repository shall uniquely identify each AIP within the repository. =====	+	== [[PD:CCSDS_652.0-M-1#DIGITAL OBJECT MANAGEMENT|DIGITAL OBJECT MANAGEMENT]] ==
		+	=== [[PD:CCSDS_652.0-M-1#INGEST: ACQUISITION OF CONTENT|INGEST: ACQUISITION OF CONTENT]] ===
		+	==== [[PD:CCSDS_652.0-M-1#The repository shall identify the Content Information and the Information Properties that the repository will preserve.|The repository shall identify the Content Information and the Information Properties that the repository will preserve.]] ====
−	====== The repository shall have unique identifiers. ======	+	<span style="color:red">Essential requirements not fulfilled</span>
−	====== The repository shall assign and maintain persistent identifiers of the AIP and its components so as to be unique within the context of the repository. ======	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have a procedure(s) for identifying those Information Properties that it will preserve.|The repository shall have a procedure(s) for identifying those Information Properties that it will preserve.]] =====
−	====== Documentation shall describe any processes used for changes to such identifiers. ======	+	<span style="color:red">Essential requirements not fulfilled</span>
−	====== The repository shall be able to provide a complete list of all such identifiers and do spot checks for duplications. ======	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have a record of the Content Information and the Information Properties that it will preserve.|The repository shall have a record of the Content Information and the Information Properties that it will preserve.]] =====
−	====== The system of identifiers shall be adequate to fit the repository’s current and foreseeable future requirements such as numbers of objects. ======	+	<span style="color:red">Essential requirements not fulfilled</span>
−	''Supporting Text''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall clearly specify the information that needs to be associated with specific Content Information at the time of its deposit.|The repository shall clearly specify the information that needs to be associated with specific Content Information at the time of its deposit.]] ====
−	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''<br \>	+	<span style="color:orange">Minor requirements are not fulfilled</span>
−	Documentation describing naming convention and physical evidence of its application (e.g.,
−	logs).
−	===== The repository shall have a system of reliable linking/resolution services in order to find the uniquely identified object, regardless of its physical location. =====	+	The wiki template [[:pool:Template:Audio_file|Audio_file]]shows all needed information. But there is limited documentation about it and how to handle it. The section on references is appropriate but the problems start with date fields because there is no date format specified. Also problematic is, that there is no information about the vocabulary to use, should it be a controlled vocabulary (which one) is it free, are there different requirements for each field?
−	''Supporting Text''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have adequate specifications enabling recognition and parsing of the SIPs.|The repository shall have adequate specifications enabling recognition and parsing of the SIPs.]] ====
−	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''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Documentation describing naming convention and physical evidence of its application (e.g.,
−	logs).
−	''Discussion''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have mechanisms to appropriately verify the identity of the Producer of all materials.|The repository shall have mechanisms to appropriately verify the identity of the Producer of all materials.]] ====
−	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
−	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 traceability. Subsection 4.2.1 requires that the
−	components of an AIP be suitably bound and identified for long-term management, but
−	places no restrictions on how AIPs are identified with files. Thus, in the general case, an AIP
−	may be distributed over many files, or a single file may contain more than one AIP.
−	Therefore identifiers and filenames may not necessarily correspond to each other.
−	Documentation must represent these relationships.
−	==== The repository shall have access to necessary tools and resources to provide authoritative Representation Information for all of the digital objects it contains. In particular the following aspects must be checked. ====	+	<span style="color:orange">Minor requirements are not fulfilled</span>
−	===== The repository shall have tools or methods to identify the file type of all submitted Data Objects. =====	+	To upload AIPs (Flac files) to the archival storage the FTP protocol is used with user authentication. The user name of the person who uploaded a certain file is visible on the file system of the archival storage as the UNIX owner of the file. This information is not visible and therefor not verifiable by the designated community.
−	===== The repository shall have tools or methods to determine what Representation Information is necessary to make each Data Object understandable to the Designated Community. =====	+	The history of the associated PDI and the identity of its creator is publicly visible and can be verified by everyone. The PDI is stored and edited in wiki pages and MediaWiki requires a password protected user login to edit this information.
−	===== The repository shall have access to the requisite Representation Information. =====	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have an ingest process which verifies each SIP for completeness and correctness.|The repository shall have an ingest process which verifies each SIP for completeness and correctness.]] ====
−	===== The repository shall have tools or methods to ensure that the requisite Representation Information is persistently associated with the relevant Data Objects. =====	+	<span style="color:red">Essential requirements not fulfilled</span>
−	''Supporting Text''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall obtain sufficient control over the Digital Objects to preserve them.|The repository shall obtain sufficient control over the Digital Objects to preserve them.]] ====
−	This is necessary in order to ensure that the repository’s digital objects are understandable to
−	the Designated Community.
−	''Examples of Ways the Repository can Demonstrate it is Meeting these Requirements''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall provide the producer/depositor with appropriate responses at agreed points during the ingest processes.|The repository shall provide the producer/depositor with appropriate responses at agreed points during the ingest processes.]] ====
−	Subscription or access to registries of Representation Information (including format
−	registries); viewable records in local registries (with persistent links to digital objects);
−	database records that include Representation Information and a persistent link to relevant
−	digital objects.
−	''Discussion''<br \>	+	<span style="color:green">Requirements fulfilled</span>
−	These tools and resources can be held internally or can be shared via, for example, a trusted
−	set of registries. However, this requirement does not demand that each repository has such
−	tools and resources, merely that it has access to them. For example a repository may access
−	external registries. 1 Any such registry is a specialized type of repository, which itself must be
−	certified/trustworthy. The repository may use these types of standardized, authoritative
−	information sources to identify and/or verify the Representation Information components of
−	Content Information and PDI. This will reduce the long-term maintenance costs to the
−	repository and improve quality control. Sometimes there is both general Representation
−	Information (e.g., format information) and specific Representation Information (e.g.,
−	meanings of individual fields within a dataset). Often the general information will be
−	available in an external repository, but the local repository may need to maintain the
−	instance-specific information. It is likely that many repositories would wish to keep local
−	copies of relevant Representation Information; however, this may not be practical in all
−	cases. Even where a repository strives to keep all such information locally there may be, for
−	example, a schedule of updates which means that until an update is performed, the local
−	Representation Information is incomplete. This may be regarded as a kind of local caching
−	of, for example, the Representation Information held in registries. Alternatively one may say
−	that in these cases, the use of international registries is not meant to replace local registries
−	but instead serve as a resource to verify or obtain independent, authoritative information
−	about any and all Representation Information. Good practice suggests that any locally held
−	Representation Information should also be made available to other repositories via a trusted
−	registry. In addition any item of Representation Information should itself have adequate
−	Representation Information to ensure that the Designated Community can understand and use
−	the data object being preserved.
−	==== The repository shall have documented processes for acquiring Preservation Description Information (PDI) for its associated Content Information and acquire PDI in accordance with the documented processes. In particular the following aspects must be checked. ====	+	With the depositors there are no agreed points where responses are necessary. But it is possible to get a lot of information about ingested objects by the category listing (each depositor has it's own category to list all his objects), the recent changes page of the wiki and other ways (eg. watchlists).
		+	Reports about the ingestion process are done usually annually for the financial supporters.
−	===== The repository shall have documented processes for acquiring PDI. =====	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have contemporaneous records of actions and administration processes that are relevant to content acquisition.|The repository shall have contemporaneous records of actions and administration processes that are relevant to content acquisition.]] ====
−	===== The repository shall execute its documented processes for acquiring PDI. =====	+	<span style="color:red">Essential requirements not fulfilled</span>
−	===== The repository shall ensure that the PDI is persistently associated with the relevant Content Information. =====
−	''Supporting Text''<br \>	+	=== [[PD:CCSDS_652.0-M-1#INGEST: CREATION OF THE AIP|INGEST: CREATION OF THE AIP]] ===
−	This is necessary in order to ensure that an auditable trail to support claims of authenticity is	+	==== [[PD:CCSDS_652.0-M-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.|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.]] ====
−	available, that unauthorized changes to the digital holdings can be detected, and that the
−	digital objects can be identified and placed in their appropriate context.
−	: The Unified Digital Formats Registry (UDFR, http://www.gdfr.info/udfr.html) and the UK Digital Curation Centre’s Registry Repository of Representation Information (RRORI, http://registry.dcc.ac.uk) are two emerging examples.	+	<span style="color:red">Essential requirements not fulfilled</span>
−	''Examples of Ways the Repository can Demonstrate it is Meeting these Requirements''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall be able to identify which definition applies to which AIP.|The repository shall be able to identify which definition applies to which AIP.]] =====
−	Standard operating procedures; manuals describing ingest procedures; viewable
−	documentation on how the repository acquires and manages Preservation Description
−	Information (PDI); creation of checksums or digests, consulting with Designated Community
−	about Context.
−	''Discussion''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	PDI is needed not only by the repository to help ensure the Content Information is not
−	corrupted (Fixity) and is findable (Reference Information), but to help ensure the Content
−	Information is adequately understandable by providing a historical perspective (Provenance
−	Information) and by providing relationships to other information (Context Information). The
−	extent of such information needs is best addressed by members of the Designated
−	Community(ies). The PDI must be permanently associated with Content Information.
−	==== The repository shall ensure that the Content Information of the AIPs is understandable for their Designated Community at the time of creation of the AIP. In particular the following aspects must be checked. ====	+	===== [[PD:CCSDS_652.0-M-1#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.|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.]] =====
−	===== Repository shall have a documented process for testing understandability for their Designated Communities of the Content Information of the AIPs at their creation. =====	+	<span style="color:red">Essential requirements not fulfilled</span>
−	===== The repository shall execute the testing process for each class of Content Information of the AIPs. =====	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have a description of how AIPs are constructed from SIPs.|The repository shall have a description of how AIPs are constructed from SIPs.]] ====
−	===== The repository shall bring the Content Information of the AIP up to the required level of understandability if it fails the understandability testing. =====	+	<span style="color:red">Essential requirements not fulfilled</span>
−	''Supporting Text''<br \>	+	The process is not documented but essentially the SIP is the Flac file that is uploaded to the storage server and forms together with the detailed description in the wiki the AIP. So the AIP consists of the wiki page and the linked Flac file.
−	This is necessary in order to ensure that one of the primary tests of preservation, namely that
−	the digital holdings are understandable by their Designated Community, can be met. (See 4.3
−	for additional requirements for understandability beyond ingest.)
−	''Examples of Ways the Repository can Demonstrate it is Meeting these Requirements''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall document the final disposition of all SIPs. In particular the following aspect must be checked.|The repository shall document the final disposition of all SIPs. In particular the following aspect must be checked.]] ====
−	Test procedures to be run against the digital holdings to ensure their understandability to the
−	defined Designated Community; records of such tests being performed and evaluated;
−	evidence of gathering or identifying Representation Information to fill any intelligibility gaps
−	which have been found; retention of individuals with the discipline expertise.
−	''Discussion''<br \>	+	===== [[PD:CCSDS_652.0-M-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.|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.]] =====
−	This requirement is concerned with the understandability of the AIP. If the ingested material
−	is not understandable, the repository needs to ingest or make available additional information
−	to make sure that the AIPs are understandable to the Designated Community(ies). For
−	example, if documents are written in a dying language and the Designated Community is no
−	longer able to understand the language the documents are written in, the repository would
−	need to provide additional documentation that would allow the Designated Community to
−	understand the documents (e.g., translations of the documents in a language the Designated
−	Community could understand or dictionaries that would allow the Designated Communities
−	to translate the documents into a language its members understand).
−	==== The repository shall verify each AIP for completeness and correctness at the point it is created. ====	+	<span style="color:orange">Minor requirements are not fulfilled</span>
−	''Supporting Text''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have and use a convention that generates persistent, unique identifiers for all AIPs.|The repository shall have and use a convention that generates persistent, unique identifiers for all AIPs.]] ====
−	This is necessary in order to ensure that what is maintained over the long term is as it should
−	be and can be traced to the information provided by the Producers.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Description of the procedure that verifies completeness and correctness of the AIPs; logs of
−	the procedure.
−	''Discussion''<br \>	+	Each AIP is identified by a string composed in the following way: <Label>-<Catalog number>-<Order number>
−	The repository should be sure that the AIPs it creates are as they are expected to be by
−	checking them against the associated definition for each AIP or class of AIP (see 4.2.1) and
−	the description of how AIPs are constructed from SIPs (see 4.2.2). If the repository has a
−	standard process to verify SIPs for both completeness and correctness and a demonstrably
−	correct process for transforming SIPs into AIPs, then it simply needs to demonstrate that the
−	initial checks were carried out successfully and that the transformation process was carried
−	out without indicating errors. On the other hand repositories that must create unique
−	processes for many of their AIPs will also need to generate unique methods for validating the
−	completeness and correctness of AIPs. This may include performing tests of some sort on the
−	content of the AIP that can be compared with tests on the SIP. Such tests might be simple
−	(counting the number of records in a file, or performing some simple statistical measure), but
−	they might be complex. Documentation should describe how the completeness and
−	correctness of AIPs is ensured, starting with receipt from the producer and continuing
−	through AIP creation and supporting long-term preservation. Example approaches include
−	the use of checksums, testing that checksums are still correct at various points during ingest
−	and preservation, logs that such checks have been made, and any special tests that may be
−	required for a particular AIP instance or class.
−	==== The repository shall provide an independent mechanism for verifying the integrity of the repository collection/content. ====	+	Example:
		+	* Label: Homocord
		+	* Catalog number: B 367
		+	* Order number: M 17234
−	''Supporting Text''<br \>	+	This results in the URL for the detailed information page: [[:pool:Homocord-b367-m17234|http://pool.publicdomainproject.org/index.php/Homocord-b367-m17234]]
−	This is necessary to enable the audit of the integrity of the collection as a whole.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	And the according Flac file name is: [http://pool.publicdomainproject.org/audio/flac/genres/religious_music/choral/nebe-quartett/homocord-b367-m17234.flac homocord-b367-m17234.flac]
−	Documentation provided for 4.2.1 through 4.2.4; documented agreements negotiated between
−	the producer and the repository (see 4.1.1-4.1.8); logs of material received and associated
−	action (receipt, action, etc.) dates; logs of periodic checks.
−	''Discussion''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall uniquely identify each AIP within the repository.|The repository shall uniquely identify each AIP within the repository.]] =====
−	It is the responsibility of the repository to choose the appropriate mechanism for checking the
−	completeness and correctness of its collections. In general, it is likely that a repository that
−	meets all the previous criteria will satisfy this one without needing to demonstrate anything
−	more. As a separate requirement, it demonstrates the importance of being able to audit the
−	integrity of the collection as a whole. For example, if a repository claims to have all e-mail
−	sent or received by The Yoyodyne Corporation between 1985 and 2005, it has been required
−	to show that:
−	* the content it holds came from Yoyodyne’s e-mail servers;
−	* it is all correctly transformed into a preservation format;
−	* each monthly SIP of e-mail has been correctly preserved, including original unique identifiers such as Message-IDs.
−	However, it may still have no way of showing whether this really represents all of
−	Yoyodyne’s email. For example, if there is a three-day period with no messages in the
−	repository, is this because Yoyodyne was shut down for those three days, or because the e-
−	mail was lost before the SIP was constructed? This case could be resolved by the repository’s
−	amending its description of the collection, but other cases may not be so straightforward. A
−	familiar mechanism from the world of traditional materials in libraries and archives is an
−	accessions or acquisitions register that is independent of other catalog metadata. A repository
−	should be able to show, for each item in its accessions register, which AIP(s) contain content
−	from that item. Alternatively, it may need to show that there is no AIP for an item, either
−	because ingest is still in progress, or because the item was rejected for some reason.
−	Conversely, any AIP should be able to be related to an entry in the acquisitions register.
−	==== The repository shall have contemporaneous records of actions and administration processes that are relevant to AIP creation. ====	+	<span style="color:green">Requirements fulfilled</span>
−	''Supporting Text''<br \>	+	====== [[PD:CCSDS_652.0-M-1#The repository shall have unique identifiers.|The repository shall have unique identifiers.]] ======
−	This is necessary in order to ensure that there is omitted from the record nothing relevant that
−	might be needed to provide an independent means to verify that all AIPs have been properly
−	created in accord with the documented procedures (see 4.2.1 through 4.2.9). It is the
−	responsibility of the repository to justify its practice in this respect.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	<span style="color:green">Requirements fulfilled</span>
−	Written documentation of decisions and/or action taken with timestamps; preservation
−	metadata logged, stored, and linked to pertinent digital objects.
−	''Discussion''<br \>	+	Given that there are no conflicting catalog/order numbers used by a label. This is unlikely but it could happen.
−	These records must be created on or about the time of the actions they refer to and are related
−	to actions associated with AIP creation. The records may be automated or may be written by
−	individuals, depending on the nature of the actions described. Where community or
−	international standards are used, the repository must demonstrate that all relevant actions are
−	carried through.
−	=== PRESERVATION PLANNING ===	+	====== [[PD:CCSDS_652.0-M-1#The repository shall assign and maintain persistent identifiers of the AIP and its components so as to be unique within the context of the repository.|The repository shall assign and maintain persistent identifiers of the AIP and its components so as to be unique within the context of the repository.]] ======
−	==== The repository shall have documented preservation strategies relevant to its holdings. ====	+	<span style="color:green">Requirements fulfilled</span>
−	''Supporting Text''<br \>	+	The described naming scheme is unique in the context of 78rpm records which are the only informations that are currently preserved.
−	This is necessary in order that it is clear how the repository plans to ensure the information
−	will remain available and usable for future generations and to provide a means to check and
−	validate the preservation work of the repository.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	====== [[PD:CCSDS_652.0-M-1#Documentation shall describe any processes used for changes to such identifiers.|Documentation shall describe any processes used for changes to such identifiers.]] ======
−	Documentation identifying each preservation risk identified and the strategy for dealing with
−	that risk.
−	''Discussion''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	These documented preservation strategies will describe how the repository will act upon
−	identified risks, as part of the preservation strategic plan. These preservation strategies and
−	the preservation strategic plan will typically address the degradation of storage media, the
−	obsolescence of media drives, and the obsolescence or inadequacy of Representation
−	Information (including formats) as the knowledge base of the Designated Community
−	changes, and safeguards against accidental or intentional digital corruption. For example, if
−	migration is the chosen approach to some of these issues, there also needs to be Preservation
−	Policies on what triggers a migration and what types of migration are expected to solve the
−	preservation risk identified. The preservation strategy will describe the range of activities
−	that need to be done in case of a migration.
−	==== The repository shall have mechanisms in place for monitoring its preservation environment. ====	+	There is no documentation.
−	''Supporting Text''<br \>	+	====== [[PD:CCSDS_652.0-M-1#The repository shall be able to provide a complete list of all such identifiers and do spot checks for duplications.|The repository shall be able to provide a complete list of all such identifiers and do spot checks for duplications.]] ======
−	This is necessary so that the repository can react to changes and thereby ensure that the
−	preserved information remains understandable and usable by the Designated Community.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	<span style="color:orange">Minor requirements are not fulfilled</span>
−	Surveys of the Designated Community of the repository.
−	''Discussion''<br \>	+	A complete list of all used identifiers is accessible via the category listing [[:pool:Category:Audio_file_licenses|Audio file licenses]].
−	The repository should show that it has some active mechanism to ensure that the preserved
−	information remains understandable and usable by the Designated Community and that it has
−	mechanisms in place for monitoring and notification when Representation Information
−	(including formats) approaches obsolescence or is no longer viable. For most repositories,
−	the concern will be with the Representation Information used to preserve information, which
−	may include information on how to deal with a file format or software that can be used to
−	render or process it. Sometimes the format needs to change because the repository can no
−	longer deal with it. Sometimes the format is retained and the information about what
−	software is needed to process it needs to change. If the mechanism depends on an external
−	registry, the repository must demonstrate how it uses the information from that registry.
−	===== The repository shall have mechanisms in place for monitoring and notification when Representation Information is inadequate for the Designated Community to understand the data holdings. =====	+	There is no automated way to check for duplication. In the wiki it should not be possible to generate duplicates because the page names would create a conflict. There can be only one page with a certain name because no hierarchy is in use. But on the storage server it would be possible to accidentally create duplicates because of the manual upload process and the hierarchical organization (Folder structure by genre/artist).
−	''Supporting Text''<br \>	+	====== [[PD:CCSDS_652.0-M-1#The system of identifiers shall be adequate to fit the repository's current and foreseeable future requirements such as numbers of objects.|The system of identifiers shall be adequate to fit the repository's current and foreseeable future requirements such as numbers of objects.]] ======
−	This is necessary in order to ensure that the preserved information remains understandable
−	and usable by the Designated Community.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Subscription to a Representation Information registry service; subscription to a technology
−	watch service, surveys amongst its Designated Community members, relevant working
−	processes to deal with this information.
−	''Discussion''<br \>	+	It is obvious that this naming scheme is dependent on the naming of the collected items and is tailored to released records. The result are several problems:
−	The repository must show that it has some active mechanism to warn of impending	+	* It is unclear how to handle unreleased records (No order/catalog number)
−	obsolescence. Obsolescence is determined largely in terms of the knowledge base of the	+	* The archive is open for other recording formats like cylinders, open reel tape and even motion pictures where this naming scheme is not usable
−	Designated Community.	+	* The naming scheme does not describe how to handle retouched versions (clean master) of the raw digitization (master) where both have to be searchable, distinguishable and accessible
−	==== The repository shall have mechanisms to change its preservation plans as a result of its monitoring activities. ====	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have a system of reliable linking/resolution services in order to find the uniquely identified object, regardless of its physical location.|The repository shall have a system of reliable linking/resolution services in order to find the uniquely identified object, regardless of its physical location.]] =====
−	''Supporting Text''<br \>	+	<span style="color:orange">Minor requirements are not fulfilled</span>
−	This is necessary in order for the repository to be prepared for changes in the external
−	environment that may make its current preservation plans a bad choice as the time to
−	implement draws near.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	The naming convention in use is suitable to meet this requirement if only shellac records are archived. Problematic is the missing documentation.
−	Preservation Plans tied to formal or informal technology watch(es); preservation planning or
−	processes that are timed to shorter intervals (e.g., not more than five years); proof of frequent
−	Preservation Policies and Preservation Plans updates; sections of Preservation Policies that
−	address how plans may be updated and that address how often the plans are required to be
−	reviewed and reaffirmed or updated.
−	''Discussion''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have access to necessary tools and resources to provide authoritative Representation Information for all of the digital objects it contains. In particular the following aspects must be checked.|The repository shall have access to necessary tools and resources to provide authoritative Representation Information for all of the digital objects it contains. In particular the following aspects must be checked.]] ====
−	The repository should demonstrate or describe how it reacts to information from monitoring,
−	which sometimes requires a repository to change how it deals with the material it holds in
−	ways that could not have been anticipated at an earlier stage. The repository should
−	periodically review its preservation plans and the technology environment and, if necessary,
−	makes changes to those plans to ensure their continued effectiveness. Another possible
−	response to information gathered by monitoring is for the repository to update and create
−	additional Representation Information and/or PDI.
−	===== The repository shall have mechanisms for creating, identifying or gathering any extra Representation Information required. =====	+	<span style="color:red">Essential requirements not fulfilled</span>
−	''Supporting Text''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have tools or methods to identify the file type of all submitted Data Objects.|The repository shall have tools or methods to identify the file type of all submitted Data Objects.]] =====
−	This is necessary in order to ensure that the preserved information remains understandable
−	and usable by the Designated Community.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	<span style="color:green">Requirements fulfilled</span>
−	Subscription to a format registry service; subscription to a technology watch service;
−	preservation plans.
−	''Discussion''<br \>	+	The Unix tool ''file'' and other more format specific tools are available on the servers.
−	The repository should have mechanisms in place for monitoring and notification when
−	Representation Information (including formats) approaches obsolescence or is no longer
−	viable, and it should be able to show that it has mechanisms to address such notifications.
−	==== The repository shall provide evidence of the effectiveness of its preservation activities. ====	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have tools or methods to determine what Representation Information is necessary to make each Data Object understandable to the Designated Community.|The repository shall have tools or methods to determine what Representation Information is necessary to make each Data Object understandable to the Designated Community.]] =====
−	''Supporting Text''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	This is necessary in order to assure the Designated Community that the repository will be
−	able to make the information available and usable over the mid-to-long-term.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	No tools or methods in use.
−	Collection of appropriate preservation metadata; proof of usability of randomly selected
−	digital objects held within the system; demonstrable track record for retaining usable digital
−	objects over time; Designated Community polls.
−	''Discussion''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have access to the requisite Representation Information.|The repository shall have access to the requisite Representation Information.]] =====
−	The repository should be able to demonstrate the continued preservation, including
−	understandability, of its holdings. This could be evaluated at a number of degrees and
−	depends on the specificity of the Designated Community. If a Designated Community is
−	fairly broad, an auditor could represent the test subject in the evaluation. More specific
−	Designated Communities could require significant efforts.
		+	<span style="color:green">Requirements fulfilled</span>
−	=== AIP PRESERVATION ===	+	Due to the fact that the Public Domain Project only uses Free and Open Source Software (FOSS) access to all requisite Representation Information is guarantied.
−	==== The repository shall have specifications for how the AIPs are stored down to the bit level. ====	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have tools or methods to ensure that the requisite Representation Information is persistently associated with the relevant Data Objects.|The repository shall have tools or methods to ensure that the requisite Representation Information is persistently associated with the relevant Data Objects.]] =====
−	''Supporting Text''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	This is necessary in order to ensure that the information can be extracted from the AIP over
−	the long-term.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	This strong requirement is not fulfilled.
−	Documentation of the format of AIPs; EAST and Data Entity Dictionary Specification
−	Language (DEDSL) descriptions of the data components (see references [B6] and [B7]).
−	''Discussion''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have documented processes for acquiring Preservation Description Information (PDI) for its associated Content Information and acquire PDI in accordance with the documented processes. In particular the following aspects must be checked.|The repository shall have documented processes for acquiring Preservation Description Information (PDI) for its associated Content Information and acquire PDI in accordance with the documented processes. In particular the following aspects must be checked.]] ====
−	The repository should specify the Representation information down to the bit level of each
−	AIP component and must specify how the separate components are packaged together. The
−	Representation Information must be available for each AIP and must be appropriately linked
−	to the AIP. Often, repositories are tempted to describe AIP content only down to a level
−	where a program will then be used to convert the information to a form understandable to
−	their Designated Communities. However, if those programs ever fail to operate, then the
−	information would be lost in all the AIPs that relied on that program.
−	===== The repository shall preserve the Content Information of AIPs. =====	+	<span style="color:red">Essential requirements not fulfilled</span>
−	''Supporting Text''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have documented processes for acquiring PDI.|The repository shall have documented processes for acquiring PDI.]] =====
−	This is necessary because it is the fundamental mission of a repository to preserve the
−	Content Information for its Designated Communities.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Preservation workflow procedure documentation; workflow procedure documentation;
−	Preservation Policy documents specifying treatment of AIPs and under what circumstances
−	they may ever be deleted; ability to demonstrate the sequence of conversions for an AIP for
−	any particular digital object or group of objects ingested; documentation linking ingested
−	objects and the current AIPs.
−	''Discussion''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall execute its documented processes for acquiring PDI.|The repository shall execute its documented processes for acquiring PDI.]] =====
−	The repository should be able to demonstrate that the AIPs faithfully reflect the information
−	that was captured during ingest and that any subsequent or future planned transformations
−	will continue to preserve all the required Information Properties of the Content Information.
−	One approach to this requirement assumes that the repository has a policy specifying that
−	AIPs cannot be deleted at any time. This particularly simple and robust implementation
−	preserves links between what was originally ingested, as well as new versions that have been
−	transformed or changed in any way. Depending upon implementation, these newer objects
−	may be completely new AIPs or merely updated AIPs. Either way, persistent links between
−	the ingested object and the resulting AIP should be maintained.
−	===== The repository shall actively monitor the integrity of AIPs. =====	+	<span style="color:red">Essential requirements not fulfilled</span>
−	''Supporting Text''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall ensure that the PDI is persistently associated with the relevant Content Information.|The repository shall ensure that the PDI is persistently associated with the relevant Content Information.]] =====
−	This is necessary in order to protect the integrity of the archival objects over time.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	<span style="color:green">Requirements fulfilled</span>
−	Fixity information (e.g., checksums) for each ingested digital object/AIP; logs of fixity
−	checks; documentation of how AIPs and Fixity information are kept separate; documentation
−	of how AIPs and accession registers are kept separate.
−	''Discussion''<br \>	+	At the moment the PDI is stored inside the MediaWiki and is permanently linked to the audio file (Which does not contain PDI). Both the file name of the content information and the wiki page use the same naming scheme so the association is obvious.
−	A repository should have logs that show actions taken to check the integrity of archival
−	objects in order to assure funders, producers, and users—and to allow them to
−	audit/validate—that the repository is taking the necessary steps to ensure the long-term
−	integrity of the digital objects. The repository should also document that integrity checks are
−	carried out on a regular basis, in order to catch any changes in AIPs as soon as possible so
−	that corrective action can be taken as soon as possible. The repository should allow interested
−	parties to verify that this is the case.
−	At present, most repositories deal with this at the level of individual information objects by	+	==== [[PD:CCSDS_652.0-M-1#The repository shall ensure that the Content Information of the AIPs is understandable for their Designated Community at the time of creation of the AIP. In particular the following aspects must be checked.|The repository shall ensure that the Content Information of the AIPs is understandable for their Designated Community at the time of creation of the AIP. In particular the following aspects must be checked.]] ====
−	using a checksum of some form, such as MD5. In this case, the repository should be able,
−	and may want to demonstrate that, the Fixity Information (checksums, and the information
−	that ties them to AIPs) are stored separately or protected separately from the AIPs
−	themselves, so that accidental alteration of the AIP would not also damage the Fixity
−	Information. Also, someone who can maliciously alter an AIP would not likely be able as
−	easily to alter the Fixity Information as well.
−	==== The repository shall have contemporaneous records of actions and administration processes that are relevant to storage and preservation of the AIPs. ====	+	<span style="color:red">Essential requirements not fulfilled</span>
−	''Supporting Text''<br \>	+	===== [[PD:CCSDS_652.0-M-1#Repository shall have a documented process for testing understandability for their Designated Communities of the Content Information of the AIPs at their creation.|Repository shall have a documented process for testing understandability for their Designated Communities of the Content Information of the AIPs at their creation.]] =====
−	This is necessary in order to ensure documentation is not omitted or erroneous or of
−	questionable authenticity.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Written documentation of decisions and/or action taken; preservation metadata logged,
−	stored, and linked to pertinent digital objects.
−	''Discussion''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall execute the testing process for each class of Content Information of the AIPs.|The repository shall execute the testing process for each class of Content Information of the AIPs.]] =====
−	The records may be automated or may be written by individuals, depending on the nature of
−	the actions described. Where community or international standards are used, the repository
−	must demonstrate that all relevant actions are appropriately performed.
−	===== The repository shall have procedures for all actions taken on AIPs. =====	+	<span style="color:red">Essential requirements not fulfilled</span>
−	''Supporting Text''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall bring the Content Information of the AIP up to the required level of understandability if it fails the understandability testing.|The repository shall bring the Content Information of the AIP up to the required level of understandability if it fails the understandability testing.]] =====
−	This is necessary in order to ensure that any actions performed against an AIP do not alter
−	the AIP information in a manner unacceptable to its Designated Communities.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Written documentation describing all actions that can be performed against an AIP.
−	''Discussion''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall verify each AIP for completeness and correctness at the point it is created.|The repository shall verify each AIP for completeness and correctness at the point it is created.]] ====
−	This documentation is normally created during design of the repository. It should detail the
−	normal handling of AIPs, all actions that can be performed against the AIPs, including
−	success and failure conditions and details of how these processes can be monitored.
−	===== The repository shall be able to demonstrate that any actions taken on AIPs were compliant with the specification of those actions. =====	+	<span style="color:red">Essential requirements not fulfilled</span>
−	''Supporting Text''<br \>	+	There is no verification process in use. Essentially the SIP is created by the same person that will ingest it and creates the AIP. For example there is no four-eyes principle in use.
−	This is necessary in order to ensure that any actions performed against an AIP do not alter
−	the AIP information in a manner unacceptable to its Designated Communities.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall provide an independent mechanism for verifying the integrity of the repository collection/content.|The repository shall provide an independent mechanism for verifying the integrity of the repository collection/content.]] ====
−	Preservation metadata logged, stored, and linked to pertinent digital objects and
−	documentation of that action; procedural audits of the repository showing that all actions
−	conform to the documented processes.
−	''Discussion''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Successful preservation of information in the archive is strongly linked to following
−	established and documented procedures to complete any actions that affect the repository
−	data. The more often ‘special handling’ of repository data occurs and the more often this
−	‘special handling’ is not overseen in a consistent manner, the more likely that the data held
−	by the repository will be compromised. When procedures are regularly followed, any
−	deviation from procedures that would be likely to cause an alteration in the data will more
−	likely be noticed or, if not noticed, may more likely be able to be corrected, or the timing and
−	likely change could be identified in the future.
		+	==== [[PD:CCSDS_652.0-M-1#The repository shall have contemporaneous records of actions and administration processes that are relevant to AIP creation.|The repository shall have contemporaneous records of actions and administration processes that are relevant to AIP creation.]] ====
−	=== INFORMATION MANAGEMENT ===	+	<span style="color:orange">Minor requirements are not fulfilled</span>
−	==== The repository shall specify minimum information requirements to enable the Designated Community to discover and identify material of interest. ====	+	For the PDI there the records of actions are automatically captured. Every change on a wiki page is logged, the difference to the previous version can be inspected and the old version can be restored if needed. Here is an example how the version history looks like: [http://pool.publicdomainproject.org/index.php?title=Columbia-a3996-81215&action=history Version history of Columbia-a3996-81215]
−	''Supporting Text''<br \>	+	But there is no such thing or other processes for the content information (the Flac files) to capture records of actions.
−	This is necessary in order to enable discovery of the repository’s holdings.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>
−	Retrieval and descriptive information, discovery metadata, such as Dublin Core, and other
−	documentation describing the object.
−	''Discussion''<br \>	+	=== [[PD:CCSDS_652.0-M-1#PRESERVATION PLANNING|PRESERVATION PLANNING]] ===
−	The repository should be able to deal with the types of requests that will come from a typical
−	user from the Designated Community. A repository does not necessarily have to satisfy every
−	possible request. Retrieval metadata is distinct from descriptive information that describes
−	what has been found.
−	==== The repository shall capture or create minimum descriptive information and ensure that it is associated with the AIP. ====	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have documented preservation strategies relevant to its holdings.|The repository shall have documented preservation strategies relevant to its holdings.]] ====
−	''Supporting Text''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	This is required in order to ensure that descriptive information is associated with the AIP.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	There are no documented preservation strategies.
−	Descriptive metadata; internal or external persistent, unique identifier or locator that is
−	associated with the AIP (see also [[PD:CCSDS_652.0-M-1#The repository shall have and use a convention that generates persistent, unique identifiers for all AIPs.|4.2.4]] about persistent, unique identifier); system
−	documentation and technical architecture; depositor agreements; metadata policy
−	documentation, incorporating details of metadata requirements and a statement describing
−	where responsibility for its procurement falls; process workflow documentation.
−	''Discussion''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have mechanisms in place for monitoring its preservation environment.|The repository shall have mechanisms in place for monitoring its preservation environment.]] ====
−	The repository should show that it associates with each AIP, minimum descriptive
−	information that was either received from the producer or created by the repository.
−	Associating the descriptive information with the object is important, although it does not
−	require one-to-one correspondence, and may not necessarily be stored with the AIP.
−	Hierarchical schemes of description can allow some descriptive elements to be associated
−	with many items.
−	==== The repository shall maintain bi-directional linkage between each AIP and its descriptive information. ====	+	<span style="color:red">Essential requirements not fulfilled</span>
−	''Supporting Text''<br \>	+	There are no formal mechanisms for monitoring the preservation environment. But the active people in the project are in regular contact with groups of the designated communities. This is done by attending conferences, assemblies, regular meetings of user groups. Also the recommendations on formats and media published by the associations of archives or libraries are observed in a informal way.
−	This is necessary to ensure that all AIPs can be located and retrieved.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have mechanisms in place for monitoring and notification when Representation Information is inadequate for the Designated Community to understand the data holdings.|The repository shall have mechanisms in place for monitoring and notification when Representation Information is inadequate for the Designated Community to understand the data holdings.]] =====
−	Descriptive metadata; unique, persistent identifier or locator associated with the AIP;
−	documented relationship between the AIP and its metadata; system documentation and
−	technical architecture; process workflow documentation.
−	''Discussion''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Repositories must implement procedures to establish and maintain relationships to associate
−	descriptive information for each AIP, and should ensure that every AIP has some descriptive
−	information associated with it and that all descriptive information must point to at least one
−	AIP.
−	===== The repository shall maintain the associations between its AIPs and their descriptive information over time. =====	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have mechanisms to change its preservation plans as a result of its monitoring activities.|The repository shall have mechanisms to change its preservation plans as a result of its monitoring activities.]] ====
−	''Supporting Text''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	This is necessary to ensure that all AIPs can continue to be located and retrieved.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	This and the next requirement fail because there are no monitoring activities in place on which a reaction could be defined.
−	Log detailing ongoing maintenance or checking of the integrity of the data and its
−	relationships to the associated descriptive information, especially following repair or
−	modification of the AIP; legacy descriptive information; persistence of identifier or locator;
−	documented relationship between AIP and its descriptive information; system documentation
−	and technical architecture; process workflow documentation.
−	''Discussion''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have mechanisms for creating, identifying or gathering any extra Representation Information required.|The repository shall have mechanisms for creating, identifying or gathering any extra Representation Information required.]] =====
−	Repositories must implement procedures that let them know when the relationship between
−	the data and the associated descriptive information is temporarily broken to ensure that it can
−	be restored.
−	=== ACCESS MANAGEMENT ===	+	<span style="color:red">Essential requirements not fulfilled</span>
−	The term ‘access’ has a number of different senses, including access by users to the
−	repository system, for example, physical security and user authentication, and the different
−	stages of accessing records (making a request, verifying the rights of the requester, and
−	preparing and sending a Dissemination Information Package [DIP]). This subsection is
−	concerned with all of these. It is divided into two main requirements, one concerned with the
−	existence and implementation of access policies, and one with the capacity of the repository
−	to provide demonstrably authentic objects as DIPs. Thus the first requirement relates to
−	requests initiated by a user and how the repository handles them to ensure that rights and
−	agreements are respected, that security is monitored, that requests are fulfilled, etc. The
−	second requirement relates to what is delivered to the Consumer and the trust that can be
−	placed in it.
−	It must be understood that the capabilities and sophistication of the access system will vary	+	==== [[PD:CCSDS_652.0-M-1#The repository shall provide evidence of the effectiveness of its preservation activities.|The repository shall provide evidence of the effectiveness of its preservation activities.]] ====
−	depending on the repository’s Designated Community and the access mandates of the
−	repository. Because of the variety of repositories and access mandates, these criteria may be
−	subject to questions about applicability and interpretation at a local level.
−	==== The repository shall comply with Access Policies. ====	+	<span style="color:red">Essential requirements not fulfilled</span>
−	''Supporting Text''<br \>
−	This is necessary in order to ensure the repository has fully addressed all aspects of usage
−	which might affect the trustworthiness of the repository, particularly with reference to
−	support of the user community.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	=== [[PD:CCSDS_652.0-M-1#AIP PRESERVATION|AIP PRESERVATION]] ===
−	Statements of policies that are available to the user communities; information about user
−	capabilities (authentication matrices); logs and audit trails of access requests; explicit tests of
−	some types of access.
−	''Discussion''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have specifications for how the AIPs are stored down to the bit level.|The repository shall have specifications for how the AIPs are stored down to the bit level.]] ====
−	Depending on the nature of the repository, the Access Policies may cover:
−	* statements of what is accessible to which community, and on what conditions;
−	* requirements for authentication and authorization of accessors;
−	* enforcement of agreements applicable to access conditions;
−	* recording of access actions.
−	Access may be managed partly by computers and partly by humans; checking passports, for	+	<span style="color:orange">Minor requirements are not fulfilled</span>
−	instance, before issuing a user ID and password may be an appropriate part of access
−	management for some institutions.
−	===== The repository shall log and review all access management failures and anomalies. =====	+	All file formats used for AIPs or other relevant information are well documented open standards down to the bit level. The representation information is not available locally and it's not linked to the AIPs.
−	''Supporting Text''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall preserve the Content Information of AIPs.|The repository shall preserve the Content Information of AIPs.]] =====
−	This is necessary in order to identify security threats and access management system failures.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Access logs, capability of the system to use automated analysis/monitoring tools and
−	generate problem/error messages; notes of reviews undertaken or action taken as a result of
−	reviews.
−	''Discussion''<br \>	+	No documented work flows.
−	A repository should have some automated mechanism to note anomalous or unusual denials
−	and use them to identify either security threats or failures in the access management system,
−	such as valid users’ being denied access. This does not mean looking at every denied access.
−	==== The repository shall follow policies and procedures that enable the dissemination of digital objects that are traceable to the originals, with evidence supporting their authenticity. ====	+	===== [[PD:CCSDS_652.0-M-1#The repository shall actively monitor the integrity of AIPs.|The repository shall actively monitor the integrity of AIPs.]] =====
−	''Supporting Text''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	This is necessary to establish an auditable chain of authenticity from the AIP to disseminated
−	digital objects.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have contemporaneous records of actions and administration processes that are relevant to storage and preservation of the AIPs.|The repository shall have contemporaneous records of actions and administration processes that are relevant to storage and preservation of the AIPs.]] ====
−	System design documents; work instructions (if DIPs involve manual processing); process
−	walkthroughs; production of a sample copy with evidence of authenticity; documentation of
−	community requirements for evidence of authenticity.
−	''Discussion''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Authenticity is not an ‘all or nothing’ concept, but is a matter of degree, judged on the basis
−	of evidence. Thus the adequacy of the evidence is of key importance in assessing this
−	requirement.
−	This requirement ensures that ingest, preservation, and transformation actions do not lose	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have procedures for all actions taken on AIPs.|The repository shall have procedures for all actions taken on AIPs.]] =====
−	information that would support an auditable trail of authenticity between the original
−	deposited object and the eventual disseminated object.
−	A repository should record the processes to construct the DIPs from the relevant AIPs. This
−	is a key part of establishing that DIPs reflect the content of AIPs, and hence of original
−	material, in a trustworthy and consistent fashion. DIPs may simply be a copy of AIPs, or may
−	result from a simple format transformation of an AIP. But in other cases, they may be derived
−	in complex ways. A user may request a DIP consisting of the title pages from all e-books
−	published in a given period, for instance, which will require these to be extracted from many
−	different AIPs. Or a repository may disseminate automatically generated transcripts of voice
−	recordings. A repository that allows requests for such complex DIPs will need to put more
−	effort into demonstrating how it meets this requirement than a repository that only allows
−	requests for DIPs that correspond to an entire AIP.
−	This requirement is concerned only with the relation between DIPs and the AIPs from which	+	<span style="color:red">Essential requirements not fulfilled</span>
−	they are derived; elsewhere the link between the originals SIPs and the AIPs is considered.
−	===== The repository shall record and act upon problem reports about errors in data or responses from users. =====	+	===== [[PD:CCSDS_652.0-M-1#The repository shall be able to demonstrate that any actions taken on AIPs were compliant with the specification of those actions.|The repository shall be able to demonstrate that any actions taken on AIPs were compliant with the specification of those actions.]] =====
−	''Supporting Text''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	This is necessary in order for the users to consider the repository to be a trustworthy source
−	of information.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>
−	System design documents; work instructions (if DIPs involve manual processing); process
−	walkthroughs; logs of orders and DIP production; documentation of error reports and the
−	actions taken.
−	''Discussion''<br \>	+	=== [[PD:CCSDS_652.0-M-1#INFORMATION MANAGEMENT|INFORMATION MANAGEMENT]] ===
−	The objective of access management is to ensure that a user receives a usable and correct
−	version of the digital object(s) (i.e., DIP) that he or she requested. A repository should show
−	that any problems that do occur and are brought to its attention are investigated and acted on.
−	Such responsiveness is essential for the repository to be considered trustworthy.
		+	==== [[PD:CCSDS_652.0-M-1#The repository shall specify minimum information requirements to enable the Designated Community to discover and identify material of interest.|The repository shall specify minimum information requirements to enable the Designated Community to discover and identify material of interest.]] ====
−	== INFRASTRUCTURE AND SECURITY RISK MANAGEMENT ==	+	<span style="color:green">Requirements fulfilled</span>
−	=== TECHNICAL INFRASTRUCTURE RISK MANAGEMENT ===	+	All the descriptive information can be searched by the free text search function of the MediaWiki software. For example if someone is interested in instrumental music it can be found with the search term, according to the metadata attribute ''Vocal range'' with the value ''instrumental''.
−	==== The repository shall identify and manage the risks to its preservation operations and goals associated with system infrastructure. ====	+	[[:pool:index.php?search=Vocal+range+instrumental|Search results for ''Vocal range instrumental'']]
−	''Supporting Text''<br \>	+	Another option to discover material of interest is by using the category system. Every work is added to several categories like genres, country of origin, creation year, recording formats, digitalization devices etc. The example recording above is in several categories, one is the recording label ''Decca Records''. This information can be used to show all recordings of ''Decca Records'' in the public domain archive:
−	This is necessary to ensure a secure and trustworthy infrastructure.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	[[:pool:Category:Decca_Records|Category:Decca_Records]]
−	Infrastructure inventory of system components; periodic technology assessments; estimates
−	of system component lifetime; export of authentic records to an independent system; use of
−	strongly community supported software e.g., Apache, iRODS, Fedora); re-creation of
−	archives from backups.
−	''Discussion''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall capture or create minimum descriptive information and ensure that it is associated with the AIP.|The repository shall capture or create minimum descriptive information and ensure that it is associated with the AIP.]] ====
−	The repository should conduct or contract assessments of the risks related to hardware and
−	software infrastructure, and operational procedures. The repository should provide
−	mechanisms that minimize risk from dependencies on proprietary or obsolete system
−	infrastructure and from operational error. The degree of support required relates to the
−	criticality of the subsystem(s) involved in long-term preservation. The repository should
−	maintain a system that is scalable (e.g., able to handle anticipated future volumes of both
−	bytes and files) without a major disruption of the system. The repository should maintain a
−	system that is evolvable. That is, the system should be designed in such a way that major
−	components of the system can be replaced with newer technologies without major disruption
−	of the system as a whole. The repository system should be extensible. That is, the system
−	should be designed to accommodate future formats (media and files) without major
−	disruption of the system as a whole. The repository should be able to export its holdings to a
−	future custodian. The repository should be able to re-create the archives after an operational
−	error that overwrites or deletes digital holdings.
−	===== The repository shall employ technology watches or other technology monitoring notification systems. =====	+	<span style="color:orange">Minor requirements are not fulfilled</span>
−	''Supporting Text''<br \>	+	The minimum information requirements are specified by the ''Audio file'' template in the wiki. This template acts as the input mask when the SIP is built. The template page also includes the documentation about the usage of this template.
−	This is necessary to track when hardware or software components will become obsolete and
−	migration is needed to new infrastructure.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	Audio file template:<br/>
−	Management of periodic technology assessment reports. Comparison of existing technology	+	[[:pool:Template:Audio_file|http://pool.publicdomainproject.org/index.php/Template:Audio_file]]
−	to each new assessment.
−	''Discussion''<br \>	+	The template page also contains the available documentation how to use this template. There is no documentation about the vocabulary that should be used to fill the metadata information.
−	The objective is to understand when any subsystem poses a risk of obsolescence, and enable
−	planning migration to new technology before interoperability mechanisms are no longer
−	available. This can be driven by proprietary software dependencies (the vendor no longer
−	supports the subsystem component), and by emergence of new protocols (the mechanism for
−	accessing the system has become obsolete and is no longer supported).
−	====== The repository shall have hardware technologies appropriate to the services it provides to its designated communities. ======	+	Responsibility for the procurement of metadata lies in the ingestion process where the SIP is assembled.
−	''Supporting Text''<br \>	+	Capturing provenience and context information with help of this template is done manually and is done until all needed information is found. The minimum level is determined by the requirement that the public domain project is only allowed to publish works that are in the public domain (copyright free). So at least the information to decide on the legal status of the work must be present. This includes title, all authors and there living dates, first release date and publishing label. Technical metadata is also captured with this template like format of the analog recording, devices used for digitalization, catalog and stamper numbers and track length.
−	This is necessary to provide expected, contracted, secure, and persistent levels of service
−	including: ease of ingest and dissemination through appropriate depositor and user interfaces
−	and technologies such as upload mechanisms; on-going digital object management;
−	preservation approaches and solutions, such as migration; and system security.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	A finished SIP could look like this example: [[:pool:Decca-wa782-kwa5215|Decca-wa782-kwa5215]]
−	Maintenance of up-to-date Designated Community technology, expectations, and use
−	profiles; provision of bandwidth adequate to support ingest and use demands; systematic
−	elicitation of feedback regarding hardware and service adequacy; maintenance of a current
−	hardware inventory.
−	''Discussion''<br \>	+	Additional to the descriptive information captured with the ''Audio file'' template the SIP gets also context information by categorization. The public domain project uses a polyhierarchical category tree that contains differentiation between genres, country of origin, creation year, recording formats, digitalization devices etc.
−	The repository should be aware of the types of storage, file management, preservation and
−	access services expected by its Designated Community, including where applicable, the
−	types of media to be delivered, and needs to make sure its hardware capabilities can support
−	these services. The objective is to track when changes in service requirements by the
−	designated communities require a corresponding change in the hardware technology, when
−	changes in ingestion policies require expanded capabilities, and when changes in
−	preservation policies require new preservation capabilities. This can be driven by changes in
−	capacity requirements (the time needed to read all media is longer than the media lifetime),
−	by changes in delivery mechanisms (new clients for displaying authentic records), and
−	changes in the number and size of archived records.
−	====== The repository shall have procedures in place to monitor and receive notifications when hardware technology changes are needed. ======	+	Missing is a documentation on the categorization process for an AIP.
−	''Supporting Text''<br \>	+	As shown in [[PD:Internal_CCSDS_652.0-M-1_audit#The repository shall have and use a convention that generates persistent, unique identifiers for all AIPs.|The repository shall have and use a convention that generates persistent, unique identifiers for all AIPs.]] there is a naming scheme in use that provides persistent, unique identifiers for all AIPs and descriptive information as long as only shellac records are archived.
−	This is necessary to ensure expected, contracted, secure, and persistent levels of service.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	There is no detailed process work flow documentation.
−	Audits of capacity versus actual usage; audits of observed error rates; audits of performance
−	bottlenecks that limit ability to meet user community access requirements; documentation of
−	technology watch assessments; documentation of technology updates from vendors.
−	''Discussion''<br \>	+	There is no system and technical architecture documentation.
−	The repository should conduct or contract frequent environmental scans regarding hardware
−	status, sources of failure, and interoperability among hardware components. The repository
−	should also be in contact with its hardware vendors regarding technology updates, points of
−	likely failure, and how new components may affect system integration and performance. The
−	objective is to track when changes in service requirements by the designated communities
−	require a corresponding change in the hardware technology, when changes in ingestion
−	policies require expanded capabilities, and when changes in preservation policies require
−	new preservation capabilities. This can be driven by changes in capacity requirements (the
−	time needed to read all media is longer than the media lifetime), by changes in delivery
−	mechanisms (new clients for displaying authentic records), and changes in the number and
−	size of archived records.
−	====== The repository shall have procedures in place to evaluate when changes are needed to current hardware. ======	+	==== [[PD:CCSDS_652.0-M-1#The repository shall maintain bi-directional linkage between each AIP and its descriptive information.|The repository shall maintain bi-directional linkage between each AIP and its descriptive information.]] ====
−	''Supporting Text''<br \>	+	<span style="color:orange">Minor requirements are not fulfilled</span>
−	This is necessary to ensure that the repository has the capacity to make informed and timely
−	decisions when information indicates the need for new hardware.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	One direction is from the descriptive information to the AIP. This is achieved by a link on the wiki page withe the descriptive information to the Flac file. It is also achieved by the use of a unique, persistent identifier for each work. This identifier is used to name the wiki page containing the descriptive metadata and also the file name of the Flac file.
−	Evaluation procedures in place; documented staff expertise in each technology subsystem.
−	''Discussion''<br \>	+	Example:
−	Given information from technology watches or other technology monitoring notification
−	systems, the repository should have procedures and expertise to evaluate this data and make
−	sound decisions regarding the need for new hardware. The objective is to track when
−	technology providers have developed subsystems that minimize risk, or that minimize cost,
−	or that improve performance. This is necessary to track emerging technologies and plan for
−	upgrades before capacity limits occur. The evaluation should identify when the risk of using
−	new technology outweighs the expected benefit, and when the new technology is sufficiently
−	mature to minimize risk.
−	====== The repository shall have procedures, commitment and funding to replace hardware when evaluation indicates the need to do so. ======	+	* Descriptive Metadata for [[:pool:Hmv-d1388-08247| Hmv-d1388-08247]]
		+	* The associated AIP with the file name [http://pool.publicdomainproject.org/audio/flac/genres/classical/chamber_music/budapest_string_quartet/hmv-d1388-08247.flac  hmv-d1388-08247.flac]
−	''Supporting Text''<br \>	+	For the other direction the unique, persistent identifier is used to locate the descriptive metadata in the wiki. This can be done by directly entering the URL ''http://pool.publicdomainproject.org/index.php/'' and the identifier at the end or by using the search function of the wiki.
−	This is necessary to ensure hardware replacement in a timely fashion so as to avert system
−	failure or performance inadequacy. Without such a commitment, and more importantly,
−	without escrowed financial resources or a secure funding stream, technology watches and
−	notifications are of little value. The repository must have mechanisms for evaluating the
−	efficacy of the new systems before implementation in the production system.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	Beneficial would be a URL (web link) to the descriptive information inside the Flac metadata tags.
−	Statement of commitment to provide expected and contracted levels of service; evidence of
−	ongoing financial assets set aside for hardware procurement; demonstration of cost savings
−	through amortized cost of new system.
−	''Discussion''<br \>	+	For the physical records this bidirectional linking also holds as the context information (category) in the wiki contains the physical location of the record. In the opposite direction the catalog or stamper number can be used to find its descriptive information as well the number of the container to find the context information about the grouped items.
−	The objective is to demonstrate that the repository has the ability to incorporate new
−	technology, both financially through funding commitments or cost reduction, and
−	operationally through verification of the capabilities of the new systems.
−	====== The repository shall have software technologies appropriate to the services it provides to its designated communities. ======	+	As with other requirements there is a lack of documentation about the process work flow and technical architecture.
−	''Supporting Text''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall maintain the associations between its AIPs and their descriptive information over time.|The repository shall maintain the associations between its AIPs and their descriptive information over time.]] =====
−	This is necessary to provide expected, contracted, secure, and persistent levels of service
−	including: ease of ingest and dissemination through appropriate depositor and user interfaces
−	and technologies such as upload mechanisms; on-going digital object management;
−	preservation approaches and solutions, such as migration; and system security.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Maintenance of up-to-date Designated Community technology, expectations, and use
−	profiles; provision of software systems adequate to support ingest and use demands;
−	systematic elicitation of feedback regarding software and service adequacy; maintenance of a
−	current software inventory.
−	''Discussion''<br \>
−	The objective is to track when changes in service requirements by the designated
−	communities require a corresponding change in the software components, when changes in
−	ingestion policies require support for new data formats and when changes in software
−	technology require new format migration capabilities. This can be driven by changes in
−	access requirements (new clients that require new data formats become preferred), by
−	changes in delivery mechanisms (new data transfer mechanisms), and changes in the number
−	and size of archived records that require more scalable software.
−	====== The repository shall have procedures in place to monitor and receive notifications when software changes are needed. ======	+	=== [[PD:CCSDS_652.0-M-1#ACCESS MANAGEMENT|ACCESS MANAGEMENT]] ===
−	''Supporting Text''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall comply with Access Policies.|The repository shall comply with Access Policies.]] ====
−	This is necessary to ensure expected, contracted, secure, and persistent levels of service.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	<span style="color:green">Requirements fulfilled</span>
−	Audits of capacity versus actual usage; audits of observed error rates; audits of performance
−	bottlenecks that limit ability to meet user community access requirements; documentation of
−	technology watch assessments; documentation of software updates from vendors.
−	''Discussion''<br \>	+	The public domain project allows free unlimited access to its collection. So there is no need for user accounts or access management to use the available items.
−	The objective is to track when changes in service requirements by the designated
−	communities require a corresponding change in the software technology, when changes in
−	ingestion policies require expanded capabilities, and when changes in preservation policies
−	require new preservation capabilities. This can be driven by security updates (vendor
−	supplied corrections to newly identified vulnerabilities), by changes in delivery mechanisms
−	(new software clients for displaying authentic records), and changes in the number and size
−	of archived records (expanded database requirements). The repository should conduct or
−	contract frequent environmental scans regarding software evolution, likely points of failure,
−	and interoperability among the software and hardware components. The repository should
−	also be in contact with its software vendors regarding technology updates, points of likely
−	failure, and how new programs may affect system integration and performance.
−	====== The repository shall have procedures in place to evaluate when changes are needed to current software. ======	+	This is documented for the designated communities on the landing page for the media pool and also on the multi language frequently asked questions (FAQ) page:
−	''Supporting Text''<br \>	+	From [[:pool:Main_Page|Media pool main page]]:<br/>
−	This is necessary to ensure that the repository has the capacity to make informed and timely	+	''Creative works of literature, science and art are subject to copyright law. Works in the public domain are those whose intellectual property rights have expired. With the help of volunteers, our team cleans, cataloged and digitized hundreds of gramophone records. After the clearing of copyrights, free works are available inside our media pool and Wikimedia Commons, compressed in Flac without any loss in quality (24-bit/192kHz).''
−	decisions when information indicates the need for new software.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	And further down on the same page:<br/>
−	Evaluation procedures in place; documented staff expertise in each software technology	+	''Permission: distributing, reproducing, streaming, sampling, remixing''
−	subsystem.
−	''Discussion''<br \>	+	From the [[PD:FAQ#What_I.27m_allowed_to_do_with_the_music_files.3F|FAQ]]:<br/>
−	Given information from technology watches or other technology monitoring notification	+	''Question: What I'm allowed to do with the music files?''<br/>
−	systems, the repository should have procedures and expertise to evaluate this data and make	+	''Answer: There is no restriction. You can for ex. redistribute it, copy it, modify it, use it in your own productions, use it as background music and so on.''
−	sound decisions regarding the need for new software. The objective is to track when
−	technology providers have developed software infrastructure that minimizes risk, or that
−	minimizes cost, or that improves performance. This is necessary to track emerging
−	technologies, and plan for upgrades before capacity limits occur. The evaluation should
−	identify when the risk of using new technology outweighs the expected benefit, and when the
−	new technology is sufficiently mature to minimize risk.
−	====== The repository shall have procedures, commitment, and funding to replace software when evaluation indicates the need to do so. ======	+	Unusual for other archives is the fact, that everybody can contribute to the project by supplying additional metadata, context information or by submitting SIPs to the archive. The project is and should be driven by volunteers as it is the base principle of this (and related) archives.
−	''Supporting Text''<br \>	+	To be able to do so, a user needs to create a user account and a wiki administrator needs to give writing rights to this user. This is more complicated for a wiki than usual but it had to made that strict because of severe spamming problems. Without more wiki administrators the project is not able to maintain easy writing access and keeping the wiki free from spam.
−	This is necessary to ensure software replacement in a timely fashion so as to avert system
−	failure or performance inadequacy. Without such a commitment, and more importantly,
−	without escrowed financial resources or a secure funding stream, technology watches and
−	notifications are of little value. The repository must have mechanisms for evaluating the
−	efficacy of the new systems before implementation in the production system.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall log and review all access management failures and anomalies.|The repository shall log and review all access management failures and anomalies.]] =====
−	Statement of commitment to provide expected and contracted levels of service; evidence of
−	ongoing financial assets set aside for software procurement; demonstration of cost savings
−	through amortized cost of new system.
−	''Discussion''<br \>	+	<span style="color:orange">Minor requirements are not fulfilled</span>
−	The objective is to demonstrate that the repository has the ability to incorporate new
−	technology, both financially through funding commitments or cost reduction, and
−	operationally through verification of the capabilities of the new systems.
−	===== The repository shall have adequate hardware and software support for backup functionality sufficient for preserving the repository content and tracking repository functions. =====	+	Related to access management failures are two logging systems. The first are the logging features of the MediaWiki software. This logs can be accessed via the ''Special pages'' link in the wiki: [http://pool.publicdomainproject.org/index.php?title=Special%3ALog&type=&user=&page=&year=&month=-1&tagfilter= Logs from the data pool wiki]
−	''Supporting Text''<br \>	+	The second logging system are the logs from the web server application (apache2) and a user front end (piwix) to create statistics and analyze this logs:
−	This is necessary in order to ensure continued access to and tracking of preservation
−	functions applied to the digital objects in their custody.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	* [http://195.176.247.101/stats/index.php?module=CoreHome&action=index&idSite=1&period=month&date=2016-05-18#?module=Actions&action=menuGetDownloads&idSite=1&period=month&date=2016-05-18 Webserver logs for the media data]
−	Documentation of what is being backed up and how often; audit log/inventory of backups;	+	* [http://195.176.247.101/stats/index.php?module=CoreHome&action=index&idSite=1&period=month&date=2016-05-05#?module=Actions&action=menuGetPageTitles&idSite=1&period=month&date=2016-05-05 Webserver logs for the error pages]. Status code ''404'' are ''Page not found'' errors
−	validation of completed backups; disaster recovery plan, policy and documentation; fire
−	drills; testing of backups; support contracts for hardware and software for backup
−	mechanisms; demonstrated preservation of system metadata such as access controls, location
−	of replicas, audit trails, checksum values.
−	''Discussion''<br \>	+	Not fulfilled is the requirement that written notes should exist of of reviews undertaken or action taken as a result of reviews.
−	The repository should be able to demonstrate the adequacy of the processes, hardware, and
−	software for its backup systems and the full range of ingest, preservation, and dissemination
−	functions required of a repository entrusted with long-term preservation. Simple backup
−	mechanisms must preserve not only the repository main content, but also the system
−	metadata generated by the preservation functions. Repositories need to develop backup plans
−	that ensure their continuity of operations across all failure modes.
−	===== The repository shall have effective mechanisms to detect bit corruption or loss. =====	+	From the discussion in the [[PD:CCSDS_652.0-M-1#The repository shall log and review all access management failures and anomalies.|CCSDS_652.0-M-1]] document one important concern is ''such as valid users’ being denied access''.
−	''Supporting Text''<br \>	+	Due to the nature of the public domain project this requirement is fulfilled when the requirement ''[[PD:Internal_CCSDS_652.0-M-1_audit#The repository shall maintain the associations between its AIPs and their descriptive information over time.|The repository shall maintain the associations between its AIPs and their descriptive information over time.]]'' is met because if it is possible to access the AIP from the descriptive metadata it is possible for the designated communities to get the AIP too. But this requirement is not yet fulfilled.
−	This is necessary in order to ensure that AIPs and metadata are uncorrupted or any data
−	losses are detected and fall within the tolerances established by repository policy (see 3.3.5).
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall follow policies and procedures that enable the dissemination of digital objects that are traceable to the originals, with evidence supporting their authenticity.|The repository shall follow policies and procedures that enable the dissemination of digital objects that are traceable to the originals, with evidence supporting their authenticity.]] ====
−	Documents that specify bit error detection and correction mechanisms used; risk analysis;
−	error reports; threat analysis; periodic analysis of the integrity of repository holdings.
−	''Discussion''<br \>	+	<span style="color:green">Requirements fulfilled</span>
−	The objective is a comprehensive treatment of the sources of data loss and their real-world
−	complexity. Any data or metadata that is (temporarily) lost should be recoverable from
−	backups. Routine systematic failures must not be allowed to accumulate and cause data loss
−	beyond the tolerances established by the repository policies. Mechanisms such as checksums
−	(MD5 signatures) or digital signatures should be recognized for their effectiveness in
−	detecting bit loss and incorporated into the overall approach of the repository for validating
−	integrity.
−	====== The repository shall record and report to its administration all incidents of data corruption or loss, and steps shall be taken to repair/replace corrupt or lost data. ======	+	From the discussion section of this requirement:
		+	''This requirement is concerned only with the relation between DIPs and the AIPs from which they are derived; elsewhere the link between the originals SIPs and the AIPs is considered.''
−	''Supporting Text''<br \>	+	The public domain project delivers as DIP directly the Flac file from the archival storage without modification. The designated community is able to check the authenticity of this Flac file because there are [[Wikipedia:Cyclic_redundancy_check|CRC]] and [[Wikipedia:Hash_function|hashes]] included in the Flac file to detect transmission errors.
−	This is necessary in order to ensure the repository administration is being kept informed of
−	incidents and recovery actions, and to enable identification of sources of data corruption or
−	loss.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	Additionally it would be helpful for the designated community to include the hash values of each AIP in the metadata details web page.
−	Procedures related to reporting incidents to administrators; preservation metadata (e.g., PDI)
−	records; comparison of error logs to reports to administration; escalation procedures related
−	to data loss; tracking of sources of incidents; remediation actions taken to remove sources of
−	incidents.
−	''Discussion''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall record and act upon problem reports about errors in data or responses from users.|The repository shall record and act upon problem reports about errors in data or responses from users.]] =====
−	Having effective mechanisms to detect bit corruption and loss within a repository system is
−	critical but it is only the initial step of a larger process. In addition to recording, reporting,
−	and repairing as soon as possible all violations of data integrity, these incidents and the
−	recovery actions and their results must be reported to administrators and made available to all
−	relevant staff. Given identification of the sources of data loss, an assessment of revisions to
−	software and hardware systems, or operational procedures, or management policies is needed
−	to minimize future risk of data loss.
−	===== The repository shall have a process to record and react to the availability of new security updates based on a risk-benefit assessment. =====	+	<span style="color:orange">Minor requirements are not fulfilled</span>
−	''Supporting Text''<br \>	+	The repository acts quickly on problem reports from members of the designated community or from internal staff. Most of the time problems are reported by e-mail and then forwarded to the responsible person.
−	This is necessary in order to protect the integrity of the archival objects from unauthorized
−	changes or deletions.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	There are no formal processes for problem reports and the reports from the last years are not archived in a central place where they can be reviewed or tracked if they are solved.
−	Risk register (list of all patches available and risk documentation analysis); evidence of
−	update processes (e.g., server update manager daemon); documentation related to the update
−	installations.
−	''Discussion''<br \>
−	Decisions to apply security updates are likely to be the outcome of a risk-benefit assessment;
−	security patches are frequently responsible for upsetting alternative aspects of system
−	functionality or performance. It may not be necessary for a repository to implement all
−	software patches, and the application of any must be carefully considered. Each security
−	update implemented by the repository must be documented with details about how it is
−	completed; both automated and manual updates are acceptable. Significant security updates
−	might pertain to software other than core operating systems, such as database applications
−	and Web servers, and these should also be documented. Security updates are not limited to
−	software security updates. Updates to actual hardware or to the hardware system’s firmware
−	are included. Over time it is likely that security updates will also be needed for the repository
−	processes and for its physical security. Although security updates can be considered as a part
−	of the change control, they are identified separately here because there are often outside
−	services that compile and circulate information on security issues and updates. At a
−	minimum, repositories should be monitoring these services to ensure that repository-held
−	data is not subject to compromise by identified threats.
−	===== The repository shall have defined processes for storage media and/or hardware change (e.g., refreshing, migration). =====	+	== [[PD:CCSDS_652.0-M-1#INFRASTRUCTURE AND SECURITY RISK MANAGEMENT|INFRASTRUCTURE AND SECURITY RISK MANAGEMENT]] ==
−	''Supporting Text''<br \>	+	=== [[PD:CCSDS_652.0-M-1#TECHNICAL INFRASTRUCTURE RISK MANAGEMENT|TECHNICAL INFRASTRUCTURE RISK MANAGEMENT]] ===
−	This is necessary in order to ensure that data is not lost when either the media fail or the
−	supporting hardware can no longer be used to access the data.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Documentation of migration processes; policies related to hardware support, maintenance,
−	and replacement; documentation of hardware manufacturer’s expected support life cycles;
−	policies related to migration of records to alternate hardware systems.
−	''Discussion''<br \>	+	==== [[PD:CCSDS_652.0-M-1#The repository shall identify and manage the risks to its preservation operations and goals associated with system infrastructure.|The repository shall identify and manage the risks to its preservation operations and goals associated with system infrastructure.]] ====
−	The repository should have estimates of the access speed and the quantity of information for
−	each type of storage media. Then with estimates of the reliable lifetime of the storage media
−	and information of system loading, etc., the repository can estimate the time required for
−	storage media migration, or refreshing or copying between media without reformatting the
−	bit stream. The repository can then set triggers for initiating the action at an appropriate time
−	so the actions will be completed before data is lost. Copying large quantities of data can take
−	a long time and can affect other system performance metrics. Repositories should also
−	consider the obsolescence of any and all hardware components within the repository system
−	as potential trigger events for migration. Increasingly, long-term, appropriate support for
−	system hardware components is difficult to obtain, exposing repositories to risks and
−	liabilities should they choose to continue to operate the hardware beyond the manufacturer or
−	third-party support warranties. Repositories will likely need to perform media migration off
−	of some types of media onto better supported media based on the estimated lifetime of
−	hardware support rather than on the longer life expected from the media. It is important that
−	the process include a check that the copying has happened correctly.
−	===== The repository shall have identified and documented critical processes that affect its ability to comply with its mandatory responsibilities. =====	+	<span style="color:red">Essential requirements not fulfilled</span>
−	''Supporting Text''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall employ technology watches or other technology monitoring notification systems.|The repository shall employ technology watches or other technology monitoring notification systems.]] =====
−	This is necessary in order to ensure that the critical processes can be monitored to ensure that
−	they continue to meet the mandatory responsibilities and to ensure that any changes to those
−	processes are examined and tested.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Traceability matrix between processes and mandatory requirements.
−	''Discussion''<br \>	+	====== [[PD:CCSDS_652.0-M-1#The repository shall have hardware technologies appropriate to the services it provides to its designated communities.|The repository shall have hardware technologies appropriate to the services it provides to its designated communities.]] ======
−	Examples of critical processes include data management, access, archival storage, ingest, and
−	security processes. Traceability makes it possible to understand which repository processes
−	are required to meet each of the mandatory responsibilities.
−	====== The repository shall have a documented change management process that identifies changes to critical processes that potentially affect the repository’s ability to comply with its mandatory responsibilities. ======	+	<span style="color:orange">Minor requirements are not fulfilled</span>
−	''Supporting Text''<br \>	+	Maintenance of up-to-date Designated Community technology, expectations, and use profiles; provision of bandwidth adequate to support ingest and use demands; systematic elicitation of feedback regarding hardware and service adequacy; maintenance of a current hardware inventory.
−	This is necessary in order to ensure that the repository can specify not only the current
−	processes, but the prior processes that were applied to the repository holdings.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	The server hardware for hosting the ingest, search and delivery services where upgraded in spring 2015. There performance is very good compared to the current workload. They are ready to handle many more users.
−	Documentation of change management process; assessment of risk associated with a process
−	change; analysis of the expected impact of a process change; comparison of logs of actual
−	changes to processes versus associated analyses of their impact and criticality.
−	''Discussion''<br \>	+	The archival storage system is still fast enough for the current demands and has also still enough storage capacity for the next time. In the archival storage system  there are 50% spare slots for additional hard drives.
−	Examples of this would include changes to processes for data management, access, archival
−	storage, ingest, and security. The really important thing is to be able to know what changes
−	were made and when they were made. Traceability makes it possible to understand what was
−	affected by particular changes to the systems. If unintended consequences are later
−	discovered, then having this record may make it possible to reverse the changes or at least to
−	document the changes that were introduced. Change management is a component of the
−	broader topic of configuration management described by ISO 10007:2003 which includes
−	configuration management planning, configuration identification, change control,
−	configuration status accounting and configuration audit. Configuration Management efforts
−	should result in a complete audit trail of decisions and design modifications.
−	====== The repository shall have a process for testing and evaluating the effect of changes to the repository’s critical processes. ======	+	The Internet connectivity is a symmetrical 1 Gbit/s connection without traffic limitation. For the current user numbers this is enough to achieve short download times.
−	''Supporting Text''<br \>	+	This requirement is not fulfilled because there exists no current hardware inventory and there is no procedure or system to ask for and receive feedback from the designated communities.
−	This is necessary in order to protect the integrity of the repository’s critical processes such
−	that they continue in their ability to meet the repository’s mandatory requirements.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	====== [[PD:CCSDS_652.0-M-1#The repository shall have procedures in place to monitor and receive notifications when hardware technology changes are needed.|The repository shall have procedures in place to monitor and receive notifications when hardware technology changes are needed.]] ======
−	Documented testing procedures; documentation of results from prior tests and proof of
−	changes made as a result of tests; analysis of the impact of a process change.
−	''Discussion''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Changes to critical systems should be, where possible, pre-tested separately, the expected
−	behaviors documented, and roll-back procedures prepared. After changes, the systems should
−	be monitored for unexpected and unacceptable behavior. If such behavior is discovered the
−	changes and their consequences should be reversed. Whole-system testing or unit testing can
−	address this requirement; complex safety-type tests are not required. Testing can be very
−	expensive, but there should be some recognition of the fact that a completely open regime
−	where no changes are ever evaluated or tested will have problems.
−	==== The repository shall manage the number and location of copies of all digital objects. ====	+	No written procedures but monitoring systems in place to observe server workloads, memory usage, network traffic and free archival storage space.
−	''Supporting Text''<br \>	+	====== [[PD:CCSDS_652.0-M-1#The repository shall have procedures in place to evaluate when changes are needed to current hardware.|The repository shall have procedures in place to evaluate when changes are needed to current hardware.]] ======
−	This is necessary in order to assert that the repository is providing an authentic copy of a
−	particular digital object.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Random retrieval tests; validation of object existence for each registered location; validation
−	of a registered location for each object on storage systems; provenance and fixity checking
−	information; location register/log of digital objects compared to the expected number and
−	location of copies of particular objects.
−	''Discussion''<br \>	+	====== [[PD:CCSDS_652.0-M-1#The repository shall have procedures, commitment and funding to replace hardware when evaluation indicates the need to do so.|The repository shall have procedures, commitment and funding to replace hardware when evaluation indicates the need to do so.]] ======
−	A repository can have different preservation policies for different classes of objects,
−	depending on factors such as the producer, the information type, or its value. Repositories
−	may require a different number of copies for each class, or manage versions needed to meet
−	access requirements. There may be additional identification requirements if the data integrity
−	mechanisms use alternative copies to replace failed copies. The location of each digital
−	object must be described such that the object can be located precisely, without ambiguity.
−	The location can be an absolute physical location or a logical location within a storage media
−	or a storage subsystem. Provenance information about copying and moving the data must be
−	maintained/updated, including the identification of those responsible. This is necessary in
−	order to track chain of custody and assert that the repository is providing an authentic copy of
−	a particular digital object. The repository must be able to distinguish between versions of
−	objects or copies and identical copies. This is necessary in order that a repository can assert
−	that it is providing an authentic copy of the correct version of an object.
−	===== The repository shall have mechanisms in place to ensure any/multiple copies of digital objects are synchronized. =====	+	<span style="color:red">Essential requirements not fulfilled</span>
−	''Supporting Text''<br \>	+	====== [[PD:CCSDS_652.0-M-1#The repository shall have software technologies appropriate to the services it provides to its designated communities.|The repository shall have software technologies appropriate to the services it provides to its designated communities.]] ======
−	This is necessary in order to ensure that multiple copies of a digital object remain identical,
−	within a time established as acceptable by the repository, and that a copy can be used to
−	replace a corrupted copy of the object.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	<span style="color:orange">Minor requirements are not fulfilled</span>
−	Synchronization workflows; system analysis of how long it takes for copies to synchronize;
−	procedures/documentation of synchronization processes.
−	''Discussion''<br \>	+	The examples of ways the repository can demonstrate it is meeting this requirement clearly shows that several requirements have to be met:
−	The disaster recovery plan should address what to do should a disaster and an update
−	coincide. For example, if one copy of an object is altered and a disaster occurs while the
−	second is being updated, there needs to be a mechanism to assure that the copy will be
−	updated at the first available opportunity. The mechanisms to synchronize copies of digital
−	objects should be able to detect bit corruption and validate fixity checks before
−	synchronization is attempted.
		+	'''Maintenance of up-to-date Designated Community technology, expectations, and use profiles'''<br/>
		+	At the time of writing the expectations of the designated community is moving towards mobile use on smart phones and tablets. The MediaWiki software is not very well suited yet for this devices. This is a known problem and the MediaWiki community is working on this. On desktop and laptop computers the project gives access in a usefull way. The finding aids could be improved for the global community.
−	=== SECURITY RISK MANAGEMENT ===	+	The on-line radio streams and the page to access this streams seems to fulfill the needs.
−	==== The repository shall maintain a systematic analysis of security risk factors associated with data, systems, personnel, and physical plant. ====	+	'''Provision of software systems adequate to support ingest and use demands'''<br/>
		+	Software support for ingest is weak.
−	''Supporting Text''<br \>	+	'''Systematic elicitation of feedback regarding software and service adequacy'''<br/>
−	This is necessary to ensure ongoing and uninterrupted service to the Designated Community.	+	There is no systematic elicitation of feedback about software topics.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	'''Maintenance of a current software inventory'''<br/>
−	Repository employs the codes of practice found in the ISO 27000 series of standards system	+	Software inventory is managed via the package manager ''apt'' used in Debian GNU/Linux. This covers most of the used software like operating system, common services, web server, on-line radio software etc. MediaWiki and the statistics tool piwix are maintained separately. To help the system administrator MediaWiki provides a inventory of installed extensions and version numbers of them together with the version number of the dependencies: [[Special:Version|Version number of MediaWiki and its extensions]]
−	control list; risk, threat, or control analysis.
−	''Discussion''<br \>	+	====== [[PD:CCSDS_652.0-M-1#The repository shall have procedures in place to monitor and receive notifications when software changes are needed.|The repository shall have procedures in place to monitor and receive notifications when software changes are needed.]] ======
−	The repository should conduct regular risk assessments and maintain adequate security
−	protection in order to provide expected and contracted levels of service, following codes of
−	practice such as ISO 27000.
−	‘System’ here refers to more than IT systems, such as hardware, software, communications	+	<span style="color:red">Essential requirements not fulfilled</span>
−	equipment and facilities, and firewalls. Fire protection and flood detection systems are also
−	significant, as are means to assess personnel, management, and administration procedures,
−	resources, as well as operations and service delivery. Loss of income, budget and reputation
−	are significant threats to overall operations as is loss of mandate. On-going internal and
−	external evaluation should be conducted to assess quality of service and relevance to user
−	community served and periodic financial audits should be secured to ascertain ethical and
−	legal practice and maintenance of required operating funds. Intellectual property rights
−	practices should also be reviewed regularly as well as the repository’s liability for regulatory
−	non-compliance as applicable. The repository should assess its staff’s skills against those
−	required in the evolving digital repository environment and ensure acquisition of new staff or
−	retraining of existing staff as necessary. Regular risk assessment should also address external
−	threats and denial of service attacks and loss of or unacceptable quality of third party
−	services. The repository may conduct overall risk assessments with tools such as
−	DRAMBORA. 2
−	==== The repository shall have implemented controls to adequately address each of the defined security risks. ====	+	====== [[PD:CCSDS_652.0-M-1#The repository shall have procedures in place to evaluate when changes are needed to current software.|The repository shall have procedures in place to evaluate when changes are needed to current software.]] ======
−	''Supporting Text''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	This is necessary in order to ensure that controls are in place to meet the security needs of the
−	repository.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	====== [[PD:CCSDS_652.0-M-1#The repository shall have procedures, commitment, and funding to replace software when evaluation indicates the need to do so.|The repository shall have procedures, commitment, and funding to replace software when evaluation indicates the need to do so.]] ======
−	Repository employs the codes of practice found in the ISO 27000 series of standards; system
−	control list; risk, threat, or control analyses; and addition of controls based on ongoing risk
−	detection and assessment. Repository maintains ISO 17799 certification.
−	''Discussion''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	The repository should show how it has dealt with its security requirements. If some types of
−	material are more likely to be attacked, the repository will need to provide more protection,
−	for instance. Repositories that have experienced incidents could record such instances,
−	including the times when systems or content were affected and describe procedures that have
−	been put in place to prevent similar occurrences in the future. Repositories may also conduct
−	a variety of disaster drills that may involve their parent organization or the community at
−	large. Contingency plans are especially important and need to be tested, updated, and revised
−	on a regular basis. See http://www.repositoryaudit.eu/.
−	==== The repository staff shall have delineated roles, responsibilities, and authorizations related to implementing changes within the system. ====	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have adequate hardware and software support for backup functionality sufficient for preserving the repository content and tracking repository functions.|The repository shall have adequate hardware and software support for backup functionality sufficient for preserving the repository content and tracking repository functions.]] =====
−	''Supporting Text''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	This is necessary in order to ensure that individuals have the authority to implement changes,
−	that adequate resources have been assigned for the effort, and that the responsible individuals
−	will be accountable for implementing such changes.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have effective mechanisms to detect bit corruption or loss.|The repository shall have effective mechanisms to detect bit corruption or loss.]] =====
−	Repository employs the codes of practice found in the ISO 27000 series of standards;
−	organizational chart; system authorization documentation. Repository maintains ISO 17799
−	certification.
−	''Discussion''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Authorizations are about who can do what: who can add users, who has access to change
−	metadata, who can access audit logs. It is important that authorizations are justified, that staff
−	understand what they are authorized to do, that staff have required skills associated with
−	various roles and authorizations, and that there is a consistent view of this across the
−	organization.
−	==== The repository shall have suitable written disaster preparedness and recovery plan(s), including at least one off-site backup of all preserved information together with an offsite copy of the recovery plan(s). ====	+	====== [[PD:CCSDS_652.0-M-1#The repository shall record and report to its administration all incidents of data corruption or loss, and steps shall be taken to repair/replace corrupt or lost data.|The repository shall record and report to its administration all incidents of data corruption or loss, and steps shall be taken to repair/replace corrupt or lost data.]] ======
−	''Supporting Text''<br \>	+	<span style="color:red">Essential requirements not fulfilled</span>
−	This is necessary in order to ensure that sufficient backup and recovery capabilities are in
−	place to facilitate continuing preservation of and access to systems and their content with
−	limited disruption of services.
−	''Examples of Ways the Repository Can Demonstrate It Is Meeting This Requirement''<br \>	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have a process to record and react to the availability of new security updates based on a risk-benefit assessment.|The repository shall have a process to record and react to the availability of new security updates based on a risk-benefit assessment.]] =====
−	Repository employs the codes of practice found in the ISO 27000 series of standards; disaster
−	and recovery plans; information about and proof of at least one off-site copy of preserved
−	information; service continuity plan; documentation linking roles with activities; local
−	geological, geographical, or meteorological data or threat assessments. Repository maintains
−	ISO 17799 certification.
−	''Discussion''<br \>	+	<span style="color:green">Requirements fulfilled</span>
−	The level of detail in a disaster plan, and the specific risks addressed need to be appropriate
−	to the repository’s location and service expectations. Fire is an almost universal concern, but
−	earthquakes may not require specific planning at all locations. The disaster plan must,
−	however, deal with unspecified situations that would have specific consequences, such as
−	lack of access to a building or widespread illness among critical staff. In the event of a
−	disaster at the repository, the repository may want to contact local and/or national disaster
−	recovery bodies for assistance. Repositories may also conduct a variety of disaster drills that
−	may involve their parent organization or the community at large.
		+	To be informed which security updates are available the public domain project is subscribed to this two mailing lists:
		+	* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki update and security announcements list]
		+	* [https://lists.debian.org/debian-security-announce/ Debian Security announcements]
−	== ANNEX A SECURITY CONSIDERATIONS (INFORMATIVE) ==	+	Log files from the package manager are available on the server to check what software and patches was installed.
−	=== A1    INTRODUCTION ===	+	The risk-benefit analysis is done by the Debian security team. This volunteers monitor the newly discovered security problems in the Debian stable systems (GNU/Linux operating system and important application software). They prepare, test and provide patches against this problems and try to make sure that the expected behavior does not change.
−	The use of the Audit and Certification Recommended Practice has several potential areas of
−	security concern.
−	One security concern is the possibility that the repository is fooled into undergoing an audit	+	For the MediaWiki software the risk-benefit analysis is done by the system administrator. But normally MediaWiki security patches are well tested and if there is any side effect it is documented by the developers: [https://lists.wikimedia.org/pipermail/mediawiki-announce/ Archive of MediaWiki-announce mails]
−	by someone unqualified or even malicious.
−	Another concern involves the possible release of confidential information which is collected
−	as evidence by the auditor.
−	=== A2    SECURITY CONCERNS WITH RESPECT TO THE CCSDS DOCUMENT ===	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have defined processes for storage media and/or hardware change (e.g., refreshing, migration).|The repository shall have defined processes for storage media and/or hardware change (e.g., refreshing, migration).]] =====
−	The repository may ask someone to perform an audit using this Recommended Practice.
−	There is a possibility that the person contacted is not in fact the person that the repository
−	believes him or her to be. Alternatively the correct person may be contacted but in fact
−	another, possibly malicious, person may turn up to perform the audit.
−	In the process of collecting evidence for the various metrics the auditor may collect
−	information which is confidential or sensitive, for example details of security weaknesses.
−	There is a danger that such information may fall into the wrong hands and expose the
−	repository to increased risk. Alternatively in the process of collecting evidence the repository
−	system may be damaged.
−	While these are all valid security concerns, they fall outside the purview of this	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Recommended Practice, which applies only to the metrics which an auditor should use for
−	auditing a repository.
−	=== A3    POTENTIAL THREATS AND ATTACK SCENARIOS ===	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have identified and documented critical processes that affect its ability to comply with its mandatory responsibilities.|The repository shall have identified and documented critical processes that affect its ability to comply with its mandatory responsibilities.]] =====
−	Impersonation of an auditor and/or release of confidential information could both result in
−	exposing the repository and its holdings to increased risk and loss of reputation of the
−	repository.
−	=== A4    CONSEQUENCES OF NOT APPLYING SECURITY TO THE TECHNOLOGY ===	+	<span style="color:red">Essential requirements not fulfilled</span>
−	While these security issues are of concern, they are out of scope with respect to this
−	document. This document aims to provide the basis for an audit and certification process for
−	assessing the trustworthiness of digital repositories. Providing protection against false
−	auditors must rely on the repository’s identification and authorization systems. Protection
−	against loss of confidential information in the possession of the auditor must be provided by
−	the security system of that auditor and the method of transmission of information which is
−	agreed between the repository and auditor. Protection against damage to the repository or its
−	holdings during an audit must rely on the security and safety systems of the repository.
		+	====== [[PD:CCSDS_652.0-M-1#The repository shall have a documented change management process that identifies changes to critical processes that potentially affect the repository's ability to comply with its mandatory responsibilities.|The repository shall have a documented change management process that identifies changes to critical processes that potentially affect the repository's ability to comply with its mandatory responsibilities.]] ======
−	== ANNEX B REFERENCES (INFORMATIVE) ==	+	<span style="color:red">Essential requirements not fulfilled</span>
−	[B1] D. Waters and J. Garrett. Preserving Digital Information. Report of the Task Force	+	====== [[PD:CCSDS_652.0-M-1#The repository shall have a process for testing and evaluating the effect of changes to the repository's critical processes.|The repository shall have a process for testing and evaluating the effect of changes to the repository's critical processes.]] ======
−	on Archiving of Digital Information. Washington, DC: CLIR, May 1996.
−	[B2] Trusted Digital Repositories: Attributes and Responsibilities. An RLG-OCLC Report.	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Mountain View, CA: RLG, May 2002.
−	[B3] Trustworthy Repositories Audit & Certification: Criteria and Checklist. Version 1.0.	+	==== [[PD:CCSDS_652.0-M-1#The repository shall manage the number and location of copies of all digital objects.|The repository shall manage the number and location of copies of all digital objects.]] ====
−	Chicago: CRL, February 2007.
−	[B4] Producer-Archive Interface Methodology Abstract Standard. Recommendation for	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Space Data System Standards, CCSDS 651.0-M-1. Magenta Book. Issue 1.
−	Washington, D.C.: CCSDS, May 2004.
−	[B5] XML Formatted Data Unit (XFDU) Structure and Construction Rules.	+	===== [[PD:CCSDS_652.0-M-1#The repository shall have mechanisms in place to ensure any/multiple copies of digital objects are synchronized.|The repository shall have mechanisms in place to ensure any/multiple copies of digital objects are synchronized.]] =====
−	Recommendation for Space Data System Standards, CCSDS 661.0-B-1. Blue Book.
−	Issue 1. Washington, D.C.: CCSDS, September 2008.
−	[B6] The Data Description Language EAST Specification (CCSD0010). Recommendation	+	<span style="color:red">Essential requirements not fulfilled</span>
−	for Space Data System Standards, CCSDS 644.0-B-3. Blue Book. Issue 3.
−	Washington, D.C.: CCSDS, July 2009.
−	[B7] Data Entity Dictionary Specification Language (DEDSL)—Abstract Syntax
−	(CCSD0011). Recommendation for Space Data System Standards, CCSDS 647.1-B-
−	1. Blue Book. Issue 1. Washington, D.C.: CCSDS, June 2001.
−	[B8] “Digital Preservation Management: Implementing Short-Term Strategies for Long-	+	=== [[PD:CCSDS_652.0-M-1#SECURITY RISK MANAGEMENT|SECURITY RISK MANAGEMENT]] ===
−	Term Problems.” Digital Preservation Management Resources. Cornell University.
−	[B9] Quality Management Systems—Fundamentals and Vocabulary.                 International	+	==== [[PD:CCSDS_652.0-M-1#The repository shall maintain a systematic analysis of security risk factors associated with data, systems, personnel, and physical plant.|The repository shall maintain a systematic analysis of security risk factors associated with data, systems, personnel, and physical plant.]] ====
−	Standard, ISO 9000:2005. 3rd edition. Geneva: ISO, 2005.
−	[B10] Information Technology—Security Techniques—Code of Practice for Information	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Security Management. International Standard, ISO/IEC 17799:2005. 2nd edition.
−	Geneva: ISO, 2005.
−	[B11] Information and Documentation—Records Management—Part                1:   General.	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have implemented controls to adequately address each of the defined security risks.|The repository shall have implemented controls to adequately address each of the defined security risks.]] ====
−	International Standard, ISO 15489-1:2001. Geneva: ISO, 2001.
−	[B12] Information and Documentation—Records Management—Part 2: Guidelines.	+	<span style="color:red">Essential requirements not fulfilled</span>
−	International Standard, ISO/TR 15489-2:2001. Geneva: ISO, 2001.
−	[B13] Trustworthy Information Systems Handbook.     Version 4.   Saint Paul, Minnesota:	+	==== [[PD:CCSDS_652.0-M-1#The repository staff shall have delineated roles, responsibilities, and authorizations related to implementing changes within the system.|The repository staff shall have delineated roles, responsibilities, and authorizations related to implementing changes within the system.]] ====
−	Minnesota Historical Society, July 2002.
−	[B14] Ron Ross, et al. Guide for Assessing the Security Controls in Federal Information	+	<span style="color:red">Essential requirements not fulfilled</span>
−	Systems. National Institute of Standards and Technology Special Publication 800-
−	53A. Gaithersburg, Maryland: NIST, July 2008.
−	[B15] Susanne Dobratz, Astrid Schoger, and Stefan Strathmann. “The nestor Catalogue of	+	==== [[PD:CCSDS_652.0-M-1#The repository shall have suitable written disaster preparedness and recovery plan(s), including at least one off-site backup of all preserved information together with an offsite copy of the recovery plan(s).|The repository shall have suitable written disaster preparedness and recovery plan(s), including at least one off-site backup of all preserved information together with an offsite copy of the recovery plan(s).]] ====
−	Criteria for Trusted Digital Repository Evaluation and Certification.” Journal of
−	Digital Information 8, no. 2 (2007).
		+	<span style="color:red">Essential requirements not fulfilled</span>
		+	[[Category:PD:Administration]]
	[[Category:Archival_science]]		[[Category:Archival_science]]

---

Revision as of 16:42, 23 January 2017

WARNING

This is only a working draft. This audit is not finished and does not represent the current state of the Public Domain Project! Date of audit report: June 2016

Version of audit report: 1.0

This is the first audit of the public domain project. This audit is the starting point for a long term program to develop and install the required organizational and technical methods to fulfill the requirements for a long term digital archive.

This audit was done according to the recommended practice 652.0-M-1 AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES from 2011 published by the Consultative Committee for Space Data Systems (CCSDS). The same committee that published the Reference Model for an Open Archival Information System (OAIS).

It was clear from the beginning, that this first audit will show a lot of weak points, not addressed problems and essential requirements that are not fulfilled.

Therefor the huge amount of requirements marked as not fulfilled (red) should not lead to the verdict that the public domain project is completely not trustworthy. The existence of this audit is more than many other archives provide as publicly available information source to evaluate the trustworthiness.

The result of this first audit is the fundamental work for the development of requirements for future processes, technical methods and investments. It helps also to manage this development projects as it provides a metric to measure the impact of a proposal.

This audit will be replaced by a more recent audit after the implementation of serious improvements. So it is possible to track the efforts the project invests into the longterm preservation and its trustworthiness.

This audit documentation is structured in a similar way as the CCSDS 652.0-M-1 Recommended Practice document:

• introduction
• overview of audit and certification criteria
• conclusion
• catalog of requirements

OVERVIEW OF AUDIT AND CERTIFICATION CRITERIA

A TRUSTWORTHY DIGITAL REPOSITORY

Definition of a trustworthy digital repository as given in the CCSDS 652.0-M-1 Recommended Practice document:

A trustworthy digital repository will understand threats to and risks within its systems. Constant monitoring, planning, and maintenance, as well as conscious actions 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.

DEFINITIONS

Each requirement is marked with a color, to show its status of fulfillment:

• Requirements fulfilled
• Minor requirements are not fulfilled
• Essential requirements not fulfilled

These definitions from the original audit document all apply to this internal audit:

• TERMINOLOGY
• Glossary
• CONVENTIONS

For a better understanding some paragraphs of the CCSDS 652.0-M-1 Recommended Practice are reproduced here.

CONFORMANCE

Original text: An archive that conforms to this Recommended Practice shall have satisfied the auditor on each of the requirements.

EVIDENCE

Each metric in the Recommended Practice 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.

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.

ACRONYMS AND ABBREVIATIONS

AIP	Archival Information Package (defined in reference [1])
CCSDS	Consultative Committee for Space Data Systems
DEDSL	Data Entity Specification Language
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

REFERENCES

[1] Reference Model for an Open Archival Information System (OAIS).

For convenience the full text of the recommended practice CCSDS 652.0-M-1 AUDIT AND CERTIFICATION OF TRUSTWORTHY DIGITAL REPOSITORIES is readable on this wiki page: PD:CCSDS_652.0-M-1. Every requirement is directly linked to the corresponding explanation in the CCSDS 652.0-M-1 Recommended Practice.

The original document is published on the CCSDS Website: CCSDS Recommended Practices (Magenta Books)

CONCLUSION AND FIELDS OF NON CONFORMANCE

OVERVIEW

Of the 108 normative metrics the final status is the following:

Metrics with all requirements fulfilled (green): 16
Metrics where Minor requirements are not fulfilled (orange): 15
Metrics with essential requirements not fulfilled (red): 77

FIELDS OF NON CONFORMANCE

ESSENTIAL DEFINITIONS

In the project and between the project members there is a mutual understanding of the designated communities but it is not precisely defined and therefor the knowledge base of these communities is not known.

The same is true for the definition of the content information that has to be preserved.

REPRESENTATION INFORMATION

An example of an underdeveloped area is the field of representation information, because the awareness of the underlying problems and the concepts to handle them was missing in the project at the beginning of this audit. The consequent use of open standards and open source software makes it a bit less critical. But because any representation information is missing, it still creates a large long term risk for the repository.

This whole topic has to be addressed in the near future.

MANAGEMENT AND PRESERVATION PLANNING

The area of management tasks, strategic planning, development of policies and tracking is also underdeveloped. Also, there is no risk assessment installed and consequently there are no processes to observe the technical and legal environment of the repository on a regular basis.

Also missing is a system to plan, manage and track work packages, milestones, issues etc. to support the further development of management and preservation planning.

Furthermore a system which enables end users and producers to submit feedback and where submitters can observe the reactions and actions in response to their feedback is missing.

DIGITAL OBJECT MANAGEMENT

It was already known that the handling of the digital objects in the repository has its risks that have not been addressed yet.

The digital objects are at risk because there is no system to prevent unintended deletion of objects, there is no off-site backup and there is no system and associated monitoring to guarantee the bit-level correctness of the digital objects now and in the future.

Also the system to create identifiers for AIPs is not documented and is not ideal for the scalability of the repository.

CONCLUSION

As it was expected a lot of requirements are not fulfilled. However, the value of this audit is high because it detected very underdeveloped areas inside the project and as such raises the awareness of these problems. Twelve issues them can easily be fixed by documenting what is currently implemented.

It is of high importance to fix the lack of the essential definitions about content information and designated community.

A large field to work on are the regular maintenance and observation tasks of the management and preservation planning. They have to be defined, documented, executed and reviewed.

On the technical side, the completely missing representation information is a substantial shortcoming for a longterm repository. If this information is collected in the near future and maintained thereafter, the real risk of losing understandability is relatively low.

ORGANIZATIONAL INFRASTRUCTURE

With this chapter the catalog of requirements starts. Every requirement is explained in the CCSDS 652.0-M-1 document, this explanation can be reached directly by clicking on the heading of the requirement.

GOVERNANCE AND ORGANIZATIONAL VIABILITY

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.

Requirements fulfilled

Bylaws §2 of the Swiss Foundation Public Domain

The repository shall have a Preservation Strategic Plan that defines the approach the repository will take in the long-term support of its mission.

Essential requirements not fulfilled

The repository shall have an appropriate succession plan, contingency plans, and/or escrow arrangements in place in case the repository ceases to operate or the governing or funding institution substantially changes its scope.

Essential requirements not fulfilled

There is no succession plan to address the case the repository ceases to operate or the governing or funding institution substantially changes its scope.

Escrow arrangements are not needed because of the consequent use of free and open source software.

The repository shall monitor its organizational environment to determine when to execute its succession plan, contingency plans, and/or escrow arrangements.

Minor requirements are not fulfilled

Financial monitoring is done every year in retrospect to fulfill the accounting requirements for a charity foundation in Switzerland. This includes an external audit by certified layers and is supervised by the Eidgenössische Stiftungsaufsicht.

Monitoring the organizational environment is not in place and fiscal planning is underdeveloped.

The repository shall have a Collection Policy or other document that specifies the type of information it will preserve, retain, manage, and provide access to.

Requirements fulfilled

Bylaws §2 of the Swiss Foundation Public Domain

ORGANIZATIONAL STRUCTURE AND STAFFING

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.

Essential requirements not fulfilled

The repository shall have identified and established the duties that it needs to perform.

Essential requirements not fulfilled

The repository shall have the appropriate number of staff to support all functions and services.

Essential requirements not fulfilled

The repository shall have in place an active professional development program that provides staff with skills and expertise development opportunities.

Essential requirements not fulfilled

PROCEDURAL ACCOUNTABILITY AND PRESERVATION POLICY FRAMEWORK

The repository shall have defined its Designated Community and associated knowledge base(s) and shall have these definitions appropriately accessible.

Essential requirements not fulfilled

The repository shall have Preservation Policies in place to ensure its Preservation Strategic Plan will be met.

Essential requirements not fulfilled

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.

Essential requirements not fulfilled

The repository shall have a documented history of the changes to its operations,

Essential requirements not fulfilled

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.

Minor requirements are not fulfilled

Reports of financial and technical audits:
Publications of the Foundation do not include yet financial reports because the foundation is quite new and the first report covering 2014 is just finished. But it is planned to publish them.

The first technical audit is the one that is presented in this document. It is published publicly on this page: Internal Audit (CCSDS_652.0-M-1)

Disclosure of governance documents:
As can be seen from other requirements there are no governance documents yet, so there is nothing to be publicly available.

Contracts and agreements with providers of funding and critical services:
They are not publicly available yet.

The repository shall define, collect, track, and appropriately provide its information integrity measurements.

Essential requirements not fulfilled

The repository shall commit to a regular schedule of self-assessment and external certification.

Essential requirements not fulfilled

FINANCIAL SUSTAINABILITY

The repository shall have short- and long-term business planning processes in place to sustain the repository over time.

Essential requirements not fulfilled

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.

Requirements fulfilled

The auditor has witnessed audited annual financial statements for the year 2014 and 2015. As shown above, these statements are not publicly available which should be changed.

The repository shall have an ongoing commitment to analyze and report on financial risk, benefit, investment, and expenditure (including assets, licenses, and liabilities).

Essential requirements not fulfilled

CONTRACTS, LICENSES, AND LIABILITIES

The repository shall have and maintain appropriate contracts or deposit agreements for digital materials that it manages, preserves, and/or to which it provides access.

Essential requirements not fulfilled

The repository shall have contracts or deposit agreements which specify and transfer all necessary preservation rights, and those rights transferred shall be documented.

Essential requirements not fulfilled

The repository shall have specified all appropriate aspects of acquisition, maintenance, access, and withdrawal in written agreements with depositors and other relevant parties.

Essential requirements not fulfilled

The repository shall have written policies that indicate when it accepts preservation responsibility for contents of each set of submitted data objects.

Essential requirements not fulfilled

The repository shall have policies in place to address liability and challenges to ownership/rights.

Requirements fulfilled

The repository shall track and manage intellectual property rights and restrictions on use of repository content as required by deposit agreement, contract, or license.

Requirements fulfilled

The goal of the Public Domain Project is to make accessible digitized audio content. This requires a thoroughly checking of the intellectual property rights of each work.

The result of this effort can be seen on every detail information page like this example (Gramophone-14678-b45142). Every work includes information about the copyright status in Switzerland, the European Union and the United States including the year when the work enters the public domain. With this information it is possible to track once a year which works entered the public domain (Relevant is only the year, so once a year is enough) and can be made accessible.

DIGITAL OBJECT MANAGEMENT

INGEST: ACQUISITION OF CONTENT

The repository shall identify the Content Information and the Information Properties that the repository will preserve.

Essential requirements not fulfilled

The repository shall have a procedure(s) for identifying those Information Properties that it will preserve.

Essential requirements not fulfilled

The repository shall have a record of the Content Information and the Information Properties that it will preserve.

Essential requirements not fulfilled

The repository shall clearly specify the information that needs to be associated with specific Content Information at the time of its deposit.

Minor requirements are not fulfilled

The wiki template Audio_fileshows all needed information. But there is limited documentation about it and how to handle it. The section on references is appropriate but the problems start with date fields because there is no date format specified. Also problematic is, that there is no information about the vocabulary to use, should it be a controlled vocabulary (which one) is it free, are there different requirements for each field?

The repository shall have adequate specifications enabling recognition and parsing of the SIPs.

Essential requirements not fulfilled

The repository shall have mechanisms to appropriately verify the identity of the Producer of all materials.

Minor requirements are not fulfilled

To upload AIPs (Flac files) to the archival storage the FTP protocol is used with user authentication. The user name of the person who uploaded a certain file is visible on the file system of the archival storage as the UNIX owner of the file. This information is not visible and therefor not verifiable by the designated community.

The history of the associated PDI and the identity of its creator is publicly visible and can be verified by everyone. The PDI is stored and edited in wiki pages and MediaWiki requires a password protected user login to edit this information.

The repository shall have an ingest process which verifies each SIP for completeness and correctness.

Essential requirements not fulfilled

The repository shall obtain sufficient control over the Digital Objects to preserve them.

The repository shall provide the producer/depositor with appropriate responses at agreed points during the ingest processes.

Requirements fulfilled

With the depositors there are no agreed points where responses are necessary. But it is possible to get a lot of information about ingested objects by the category listing (each depositor has it's own category to list all his objects), the recent changes page of the wiki and other ways (eg. watchlists). Reports about the ingestion process are done usually annually for the financial supporters.

The repository shall have contemporaneous records of actions and administration processes that are relevant to content acquisition.

Essential requirements not fulfilled

INGEST: CREATION OF THE AIP

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.

Essential requirements not fulfilled

The repository shall be able to identify which definition applies to which AIP.

Essential requirements not fulfilled

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.

Essential requirements not fulfilled

The repository shall have a description of how AIPs are constructed from SIPs.

Essential requirements not fulfilled

The process is not documented but essentially the SIP is the Flac file that is uploaded to the storage server and forms together with the detailed description in the wiki the AIP. So the AIP consists of the wiki page and the linked Flac file.

The repository shall document the final disposition of all SIPs. In particular the following aspect must be checked.

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.

Minor requirements are not fulfilled

The repository shall have and use a convention that generates persistent, unique identifiers for all AIPs.

Essential requirements not fulfilled

Each AIP is identified by a string composed in the following way: <Label>-<Catalog number>-<Order number>

Example:

• Label: Homocord
• Catalog number: B 367
• Order number: M 17234

This results in the URL for the detailed information page: http://pool.publicdomainproject.org/index.php/Homocord-b367-m17234

And the according Flac file name is: homocord-b367-m17234.flac

The repository shall uniquely identify each AIP within the repository.

Requirements fulfilled

The repository shall have unique identifiers.

Requirements fulfilled

Given that there are no conflicting catalog/order numbers used by a label. This is unlikely but it could happen.

The repository shall assign and maintain persistent identifiers of the AIP and its components so as to be unique within the context of the repository.

Requirements fulfilled

The described naming scheme is unique in the context of 78rpm records which are the only informations that are currently preserved.

Documentation shall describe any processes used for changes to such identifiers.

Essential requirements not fulfilled

There is no documentation.

The repository shall be able to provide a complete list of all such identifiers and do spot checks for duplications.

Minor requirements are not fulfilled

A complete list of all used identifiers is accessible via the category listing Audio file licenses.

There is no automated way to check for duplication. In the wiki it should not be possible to generate duplicates because the page names would create a conflict. There can be only one page with a certain name because no hierarchy is in use. But on the storage server it would be possible to accidentally create duplicates because of the manual upload process and the hierarchical organization (Folder structure by genre/artist).

The system of identifiers shall be adequate to fit the repository's current and foreseeable future requirements such as numbers of objects.

Essential requirements not fulfilled

It is obvious that this naming scheme is dependent on the naming of the collected items and is tailored to released records. The result are several problems:

• It is unclear how to handle unreleased records (No order/catalog number)
• The archive is open for other recording formats like cylinders, open reel tape and even motion pictures where this naming scheme is not usable
• The naming scheme does not describe how to handle retouched versions (clean master) of the raw digitization (master) where both have to be searchable, distinguishable and accessible

The repository shall have a system of reliable linking/resolution services in order to find the uniquely identified object, regardless of its physical location.

Minor requirements are not fulfilled

The naming convention in use is suitable to meet this requirement if only shellac records are archived. Problematic is the missing documentation.

The repository shall have access to necessary tools and resources to provide authoritative Representation Information for all of the digital objects it contains. In particular the following aspects must be checked.

Essential requirements not fulfilled

The repository shall have tools or methods to identify the file type of all submitted Data Objects.

Requirements fulfilled

The Unix tool file and other more format specific tools are available on the servers.

The repository shall have tools or methods to determine what Representation Information is necessary to make each Data Object understandable to the Designated Community.

Essential requirements not fulfilled

No tools or methods in use.

The repository shall have access to the requisite Representation Information.

Requirements fulfilled

Due to the fact that the Public Domain Project only uses Free and Open Source Software (FOSS) access to all requisite Representation Information is guarantied.

The repository shall have tools or methods to ensure that the requisite Representation Information is persistently associated with the relevant Data Objects.

Essential requirements not fulfilled

This strong requirement is not fulfilled.

The repository shall have documented processes for acquiring Preservation Description Information (PDI) for its associated Content Information and acquire PDI in accordance with the documented processes. In particular the following aspects must be checked.

Essential requirements not fulfilled

The repository shall have documented processes for acquiring PDI.

Essential requirements not fulfilled

The repository shall execute its documented processes for acquiring PDI.

Essential requirements not fulfilled

The repository shall ensure that the PDI is persistently associated with the relevant Content Information.

Requirements fulfilled

At the moment the PDI is stored inside the MediaWiki and is permanently linked to the audio file (Which does not contain PDI). Both the file name of the content information and the wiki page use the same naming scheme so the association is obvious.

The repository shall ensure that the Content Information of the AIPs is understandable for their Designated Community at the time of creation of the AIP. In particular the following aspects must be checked.

Essential requirements not fulfilled

Repository shall have a documented process for testing understandability for their Designated Communities of the Content Information of the AIPs at their creation.

Essential requirements not fulfilled

The repository shall execute the testing process for each class of Content Information of the AIPs.

Essential requirements not fulfilled

The repository shall bring the Content Information of the AIP up to the required level of understandability if it fails the understandability testing.

Essential requirements not fulfilled

The repository shall verify each AIP for completeness and correctness at the point it is created.

Essential requirements not fulfilled

There is no verification process in use. Essentially the SIP is created by the same person that will ingest it and creates the AIP. For example there is no four-eyes principle in use.

The repository shall provide an independent mechanism for verifying the integrity of the repository collection/content.

Essential requirements not fulfilled

The repository shall have contemporaneous records of actions and administration processes that are relevant to AIP creation.

Minor requirements are not fulfilled

For the PDI there the records of actions are automatically captured. Every change on a wiki page is logged, the difference to the previous version can be inspected and the old version can be restored if needed. Here is an example how the version history looks like: Version history of Columbia-a3996-81215

But there is no such thing or other processes for the content information (the Flac files) to capture records of actions.

PRESERVATION PLANNING

The repository shall have documented preservation strategies relevant to its holdings.

Essential requirements not fulfilled

There are no documented preservation strategies.

The repository shall have mechanisms in place for monitoring its preservation environment.

Essential requirements not fulfilled

There are no formal mechanisms for monitoring the preservation environment. But the active people in the project are in regular contact with groups of the designated communities. This is done by attending conferences, assemblies, regular meetings of user groups. Also the recommendations on formats and media published by the associations of archives or libraries are observed in a informal way.

The repository shall have mechanisms in place for monitoring and notification when Representation Information is inadequate for the Designated Community to understand the data holdings.

Essential requirements not fulfilled

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

Essential requirements not fulfilled

This and the next requirement fail because there are no monitoring activities in place on which a reaction could be defined.

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

Essential requirements not fulfilled

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

Essential requirements not fulfilled

AIP PRESERVATION

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

Minor requirements are not fulfilled

All file formats used for AIPs or other relevant information are well documented open standards down to the bit level. The representation information is not available locally and it's not linked to the AIPs.

The repository shall preserve the Content Information of AIPs.

Essential requirements not fulfilled

No documented work flows.

The repository shall actively monitor the integrity of AIPs.

Essential requirements not fulfilled

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

Essential requirements not fulfilled

The repository shall have procedures for all actions taken on AIPs.

Essential requirements not fulfilled

The repository shall be able to demonstrate that any actions taken on AIPs were compliant with the specification of those actions.

Essential requirements not fulfilled

INFORMATION MANAGEMENT

The repository shall specify minimum information requirements to enable the Designated Community to discover and identify material of interest.

Requirements fulfilled

All the descriptive information can be searched by the free text search function of the MediaWiki software. For example if someone is interested in instrumental music it can be found with the search term, according to the metadata attribute Vocal range with the value instrumental.

Search results for Vocal range instrumental

Another option to discover material of interest is by using the category system. Every work is added to several categories like genres, country of origin, creation year, recording formats, digitalization devices etc. The example recording above is in several categories, one is the recording label Decca Records. This information can be used to show all recordings of Decca Records in the public domain archive:

Category:Decca_Records

The repository shall capture or create minimum descriptive information and ensure that it is associated with the AIP.

Minor requirements are not fulfilled

The minimum information requirements are specified by the Audio file template in the wiki. This template acts as the input mask when the SIP is built. The template page also includes the documentation about the usage of this template.

Audio file template:
http://pool.publicdomainproject.org/index.php/Template:Audio_file

The template page also contains the available documentation how to use this template. There is no documentation about the vocabulary that should be used to fill the metadata information.

Responsibility for the procurement of metadata lies in the ingestion process where the SIP is assembled.

Capturing provenience and context information with help of this template is done manually and is done until all needed information is found. The minimum level is determined by the requirement that the public domain project is only allowed to publish works that are in the public domain (copyright free). So at least the information to decide on the legal status of the work must be present. This includes title, all authors and there living dates, first release date and publishing label. Technical metadata is also captured with this template like format of the analog recording, devices used for digitalization, catalog and stamper numbers and track length.

A finished SIP could look like this example: Decca-wa782-kwa5215

Additional to the descriptive information captured with the Audio file template the SIP gets also context information by categorization. The public domain project uses a polyhierarchical category tree that contains differentiation between genres, country of origin, creation year, recording formats, digitalization devices etc.

Missing is a documentation on the categorization process for an AIP.

As shown in The repository shall have and use a convention that generates persistent, unique identifiers for all AIPs. there is a naming scheme in use that provides persistent, unique identifiers for all AIPs and descriptive information as long as only shellac records are archived.

There is no detailed process work flow documentation.

There is no system and technical architecture documentation.

The repository shall maintain bi-directional linkage between each AIP and its descriptive information.

Minor requirements are not fulfilled

One direction is from the descriptive information to the AIP. This is achieved by a link on the wiki page withe the descriptive information to the Flac file. It is also achieved by the use of a unique, persistent identifier for each work. This identifier is used to name the wiki page containing the descriptive metadata and also the file name of the Flac file.

Example:

• Descriptive Metadata for Hmv-d1388-08247
• The associated AIP with the file name hmv-d1388-08247.flac

For the other direction the unique, persistent identifier is used to locate the descriptive metadata in the wiki. This can be done by directly entering the URL http://pool.publicdomainproject.org/index.php/ and the identifier at the end or by using the search function of the wiki.

Beneficial would be a URL (web link) to the descriptive information inside the Flac metadata tags.

For the physical records this bidirectional linking also holds as the context information (category) in the wiki contains the physical location of the record. In the opposite direction the catalog or stamper number can be used to find its descriptive information as well the number of the container to find the context information about the grouped items.

As with other requirements there is a lack of documentation about the process work flow and technical architecture.

The repository shall maintain the associations between its AIPs and their descriptive information over time.

Essential requirements not fulfilled

ACCESS MANAGEMENT

The repository shall comply with Access Policies.

Requirements fulfilled

The public domain project allows free unlimited access to its collection. So there is no need for user accounts or access management to use the available items.

This is documented for the designated communities on the landing page for the media pool and also on the multi language frequently asked questions (FAQ) page:

From Media pool main page:
Creative works of literature, science and art are subject to copyright law. Works in the public domain are those whose intellectual property rights have expired. With the help of volunteers, our team cleans, cataloged and digitized hundreds of gramophone records. After the clearing of copyrights, free works are available inside our media pool and Wikimedia Commons, compressed in Flac without any loss in quality (24-bit/192kHz).

And further down on the same page:
Permission: distributing, reproducing, streaming, sampling, remixing

From the FAQ:
Question: What I'm allowed to do with the music files?
Answer: There is no restriction. You can for ex. redistribute it, copy it, modify it, use it in your own productions, use it as background music and so on.

Unusual for other archives is the fact, that everybody can contribute to the project by supplying additional metadata, context information or by submitting SIPs to the archive. The project is and should be driven by volunteers as it is the base principle of this (and related) archives.

To be able to do so, a user needs to create a user account and a wiki administrator needs to give writing rights to this user. This is more complicated for a wiki than usual but it had to made that strict because of severe spamming problems. Without more wiki administrators the project is not able to maintain easy writing access and keeping the wiki free from spam.

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

Minor requirements are not fulfilled

Related to access management failures are two logging systems. The first are the logging features of the MediaWiki software. This logs can be accessed via the Special pages link in the wiki: Logs from the data pool wiki

The second logging system are the logs from the web server application (apache2) and a user front end (piwix) to create statistics and analyze this logs:

• Webserver logs for the media data
• Webserver logs for the error pages. Status code 404 are Page not found errors

Not fulfilled is the requirement that written notes should exist of of reviews undertaken or action taken as a result of reviews.

From the discussion in the CCSDS_652.0-M-1 document one important concern is such as valid users’ being denied access.

Due to the nature of the public domain project this requirement is fulfilled when the requirement The repository shall maintain the associations between its AIPs and their descriptive information over time. is met because if it is possible to access the AIP from the descriptive metadata it is possible for the designated communities to get the AIP too. But this requirement is not yet fulfilled.

The repository shall follow policies and procedures that enable the dissemination of digital objects that are traceable to the originals, with evidence supporting their authenticity.

Requirements fulfilled

From the discussion section of this requirement: This requirement is concerned only with the relation between DIPs and the AIPs from which they are derived; elsewhere the link between the originals SIPs and the AIPs is considered.

The public domain project delivers as DIP directly the Flac file from the archival storage without modification. The designated community is able to check the authenticity of this Flac file because there are CRC and hashes included in the Flac file to detect transmission errors.

Additionally it would be helpful for the designated community to include the hash values of each AIP in the metadata details web page.

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

Minor requirements are not fulfilled

The repository acts quickly on problem reports from members of the designated community or from internal staff. Most of the time problems are reported by e-mail and then forwarded to the responsible person.

There are no formal processes for problem reports and the reports from the last years are not archived in a central place where they can be reviewed or tracked if they are solved.

INFRASTRUCTURE AND SECURITY RISK MANAGEMENT

TECHNICAL INFRASTRUCTURE RISK MANAGEMENT

Essential requirements not fulfilled

The repository shall identify and manage the risks to its preservation operations and goals associated with system infrastructure.

Essential requirements not fulfilled

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

Essential requirements not fulfilled

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

Minor requirements are not fulfilled

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

The server hardware for hosting the ingest, search and delivery services where upgraded in spring 2015. There performance is very good compared to the current workload. They are ready to handle many more users.

The archival storage system is still fast enough for the current demands and has also still enough storage capacity for the next time. In the archival storage system there are 50% spare slots for additional hard drives.

The Internet connectivity is a symmetrical 1 Gbit/s connection without traffic limitation. For the current user numbers this is enough to achieve short download times.

This requirement is not fulfilled because there exists no current hardware inventory and there is no procedure or system to ask for and receive feedback from the designated communities.

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

Essential requirements not fulfilled

No written procedures but monitoring systems in place to observe server workloads, memory usage, network traffic and free archival storage space.

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

Essential requirements not fulfilled

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

Essential requirements not fulfilled

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

Minor requirements are not fulfilled

The examples of ways the repository can demonstrate it is meeting this requirement clearly shows that several requirements have to be met:

Maintenance of up-to-date Designated Community technology, expectations, and use profiles
At the time of writing the expectations of the designated community is moving towards mobile use on smart phones and tablets. The MediaWiki software is not very well suited yet for this devices. This is a known problem and the MediaWiki community is working on this. On desktop and laptop computers the project gives access in a usefull way. The finding aids could be improved for the global community.

The on-line radio streams and the page to access this streams seems to fulfill the needs.

Provision of software systems adequate to support ingest and use demands
Software support for ingest is weak.

Systematic elicitation of feedback regarding software and service adequacy
There is no systematic elicitation of feedback about software topics.

Maintenance of a current software inventory
Software inventory is managed via the package manager apt used in Debian GNU/Linux. This covers most of the used software like operating system, common services, web server, on-line radio software etc. MediaWiki and the statistics tool piwix are maintained separately. To help the system administrator MediaWiki provides a inventory of installed extensions and version numbers of them together with the version number of the dependencies: Version number of MediaWiki and its extensions

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

Essential requirements not fulfilled

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

Essential requirements not fulfilled

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

Essential requirements not fulfilled

The repository shall have adequate hardware and software support for backup functionality sufficient for preserving the repository content and tracking repository functions.

Essential requirements not fulfilled

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

Essential requirements not fulfilled

The repository shall record and report to its administration all incidents of data corruption or loss, and steps shall be taken to repair/replace corrupt or lost data.

Essential requirements not fulfilled

The repository shall have a process to record and react to the availability of new security updates based on a risk-benefit assessment.

Requirements fulfilled

To be informed which security updates are available the public domain project is subscribed to this two mailing lists:

• MediaWiki update and security announcements list
• Debian Security announcements

Log files from the package manager are available on the server to check what software and patches was installed.

The risk-benefit analysis is done by the Debian security team. This volunteers monitor the newly discovered security problems in the Debian stable systems (GNU/Linux operating system and important application software). They prepare, test and provide patches against this problems and try to make sure that the expected behavior does not change.

For the MediaWiki software the risk-benefit analysis is done by the system administrator. But normally MediaWiki security patches are well tested and if there is any side effect it is documented by the developers: Archive of MediaWiki-announce mails

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

Essential requirements not fulfilled

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

Essential requirements not fulfilled

The repository shall have a documented change management process that identifies changes to critical processes that potentially affect the repository's ability to comply with its mandatory responsibilities.

Essential requirements not fulfilled

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

Essential requirements not fulfilled

The repository shall manage the number and location of copies of all digital objects.

Essential requirements not fulfilled

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

Essential requirements not fulfilled

SECURITY RISK MANAGEMENT

The repository shall maintain a systematic analysis of security risk factors associated with data, systems, personnel, and physical plant.

Essential requirements not fulfilled

The repository shall have implemented controls to adequately address each of the defined security risks.

Essential requirements not fulfilled

The repository staff shall have delineated roles, responsibilities, and authorizations related to implementing changes within the system.

Essential requirements not fulfilled

The repository shall have suitable written disaster preparedness and recovery plan(s), including at least one off-site backup of all preserved information together with an offsite copy of the recovery plan(s).

Essential requirements not fulfilled