The Trustworthy Repositories Audit & Certification: Criteria and Checklist (TRAC), is the principle tool used by CRL in its auditing and certification of digital repositories. TRAC criteria measure the ability of a given repository to preserve digital content in a way that serves the repository's stakeholder community.
TRAC metrics are based on the OAIS reference model/ ISO 14721:2012 standard. This standard was developed through the Consultative Committee for Space Data Systems (CCSDS) and a task force under the auspices of OCLC's Research Libraries Group (RLG) and the National Archives and Records Administration (NARA). The final version of TRAC was revised by the Center for Research Libraries and the Research Libraries Group (RLG) after jointly conducting test audits of several digital repositories in 2005-2006. The final version of the TRAC checklist was published in 2007 by CRL and RLG. The full TRAC document in PDF format is available on the CRL website.
A list of the TRAC metrics, with examples of the types of evidence of compliance with those metrics, is found below. Many of the concepts and terms used in TRAC are defined in the OAIS Reference Manual (ISO 14721:2012).
Section A. Organizational Infrastructure
A1. Governance & organizational viability
A1.1 Repository has a mission statement that reflects a commitment to the long-term retention of, management of, and access to digital information.
Evidence: Mission statement for the repository; mission statement for the organizational context in which the repository sits; legal or legislative mandate; regulatory requirements.
A1.2 Repository has an appropriate, formal succession plan, contingency plans, and/or escrow arrangements in place in case the repository ceases to operate or the governing or funding institution substantially changes its scope.
Evidence: Succession plan's); escrow plans); explicit and specific statement documenting the intent to ensure continuity of the repository, and the steps taken and to be taken to ensure continuity; formal documents describing exit strategies and contingency plans; depositor agreements.
A2. Organizational structure & staffing
A2.1 Repository has identified and established the duties that it needs to perform and has appointed staff with adequate skills and experience to fulfill these duties.
Evidence: A staffing plan; competency definitions; job description; development plans; plus evidence that the repository review and maintains these documents as requirements evolve.
A2.2 Repository has the appropriate number of staff to support all functions and services.
Evidence: Organizational charts; definitions of roles and responsibilities; comparison of staffing levels to commitments and estimates of required effort.
A2.3 Repository has an active professional development program in place that provides staff with skills and expertise development opportunities.
Evidence: Professional development plans and reports; training requirements and training budgets, documentation of training expenditures (amount per staff); performance goals and documentation of staff assignments and achievements, copies of certificates awarded.
A3. Procedural accountability & policy framework (documentation)
A3.1 Repository has defined its designated community(ies) and associated knowledge base(s) and has publicly accessible definitions and policies in place to dictate how its preservation service requirements will be met.
Evidence: Mission statement; written definitions of the designated community(ies); documented policies; service-level agreements.
A3.2 Repository has procedures and policies in place, and mechanisms for their review, update, and development as the repository grows and as technology and community practice evolves.
Evidence: Written documentation in the form of policies, procedures, protocols, rules, manuals, handbooks, and workflows; specification of review cycle for documentation; documentation detailing review, update, and development mechanisms. If documentation is embedded in system logic, functionality should demonstrate the implementation of policies and procedures.
A3.3 Repository maintains written policies that specify the nature of any legal permissions required to preserve digital content over time, and repository can demonstrate that these permissions have been acquired when needed.
Evidence: Deposit agreements; records schedule; digital preservation policies; records legislation and policies; service agreements.
A3.4 Repository is committed to formal, periodic review and assessment to ensure responsiveness to technological developments and evolving requirements.
Evidence: A self-assessment schedule, timetables for review and certification; results of self-assessment; evidence of implementation of review outcomes.
A3.5 Repository has policies and procedures to ensure that feedback from producers and users is sought and addressed over time.
Evidence: A policy that requires a feedback mechanism; a procedure that addresses how the repository seeks, captures, and documents responses to feedback; documentation of workflow for feedback (i.e., how feedback is used and managed); quality assurance records.
A3.6 Repository has a documented history of the changes to its operations, procedures, software, and hardware that, where appropriate, is linked to relevant preservation strategies and describes potential effects on preserving digital content.
Evidence: Policies, procedures, and results of changes that affect all levels of the repository: objects, aggregations of objects; object-level preservation metadata; repository’s records retention strategy document.
A3.7 Repository commits to transparency and accountability in all actions supporting the operation and management of the repository, especially those that affect the preservation of digital content over time.
Evidence: Comprehensive documentation that is readily accessible to stakeholders; unhindered access to content and associated information within repository.
A3.8 Repository commits to defining, collecting, tracking, and providing, on demand, its information integrity measurements.
Evidence: An implemented registry system; a definition of the repository’s integrity measurements; documentation of the procedures and mechanisms for integrity measurements; an audit system for collecting, tracking, and presenting integrity measurements; procedures for responding to results of integrity measurements that indicate digital content is at risk; policy and workflow documentation.
A3.9 Repository commits to a regular schedule of self-assessment and certification and, if certified, commits to notifying certifying bodies of operational changes that will change or nullify its certification status.
Evidence: Completed, dated audit checklists from self-assessment or objective audit; certificates awarded for certification; presence in a certification register (when available); timetable or budget allocation for future certification.
A4. Financial sustainability
A4.1 Repository has short- and long-term business planning processes in place to sustain the repository over time.
Evidence: Operating plans; financial reports; budgets; financial audit reports; annual financial reports; financial forecasts; business plans; audit procedures and calendars; evidence of comparable institutions; exposure of business plan to scenarios.
A4.2 Repository has in place processes to review and adjust business plans at least annually.
Evidence: Business plans, audit planning (e.g., scope, schedule, process, and requirements) and results; financial forecasts; recent audits and evidence of impact on repository operating procedures.
A4.3 Repository’s financial practices and procedures are transparent, compliant with relevant accounting standards and practices, and audited by third parties in accordance with territorial legal requirements.
Evidence: Demonstrated dissemination requirements for business planning and practices; citations to and/or examples of accounting and audit requirements, standards, and practice; evidence of financial audits already taking place.
A4.4 Repository has ongoing commitment to analyze and report on risk, benefit, investment, and expenditure (including assets, licenses, and liabilities).
Evidence: Risk management documents that identify perceived and potential threats and planned or implemented responses (a risk register); technology infrastructure investment planning documents; costbenefit analyses; financial investment documents and portfolios; requirements for and examples of licenses, contracts, and asset management; evidence of revision based on risk.
A4.5 Repository commits to monitoring for and bridging gaps in funding.
Evidence: Fiscal and fiduciary policies, procedures, protocols, requirements; budgets and financial analysis documents; fiscal calendars; business plan(s); any evidence of active monitoring and preparedness.
A5. Contracts, licenses, & liabilities
A5.1 If repository manages, preserves, and/or provides access to digital materials on behalf of another organization, it has and maintains appropriate contracts or deposit agreements.
Evidence: Deposit agreements; policies on third-party deposit arrangements; contracts; definitions of service levels; Web archiving policies; procedure for reviewing and maintaining agreements, contracts, and licenses.
A5.2 Repository contracts or deposit agreements must specify and transfer all necessary preservation rights, and those rights transferred must be documented.
Evidence: Contracts, deposit agreements; specification(s) of rights transferred for different types of digital content (if applicable); policy statement on requisite preservation rights.
A5.3 Repository has specified all appropriate aspects of acquisition, maintenance, access, and withdrawal in written agreements with depositors and other relevant parties.
Evidence: Submission agreements/deposit agreements/deeds of gift; written standard operating procedures.
A5.4 Repository tracks and manages intellectual property rights and restrictions on use of repository content as required by deposit agreement, contract, or license.
Evidence: A policy statement that defines and specifies the repository’s requirements and process for managing intellectual property rights; depositor agreements; samples of agreements and other documents that specify and address intellectual property rights; demonstrable way to monitor intellectual property; results from monitoring.
A5.5 If repository ingests digital content with unclear ownership/rights, policies are in place to address liability and challenges to those rights.
Evidence: A definition of rights; citations for relevant laws and requirements; policy on responding to challenges; documented track record for responding to challenges in ways that do not inhibit preservation; examples of legal advice sought and received.
B. Digital Object Management
B1. Ingest: acquisition of content
B1.1 Repository identifies properties it will preserve for digital objects.
Evidence: Mission statement; submission agreements/deposit agreements/deeds of gift; workflow and policy documents, including written definition of properties as agreed in the deposit agreement/deed of gift; written processing procedures; documentation of properties to be preserved.
B1.2 Repository clearly specifies the information that needs to be associated with digital material at the time of its deposit (i.e., SIP).
Evidence: Transfer requirements; producer-archive agreements.
B1.3 Repository has mechanisms to authenticate the source of all materials.
Evidence: Submission agreements/deposit agreements/deeds of gift; workflow documents; evidence of appropriate technological measures; logs from procedures and authentications.
B1.4 Repository’s ingest process verifies each submitted object (i.e., SIP) for completeness and correctness as specified in B1.2.
Evidence: Appropriate policy documents and system log files from system performing ingest procedure; formal or informal “acquisitions register” of files received during the transfer and ingest process; workflow, documentation of standard operating procedures, detailed procedures; definition of completeness and correctness, probably incorporated in policy documents.
B1.5 Repository obtains sufficient physical control over the digital objects to preserve them.
Evidence: Submission agreements/deposit agreements/deeds of gift; workflow documents; system log files from the system performing ingest procedures; logs of files captured during Web harvesting.
B1.6 Repository provides producer/depositor with appropriate responses at predefined points during the ingest processes.
Evidence: Submission agreements/deposit agreements/deeds of gift; workflow documentation; standard operating procedures; evidence of “reporting back.”
B1.7 Repository can demonstrate when preservation responsibility is formally accepted for the contents of the submitted data objects (i.e., SIPs).
Evidence: Submission agreements/deposit agreements/deeds of gift; confirmation receipt sent back to producer.
B1.8 Repository has contemporaneous records of actions and administration processes that are relevant to preservation (Ingest: content acquisition).
Evidence: Written documentation of decisions and/or action taken; preservation metadata logged, stored, and linked to pertinent digital objects.
B2. Ingest: creation of the archival package
B2.1 Repository has an identifiable, written definition for each AIP or class of information preserved by the repository.
Evidence: Documentation identifying each class of AIP and describing how each is implemented within the repository. Implementations may, for example, involve some combination of files, databases, and/or documents.
B2.2 Repository has a definition of each AIP (or class) that is adequate to fit long-term preservation needs.
Evidence: Documentation that relates the AIP component’s contents to the related preservation needs of the repository, with enough detail for the repository's providers and consumers to be confident that the significant properties of AIPs will be preserved.
B2.3 Repository has a description of how AIPs are constructed from SIPs.
Evidence: Process description documents; documentation of SIP relationship to AIP; clear documentation of how AIPs are derived from SIPs; documentation of standard/process against which normalization occurs; documentation of normalization outcome and how outcome is different from SIP.
B2.4 Repository can demonstrate that all submitted objects (i.e., SIPs) are either accepted as whole or part of an eventual archival object (i.e., AIP), or otherwise disposed of in a recorded fashion.
Evidence: System processing files; disposal records; donor or depositor agreements/deeds of gift; provenance tracking system; system log files.
B2.5 Repository has and uses a naming convention that generates visible, persistent, unique identifiers for all archived objects (i.e., AIPs).
Evidence: Documentation describing naming convention and physical evidence of its application (e.g., logs).
B2.6 If unique identifiers are associated with SIPs before ingest, the repository preserves the identifiers in a way that maintains a persistent association with the resultant archived object (e.g., AIP).
Evidence: Workflow documents and evidence of traceability (e.g., SIP identifier embedded in AIP, mapping table of SIP IDs to AIPs).
B2.7 Repository demonstrates that it has access to necessary tools and resources to establish authoritative Representation Information of the digital objects it contains.
Evidence: "Evidence: Subscription or access to such registries; association of unique identifiers 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.
B2.8 Repository records/registers Representation Information (including formats) ingested.
Evidence: Viewable records in local format registry (with persistent links to digital objects); local metadata registry(ies); database records that include Representation Information and a persistent link to relevant digital objects.
B2.9 Repository has documented processes for acquiring preservation metadata (i.e., PDI) for its associated Content Information and acquires preservation metadata in accordance with the documented processes. The repository must maintain viewable documentation on how the repository acquires and manages Preservation Description Information (PDI).
Evidence: Viewable documentation on how the repository acquires and manages Preservation Description Information (PDI).
B2.10 Repository has a documented process for testing understandability of the information content and bringing the information content up to the agreed level of understandability.
Evidence: Retention of individuals with the discipline expertise; periodic assembly of designated or outside community members to evaluate and identify additional required metadata.
B2.11 Repository verifies each AIP for completeness and correctness at the point it is generated.
Evidence: Description of the procedure that verifies completeness and correctness; logs of the procedure.
B2.12 Repository provides an independent mechanism for audit of the integrity of the repository collection/content.
Evidence: Documentation provided for B2.1 through B2.6; documented agreements negotiated between the producer and the repository (see B 1.1-B1.9); logs of material received and associated action (receipt, action, etc.) dates; logs of periodic checks.
B2.13 Repository has contemporaneous records of actions and administration processes that are relevant to preservation (AIP creation).
Evidence: Written documentation of decisions and/or action taken; preservation metadata logged, stored, and linked to pertinent digital objects.
B3. Preservation planning
B3.1 Repository has documented preservation strategies.
Evidence: Documentation identifying each preservation issue and the strategy for dealing with that issue.
B3.2 Repository has mechanisms in place for monitoring and notification when Representation Information (including formats) approaches obsolescence or is no longer viable.
Evidence: Subscription to a format registry service; subscription to a technology watch service; percentage of at least one staff member dedicated to monitoring technological obsolescence issues.
B3.3 Repository has mechanisms to change its preservation plans as a result of its monitoring activities.
Evidence: Preservation planning policies tied to formal or information technology watch(es); preservation planning or processes that are timed to shorter intervals (e.g., not more than five years); proof of frequent preservation planning/policy updates.
B3.4 Repository can provide evidence of the effectiveness of its preservation planning.
Evidence: Collection of appropriate preservation metadata; proof of usability of randomly selected digital objects held within the system; demonstrable track record for retaining usable digital objects over time.
B4. Preservation Planning
B4.1 Repository employs documented preservation strategies.
Evidence: Documentation of strategies and their appropriateness to repository objects; evidence of application (e.g., in preservation metadata); see B3.3.
B4.2 Repository implements/responds to strategies for archival object (i.e., AIP) storage and migration.
Evidence: Institutional technology and standards watch; demonstration of objects on which a preservation strategy has been performed; demonstration of appropriate preservation metadata for digital objects.
B4.3 Repository preserves the Content Information of archival objects (i.e., AIPs).
Evidence: Policy documents specifying treatment of AIPs and whether they may ever be deleted; ability to demonstrate the chain of AIPs for any particular digital object or group of objects ingested; workflow procedure documentation.
B4.4 Repository actively monitors integrity of archival objects (i.e., AIPs).
Evidence: Logs of fixity checks (e.g., checksums); documentation of how AIPs and Fixity information are kept separate.
B4.5 Repository has contemporaneous records of actions and administration processes that are relevant to preservation (Archival Storage).
Evidence: Written documentation of decisions and/or action taken; preservation metadata logged, stored, and linked to pertinent digital objects.
B5. Information management
B5.1 Repository articulates minimum metadata requirements to enable the designated community(ies) to discover and identify material of interest.
Evidence: Descriptive metadata.
B5.2 Repository captures or creates minimum descriptive metadata and ensures that it is associated with the archived object (i.e., AIP).
Evidence: Descriptive metadata; persistent identifier/locator associated with AIP; system documentation and technical architecture; depositor agreements; metadata policy documentation, incorporating details of metadata requirements and a statement describing where responsibility for its procurement falls; process workflow documentation.
B5.3 Repository can demonstrate that referential integrity is created between all archived objects (i.e., AIPs) and associated descriptive information.
Evidence: Descriptive metadata; persistent identifier/locator associated with AIP; documented relationship between AIP and metadata; system documentation and technical architecture; process workflow documentation.
B5.4 Repository can demonstrate that referential integrity is maintained between all archived objects (i.e., AIPs) and associated descriptive information.
Evidence: Log detailing ongoing monitoring/checking of referential integrity, especially following repair/modification of AIP; legacy descriptive metadata; persistence of identifier/locator; documented relationship between AIP and metadata; system documentation and technical architecture; process workflow documentation.
B6. Access management
B6.1 Repository documents and communicates to its designated community(ies) what access and delivery options are available.
Evidence: Public versions of access policies; delivery policies; fee policies.
B6.2 Repository has implemented a policy for recording all access actions (includes requests, orders etc.) that meet the requirements of the repository and information producers/depositors.
Evidence: Access policies; use statements.
B6.3 Repository ensures that agreements applicable to access conditions are adhered to.
Evidence: Access policies; logs of user access and user denials; access system mechanisms that prevent unauthorized actions (such as save, print, etc.); user compliance agreements.
B6.4 Repository has documented and implemented access policies (authorization rules, authentication requirements) consistent with deposit agreements for stored objects.
Evidence: Access validation mechanisms within system; documentation of authentication and validation procedures.
B6.5 Repository access management system fully implements access policy.
Evidence: Logs and audit trails of access requests; information about user capabilities (authentication matrices); explicit tests of some types of access.
B6.6 Repository logs all access management failures, and staff review inappropriate “access denial” incidents.
Evidence: Access logs; capability of system to use automated analysis/monitoring tools and generate problem/error messages; notes of reviews undertaken or action taken as result of reviews.
B6.7 Repository can demonstrate that the process that generates the requested digital object(s) (i.e., DIP) is completed in relation to the request.
Evidence: System design documents; work instructions (if DIPs involve manual processing); process walkthroughs; logs of orders and DIP production; test accesses to verify delivery of appropriate digital objects.
B6.8 Repository can demonstrate that the process that generates the requested digital object(s) (i.e., DIP) is correct in relation to the request.
Evidence: System design documents; work instructions (if DIPs involve manual processing); process walkthroughs; logs of orders and DIP production.
B6.9 Repository demonstrates that all access requests result in a response of acceptance or rejection.
Evidence: System design documents; work instructions (if DIPs involve manual processing); process walkthroughs; logs of orders and DIP production.
B6.10 Repository enables the dissemination of authentic copies of the original or objects traceable to originals.
Evidence: System design documents; work instructions (if DIPs involve manual processing); process walkthroughs; production of a sample authenticated copy; documentation of community requirements for authentication.
C. Technologies, Technical Infrastructure, & Security
C1. System Infrastructure
C1.1 Repository functions on well-supported operating systems and other core infrastructural software.
Evidence: Software inventory; system documentation; support contracts; use of strongly community supported software (i.e., Apache).
C1.2 Repository ensures that it has adequate hardware and software support for backup functionality sufficient for the repository’s services and for the data held, e.g., metadata associated with access controls, repository main content.
Evidence: Documentation of what is being backed up and how often; audit log/inventory of backups; validation of completed backups; disaster recovery plan—policy and documentation; “firedrills”—testing of backups; support contracts for hardware and software for backup mechanisms.
C1.3 Repository manages the number and location of copies of all digital objects.
Evidence: random retrieval tests; system test; location register/log of digital objects compared to the expected number and location of copies of particular objects.
C1.4 Repository has mechanisms in place to ensure any/multiple copies of digital objects are synchronized.
Evidence: Workflows; system analysis of how long it takes for copies to synchronize; procedures/documentation of operating procedures related to updates and copy synchronization; procedures/documentation related to whether changes lead to the creation of new copies and how those copies are propagated and/or linked to previous versions.
C1.5 Repository has effective mechanisms to detect bit corruption or loss.
Evidence: Documents that specify bit error detection and correction mechanisms used; risk analysis; error reports; threat analyses.
C1.6 Repository reports to its administration all incidents of data corruption or loss, and steps taken to repair/replace corrupt or lost data.
Evidence: Preservation metadata (e.g., PDI) records; comparison of error logs to reports to administration; escalation procedures related to data loss.
C1.7 Repository has defined processes for storage media and/or hardware change (e.g., refreshing, migration).
Evidence: Documentation of processes; policies related to hardware support, maintenance, and replacement; documentation of hardware manufacturers’ expected support life cycles.
C1.8 Repository has a documented change management process that identifies changes to critical processes that potentially affect the repository’s ability to comply with its mandatory responsibilities.
Evidence: Documentation of change management process; comparison of logs of actual system changes to processes versus associated analyses of their impact and criticality.
C1.9 Repository has a process for testing the effect of critical changes to the system.
Evidence: Documented testing procedures; documentation of results from prior tests and proof of changes made as a result of tests.
C1.10 Repository has a process to react to the availability of new software security updates based on a risk-benefit assessment.
Evidence: Risk register (list of all patches available and risk documentation analysis); evidence of update processes (e.g., server update manager daemon); documentation related to the update installations.
C2. Appropriate technologies
C2.1 Repository has hardware technologies appropriate to the services it provides to its designated community(ies) and has procedures in place to receive and monitor notifications, and evaluate when hardware technology changes are needed.
Evidence: Technology watch; documentation of procedures; designated community profiles; user needs evaluation; hardware inventory.
C2.2 Repository has software technologies appropriate to the services it provides to its designated community(ies) and has procedures in place to receive and monitor notifications, and evaluate when software technology changes are needed.
Evidence: Technology watch; documentation of procedures; designated community profiles; user needs evaluation; software inventory.
C3. Security
C3.1 Repository maintains a systematic analysis of such factors as data, systems, personnel, physical plant, and security needs.
Evidence: ISO 17799 certification; documentation describing analysis and risk assessments undertaken and their outputs; logs from environmental recorders; confirmation of successful staff vetting.
C3.2 Repository has implemented controls to adequately address each of the defined security needs.
Evidence: ISO 17799 certification; system control list; risk, threat, or control analyses; addition of controls based on ongoing risk detection and assessment.
C3.3 Repository staff have delineated roles, responsibilities, and authorizations related to implementing changes within the system.
Evidence: ISO 17799 certification; organizational chart; system authorization documentation.
C3.4 Repository has suitable written disaster preparedness and recovery plan(s), including at least one off-site backup of all preserved information together with an off-site copy of the recovery plan(s).
Evidence: ISO 17799 certification; disaster and recovery plans; information about and proof of at least one off-site copy of preserved information; service continuity plan; documentation linking roles with activities; local geological, geographical, or meteorological data or threat assessments.