The CIO and the CISO. Closing the Operational Divide on Vendor Risk.

Most healthcare vendor risk issues start with split ownership, not bad intent.

I’d sum it up this way: if you want fewer vendor delays, fewer late exceptions, and fewer gaps around PHI and patient care, the CIO and CISO need one intake path, one set of approval rules, one evidence trail, and one review rhythm. That matters because in 2025, HHS OCR logged 795 large breaches, affecting about 140 million people, and business associates were tied to 35.1% of reports. On top of that, third parties were linked to about 34% of healthcare breaches.

Here’s the core of the article in plain English:

• The main problem is split ownership, which often complicates HIPAA-compliant vendor risk management. IT, security, procurement, legal, and clinical teams often move at different speeds.
• Healthcare risk is higher. A vendor failure can affect PHI, care delivery, revenue, and patient outcomes.
• The fix is shared governance. I’d set clear decision rights before intake starts, with both the CIO and CISO approving high-risk go-lives.
• Intake should route vendors by risk. PHI access, clinical links, privileged access, and patient-care impact should decide the review path.
• Assessments need the same core evidence each time. That keeps reviews consistent and cuts rework.
• Findings need owners and due dates. If an issue stays open, there should be a written exception with an end date.
• Contracts must lock in security terms before go-live. That includes the BAA, breach notice timing, MFA, encryption, patch SLAs, and audit rights.
• Monitoring cannot stop after onboarding. Monthly reviews for high-risk vendors and quarterly portfolio reviews help teams spot changes early.

A fast way to look at it:

Bottom line: vendor risk works better when it runs as a shared business process, not a string of handoffs.

Build a shared CIO-CISO governance model

A governance model only works if the CIO and CISO know who owns what before vendor intake starts. If that doesn't happen, vendor review turns into a messy handoff chain. The fix is a shared operating model with named owners, clear thresholds, and a set escalation path.

That setup turns vendor review into a defined operating process instead of a string of last-minute decisions.

Assign decision-rights before vendor intake begins

A RACI matrix (Responsible, Accountable, Consulted, Informed) is the most practical way to map ownership ^[2]:

This table keeps things plain. The CIO owns operational fit and integration readiness. The CISO owns risk, security review, and contract security terms. Some decisions, though, should stay shared.

For vendors that handle PHI or support clinical or revenue-cycle operations, go-live should require approval from both the CIO and CISO.

Agree on a joint risk appetite and escalation path

Risk appetite stops being a theory when a late-stage review puts a launch date on the line. That's when teams find out whether their rules are clear or just sitting in a slide deck.

CIO and CISO leaders should set concrete thresholds by vendor tier. Tier 1 vendors that support EHR access, medication management, or clinical decision support should have zero tolerance for missing MFA, unencrypted PHI, or unpatched critical vulnerabilities unless documented compensating controls are in place. Tier 2 vendors tied to revenue-cycle operations should put more weight on data integrity, uptime, and fraud exposure. Tier 3 low-risk utilities can follow a lighter baseline.

The escalation path needs that same level of detail. Any critical finding on a Tier 1 vendor should trigger acknowledgment within 4 hours and a resolution plan within 72 hours. If the issue is still open, escalation should move from IT and security leads to the CIO and CISO. If patient safety or revenue continuity is at risk, it should move next to the COO, CMO, or CFO.

Those thresholds shouldn't live in someone's head or get dug up from old email threads. They should sit in incident response playbooks and vendor management policies where people can find and use them.

Use one system of record for workflows and evidence

Disconnected tools make ownership fuzzy. Email chains, shared drives, and side spreadsheets might seem fine at first, but they usually lead to missed approvals, stale evidence, and finger-pointing when something slips.

Censinet RiskOps centralizes assessments, findings, approvals, and evidence, including SOC 2 reports and contracts with security clauses. Shared dashboards show findings, due dates, and approvals, so decision-rights are enforced by the system itself instead of being tracked by hand.

When ownership, thresholds, and evidence live in one place, vendor intake can be routed by criticality, access, and data sensitivity.

sbb-itb-535baee

Standardize vendor intake and risk assessment

Once ownership is clear, standardize third-party vendor risk management so every vendor goes through the same review path. When decision rights are set, intake becomes the main control point for speed and consistency.

Route vendors by criticality, access, and data sensitivity

The intake form should do more than gather information. It should route the vendor. Ask only for the details that determine risk: PHI access, EHR or clinical connectivity, privileged access, remote access, offshore support, criticality, and patient-care impact. Those answers should set the review path, not the requester's opinion.

A vendor that touches PHI or clinical systems should never move through the same path as a low-risk administrative tool.

According to Ponemon Institute research, an average of 43% of the roughly 1,950 third parties used by healthcare organizations have access to PHI, yet only 40% of organizations always complete a risk assessment before contracting ^[5]. That gap is exactly what a standardized intake process is meant to close.

This also means accounting for concentration risk: whether multiple departments depend on the same vendor. If one supplier supports half the organization, a failure can hit far harder than a niche tool used by a single team. That routing discipline helps keep high-risk vendors from slipping into a low-friction path by mistake.

Use a standard assessment package for every risk tier

Don't send every vendor the same long questionnaire. Instead, make sure each tier starts from the same evidence framework. High-risk vendors should get the full package: a detailed questionnaire, data-flow diagrams, security policies, certifications such as SOC 2 or HITRUST, a recent penetration-test summary, incident response history, and key subprocessor disclosures. Medium- and low-risk vendors should get a shorter version of that same framework.

For vendors that handle PHI or connect to clinical systems, the package should ask direct questions about how data is encrypted in transit and at rest, whether encryption keys are customer-managed, how audit logs are retained, and how fast the vendor can detect and report a breach. These are baseline checks for any vendor that touches patient data.

When vendors answer the same core questions and submit the same types of evidence, reviewers can focus on gaps and exceptions instead of rebuilding the review from scratch each time.

Speed up reviews without removing human oversight

Automation should ingest evidence, prefill responses, flag gaps, and route cases by tier. Tools such as Censinet AI are built around this model, where automation speeds up evidence collection and questionnaire processing while keeping analyst review in place for risk judgments and approval.

In practice, automation should handle the repetitive work, while analysts handle architecture fit, compensating controls, and residual-risk approval for go-live decisions tied to vendors that affect care delivery or PHI. Standardization is what makes automation useful. It cuts manual work without watering down the review.

Coordinate remediation, approvals, and contract controls

An assessment by itself doesn't solve much. The work starts after the review ends, when teams have to close findings fast enough to keep the vendor on track. Security confirms risk. IT fixes technical gaps. Procurement puts teeth into the terms. And both leaders sign off on exceptions. That's where shared ownership turns into actual execution.

Track findings with named owners and due dates

Put every finding into one remediation register that IT, security, procurement, legal, and the business owner can all see. For each item, include the vendor, service criticality, data types, severity, business impact, compensating controls, named owner, due date, closure evidence, and approval checkpoint.

Each finding should have one named owner. If the vendor has to make the fix, the vendor owns it. If the work is internal, then IT, security, procurement, or legal owns that specific action.

It also helps to sort findings into clear buckets:

• Go-live blockers
• Conditional items
• Next-cycle items

Not every finding deserves the same level of urgency.

Handle exceptions through defined approval levels

If remediation won't be done before go-live, require a written exception. That record should include the finding, business justification, compensating controls, residual risk, approver, and expiration date.

Low-risk exceptions can stay with the operating team. Medium-risk exceptions need CIO-CISO review. High-risk exceptions, especially ones tied to regulated data, patient-facing operations, or business continuity, should move up to executive leadership or a formal risk committee.

Temporary exceptions need a fixed end date. If the issue is still open then, it should go back for approval at a higher authority level. No automatic extensions.

Lock security requirements into the contract before go-live

Contract terms are what turn remediation into something enforceable. Put those terms in place before go-live. Without contract language, findings may be documented, but they aren't actionable. ^[10]

For PHI vendors, require a BAA along with a security addendum or data protection agreement that covers audit rights, MFA, encryption, patch SLAs, cyber insurance, and breach notification timelines. ^[6][9][11] HIPAA requires breach notification without unreasonable delay and no later than 60 days after discovery ^[8], but contracts should push vendors to notify the organization within 24 to 72 hours of a suspected incident so internal response teams have time to act. ^[7] If the vendor can't meet that requirement, go-live stays blocked.

Use renewal as a control point too. High-risk vendor renewals should require updated attestations, current insurance evidence, a fresh risk review, and closure of any open exceptions.

Run continuous monitoring with a joint operating cadence

Once remediation and contract terms are in place, monitoring shows whether a vendor is still operating inside the risk limits you approved. That matters more than ever in healthcare. Third-party vendors were involved in about 35% of healthcare breaches in 2023, and third-party-related breaches climbed from 74 incidents in 2018 to 254 in 2023.^[4][1] In plain English: post-go-live monitoring isn't a nice extra. It's part of day-to-day operations.

Watch for changes that raise vendor risk after onboarding

The biggest warning signs often look small at first.

A vendor may quietly add an AI analytics subprocessor that handles de-identified but still re-identifiable data. It may move PHI processing to a new cloud region. Or it may let an SSL/TLS certificate expire. None of those changes waits for your next scheduled review, but each one can shift your risk position fast.

CIO and CISO teams should keep a shared change watchlist that tracks:

• updated attestations
• certificate expirations
• security incidents
• SLA breaches
• ownership changes
• hosting migrations
• new subprocessors
• expanded access or data scope

When a threshold is crossed, action should follow right away. If a critical vendor adds a new subprocessor or moves PHI processing to a new cloud region, that should trigger an third-party risk assessment instead of sitting in the queue until the next review window.^{[12][13][14][15]}

Review shared dashboards on a fixed cadence

That watchlist should feed a shared dashboard and a set review schedule. A joint operating rhythm helps both teams work from the same dashboard and the same change log, instead of comparing notes after the fact.

Run monthly reviews for high- and critical-risk vendors, and quarterly reviews for the full portfolio. Monthly meetings should stay focused on open findings, new incidents, SLA performance, and upcoming go-lives. Quarterly reviews should look at portfolio trends, revisit risk tiers, and support renewal or exit calls.^[12][3][13]

The dashboard itself should show the items that shape decisions:

• open findings by severity
• overdue remediation counts
• exception aging in days
• critical-vendor status changes
• renewals due within 90–180 days
• named owners for each item

If a vendor is up for renewal and still has open high-severity findings or aging exceptions, flag it early for an accelerated review before anyone signs the contract.

The table below sums up the trade-offs between the two approaches:

Conclusion: A shared operating model makes vendor risk an execution discipline

A recurring cadence keeps IT and security aligned on live vendor risk and helps teams catch issues before they disrupt patient care or expose PHI.^[12][3][13]

FAQs

How do we decide vendor risk tiers?

Start with a complete vendor inventory. Then map each vendor to the business processes, clinical services, and technology systems it supports.

Next, assign tiers based on each vendor’s access to PHI or non-public personal information, effect on patient safety and revenue, network connectivity, and how much the organization depends on the service. Use shared labels like Critical, High, Moderate, and Low so teams are speaking the same language. Any vendor that handles PHI should never sit in the lowest tier.

Who approves high-risk vendor go-lives?

A cross-functional Third-Party Risk Management (TPRM) committee signs off on high-risk vendor go-lives. This group usually brings together leaders from security, privacy, compliance, and clinical teams.

The committee can approve a go-live, grant conditional approval with a remediation plan, or stop it from moving forward. Clear decision rights and documented governance keep human oversight at the center of the final call.

What should trigger a vendor reassessment?

A vendor reassessment should happen on a set schedule and when risk signals show up.

Review high-risk vendors quarterly. Review lower-risk vendors annually.

You should also reassess a vendor when monitoring flags threats or when the vendor’s risk profile changes. Common triggers include:

• infrastructure shifts
• new subcontractors
• ownership changes
• compliance lapses
• contract renewal
• major service scope changes

This way, reassessments aren't just calendar-based. They also reflect what's happening with the vendor in real time.

Related Blog Posts

• Building Vendor Risk Frameworks for Healthcare IT
• Third-Party Risk Management vs. Vendor Management: What Healthcare Leaders Need to Know
• Insurance and Benefits Administration Vendor Risk for Healthcare Organizations
• Best Practices for Vendor Risk Management in HDOs