14 Third-party Assurance: HITRUST requirements and evidence

What HITRUST 14 Third-party Assurance asks you to prove about your vendors

Domain 14, Third-party Assurance, asks your organization to govern and monitor the third parties that handle in-scope data, and that responsibility stays with you even when a provider holds its own HITRUST certification. A vendor's report can support your position, but it does not replace your own oversight of that vendor. Before the assessment starts, list every provider that stores, processes, transmits or can administer in-scope data, and confirm that each one has a documented owner inside your organization. Assessors will start from that list and work outward to the contracts, reviews and monitoring records behind it. The risk this domain addresses is simple to state and hard to sustain: a third party with weak controls can expose data that your own controls protect. In the 2025 Trust Report, HITRUST ranks a Third-Party Assurance requirement, at least annual review of service level agreements against monitoring records, as the most frequent corrective action plan in 2024. In practice, that gap usually means the review was either never scheduled, or it happened but nobody kept a record that shows the review and the follow-up. The fix is process discipline, not new tooling.

For each provider in scope, prepare the evidence an assessor will ask for: the signed contract and security terms, the service level agreement, the most recent review of that agreement against the provider's performance reports, and the record of any issues raised and how they were closed. Confirm the date of the last review for every provider and set a calendar entry for the next one. Where a provider's assurance report is out of date, or does not cover the services you use, record that gap and the compensating step you took. Ask your legal or procurement team to confirm which contract clauses give you audit rights or access to reports, since those rights determine what you can actually obtain when an assessor asks. AI-related vendors deserve a separate check. HITRUST's AI Security Assessment help page places AI security requirement statements in this domain, so if you pursue that add-on, your inventory of AI service providers, model hosts and data processors must be complete and reviewed on the same cycle. Confirm the scope of that add-on with your assessor early, because it changes what counts as a third party in your evidence set.

Which vendors and data fall into third-party assurance scope

Third-party assurance scope follows the path that in-scope data takes, not the number of contracts you hold. The cards below cover the decisions that most often change how much oversight a HITRUST assessment requires, from hosting and SaaS tools to subprocessors and AI vendors.

Providers that touch in-scope data

Start from the data, not the vendor list. Any provider that stores, processes, transmits or can administratively reach in-scope data belongs in this domain, even when the contract looks like a minor purchase. Map each provider to the data classes and environments it touches, and record where that access starts and ends. Ask each one for its own HITRUST or SOC 2 report and confirm that its scope covers the service you actually use.

Hosting and infrastructure providers

Cloud and data center providers are often the largest third-party dependency. Whether their controls can be inherited depends on how the provider's HITRUST scope is drawn and what the shared responsibility split leaves to you. Confirm which infrastructure services sit inside the provider's assessed scope, which controls remain yours to operate, and how you will evidence them. Do not assume that a provider's certificate covers your configuration.

SaaS tools with administrative access

Support desks, ticketing platforms, monitoring services, code repositories and collaboration tools often hold copies of in-scope data or privileged access to systems. Their risk sits in what they store and who can change it, not in their price. List each SaaS tool that receives logs, tickets, extracts or credentials, then document the data flow and the contractual security terms that apply to it.

Subprocessors in the chain

A direct provider may pass in-scope data to its own subprocessors, and those parties sit outside your contract. Ask each provider for its subprocessor list, the data each one receives, and how changes are notified. Confirm that the provider flows security obligations down to those subprocessors and that you can review evidence for them when your assessor asks.

AI vendors and the AI security certification

HITRUST places AI security requirement statements in this domain, so an organization pursuing the AI security certification adds work for AI vendors, including model hosts, API providers and tools that embed AI features. Identify which AI services receive in-scope data or act on it, and confirm how each one handles prompts, outputs, retention and training use. Confirm the current requirement set with HITRUST before scoping.

Vendor inventory as scope evidence

Assessors test the scope itself, so an accurate and current vendor inventory is the first evidence they request. Keep one register that links each provider to its service, data classes, environments, contract owner, assurance report and review date. Changes such as a new subprocessor or a retired tool should update that register before the next assessment window, not after.

How an assessor tests vendor oversight in a HITRUST validated assessment

This table compares the test types an External Assessor typically applies to the third-party domain, the evidence each one asks for and where organizations usually fall short. Read it as a preparation checklist: each row shows what the assessor will ask to see, so you can confirm the records exist before fieldwork begins.

Test area	What the assessor typically does	Evidence usually requested	Where findings usually arise
Vendor sampling	Selects a sample of third parties that handle in-scope data and confirms the population was complete	Current vendor inventory, data flow mapping, list of providers with access to in-scope systems	Inventory omits SaaS tools or subprocessors that touch regulated data
Due diligence files	Reviews the pre-engagement assessment for each sampled vendor and checks it was completed before data sharing	Security questionnaires, prior assurance reports, risk rating and approval records	Files are dated after contract signature or lack a documented risk decision
Contract clauses	Checks that agreements cover security obligations, breach notification, audit rights and data handling	Executed contracts, addenda, data processing terms and signature dates	Contracts are unsigned, outdated or silent on security and incident notice
SLA review against monitoring	Compares documented service level reviews with the monitoring records that should support them	SLA definitions, periodic review minutes, performance reports and tickets raised for misses	Reviews are described in policy but no dated record shows they happened
Annual review cadence	Confirms each in-scope provider was reviewed within the period the organization set, and that reviews were not skipped	Review calendar, completed annual reviews, reassessment triggers and sign-off by an accountable owner	Gaps in the review cycle, or reviews that repeat last year's text without new evidence
Compliance report review	Reads each provider's independent assurance report, checks its period and scope, and records any exceptions	Assurance reports, bridge letters, exception analysis and the organization's own follow-up decisions	Reports are on file but scope or period does not cover the services used
Offboarding and access removal	Checks that terminated or changed vendors lost access and that data was returned or deleted	Termination notices, access revocation records and data disposal confirmations	Vendor access persists after the contract ends

Sequence for building a third-party assurance program

The sequence moves from knowing which vendors touch in-scope data, to deciding how hard to look at each one, to checking their evidence on a fixed cycle and ending access cleanly when the relationship stops. Each step produces a record that a HITRUST assessor can test under domain 14 Third-party Assurance.

Inventory every provider that handles in-scope data
Start with a complete list of vendors, service providers, subcontractors and cloud platforms that store, process, transmit or can reach the in-scope environment. Procurement, IT, finance and business owners should each be asked for their contracts, because shadow SaaS tools often sit outside the official vendor register. The output is a register that names each provider, the service it delivers, the data or systems it touches and the accountable internal owner. The step is done when the register is reconciled against accounts payable and access logs, and the owner signs off on every line.
Tier providers by risk
Assign each provider a risk tier based on the sensitivity of the data it holds, the depth of its access, whether it is a single point of failure and how easily its service could be replaced. Document the criteria in a written method so that two reviewers would reach the same tier for the same vendor. Higher tiers receive deeper due diligence, more frequent report reviews and stricter contract terms. The output is a tiered register with a short rationale for each tier and a named approver, and the method is reviewed whenever the scope of the assessment changes.
Run due diligence intake
Before a provider receives access or data, collect a standard set of evidence matched to its tier. Typical items include current independent assurance reports, certifications, a security questionnaire, information on subprocessors, incident history and data location. Ask the provider which controls it operates for the services you buy and which it expects you to run yourself, since that split feeds shared responsibility records. The output is a dated due diligence file per provider, with gaps logged and an accept, accept with conditions or reject decision recorded by the business owner and security.
Review contracts and the security schedule
Check that each agreement for an in-scope provider sets out security obligations, data handling and return or deletion rules, breach notification duties, audit or evidence rights, subprocessor controls and the service levels you depend on. Legal and security should review the security schedule together, and gaps should be negotiated before signature rather than tracked afterwards. The output is a contract review record that lists the clauses checked, any exceptions and the people who approved them. Ask counsel to confirm the terms that apply in your jurisdiction and to your sector.
Review service levels and assurance reports on a set cycle
Set a review calendar by tier and read each provider's service level reports and assurance reports against the commitments in the contract. Compare the monitoring data you hold with what the provider states, note any period the provider does not cover, and check whether complementary user entity controls in the report are operating on your side. Where the reporting cadence is not documented, confirm it with the provider. The output is a signed review memo per provider with exceptions logged. HITRUST reports rank the annual review of service level agreements against monitoring records as the most frequent corrective action plan in 2024, so this record deserves the most care.
Monitor performance and track issues to closure
Between formal reviews, monitor provider performance, security notifications, changes to subprocessors and incidents that affect your data. Open an issue for every deviation, assign an owner and a target date, and escalate material findings to the risk owner. Feed confirmed issues into the risk register so they are treated the same way as internal findings. The output is an issue log that shows when each problem was raised, what was agreed, who verified the fix and when it closed. Closed issues should show evidence of verification, not only a provider's assurance that the fix is complete.
Offboard providers and retrieve or delete data
When a provider relationship ends, revoke its accounts, certificates, API keys and network paths, then retrieve or delete in-scope data as the contract requires. Obtain written confirmation of deletion or return and of subprocessor deletion where it applies. Update the register, close open issues and archive the due diligence and review files for the period the retention policy requires. The output is an offboarding record that an assessor can trace from the last access grant to the deletion certificate, so the provider's final status is documented rather than assumed.

Why a vendor's HITRUST certificate does not close this domain

A vendor's HITRUST certificate does not discharge your own third-party assurance obligations. In HITRUST's inheritance example using Oracle Cloud Infrastructure, 14 Third-party Assurance is one of the domains that cannot be inherited. The customer still reviews its providers' compliance reports and manages assurance over its own vendors. Inheritance can carry technical and physical controls from a provider into your assessment, but the decisions about which vendors you use, what they may access and whether they keep their commitments remain yours to make and evidence.

What you keep on file is the record of that oversight. For each provider that handles in-scope data, expect to hold the contract and its security terms, the due diligence you performed before onboarding, the most recent report you reviewed and the date you reviewed it, and a written note of any exceptions, complementary user entity controls you are responsible for, or subservice organizations the provider relies on. Confirm with your assessor which report types and review cadence they will accept for each provider, since the requirement is tested through your process, not through the provider's certificate alone.

This differs from inheriting technical controls in one important way. When a provider's control is inherited, the assessor tests the provider's implementation and you rely on it. In this domain the assessor tests whether you did the reviewing. A missing or stale review of a critical vendor can fail the domain even when that vendor's own certification is current. Before your next assessment, list every provider that touches in-scope data, assign a named owner for each review, and check that the evidence dates fall inside the assessment period.

Evidence that satisfies third-party assurance and how to keep it current

Assessors testing 14 Third-party Assurance look for a chain of records: who the vendors are, how much risk each one carries, what they promised in writing, and what the organization did with their assurance reports. Each artifact below goes stale on its own schedule, so the goal is a register and review cycle that keeps every record current between assessments.

Vendor inventory

A single register of every third party that stores, processes, transmits or can administer in-scope data or systems, including subcontractors reached through a primary vendor. Record the service, the data types involved, the hosting location and the business owner. Refresh it whenever procurement approves a new supplier, when a contract ends, and at least at each review cycle, because an inventory that omits a SaaS tool used by one team is the most common gap assessors find first. Confirm that cloud accounts and developer tools are included.

Risk tiering records

A documented rule that places each vendor in a tier based on data sensitivity, access level, and the impact of an outage or breach, with the reasoning written next to the result. The tier decides how deep due diligence goes and how often reviews happen. Revisit tiers when the service scope changes, when a vendor starts handling a new data class, or after a security incident involving that vendor. Tiers that were set once and never revisited suggest the program is not operating.

Completed due diligence questionnaires

Signed questionnaires that show what each vendor said about its controls before the contract was signed, scaled to the tier. Keep the version the vendor answered, the date, and the reviewer's notes on answers that were unclear, unsupported or contradicted by other evidence. Refresh the questionnaire at renewal or when the service changes materially. Old answers from a vendor that has since changed hosting providers do not describe the current risk.

Executed contracts with security terms

Signed agreements that set out security obligations, data handling and location, subprocessor approval, breach notification timelines, audit or report rights, and return or deletion of data at exit. Check that the terms in the signed contract match what the due diligence and risk tier assumed. Track renewal and amendment dates in the register so a lapsed agreement does not leave a vendor operating without current terms. Confirm with legal which clauses the organization cannot negotiate for its largest suppliers.

Assurance report reviews and exception follow-up

Records showing that the organization received each vendor's independent assurance report, such as a SOC 2 report, read it, and tracked every exception or qualified result to a decision. The review note should state the period covered, any gap between that period and the current date, which complementary user entity controls the organization must run itself, and the owner of each follow-up action. A report with exceptions that no one followed up is weaker evidence than a clean report with a documented review.

Annual SLA review tied to monitoring logs

A yearly review of each service level agreement that compares the promised performance and security metrics against the monitoring data the organization actually collected. This is the requirement HITRUST's 2025 Trust Report ranks as the most frequent corrective action plan in 2024. Keep the review memo, the metrics pulled, the source logs or dashboards, and the decision on any missed target. A review that cites no monitoring data is the pattern that fails.

Offboarding evidence

Records that show access was removed, data was returned or deleted, and the vendor's certificate or credentials were revoked when a relationship ends. Assessors ask for the exit checklist, the date each account or connection was closed, and written confirmation of data destruction where the contract requires it. Start the offboarding record when the termination decision is made, not after the contract expires, and keep it in the same register so the vendor's status is never ambiguous.

What meeting third-party assurance costs in money and effort

This table breaks down the cost components of running third-party assurance for a HITRUST scope, showing who is paid, whether each item is one-time or recurring, and what pushes it up or down. Use it to build a quote request and to decide which items self-hosted open-source tooling can reduce. No fees or durations are given because none were supplied; confirm them against your own vendor count and written scope.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it
Vendor management tooling or licenses	Software vendor, or your own team if self-hosted	Usually recurring (subscription or license)	Number of in-scope vendors and how many you track in the tool
Initial vendor due diligence and contract review	Your security, legal and procurement staff	One-time per vendor, then repeated on renewal	Data sensitivity, number of vendors touching in-scope data, contract complexity
Staff time for periodic reviews of reports and SLAs	Your internal risk or security team	Recurring	Review frequency, volume of SOC 2 and other reports, and annual SLA review cadence
Evidence upkeep (monitoring records, vendor inventories, issue logs)	Your internal team, or an implementation partner if engaged	Recurring	How many vendors you monitor and whether records are kept in one system
External readiness review	Independent consultant or readiness provider, if you hire one	One-time per assessment cycle	Current maturity of your vendor program and the scope of the readiness work agreed in writing
Assessor fieldwork time	Authorized HITRUST External Assessor organization	Recurring with each validated assessment	Sample sizes, number of vendor relationships in scope, and how well evidence is organized
Remediation of corrective action plans	Your internal owners, plus any outside help you buy	One-time per finding, with follow-up testing	Vendor oversight gaps found in earlier assessments, especially missed annual SLA reviews
Open-source tooling for inventories and workflows	Your team to host and operate; an implementation partner if engaged	Recurring operating effort, few or no license fees	Hosting in your environment, staff skills, and the upkeep of integrations

Who owns third-party assurance, what partners prepare and what auditors test

Your organization owns the vendor relationships, the risk decisions and the controls that govern third parties that handle in-scope data. No partner or assessor can decide whether a provider is acceptable to you, sign off on your contract terms or accept residual risk on your behalf. Those decisions sit with named owners in your business and security functions, and they must be documented as your decisions.

Vendor selection and risk acceptance: Decide which providers may touch in-scope data and who signs off on any exception.
Contract terms: Own the security, breach notification and audit-right clauses, and confirm that they match what your monitoring can verify.
Service level reviews: Schedule and perform the at least annual review of service level agreements against your monitoring records.
Provider assurance review: Read each provider's compliance reports, track their exceptions and decide what compensating action you take.
Offboarding: Retire access, collect or destroy data and keep the closing evidence.

Before any assessment, confirm which of these owners are named, reachable and able to produce the records that show their decisions were made.

Where third-party assurance usually fails and how to close each gap

Third-party assurance usually fails in the records around the vendor, not in the vendor's own controls. The gaps below share one pattern: a review was planned or assumed, but nothing on file proves it happened, covers the right vendor, or still applies today.

SLA reviews without monitoring records

Teams often write down that service level agreements are reviewed each year, but the file holds no evidence of the review itself. HITRUST's 2025 Trust Report ranks an annual review of SLAs against monitoring records as the most frequent corrective action plan in 2024. Close the gap by keeping a dated review record for each provider that compares contracted service levels with the performance data actually received, and by naming the person who signed off on any shortfall.

Vendors missing from the inventory

A third party that handles in-scope data but never reaches the vendor register cannot be assessed, monitored or reviewed. This usually happens with software bought by individual teams, analytics tools and subprocessors of your own providers. Close the gap by reconciling the register against accounts payable records, single sign-on applications, data flow diagrams and the subprocessor lists your providers publish, then assigning each entry a data classification and an owner.

Expired SOC 2 reports

A SOC 2 report is a point-in-time or period-based document, and a report that ends months before the current date tells you little about the vendor's controls today. Many files store the report but never record its period end, the gap to the next report, or the complementary user entity controls that you must operate yourself. Close the gap by logging each report's period, requesting a bridge letter for any gap, and documenting your own controls for each complementary user entity control.

Unreviewed AI vendors

AI services often enter the environment through a feature toggle, a browser plug-in or an API key issued to a developer, so they skip procurement entirely. HITRUST's AI Security Assessment help page places AI security requirement statements in this domain, so an e1, i1 or r2 with the AI security certification adds requirements here. Close the gap by treating any vendor that processes prompts, training data or model outputs as in scope, and by reviewing where that data is stored, retained and used for model training.

Contracts without security terms

A contract that covers price and delivery but says nothing about security, breach notification, audit rights or data return leaves you without a basis to enforce any monitoring. Renewals and purchase orders often replace the original agreement without these terms. Close the gap by checking each active contract for security obligations, incident notification timing, the right to receive assurance reports, and data deletion at exit, and by adding a remediation path to any contract that lacks them at renewal.

Assurance reports with no reliance decision

Filing a vendor's report does not show that anyone decided whether it was enough. Without a recorded decision, a report can be read as covering controls it never tested, such as the parts of the service you use, or it can be ignored entirely. Close the gap by recording, for each report, the services in scope, the exceptions it lists, the controls you must operate yourself, and who approved reliance on it.

Questions buyers ask about third-party assurance cost, effort and outsourcing

Can we run HITRUST third-party assurance in-house without a consultant?

Yes, your team can prepare the evidence in-house, but the validated assessment itself must be performed by an Authorized HITRUST External Assessor organization, and HITRUST performs central quality assurance before it issues reports. A consultant is optional. The work that stays with your organization is owning the vendor inventory, contracts, service level reviews and monitoring records, because the control owners must be your people. Before you start, ask any consultant to list the tasks they will perform and the tasks your staff keep. That list is the clearest way to compare effort across proposals.

How long is the HITRUST fieldwork window for third-party assurance?

Under the HITRUST Assessment Handbook v1.1, the assessor's validated assessment fieldwork window is at most 90 days for e1, i1 and r2 assessments. Fieldwork is the assessor's testing period, so it does not include the preparation you do beforehand. Most schedule risk sits in that preparation, especially for vendor records that are incomplete or out of date. Once certified, an e1 or i1 lasts one year and an r2 lasts two years, with an r2 interim assessment due in the 90 days before the first anniversary. Confirm the full schedule with your assessor in writing.

What does third-party assurance require from our staff week to week?

The ongoing effort falls on a few recurring tasks:

Keeping a current inventory of vendors and service providers that handle in-scope data, with a named owner for each.
Maintaining contracts that set security expectations and reporting duties for each provider.
Collecting and reviewing vendor assurance reports and exceptions as they arrive.
Reviewing service level agreements against monitoring records at least annually, which is the requirement HITRUST's 2025 Trust Report ranks as the most frequent corrective action plan in 2024.

Smaller teams often underestimate the last item, so build it into a calendar with named reviewers before the assessment begins.

What drives the cost of third-party assurance up or down?

Cost depends on what you must pay for and how much work the scope creates, so no single number applies to every organization. The main drivers are the number of vendors that touch in-scope data, the state of your existing contracts and monitoring records, whether you add the AI security certification (which places requirement statements in this domain), and how much r2 tailoring you request. Assessor fees, readiness support and any internal staff time are separate lines. Ask for a written quote that separates one-time work, such as the initial gap review and contract updates, from recurring work, such as annual reviews and monitoring, and that names the assessor's fee separately.

Which parts of third-party assurance work can an implementation partner take on?

An implementation partner can prepare systems, controls and evidence for an assessment. DeployOpen, for example, plans, implements, documents and supports self-hosted open-source platforms in your own infrastructure, and it prepares evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and it does not decide vendor risk for your organization. Suitable outsourced work includes configuring a vendor register, building evidence collection workflows and writing the supporting documentation. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, so ask for that document before signing.

Can open-source tools produce evidence for third-party assurance controls?

Open-source governance tools can organize much of the evidence. CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and it runs audits and compliance assessments with automatic mapping between frameworks. Confirm whether its current framework library covers the HITRUST requirement statements you need before you rely on it, because a framework listing does not show that a control has been tested. The tool records and tracks evidence. It does not replace the assessor's testing or the HITRUST submission.

How strictly does HITRUST score the third-party assurance domain?

Scoring depends on the assessment type. The e1 and i1 require the core requirement statements in each domain to average at least 83, while the r2 requires each domain to average at least 62 across all its requirement statements, according to the Assessment Handbook v1.1. Third-Party Assurance is also the domain where many organizations stumble, because the 2025 Trust Report ranks its annual service level review requirement as the most frequent corrective action plan in 2024. Ask your assessor or readiness provider for a gap review of this domain before fieldwork begins, and treat the result as a list of records to produce, not a score to hope for.

Does a cloud provider's HITRUST result cover our own vendor oversight?

No. In HITRUST's Oracle Cloud Infrastructure inheritance example, Third-Party Assurance is not inheritable. The customer reviews its providers' compliance reports and manages assurance over its own vendors. A provider's certification can supply evidence for controls that the provider runs, but your organization still has to decide which vendors handle in-scope data, collect their reports, and monitor them. Read the shared responsibility matrix for each provider to confirm where your obligations begin, and plan the vendor oversight work separately from any inheritance you claim.

How DeployOpen prepares third-party assurance evidence

DeployOpen works on 14 Third-party Assurance as an implementation partner. We prepare the systems, vendor records and evidence your organization needs, while your organization owns its vendor decisions and only an Authorized HITRUST External Assessor can issue a validated assessment result.

How we scope

Agree in writing which third parties handle in-scope data and which service level and monitoring records they must supply.
Define which 14 Third-party Assurance requirement statements apply to your e1, i1 or r2 scope, including any AI security statements.
Confirm with your assessor and your own vendor register where inheritance is not possible and provider reviews stay with you.

How we build

Set up a vendor inventory and review cadence that records each provider's contract terms, service levels and monitoring results.
Build the recurring annual review of service level agreements against monitoring records, the requirement most often raised as a corrective action plan in 2024.
Integrate vendor reviews with your risk management and access control processes so evidence is produced as work happens, not reconstructed later.

How we hand over

Deliver written procedures, review templates, evidence indexes and a gap list mapped to each third-party requirement statement in scope.
Document ownership, review dates and open items so your team can run the process after handover without outside help.
Provide a walkthrough so your assessor can trace each third-party requirement to its supporting records during fieldwork.

How we support

Support is available as a retainer for periodic vendor reviews, evidence refreshes and updates when the CSF version or your provider list changes.
Retainers can cover upgrades and continuous testing of the systems that exchange data with third parties, under a written scope.
Ask us to confirm in writing what a retainer includes, how changes to scope are priced and how ongoing evidence will be reviewed.