19 Data Protection & Privacy: HITRUST requirements and evidence

What HITRUST domain 19 Data Protection & Privacy asks for in an HITRUST assessment

Domain 19 Data Protection & Privacy covers how an organization classifies in-scope data, how long it keeps that data, how it deletes it, how it encrypts it at rest and which privacy obligations apply to it. It is one of the 19 assessment domains HITRUST uses to group requirement statements and score certification in e1, i1 and r2 reports. If a customer or regulator requires HITRUST, expect this domain to draw close attention, because it is among the lowest scoring areas. The HITRUST 2025 Trust Report names Data Protection & Privacy as the lowest scoring i1 domain in 2023 and tied for lowest in r2 in 2024.

The difficulty is usually not a missing tool. Assessors test whether the organization can show a decision for each data type: what it is, where it lives, who owns it, how long it stays and how it is removed at end of life. Encryption at rest is a good example. A storage platform may encrypt volumes, but the assessor will still ask which keys protect which data, who can access them, and whether backups, logs and exports are covered. Self-hosted platforms can help here. For instance, Nextcloud's encryption configuration documentation describes server-side encryption that protects file contents but not file names or folder structure, so the organization must record that gap and decide how to handle it.

Only the r2 can be tailored to include privacy requirements, so an e1 or i1 applicant will not face privacy statements in this domain. Confirm early which assessment you are pursuing and whether the AI security certification is added, since HITRUST places AI security requirement statements in this domain as well. Before you start, inventory in-scope data stores, assign a data owner for each, and check that retention and deletion rules exist in writing and have been carried out. Ask your assessor to confirm how sampling will test these records.

Which data, systems and teams fall under domain 19 in scope

Domain 19 is shaped more by what you put in scope than by the controls themselves. The four decisions below determine how many requirement statements you carry, where evidence has to come from, and whether privacy obligations apply to your assessment at all.

In-scope data types

Start by listing every data type the assessed environment stores, processes or transmits, including personal information, health data, employee records and derived datasets such as logs and analytics extracts. Each type drives how it is classified, how long it is kept and how it is deleted. Ask your assessor early which classes they will sample, because a data type that appears in one system but not in your inventory is a common source of findings.

Backups and file shares

Backups, archives, sync folders and shared drives often hold copies of in-scope data that no one tracks as a data store. Retention and deletion requirements apply to these copies as much as to the production database. Confirm where each copy lives, who can restore it, and how deletion reaches backup media. Self-hosted file platforms may encrypt file contents at rest while leaving file names and folder structure visible, so document what remains readable.

Key management for encrypted data

Encryption at rest only supports domain 19 if you can show who holds the keys, how they rotate and where they are stored. Keys kept on the same server as the encrypted data give limited protection against a server compromise. Map each encrypted store to a key owner and a rotation procedure, and confirm that key access is logged and reviewed under the audit logging domain.

AI security statements

If your e1, i1 or r2 includes the AI security certification, HITRUST places AI security requirement statements in this domain. Those statements add work where AI systems process in-scope personal or health data, such as training data, prompts, retrieved documents and model outputs. Inventory every AI system that touches in-scope data before you set the assessment boundary, since each one can add statements to scope.

Privacy tailoring in the r2

Only the r2 can be tailored to include privacy requirements, and the e1 and i1 cannot carry them. If your customers require privacy assurance, decide on the r2 before readiness work begins, because privacy statements change what you must evidence in this domain. Confirm the tailoring with your assessor in writing, and keep the privacy scope aligned with the data inventory and retention rules you already maintain.

How an HITRUST assessor tests data protection and privacy

This table compares how an assessor tests the 19 Data Protection & Privacy domain for each assessment type, with the evidence requested and the findings that usually come up. Read each row as what the assessor will ask to see, not as a pass or fail rule. The main takeaway is that classification, retention and key management need written rules that match what the systems actually do.

Test activity	What the assessor does	Evidence requested and common findings
Document review	Reads the data classification scheme, retention schedule and deletion rules against the assessed scope	Approved classification policy and retention schedule. Common finding: retention periods are not documented for some in-scope data stores
Sampling of stored data	Selects a sample of in-scope data stores and checks whether classification labels and handling rules are applied	Store inventory, label records and sample results. Common finding: classification is not applied to in-scope stores such as backups, file shares or analytics copies
Encryption settings inspection	Reviews configuration of encryption at rest on sampled stores and how keys are generated, stored and rotated	Configuration exports, key inventory and rotation logs. Common finding: encryption keys held without a defined rotation schedule
Deletion record inspection	Samples records of data disposed of at the end of retention and checks that deletion covered all copies	Deletion tickets, logs or certificates of destruction. Common finding: deletion records exist but do not cover backups or replicas
Interviews with data owners	Confirms that named owners understand their classification, retention and privacy duties for their data	Owner roster and interview notes. Common finding: owners cannot describe how long their data is kept
Privacy requirements (r2 tailored with privacy only)	Tests privacy statements in the tailored scope against the organization's own privacy notices and handling practices	Privacy notices, consent or purpose records and data subject request procedures. Confirm with the assessor which privacy requirements apply to your scope
Fieldwork and quality assurance	Completes validated fieldwork within a window of at most 90 days, then submits results for HITRUST quality assurance	Fieldwork schedule and evidence index. HITRUST performs central quality assurance before issuing reports, so ask the assessor how it tracks open items

Sequence for implementing data protection and privacy controls

This sequence turns the data protection and privacy domain from a policy statement into evidence an assessor can test, starting with knowing where in-scope data lives and ending with privacy requirements added for an r2 tailoring. Each step names the artifact that closes it so the engineer and the compliance lead agree on what done means.

Inventory in-scope data stores
Start by listing every system, database, file store, backup set, log pipeline and third-party service that holds or processes data within the assessed scope. The platform engineering lead owns the technical inventory, and the compliance lead confirms that it matches the scope agreed for the assessment. Record the owner, location, data types and whether each store is in your cloud account, a provider's environment or your own data center. The step is done when the inventory is signed off and every store can be traced to a named owner. Keep the inventory under version control so later changes show up as evidence.
Set the classification scheme and handling rules
Define a small number of data classes, such as public, internal, confidential and restricted, with a written rule for each class covering storage locations, sharing, encryption expectations and who may approve exceptions. Information security governance usually owns the scheme, and system owners apply it to each store in the inventory. Map every inventoried store to a class and flag any store whose class is unclear. The output is an approved classification standard plus a register that assigns a class to each store, which an assessor can sample against.
Define retention and deletion schedules
For each data class, set how long data is kept, the trigger that starts the clock, and how deletion is carried out and verified. Legal, records and privacy owners agree the periods, and engineering documents how each system deletes or anonymizes data, including backups and logs where deletion is harder. Test at least one deletion path end to end and keep the result. The output is an approved retention schedule and a short procedure per system that states who runs deletion, how it is logged and how exceptions such as legal holds are recorded.
Enable encryption at rest with managed keys
Encrypt in-scope data stores at rest and decide where the keys live, who can use them and how they rotate. Storage-level encryption protects file contents, but it may not cover file names, metadata or structure, so check each store against what it actually encrypts. Where an application needs to encrypt data itself, a secrets management service with versioned keys and rotation can keep key material out of application code. The output is a configuration record per store showing the encryption method, key custodian, rotation approach and a test that confirms encryption is active.
Map privacy requirements for r2 tailoring
Privacy requirements are only tailored into an r2 assessment, since the e1 and i1 cannot include them, so decide early whether the r2 scope needs them. If it does, identify which privacy obligations apply to your in-scope data, such as consent records, data subject request handling, purpose limitation and disclosure to third parties, then trace each one to a control and an owner. Confirm the tailoring choice with your assessor before fieldwork. The output is a privacy requirement matrix that links each applicable obligation to a control, an owner and the evidence that will show it operates.
Record each step's output as evidence
Keep the outputs of the earlier steps in a controlled location, with approval dates, owners and version history, so each one can be produced for an assessor without rebuilding it. A wiki with page history or a document repository can hold the standards, schedules and matrices, while the inventory and encryption records can live in a system of record. Check that each artifact has a named owner and a review date. The output is an evidence index for the domain that maps every control statement to its artifacts, which lets the compliance lead confirm completeness before the assessment starts.

Why encryption at rest and key management need their own evidence

Encryption at rest is only one part of what assessors test in 19 Data Protection & Privacy. Turning on disk or storage encryption shows that stored data is unreadable without a key, but it does not answer where the keys live, who can use them, how they rotate, or what happens when a key is compromised. Assessors usually ask for all of these, so the evidence for stored data should cover the key lifecycle as well as the ciphertext. Before the assessment, document the key hierarchy, the systems that hold or request keys, the named roles that administer them, and the rotation schedule the organization actually follows.

Self-hosted platforms show how the same question can be answered in different ways. Nextcloud's server-side encryption protects file contents on local and external storage, with keys kept on the server, but it does not encrypt file names or folder structure. That gap belongs in your scope analysis, and you may need compensating controls or a documented risk decision for metadata. OpenBao's transit secrets engine encrypts and decrypts application data without storing that data, and it supports versioned encryption keys with key rotation, which gives applications a central, auditable key service. Confirm in your own environment which keys each service uses, whether rotation is enforced or manual, and whether old key versions remain available for decryption.

Plan the evidence before the fieldwork window starts. Export key inventories and rotation records, capture the access policy that limits who can read or use each key, and keep the logs that show key use and administrative changes. Confirm these behaviors with the vendor documentation and in a test environment before you rely on them in a scoped assessment, since the exact behavior depends on your configuration and version. An independent assessor will decide whether the evidence is sufficient; a partner can help you prepare the configuration and records.

Evidence that satisfies data protection and privacy testing

Assessors testing 19 Data Protection & Privacy look for records that show data is classified, kept only as long as needed, deleted on schedule and encrypted with managed keys. The cards below cover the artifacts that usually carry that proof and how to keep each one current between assessments.

Data classification register

A register lists each data store in scope, the classification assigned to its contents, the owner accountable for it and the controls that follow from that label, such as encryption requirements and access restrictions. Assessors compare the register against real systems, so check that every file store, database, backup and logging pipeline appears and that new systems are added before they receive production data. Review the register whenever a new data type or system enters scope.

Retention and deletion schedule

The retention schedule states how long each class of in-scope data is kept, the trigger that starts the clock and the legal or contractual reason for the period. Assessors look for a schedule that matches what systems actually do, so compare it against backup rotation and log retention settings. Confirm the owner signs off on changes and that exceptions, such as legal holds, are documented with an approver and an end date.

Deletion logs and certificates

Deletion evidence shows that scheduled removals happened: job logs from storage or database purges, tickets for manual deletion requests and certificates of destruction from a disposal vendor for decommissioned media. Confirm that logs record what was removed, when and by which process, and that backup copies follow the same schedule or have a documented expiry. Gaps here are common because deletion often runs silently, so test a sample by restoring nothing and checking the record exists.

Encryption configuration exports

Configuration exports capture the settings that protect data at rest, such as whether server-side encryption is enabled for each storage backend, which cipher and key location are used and which data types are excluded. In Nextcloud, for example, server-side encryption protects file contents but does not encrypt file names or folder structure, so the export should show that limitation and any compensating control. Re-export after every upgrade or storage change, since a single backend added without encryption can fail the domain.

Key rotation records

Key management records show who created, rotated and retired encryption keys, along with the dates and the approval for each change. OpenBao's transit secrets engine supports versioned keys and rotation, so the audit trail should show that older versions remain available only for decryption where needed. Confirm that rotation follows a defined interval and that access to key administration is limited and logged, because assessors test the key process as closely as the encryption itself.

Privacy notices and DPIA outputs

Privacy notices, records of processing and data protection impact assessment outputs show how personal data is used and which safeguards were chosen for higher-risk processing. These artifacts matter most when an r2 is tailored to include privacy, since only the r2 can carry that scope. Keep each DPIA dated, linked to the systems it covers and reviewed when processing changes, so the r2 interim assessment can confirm the record still matches production.

What meeting domain 19 costs in money and effort

This table breaks down the cost and effort components of meeting Data Protection & Privacy, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a quote request so that vendors price the same scope. The main takeaway is that open-source licenses remove software spend but not the engineering, data owner and evidence work that this domain requires.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it up or down
Internal engineering for encryption and key management	Your engineers, or an implementation partner for design and build	One-time build, recurring operation	Number of data stores in scope, key rotation design, and whether keys are held in a self-hosted secrets service
Data classification and labeling	Data owners in each business line, with a facilitator from security or compliance	One-time, then periodic review	Number of data types, how many systems hold in-scope personal or regulated data, and whether a classification scheme already exists
Retention and deletion schedules	Legal, records management and data owners, plus engineers who implement deletion jobs	One-time design, recurring enforcement	Number of regulatory retention obligations, backup copies that must also expire, and the ability to delete from each system
Open-source platform licensing	Usually no license fee for self-hosted open-source software	Not applicable to license spend	Licensing is removed, but hosting, patching, upgrades and support staff remain costs. Confirm each project's license terms before deployment
Evidence collection and upkeep	Control owners and engineers who produce logs, configuration exports and sign-offs	Recurring across the assessment cycle	Whether evidence is generated automatically, how many systems are sampled, and how often data owners must recertify
External readiness review	An outside consultant or readiness reviewer, if you choose to buy one	One-time per readiness cycle	Scope size, prior gaps in this domain, and whether the reviewer also works on other domains in the same assessment
Assessor fees for validated fieldwork	An Authorized HITRUST External Assessor organization	One-time per assessment, repeated at renewal	Assessment type (e1, i1 or r2), whether privacy is tailored into an r2, and the number of in-scope systems and sample sizes
Privacy tailoring in r2 (if applicable)	Compliance lead and privacy office, with assessor agreement on scope	One-time scoping, recurring evidence	Only the r2 can include privacy. Confirm with your assessor whether privacy requirements apply to your data and jurisdictions

Who owns, implements and tests data protection and privacy

Your organization owns the decisions behind domain 19. Security, legal, privacy and data owners agree which data is in scope, how it is classified, how long each category is retained, when it is deleted and which privacy obligations apply to it. No vendor can make these calls for you, and assessors will ask who approved them and when they were last reviewed. For an r2 tailored to include privacy, this group also decides which privacy requirements are in scope and documents why any requirement is marked not applicable.

Data classification: a written scheme with owners for each data set, mapped to the systems that hold it.
Retention and deletion rules: approved schedules, with a named owner for deletion and records that show deletion ran.
Privacy obligations: the contractual, statutory and internal duties that apply to in-scope personal data, tracked to owners.
Exceptions and N/A decisions: signed risk acceptance for any gap, with a review date.
Evidence ownership: a named person who keeps the classification register, retention logs and approvals current.

Before you engage anyone, confirm that these decisions exist in writing and that someone can produce them on request.

Where data protection and privacy assessments usually fall short

Domain 19 is where HITRUST checks whether data is known, kept only as long as it should be, deleted on purpose and protected by keys that are managed apart from the data. The gaps below are the ones that tend to turn into corrective action plans, and each one is closed by evidence the assessor can sample rather than by policy wording alone.

Backups outside the data classification

Teams classify the production database and forget the nightly backups, replicas, exports and file shares that hold the same records. An assessor who samples a backup set and finds unlabeled personal or payment data will question the whole classification scheme. Check that every backup location appears in the data inventory with the same label as its source, and that the restore procedure preserves that labeling.

Retention rules that exist only in policy

A retention schedule approved by management does not show that data is actually removed when its period ends. Assessors look for the job, setting or configuration that enforces each rule, and for records showing it ran. Ask the team to name the system that deletes each data class, the owner of that job, and the log entry from its most recent run.

Deletion that is not evidenced

Deleting a record from an application does not prove it is gone from file storage, search indexes, logs or archived copies. The gap is usually the missing record of what was deleted, when and under which request or schedule. Keep a deletion log that ties each request to the systems touched, and test a sample of deleted records against every store where they might still exist.

Encryption keys stored beside the data

Encryption at rest offers little protection when the key sits in the same bucket, configuration file or server image as the ciphertext. Assessors ask where keys live, who can read them, and how they are rotated. Move keys into a dedicated secrets service, restrict access to the service's administrators, and record key version and rotation dates so the encryption claim can be sampled.

Open source software usage requirements

The HITRUST 2025 Trust Report ranks an open source software usage requirement in this domain tenth among the most frequent corrective action plans. Organizations often run open-source components without a current inventory, license review or record of who approved them. Maintain a software inventory that lists each component, its license and the business owner, and confirm that open-source components holding in-scope data are covered by the same review as commercial ones.

Questions buyers ask about domain 19 cost, effort and scope

Can an e1 or i1 include privacy requirements for domain 19?

No. Only the r2 can be tailored to include privacy, so the e1 and i1 cannot carry privacy requirements in domain 19. If a customer or regulator asks for privacy coverage inside a HITRUST assessment, the r2 is the assessment type to scope. The e1 and i1 still contain domain 19 requirement statements for data protection, so the core data handling expectations apply at those levels. Confirm the exact tailoring rules with your HITRUST External Assessor before you commit to a scope, because the choice changes both the requirement count and the evidence you must produce.

How much effort does domain 19 take compared with other domains?

Domain 19 is one of 19 domains, so its share of effort depends on how much of its data handling already exists. HITRUST's 2025 Trust Report names Data Protection & Privacy as the lowest scoring i1 domain in 2023 and tied for lowest in r2 in 2024, which signals that many organizations need substantial preparation here. The main drivers are:

How well your data classification scheme is documented and applied to in-scope systems
Whether retention and deletion rules exist for each data store and are enforced
Whether encryption at rest is consistent across databases, file stores and backups
Whether AI security requirements are added through the AI security certification

Ask your assessor and any readiness partner to estimate effort against your own gap list.

Can our own team prepare domain 19 without an outside partner?

Yes, an internal team can prepare domain 19, but the organization must own every control and every piece of evidence. Internal staff can write classification standards, set retention schedules, configure encryption and collect proof, provided they have the time and the subject knowledge. Outside help is usually most useful for gap analysis, for designing evidence collection, and for reviewing whether the results will read clearly to an assessor. Only an Authorized HITRUST External Assessor performs the validated assessment, and HITRUST performs central quality assurance before issuing a report. An implementation partner such as DeployOpen can prepare systems and evidence but does not issue reports or certificates.

What does domain 19 require from our engineering and governance teams?

Domain 19 needs both policy owners and engineers to work together. Governance staff must define what counts as personal and sensitive data, who approves retention periods and how deletion requests are handled. Engineers must make those rules real in systems, which means tagging data by classification, enforcing encryption keys and removing data when retention ends. Expect the team to keep records that show each rule was applied, not only that the rule exists. Named owners, a current inventory of in-scope data stores and a repeatable way to produce evidence for sampled systems usually determine whether the work stays on schedule.

How long can the assessor's fieldwork for domain 19 run?

The assessor's validated assessment fieldwork window is at most 90 days for e1, i1 and r2 assessments, according to the HITRUST Assessment Handbook. This limit applies to the whole fieldwork period, not to domain 19 alone, so all 19 domains share the same window. Your own preparation time sits before fieldwork and is not capped by that rule. To keep fieldwork short, have domain 19 evidence ready, organized by requirement statement and system, before the assessor begins testing. Confirm the planned dates, sampling approach and evidence owners in writing with your assessor.

Can an implementation partner issue the evidence for domain 19?

An implementation partner can prepare the evidence, but it cannot issue it as an assessment result. Evidence such as configuration exports, encryption settings, retention logs and classification records must be produced from your own systems and owned by your organization. The partner may help configure the systems, collect and organize the evidence, and document how each control works. Only the independent assessor reviews that evidence and reports results, and HITRUST performs quality assurance before a report is issued. Ask any partner to show, in writing, which deliverables are preparation work and which belong to the assessor.

Which open-source tools can help produce domain 19 evidence?

Several self-hosted open-source tools can produce parts of domain 19 evidence, though none satisfies a requirement by itself. Nextcloud's server-side encryption protects file contents at rest on local and external storage with keys kept on the server, but it does not encrypt file names or folder structure, so that gap needs a separate control. OpenBao's transit secrets engine encrypts and decrypts application data without storing it and supports versioned keys with rotation, which helps show key management. XWiki keeps every page change under version control, which can support documented policies and retention decisions. CISO Assistant can track frameworks and audits, though you should confirm how its mappings fit your HITRUST scope with your assessor.

How DeployOpen prepares data protection and privacy evidence

DeployOpen plans, implements and documents the self-hosted open-source platforms that produce data protection and privacy evidence inside your own infrastructure. We prepare systems, controls and evidence for the assessment, while your organization owns its controls and an independent HITRUST External Assessor performs the validated assessment.

How we scope

We agree a written scope listing the data stores, classifications and privacy obligations included for 19 Data Protection & Privacy.
We confirm with you whether the assessment is an r2 tailored to include privacy, since only the r2 can carry those requirements.
We map which encryption, key management and retention requirements apply to each in-scope system before any build work starts.

How we build

We configure server-side encryption for file storage and document which data, such as file names, remains outside that protection.
We set up a transit secrets service for application data encryption, with versioned keys and a documented key rotation schedule.
We implement retention and deletion routines for in-scope data and record how each routine runs and who approves it.

How we hand over

We deliver configuration records, key management procedures and retention schedules that show how each requirement is met.
We provide change histories for policy and procedure documents, so your assessor can see what changed, when and by whom.
We prepare an evidence index linking each in-scope data protection requirement to the artifacts your assessor will sample.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
We help your team keep encryption, key rotation and retention evidence current ahead of your assessment window and any interim review.
We can rerun configuration checks after platform upgrades or significant changes so evidence stays accurate between assessments.

19 Data Protection & Privacy