Vendor Risk Assessment

HICP Practice 10.1 requires you to conduct cybersecurity risk assessments for third-party vendors and business partners that access, process, or store PHI, and to base onboarding and ongoing oversight on the risk they introduce. Operationally, you need a complete PHI third-party inventory, a tiering model, standardized assessments, and documented risk decisions with follow-up remediation. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Key takeaways:

• Scope is PHI-driven: if a third party touches PHI, assess its cybersecurity risk before (and during) the relationship. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• Exams look for proof: inventory, completed assessments, risk ratings, tracked remediation, and documented exceptions. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• Standardize decisions: tier vendors, map required evidence to tiers, and enforce contract/security requirements based on the tier. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

“Vendor risk assessment requirement” becomes straightforward once you anchor it to PHI. HICP Practice 10.1 focuses your program on third parties (vendors and business partners) that access, process, or store protected health information, and expects you to evaluate their cybersecurity posture, incident history, and relevant compliance certifications. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing this is to translate the requirement into three auditable motions: (1) know which third parties touch PHI, (2) assess them consistently before data access is granted and on a defined cadence thereafter, and (3) act on results through remediation, contractual controls, or a documented risk acceptance. The assessment itself is only half the control. The “so what” is where programs fail: no follow-up, unclear approval thresholds, or exceptions made in email with no retained rationale.

This page gives you requirement-level guidance you can put into a playbook immediately: who is in scope, how to run the workflow end to end, what evidence to retain, and what auditors commonly challenge.

Regulatory text

Requirement (HICP Practice 10.1): “Conduct cybersecurity risk assessments of third-party vendors and business partners who access, process, or store PHI.” (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

What the operator must do

You must identify every third party that touches PHI and perform a cybersecurity risk assessment that evaluates, at minimum, security posture, incident history, and compliance certifications. Then you must use the results to drive onboarding decisions and ongoing oversight. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Plain-English interpretation (what this means in practice)

If an outside entity can see PHI, handle PHI, or host PHI, you are responsible for understanding the cybersecurity risk they introduce and managing it before PHI exposure occurs. “Assessment” does not mean “collect a questionnaire and file it.” It means you gather evidence, assign a risk rating you can defend, require fixes where needed, and document why access to PHI is allowed (or not allowed).

A practical way to interpret HICP 10.1 is: no PHI access without an initial assessment and a risk decision, and no long-lived PHI relationship without reassessment and tracked remediation. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Who it applies to (entities and operational context)

Entity types in scope:

• Healthcare organizations (providers, payers, clearinghouses, and healthcare delivery networks)
• Health IT vendors (including those operating platforms or services used in clinical/admin workflows) (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Third parties in scope (operational triggers): Include any vendor or business partner that:

• Accesses PHI (support staff with admin access, call centers, outsourced billing)
• Processes PHI (claims processing, analytics, transcription)
• Stores PHI (hosting, backup, managed services, EHR modules, patient engagement tools) (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Common “missed scope” examples:

• IT managed service providers with domain admin access to systems containing PHI
• SaaS tools that receive exports containing PHI “temporarily”
• Subprocessors used by a primary vendor (you still need visibility and control via contracting and assessment requirements)

What you actually need to do (step-by-step)

Use this as your minimum viable operating procedure.

Step 1: Build the PHI third-party inventory (your system of record)

1. Pull vendor lists from AP/procurement, legal, IT, and business unit rosters.
2. Normalize into one register with: vendor name, service, data types, systems integrated, access method, business owner, contract status.
3. Add a PHI touchpoint flag: access/process/store PHI (yes/no/unknown).
4. Force closure on “unknown” entries by routing to the business owner.

Output: Third-party inventory with PHI classification and accountable owners.

Step 2: Tier third parties by inherent risk (before you assess controls)

Create a tier model tied to exposure, not spend. A workable model uses factors such as:

• PHI volume/sensitivity and whether it includes special categories (clinical notes, images, etc.)
• Privileged access to environments that contain PHI
• Internet-facing connectivity or API integrations into core systems
• Criticality to patient care operations (downtime impact)

Output: Tiering rubric + tier assigned in the inventory.

Step 3: Define assessment standards per tier (questionnaire + evidence map)

HICP calls out areas to evaluate: security posture, incident history, and compliance certifications. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Turn that into a tiered evidence list:

• Security posture: security policy set, vulnerability management approach, patching expectations, access control/MFA, logging/monitoring, encryption, secure SDLC where relevant
• Incident history: prior security incidents, ransomware events, notification practices, lessons learned, customer communications approach
• Compliance certifications: relevant third-party attestations or certifications the vendor can provide (document what is acceptable for your tiers)

Be explicit about what “good enough” looks like for each tier. Otherwise, every review becomes a debate.

Output: Assessment template(s) and evidence requirements by tier.

Step 4: Run intake and complete the initial risk assessment before PHI access

1. Intake request goes through a single path (procurement or GRC intake).
2. Confirm PHI scope and tier.
3. Send the assessment package; collect evidence.
4. Review responses with an analyst checklist; follow up on gaps.
5. Assign a risk rating and decide:
   • Approve
   • Approve with conditions (required remediation, timeline, compensating controls)
   • Reject / delay until controls are in place
6. Record the decision, approver, and rationale in the third-party record.

Operational guardrail: do not allow production credentials, VPN, SSO, API keys, or data feeds until the risk decision is recorded.

Step 5: Contract and control alignment (make the assessment enforceable)

Your assessment only matters if the contract supports it. Ensure your process ties to:

• Security requirements exhibit
• Right-to-audit or right-to-assess language
• Breach/incident notification expectations
• Subprocessor controls and flow-down requirements
• Data return/destruction terms at termination

Output: Contract addendum templates and a clause checklist aligned to tiers.

Step 6: Remediation tracking and exception management

1. Convert assessment gaps into a remediation plan with owner and due date.
2. Track evidence of closure (screenshots, policy updates, attestations, test results).
3. If you accept risk, document:
   • specific gap(s)
   • compensating controls
   • why acceptance is reasonable
   • expiration date for re-review

Auditors care that exceptions are controlled, time-bound, and approved at the right level.

Step 7: Ongoing monitoring and reassessment

Set a reassessment cadence by tier and trigger reassessments on events:

• material service change, new integration, expanded PHI scope
• vendor-reported security incident
• significant control degradation discovered in monitoring

Practical monitoring signals: renewal cycles, security questionnaires refresh, updated certifications, or attestations from the vendor.

Step 8: Management reporting (prove governance)

Build a monthly or quarterly dashboard:

• number of PHI third parties by tier
• assessment completion status
• overdue remediations
• open exceptions and upcoming expirations
• high-risk vendors with action plans

This helps you demonstrate oversight without drowning in detail.

Required evidence and artifacts to retain

Keep artifacts in a retrievable system (GRC tool, shared repository with access controls, or Daydream if you want workflow + evidence capture in one place). Aim for “one click from vendor record to proof.”

Minimum evidence set:

• Third-party inventory with PHI scope and tier
• Completed assessment (questionnaire + reviewer notes)
• Evidence package received (policies, attestations, architecture summaries, etc.)
• Risk rating and documented decision (approve/conditional/reject)
• Remediation plan and closure evidence
• Exception/risk acceptance memos with approvals
• Contract/security addendum and any required clauses
• Reassessment records and monitoring notes

Common exam/audit questions and hangups

Expect questions like:

• “Show me all third parties that store PHI and their last assessment date.”
• “How do you know you didn’t miss a PHI vendor?”
• “Who can approve a high-risk vendor, and where is that documented?”
• “Show remediation evidence for these gaps you identified.”
• “How do you handle subcontractors/subprocessors?”

Hangups that stall reviews:

• Inventory does not reconcile to AP/procurement, so the population is not defensible.
• Assessments exist, but risk decisions are missing or inconsistent.
• Exceptions are granted informally and never revisited.

Frequent implementation mistakes (and how to avoid them)

1. Treating spend as risk. A low-cost SaaS app can still be high PHI risk. Use data access and privilege to tier.
2. One-size-fits-all questionnaires. Teams either over-assess low-risk vendors or under-assess high-risk ones. Fix this with tier-based requirements.
3. No gating. If IT can grant access before GRC signs off, your process becomes optional. Add access gates tied to ticketing/SSO/provisioning.
4. Collecting evidence you never review. Use a reviewer checklist mapped to your risk rubric; require documented analysis notes.
5. Ignoring incident history. HICP explicitly calls for it. Ask targeted questions and document the outcome. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
6. Letting remediation die in email. Track it like any other risk treatment plan with owners and closure evidence.

Risk implications (why this requirement matters operationally)

Third parties expand your attack surface and often become the easiest path to PHI exposure: remote access, shared credentials, weak vendor security programs, or opaque subcontracting. HICP’s emphasis on vendors that access/process/store PHI targets the real failure mode: PHI moves outside your perimeter, and your controls do not follow it. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

A disciplined vendor risk assessment program reduces the chance that PHI is placed with an unfit provider, and it gives you defensible documentation if an incident occurs and regulators ask what diligence you performed.

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Stand up a single PHI vendor intake channel and stop “side-door” onboarding.
• Produce a draft third-party inventory from procurement/AP and identify PHI-touching candidates.
• Publish a simple tiering rubric and assign preliminary tiers.
• Create a baseline assessment template that covers security posture, incident history, and compliance certifications. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Days 31–60 (Operationalize and start clearing the backlog)

• Run assessments for the highest-risk PHI vendors first (privileged access, hosting, managed services).
• Implement a documented approval workflow and risk acceptance format.
• Add a contract clause checklist and security addendum for new/renewing high-risk vendors.
• Start remediation tracking with owners and due dates in a central log.

Days 61–90 (Scale and prove governance)

• Expand assessments to remaining PHI vendors and close “unknown” PHI scope items in the inventory.
• Build recurring reporting for leadership: completion status, exceptions, remediation progress.
• Define reassessment triggers (service changes, incidents, scope expansions) and embed them in change management.
• If tooling is a constraint, configure Daydream to centralize intake, evidence collection, approval routing, and exception tracking so audit requests do not become a manual scavenger hunt.

Frequently Asked Questions

Do we have to assess every vendor, or only vendors that touch PHI?

HICP Practice 10.1 is scoped to third-party vendors and business partners that access, process, or store PHI. Build your inventory broadly, then apply this requirement to the PHI population. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

What counts as an acceptable “cybersecurity risk assessment”?

An assessment is acceptable if it evaluates security posture, incident history, and compliance certifications, and produces a documented risk rating and decision. A questionnaire alone is weak unless you review evidence and track remediation. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

How do we handle vendors that refuse to share evidence?

Treat refusal as a risk signal. Escalate to the business owner, require contract terms that allow assessment, and either apply compensating controls or decline PHI scope until due diligence is satisfied.

What about subcontractors or cloud subprocessors used by our vendor?

Capture them through contracting: require disclosure, flow-down security obligations, and notification of changes. Your assessment should include how the vendor governs its own third parties where PHI is involved.

Can we accept a vendor’s compliance certification instead of doing our own assessment?

Certifications can be strong supporting evidence, but you still need an internal risk decision tied to your PHI use case and access model. Document what the certification covers and any gaps relative to your requirements. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Who should approve a high-risk PHI vendor?

Set approval authority based on tier and residual risk. High-risk PHI access should require sign-off beyond the requester, typically involving Security/GRC and an accountable executive, with the rationale retained.