The first part of this series argued that digital preservation programs already do information security work, and that the vocabulary they use to describe it keeps that work invisible to the people who control the security budget. This part takes up the harder half: where the preservation field has underinvested, where these two disciplines genuinely pull against each other, what preservation programs stand to gain from their security colleagues, and what to bring to the first conversation.
Start with the gap.
The confidentiality problem
Two of the field’s most carefully constructed risk models define successful digital preservation without naming confidentiality. The SPOT model lists availability, identity, persistence, renderability, understandability, and authenticity (Vermaaten, Lavoie, and Caplan, 2012). CHARM lists retrievability, authenticity, integrity, accessibility, and longevity (Pennock, 2024). Related concerns appear in CHARM’s Legal and Policy risk source classes, so this is a gap in stated target values rather than a total absence.
It is also a principled one. Pennock notes that CHARM begins with a clear definition of digital preservation, and that confidentiality does not feature much in the discipline’s own definitions; she locates it more naturally elsewhere in the library systems landscape, alongside things like rights management metadata in a catalog. She also observes that the field has increasingly used “archive” and “preservation” interchangeably, which blurs the scope question without the shift being formally acknowledged (personal communication, 14 September 2026).
That reframing is more useful than a complaint about coverage. If confidentiality belongs in the access and rights layer rather than the preservation layer, the question isn’t why preservation models leave it out. The question is whether anyone at a given institution actually owns it for preserved content, particularly where those two layers are different systems run by different teams. What follows suggests the answer is often nobody.
The security literature has an interesting parallel. In their survey of four decades of CIA triad scholarship, Samonas and Coss found that the intersection of availability and confidentiality is the least studied region of the model, with almost all proposed extensions clustering around integrity. They flagged that intersection as ripe for future research.
Digital preservation programs live in that intersection. The daily question is how to make content durably available over decades while restricting who can see it, and that is exactly the territory both fields have mapped least.
Text description of the CIA triad Venn diagram
Three overlapping circles are labelled Confidentiality, Availability, and Integrity. The area where Confidentiality and Availability overlap but Integrity does not is filled in a contrasting colour.
Accompanying text reads: almost every proposed extension to the triad has clustered around integrity. Reviewing four decades of the literature, Samonas and Coss found the confidentiality and availability intersection to be the least studied region of the model, and named it as ripe for future research. Preservation programs live there. Making content durably available across decades while restricting who can see it is exactly the territory both fields have mapped least.
The source is Samonas, S. and Coss, D. (2014), The CIA strikes back, Journal of Information System Security, 10(3), 21 to 45.
The content is real. Repositories hold embargoed dissertations, restricted donor collections, research data with human subjects, and material subject to FERPA or HIPAA. Most preservation programs try to avoid taking large deposits of protected personal information, protected health information, or education records, but most end up holding some anyway.
The principle is least privilege, formalized in computer science by Saltzer and Schroeder in 1975 and practiced in closed stacks by archivists for much longer. Access goes to those with a valid purpose, and only to what that purpose requires. Preservation programs already understand this. What’s often missing is the systems and evidence to demonstrate it to someone conducting a review.
The risk transfer nobody logs
Here is where the gap turns costly, and it is better documented than most practitioners realize.
Between 2019 and 2021, the Texas Digital Library (TDL) and the UC San Diego Library (UCSD) ran an IMLS-funded planning project to test whether a nationally distributed preservation service for private and sensitive data was feasible. Distributed digital preservation services had existed in the United States for more than a decade, and none accepted sensitive data. The project set out to establish why, and what it would take to change.
Its findings describe risk transfer from within.
The report states that personally identifiable information (PII) and protected health information (PHI) in the custody of libraries, health science centers, and archives face an elevated risk of loss, and it explains the mechanism plainly. Such content is usually stored locally and rarely replicated elsewhere, which excludes it from services that provide standards-based preservation components like geographic distribution. The confidentiality requirement removed the content from the very distribution that would have protected it.
The scale is not marginal. More than half of the twenty-two Texas Digital Library member institutions held sensitive content requiring preservation action, and a survey of University of California libraries found that over half managed HIPAA data.
The decision is often explicit rather than accidental. Among the institutions the project interviewed, some assessed their sensitive holdings and decided not to bring that content into the library or archives’ custody. The recorded reasons were limited resources to manage it, unclear authority to manage it properly, and a lack of places to keep it. The report goes further and describes refusing any transfer containing PII or PHI, regardless of its historical or evidential value, as regular practice in archives, because the means to steward it are not available.
That is the risk transfer, made visible. A confidentiality risk, which is legible, owned, and reviewable, is exchanged for a durability risk that carries none of those properties, or for the content never entering custody at all. The first exposure gets logged. The second does not. The third leaves no record anywhere, which should worry the field most.
Two structural factors push in the same direction.
The first is cost. The project found that sensitive data storage costs more than ordinary preservation storage in every configuration it modeled, so institutions would want to place only genuinely at-risk content in the higher tier. A security review is also roughly a fixed cost regardless of collection size, so the smaller the program, the more prohibitive it becomes per terabyte protected.
The second is description practice, the factor most often missed. Archives describe materials in hierarchical groupings rather than at the item level, and item-level processing of large collections to isolate sensitive material is out of reach for most archives and special collections. Collections likely to contain such material therefore get handled in the aggregate, at whatever posture the most sensitive plausible item warrants. A handful of records can set the handling requirement, and therefore the copy count, for an entire collection.
None of this argues for treating restricted content casually. It argues for weighing both risks, so the tradeoff is deliberate rather than the result of a decision nobody framed. That is a conversation a preservation program cannot have alone.
A related question worth asking any preservation service provider, including this one, is: who can read member content, under what circumstances, and how it is logged. Preservation programs should ask it. Providers should have a documented answer ready before anyone asks, rather than assembling one under audit pressure.
APTrust can answer, and the answer includes a trade-off worth naming rather than smoothing over. APTrust does not hold HIPAA or FERPA certification, and it does not accept PII, PHI, or similar content unless the depositor encrypts it to the standard their institution requires. APTrust does not hold the keys and cannot decrypt that content. That is a genuine confidentiality guarantee, and it shifts the key-management problem to the depositor, as described in the next section. You can still verify the fixity of the stored object, but you can’t verify anything that depends on reading the content; and if the depositor loses the keys, the bits survive with no way to use them. A durable arrangement, not a solved problem.
APTrust has also begun early internal conversations about strengthening its security posture, including scoping what pursuing ISO/IEC 27001 would involve. No decision has been made, and the work is at the assessment stage. It’s mentioned here because the exercise itself is an instance of this post’s argument, which the next section takes up.
Where the disciplines pull against each other
Complementarity is an honest summary, but it is not the whole picture, and a post that claims only harmony is easy to discount. Six tensions are worth naming.
Text description of the security and preservation tensions table
A table with three columns: topic, security instinct, and preservation instinct.
Encryption: security says encrypt everything at rest; preservation says keys must outlive the staff who made them.
Retention: security says minimize what you hold; preservation says keep it, and keep it usable.
Currency: security says patch and upgrade aggressively; preservation says hold the environment stable to render.
Copies: security says fewer copies, less attack surface; preservation says more copies, more durability.
Restrictions: security says enforce in the current system; preservation says restrictions must outlive the system.
Incidents: security says restore service quickly; preservation says establish which copy is authentic.
Both columns are legitimate. The work is deciding each tradeoff deliberately rather than by default.
Encryption at rest. A strong confidentiality control and a serious preservation risk. Keys have to survive decades, staff turnover, and vendor changes. The TDL and UCSD project put it plainly: encryption is not a preservation best practice, but institutions holding sensitive content often regard it as their only available option. A well-encrypted, unrecoverable collection satisfies the triad completely and fails preservation entirely.
That matters beyond any one regulation. When a provider accepts only depositor-encrypted content and doesn’t hold the keys, the depositor carries the key-management burden, and tighter encryption requirements make such arrangements more common. Key escrow with succession planning, periodic re-encryption, and separating fixity verification from content access are not exotic techniques, but they are not yet standard practice either.
Data minimization. A core privacy and security principle that points in the opposite direction from indefinite retention. Records schedules and legal holds mediate this in practice, but the underlying instincts genuinely conflict, and preservation programs should expect to defend retention rather than assume it.
Platform currency. Aggressive patching and upgrading serve security. Environment stability serves renderability. Emulation and legacy dependencies sit uncomfortably in a modern vulnerability management program, and that discomfort is legitimate on both sides.
Copies. More copies improve durability, but each one expands the attack surface and adds an access-control configuration that must stay synchronized.
Restriction metadata. Access restrictions must persist as long as the content. The systems that enforce them get replaced every five to ten years. Restriction status is preservation metadata, and very few programs treat it that way or test whether it survives a migration.
Incident response. Security wants to restore quickly. Preservation wants to establish which copy is authentic and avoid overwriting evidence of what happened. In an active incident, these instincts collide, and the time to resolve that is not during one.
Naming these is not a concession. It is what makes the complementary parts credible.
What preservation gets from security
Conversations on this subject often frame preservation as the giver. The reciprocal case is at least as strong, and preservation programs routinely leave it on the table.
Identity and access infrastructure that the institution has already paid for. Single sign-on, multi-factor authentication, group management, and deprovisioning workflows are hard to build and easy to inherit.
Centralized logging. A security information and event management platform produces exactly the access and administrative audit trail that ISO 16363 and CoreTrustSeal ask repositories to evidence. The logs exist. Preservation programs rarely think to ask for access to them.
A shared evidence base. This is the most concrete form of the argument. ISO/IEC 27001 asks an organization to define a management system, run a risk assessment, select controls from the ninety-three in Annex A of the 2022 revision, and document the reasoning in a Statement of Applicability. TDR and CoreTrustSeal ask a repository for a structurally similar body of evidence about access control, logging, change management, succession planning, and risk. The vocabulary and audiences differ, but much of the underlying documentation is the same. An institution already certified to ISO 27001, or working toward it, has built a meaningful share of what a repository audit will ask for, and vice versa. The two evidence bases are rarely assembled with each other in mind, and they could be.
Third-party risk assessment. Preservation programs often experience vendor review as an obstacle to placing content offsite. It is also free, expert due diligence on an organization that may hold the only remaining copy of a collection. NIST CSF 2.0 strengthened its treatment of supply chain risk when it was published in February 2024, which gives the security office a framework-based reason to take that review seriously rather than treating it as paperwork.
Incident response capability. Plan templates, tabletop facilitation, retained external expertise, and legal and communications pathways that a preservation program would struggle to build on its own.
Executive attention. This is the largest item on the list. Security has budget authority, board-level visibility, and regulatory backing that preservation arguments rarely command. The 2024 addition of a Govern function to the NIST framework, elevating governance and accountability to a core function alongside the original five, is an opening. A risk that appears in a governance conversation gets funded differently from one that appears in a departmental plan.
CHARM was designed for exactly this move. It is compatible with ISO 31000 and ships with a risk identification framework and a risk assessment spreadsheet that produce scored, characterized risk statements. Its whole purpose is to let preservation risk enter an enterprise risk register in the format that register already uses. Between the NDSA Levels for technical maturity, DPC RAM for organizational capability, and CHARM for risk, the preservation field has assembled most of what an institutional risk conversation needs. What it has not done is present them that way.
What to bring to the conversation
Text description of the CSF function mapping
Six cards, one per CSF 2.0 function, each listing preservation practices that contribute to it.
Govern: preservation policy and retention mandate; stated risk appetite for collections; CHARM risk statements in the enterprise register.
Identify: collection inventory and asset classification; provider and supply chain assessment; collections named in the business impact analysis.
Protect: least privilege on restricted collections; immutable, retention-locked copies; separate credential and administrative domain.
Detect: scheduled fixity verification; documented cadence and alerting path; continuous monitoring evidence.
Respond: provenance and chain of custody records; determining which copy is authentic; scope of loss established against inventory.
Recover, shown highlighted: restoration from the preservation copy; stated recovery time objective; restoration fire drills.
The framework functions are from NIST (2024), The NIST Cybersecurity Framework 2.0, NIST CSWP 29. The mapping is illustrative.
Abstract advice on building a relationship with the security team is nice, but it leaves you wondering where to start. Specific artifacts are worth a great deal. Roughly in order of effort:
Find out whether they know the preservation copy exists. Surprisingly, many security teams don’t know their institution has an offsite, independently administered, immutable copy of its digitized and born-digital collections. That is a five-minute conversation with disproportionate return, and it is the right first move.
Get collections named in the business impact analysis (BIA). Most BIAs inventory systems, not content. Ask for collections to appear as an asset class with a stated recovery time objective and recovery point objective. This single act moves preservation from a departmental concern to an institutional one.
State the recovery time honestly. Weeks, not minutes, for large volumes from archival storage classes. A continuity plan can accommodate a tier that takes weeks. It cannot accommodate a claim that collapses in the first tabletop exercise, and neither can the credibility of the person who made it.
Offer a restoration fire drill and invite them. Simulating a restoration verifies the service and the organization’s ability to make sense of what comes back. The British Library’s experience is the argument: the copy survived, and the ability to use it did not. Ask to join the next institutional tabletop, too.
Bring fixity reports. Scheduled checksum verification with an alerting path is a detective control with a documented cadence. Security teams understand continuous monitoring. Present it in those terms, and it stops looking like a library activity.
Offer a crosswalk. Map preservation maturity models to the six CSF functions and hand it over. It lets the security office locate preservation work inside a structure it already uses. Use two frameworks rather than one. The NDSA Levels are a technical maturity model and exclude policy and staffing by design, leaving the entire Govern function of CSF uncovered. DPC RAM covers exactly that territory, with six of its eleven sections devoted to organizational capabilities. Against the 22 CSF categories, the Levels alone leave eight uncovered. Adding RAM brings that to three. The three that remain are incident management, incident response communication, and recovery communication, which matters because it tells a preservation program precisely where it needs its security colleagues rather than the other way around.
Rather than leave that as an exercise, APTrust has published the crosswalk. It maps all twenty cells of the NDSA Levels matrix and all eleven DPC RAM sections to the CSF categories they contribute to, rates each of the 22 CSF categories for coverage by each framework and by both together, and shows what neither covers. A companion spreadsheet keeps the reference mapping fixed and adds columns to record a program’s status, evidence, and owner. It is a practitioner aid rather than a conformance mapping, and community corrections are welcome.
Ask whether the institution holds, or is pursuing, ISO 27001. If it does, ask for the Statement of Applicability and the risk assessment. Much of what a repository audit will ask for is already written down in there, in a different vocabulary, and reusing it is faster than recreating it.
Ask the provider question and bring the answer with you. Who can read the content stored with a preservation provider, under what circumstances, and how is it logged? Arriving with the answer already documented is a materially different conversation from being asked for it.
Ask what happens to restriction metadata at the next migration. This is the question most likely to be genuinely new to both parties, and it belongs to both.
None of this is hypothetical. Pennock reports that the British Library has invested in exactly this kind of engagement with its security colleagues since early 2023, and that CHARM turned out to be an effective way to explain digital preservation to them, in part because the model made immediate sense to people who already think in risk terms (personal communication, 14 September 2026).
Where this leaves us
These two disciplines protect overlapping properties under different threat models on different time horizons, and they need each other in both directions. Security frameworks reach further into the technological environment than preservation programs typically manage on their own. Preservation risk models reach into strategy, policy, and budget, where no technical control has ever helped anyone.
The preservation field’s newest risk model does not name confidentiality among its target values, and the security field’s foundational model has never named authenticity or longevity. Each has been building the part of the picture it could see.
The practical work is unglamorous and mostly conversational: shared vocabulary, a shared risk register, an honest recovery time objective, and a standing invitation to each other’s exercises. Most institutions have not started it. The digital preservation community is well positioned to go first, and has good reason to.
References
Academic Preservation Trust. (2026). Crosswalk: NDSA Levels v2.0 and DPC RAM v3 to NIST Cybersecurity Framework 2.0. https://doi.org/10.18130/uva-open/75
British Library. (2024). Learning Lessons from the Cyber-Attack: British Library Cyber Incident Review, March 2024. London: British Library. https://www.bl.uk/stories/blogs/posts/learning-lessons-from-the-cyber-attack
Consultative Committee for Space Data Systems. (2024). Audit and Certification of Trustworthy Digital Repositories. Recommended Practice, Issue 2. CCSDS 652.0-M-2. Washington, DC: CCSDS. (Published as ISO 16363.)
CoreTrustSeal Standards and Certification Board. (2022). CoreTrustSeal Trustworthy Data Repositories Requirements 2023-2025. Zenodo. https://doi.org/10.5281/zenodo.7051012
Digital Preservation Coalition. (2024). Digital Preservation Coalition Rapid Assessment Model (DPC RAM), Version 3. http://doi.org/10.7207/dpcram24-03
International Organization for Standardization. (2022). ISO/IEC 27001: Information security, cybersecurity and privacy protection, Information security management systems, Requirements. Geneva: ISO.
International Organization for Standardization. (2018). ISO 31000: Risk management, Guidelines. Geneva: ISO.
Mumma, Courtney (2022). Preserving Sensitive Data in Distributed Digital Storage Networks. IMLS Award LG-34-19-0055-19. https://hdl.handle.net/2249.1/156715
National Digital Stewardship Alliance. (2019). Levels of Digital Preservation, Version 2.0. https://doi.org/10.17605/OSF.IO/U8M3W
National Institute of Standards and Technology. (2024). The NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29. https://doi.org/10.6028/NIST.CSWP.29
Pennock, M. (2024). Disentangling Digital Preservation Risk: An Interdisciplinary Exploration and Solution. PhD thesis, University of Dundee. https://doi.org/10.15132/20000457
Pennock, M. (2024). Scaling up knowledge of digital preservation risk: from concept to reference model and risk assessment with CHARM. iPRES 2024, Ghent, Belgium. https://doi.org/10.21428/5676bf2d.7f25ec43
Saltzer, J. H., and Schroeder, M. D. (1975). The protection of information in computer systems. Proceedings of the IEEE, 63(9), 1278-1308. https://doi.org/10.1109/PROC.1975.9939
Samonas, S., and Coss, D. (2014). The CIA strikes back: redefining confidentiality, integrity and availability in security. Journal of Information System Security, 10(3), 21-45. https://www.jissec.org/Contents/V10/N3/V10N3-Samonas.html
Vermaaten, S., Lavoie, B., and Caplan, P. (2012). Identifying threats to successful digital preservation: the SPOT model for risk assessment. D-Lib Magazine, 18(9/10). https://doi.org/10.1045/september2012-vermaaten