
Last reviewed: June 2026 Â |Â Reading time: 18 minutes
Healthcare vendor risk management is how a health system, payer, pharmaceutical company or health-tech firm assesses, tiers, contracts and monitors a single external vendor against the obligations that attach to it: HIPAA and HITECH (Protected Health Information and the mandatory Business Associate Agreement), FDA 21 CFR (medical device and pharmaceutical supplier qualification), ESG and Modern Slavery duties for clinical supply chains, and the 2025 HIPAA Security Rule NPRM (90 FR 800) with its 240-day compliance window. It determines how deeply to investigate a vendor before patient data or clinical operations depend on it.
Most healthcare vendor risk programmes were built to satisfy cybersecurity auditors. They send an annual questionnaire, collect a SOC 2 report and file it. That approach was inadequate before February 2024. After Change Healthcare, it’s indefensible.
The core problem is definitional. Healthcare organisations treat vendor risk as a cybersecurity sub-function, so their programmes find cybersecurity gaps. They were not designed to find financial distress in a revenue cycle operator, beneficial ownership opacity in a medical device distributor, labour practice violations in a pharmaceutical API manufacturer, or regulatory actions pending against a health IT vendor in a jurisdiction the questionnaire never asked about. These are the risks that produce serious incidents.
Standard TPRM frameworks built for financial services don’t map onto healthcare’s regulatory overlay. The average hospital works with more than 1,000 vendors simultaneously, according to HIPAA Journal (2026). Each one is a potential exposure point across multiple regulatory domains at once.
This guide covers the vendor-level discipline: what obligations attach to one vendor, how to tier and assess it, and what a questionnaire structurally cannot find. If you’re designing the wider programme, including governance, the full lifecycle, and board reporting, see the healthcare TPRM programme guide. For the discipline across all sectors, the complete TPRM guide and TPRM framework are the starting points.
General third-party risk management addresses cybersecurity, operational performance and commercial continuity. Healthcare vendor risk management carries those plus four layers no other sector shares at this complexity:
Key takeaways
Healthcare vendor risk management sits under five concurrent regulatory frameworks. HIPAA and HITECH govern PHI handling and impose mandatory BAA requirements. FDA 21 CFR governs medical device and pharmaceutical supplier qualification. ESG and Modern Slavery legislation impose supply chain due diligence duties. CMS Conditions of Participation set patient safety expectations. And the 2025 HIPAA Security Rule NPRM introduces new vendor oversight requirements with a 240-day compliance window once finalised.
The complexity isn’t that any single framework is difficult. All five apply at once, each with its own assessment criteria, documentation requirements and penalty structure. A programme that satisfies HIPAA doesn’t automatically satisfy FDA requirements for a medical device supplier. Both must be addressed, and they require different due diligence evidence.
The HITECH Act of 2009 extended HIPAA obligations directly to Business Associates and their sub-contractors, making fourth-party PHI exposure a statutory compliance requirement. HHS OCR enforcement records show that inadequate Business Associate due diligence is a standalone basis for action, independent of whether a breach occurred. Penalties reach $1.9 million per violation category per year.
UK healthcare organisations with annual turnover above ÂŁ36 million carry reporting obligations under the Modern Slavery Act 2015, requiring active due diligence on supplier labour practices. The Care Quality Commission (CQC) adds its own oversight expectations for registered providers.
| Framework | Applies to | Core vendor obligation | Penalty for failure |
|---|---|---|---|
| HIPAA Privacy Rule | All covered entities and BAs | BAA required before any PHI sharing; permitted uses defined specifically | Up to $50,000 per violation; $1.9m annual cap per category |
| HIPAA Security Rule | All covered entities and BAs | Administrative, physical and technical safeguards verified at all ePHI-handling vendors | Same as Privacy Rule |
| HITECH Act | BAs and their sub-contractors | HIPAA obligations flow to sub-contractors; strengthened enforcement and direct liability | Up to $1.9m per violation category per year |
| FDA 21 CFR Part 820 | Medical device manufacturers | Supplier qualification, quality agreements, incoming inspection, periodic audits | Warning letters, consent decrees, product recalls, criminal prosecution |
| CMS Conditions of Participation | Medicare and Medicaid providers | Patient safety and information governance requirements influence vendor selection | Loss of Medicare and Medicaid certification |
| Modern Slavery Act 2015 | UK organisations with ÂŁ36m+ turnover | Annual supply chain transparency statement; active due diligence on supplier labour practices | Court injunctions; reputational consequences; public registry non-compliance |
Five regulatory frameworks apply concurrently in healthcare vendor management. Satisfying one doesn’t satisfy the others. The 2025 HIPAA Security Rule NPRM adds binding requirements once finalised, covered in the next section.
On January 6, 2025, HHS published a Notice of Proposed Rulemaking at 90 FR 800, the most significant overhaul of the HIPAA Security Rule in over 20 years. Once finalised, covered entities and business associates have 240 days to comply.
Key changes: mandatory MFA, encryption of ePHI at rest and in transit, 24-hour breach notification, annual technology asset inventories, and tighter oversight of vendor security practices. The distinction between “required” and “addressable” safeguards is eliminated: all implementation specifications become mandatory.
This is the regulatory development that makes most existing healthcare vendor risk programmes immediately non-compliant once the rule finalises. HHS received over 4,000 public comments, with industry associations pushing back on implementation timelines. A final rule, possibly in modified form, is expected in 2026. HIPAA Journal tracks the rulemaking progress with current status updates.
Critical change: Under the proposed rule, business associates must report security incidents to covered entities within 24 hours of discovery. BAA templates that allow “without unreasonable delay” notification are likely non-compliant once the rule finalises. Review and update notification timelines now.
Mandatory MFA across all ePHI access points. The proposed rule requires multi-factor authentication on every system that stores, transmits or accesses ePHI, including EHR platforms, cloud services, medical devices and third-party vendor portals. Change Healthcare’s attackers used a legacy remote access portal with no MFA. That specific vulnerability becomes a documented regulatory violation under the proposed rule. Every Business Associate’s MFA enforcement must be independently verified.
Encryption of ePHI at rest and in transit. The “addressable” designation that let organisations defer encryption is removed. Encryption becomes a required safeguard at every Business Associate handling ePHI: cloud providers, EHR vendors, billing services and sub-contractors in the PHI access chain.
Annual technology asset inventories. Covered entities and business associates must maintain annually updated inventories of all technology assets with access to ePHI. For vendor risk programmes, this makes the vendor inventory a regulatory document rather than a risk-team spreadsheet.
Vendor security practice verification. The proposed rule requires annual compliance audits and tighter oversight of vendor security practices. Annual self-certification questionnaires are unlikely to satisfy this requirement. Independent verification of vendor controls moves from best practice to regulatory expectation.
Counterintuitive observation
The 2025 NPRM eliminates the “addressable vs. required” distinction that many small and mid-size healthcare organisations used to defer encryption, MFA and other technical controls. The organisations with the largest compliance gap are the ones that deliberately used “addressable” flexibility to avoid implementation costs. The rule doesn’t grandfather existing practice.
Track status at the Federal Register entry for 90 FR 800. The 240-day window starts from publication of the final rule.
The 240-day compliance window starts when the final rule publishes. Most healthcare vendor programmes run annual questionnaire cycles that won’t satisfy mandatory vendor oversight requirements under 90 FR 800.
Gap assessment delivered within 5 working days. No obligation to proceed.
What is a BAA? A Business Associate Agreement is the HIPAA-required contract between a covered entity and any vendor that creates, receives, maintains or transmits Protected Health Information. It must be signed before any PHI changes hands. A BAA is required before any PHI sharing: cloud and EHR providers, billing and revenue cycle operators, telehealth platforms, diagnostic labs and their sub-contractors all qualify. A BAA must contain eight mandatory provisions. A missing provision creates a direct compliance gap regardless of whether a breach has occurred.
A BAA records obligations. It doesn’t verify that the vendor is meeting them. HHS OCR has enforced against covered entities whose Business Associates failed, on the grounds that the oversight programme was inadequate, even where a valid BAA existed. The BAA is the contractual floor. Due diligence is the control that confirms it holds.
The sub-contractor gap. HITECH requires business associates to push HIPAA-equivalent obligations onto their own sub-contractors. Most BAAs contain this clause. Almost no covered entity verifies it operationally. Affected health systems had compliant BAAs with Change Healthcare; what they lacked was visibility into Change Healthcare’s own infrastructure sub-contractors. The 2025 NPRM is written to close exactly this gap.
For the full TPRM policy framework that governs BAA management, and for the questionnaire approach and its limitations in verifying BAA compliance, see the vendor due diligence questionnaire guide. The supply chain risk mapping method covers how to surface fourth-party dependencies.
A compliant BAA requires eight specific provisions. Missing any one creates a direct HIPAA compliance gap. The sub-contractor obligation clause is present in most BAAs but verified by almost no covered entity. This fourth-party gap was central to the Change Healthcare incident and is now a direct target of the 2025 NPRM.
FDA 21 CFR Part 820 (QMSR) requires medical device manufacturers to implement documented supplier qualification processes including evaluation criteria, approved supplier lists, incoming inspection, quality agreements and periodic audits. ISO 13485:2016 is the international equivalent and the standard due diligence threshold for health systems assessing device vendors. Connected devices additionally require MDS2 attestation and, per FDA’s 2023 cybersecurity guidance, a Software Bill of Materials (SBOM). These requirements are entirely separate from HIPAA and must be assessed independently.
Medical device vendor risk sits in a category most healthcare TPRM programmes treat as a cybersecurity problem. It’s not. FDA compliance status, active 483 observations, consent decrees and product recall history are the primary risk indicators for a medical device supplier. An annual cybersecurity questionnaire won’t find any of them.
A device manufacturer operating under an active FDA consent decree doesn’t just have a regulatory compliance problem. It’s a procurement risk for every health system using its products. The consent decree may restrict production, require third-party auditing and create supply continuity risk that a standard vendor questionnaire won’t disclose. Check FDA registration status, active 483 observations, Warning Letters, consent decree history and recall records independently at the FDA device databases.
Connected medical devices create simultaneous cybersecurity and clinical risk. Two specific assessment requirements apply only to this category and appear in almost no general TPRM framework:
MDS2 (Manufacturer Disclosure Statement for Medical Device Security). A standardised disclosure form covering cybersecurity capabilities, data handling practices and network connectivity requirements. Require a current MDS2 from every connected device vendor. An MDS2 older than 12 months on an actively deployed device is itself a risk indicator requiring escalation.
Software Bill of Materials (SBOM). FDA’s 2023 medical device cybersecurity guidance requires manufacturers to provide an SBOM: a complete inventory of every software component in the device. This lets health systems assess whether any component contains known vulnerabilities or incorporates software sourced from sanctioned entities. The SBOM requirement is now a standard pre-procurement assessment item for Tier 1 medical device vendors.
Pharmaceutical vendor risk has a supply chain dimension no questionnaire captures. Active Pharmaceutical Ingredient sourcing concentration, where a generic drug’s API comes from a single manufacturing region, creates supply disruption risk and potential sanctions exposure. The FDA Drug Shortages database consistently shows how concentration drives systemic supply vulnerability.
For UK organisations, the Modern Slavery Act 2015 reaches API manufacturers and contract research organisations in high-risk manufacturing regions. Use ESG due diligence for the labour-practice layer. See the supply chain risk management guide for the API sourcing assessment methodology.
Medical device vendors require FDA 21 CFR and ISO 13485 assessment alongside standard cybersecurity checks. Connected devices require MDS2 and SBOM. Pharmaceutical suppliers require API sourcing assessment and, for UK organisations, Modern Slavery Act verification. None of these sit inside a standard HIPAA questionnaire programme.
ESG obligations in healthcare vendor management include: Modern Slavery Act 2015 supply chain due diligence for UK organisations above ÂŁ36 million turnover; CSDDD and CSRD reporting obligations for EU-operating health systems; FCPA and UK Bribery Act exposure from vendor executive connections to public officials; sanctions screening for pharmaceutical and medical device component sourcing; and labour practice monitoring across clinical staffing agencies and pharmaceutical manufacturing supply chains. This is the most underserved category in healthcare TPRM and the one most likely to create regulatory and reputational exposure that questionnaire programmes cannot detect.
Section 54 of the Modern Slavery Act 2015 requires commercial organisations with annual turnover of ÂŁ36 million or more that supply goods or services in the UK to publish an annual transparency statement covering supply chain due diligence on labour practices. For NHS Trusts, private hospital groups, pharmaceutical manufacturers and large medical device distributors operating in the UK, this is a current legal obligation.
Clinical staffing agencies operating in high-risk recruitment regions, pharmaceutical contract manufacturers in jurisdictions with documented labour violations, and medical device component suppliers sourcing from conflict-affected areas all create potential Modern Slavery Act exposure. A signed supplier questionnaire asserting compliance is not sufficient evidence under the Act’s reasonable steps standard. Independent adverse media screening and supply chain investigation are required. See Neotas ESG due diligence services.
Healthcare procurement involves substantial government contract exposure for organisations supplying Medicare, Medicaid, NHS or other public healthcare systems. Vendor executive connections to public officials create direct FCPA and UK Bribery Act exposure for the purchasing organisation. A medical device distributor whose senior sales officer maintains an undisclosed relationship with a hospital procurement director is an FCPA risk for the health system. This category of risk is invisible to cybersecurity questionnaires and standard sanctions database checks. It requires investigation of vendor executive networks, beneficial ownership structures and third-party intermediary relationships. The financial crime compliance layer of healthcare vendor due diligence specifically addresses this exposure.
Pharmaceutical API sourcing from manufacturers in sanctioned jurisdictions, medical device component procurement from entities connected to sanctioned parties, and healthcare SaaS platforms owned through corporate structures that include sanctioned individuals all create OFAC and UK sanctions exposure. Standard vendor database checks run against the vendor’s registered corporate identity. They don’t investigate the vendor’s sub-contractor networks, component suppliers or beneficial ownership chains. Detecting this requires beneficial ownership analysis and supply chain mapping. It can’t be achieved through questionnaire self-certification.
ESG healthcare vendor risk: what to assess
Modern Slavery Act compliance across clinical staffing and pharmaceutical manufacturing. FCPA/UK Bribery Act exposure from vendor executive government connections. Sanctions proximity screening for pharmaceutical API and medical device component sourcing. CSDDD/CSRD supply chain reporting obligations for EU-active health systems. Labour practice violations in contract research organisations. Conflict mineral exposure in medical device component supply chains.
ESG obligations in healthcare vendor management are not aspirational commitments. Modern Slavery Act duties, FCPA exposure from vendor executive connections and sanctions screening for pharmaceutical supply chains are current legal obligations. No questionnaire-based programme detects these risks adequately. Intelligence-led OSINT investigation is the only effective control.
Healthcare organisations work with a wider range of vendor types than almost any other sector. Each carries a distinct regulatory obligation, primary risk domain and due diligence requirement. Treating all vendors identically is the most common structural failure in healthcare vendor risk management programmes. Tier by five criteria together: PHI access, BAA requirement, clinical criticality, FDA category and ESG exposure.
| Vendor type | Risk tier | Primary regulatory obligation | ESG/integrity flag | Primary failure risk |
|---|---|---|---|---|
| EHR and clinical software | Critical | HIPAA BAA, SOC 2, NIST CSF, 2025 NPRM MFA/encryption | Beneficial ownership; executive integrity | Mass PHI exposure; clinical operations disruption |
| Medical device manufacturers | Critical | FDA 21 CFR Part 820, ISO 13485, MDS2, SBOM, HIPAA BAA if connected | Component sourcing sanctions; conflict mineral exposure | Patient safety event; data breach via networked devices |
| Cloud and SaaS providers | Critical | HIPAA BAA, SOC 2 Type II, ISO 27001, 2025 NPRM encryption/MFA | Sub-contractor concentration; data residency | Data breach; operational downtime at scale |
| Revenue cycle and billing | High | HIPAA BAA, PCI DSS, concentration risk assessment | Financial distress signals; beneficial ownership | Financial fraud; PHI exposure; revenue cycle disruption |
| Diagnostic labs and imaging | High | HIPAA BAA, CLIA certification, accreditation status | Regulatory actions; accreditation lapse | Clinical error; PHI exposure |
| Telehealth platforms | High | HIPAA BAA, FTC Health Breach Notification Rule, 2025 NPRM | Adverse media; investor disclosure obligations | Real-time patient data breach; care disruption |
| Pharmaceutical and API suppliers | High | FDA GMP 21 CFR Part 211, ICH Q10, Modern Slavery Act (UK), CSDDD (EU) | Labour violations; API sourcing concentration; sanctions proximity | Drug safety event; ESG violation; supply disruption |
No vendor that handles PHI should receive Standard-tier treatment. Critical vendors, including EHR providers, medical device manufacturers and cloud SaaS platforms, require full intelligence-led assessment across all risk domains. Pharmaceutical and API suppliers add ESG, sanctions and FDA GMP obligations that no cybersecurity questionnaire addresses. Use the vendor risk assessment template as the tiering documentation starting point.
Covers all vendor categories, HIPAA BAA mandatory provisions, FDA 21 CFR assessment criteria, ESG due diligence requirements, the five-point tiering model and the six-step assessment process. Used by compliance and procurement teams at health systems, pharmaceutical firms and health tech companies.
Immediate access. No sales call triggered on download.
This is the assessment you run on a specific vendor before onboarding and at each review cycle. For the full TPRM lifecycle across the whole portfolio, see the programme guide. For a single Critical (Tier 1) vendor, work through six checks in sequence.
Scope and BAA
Confirm whether the vendor handles PHI and, if so, that a BAA covering all eight provisions is signed before access begins. No BAA, no PHI access. No exceptions.
Cybersecurity evidence
SOC 2 Type II or ISO 27001, penetration test within 12 months, MFA enforcement, encryption and data residency. For connected devices, require current MDS2 and SBOM documentation.
Regulatory standing
HIPAA history, FDA status for device and pharma vendors, and any enforcement action in any jurisdiction the vendor operates in. Check independently, not via self-certification.
Financial stability and concentration
Audited financials, credit signals and how much of a critical function this one vendor represents. A revenue cycle operator in financial difficulty is a patient-care risk, not just a commercial one.
Adverse media and integrity
Screening across 200+ languages, beneficial ownership to the ultimate owner, PEP and sanctions proximity, executive connections. This is the check a questionnaire structurally cannot run.
Fourth-party mapping
Identify the sub-contractors and infrastructure the vendor depends on. Verify the HITECH flow-through actually happened, not just that the clause appears in the BAA.
Tier 2 vendors get checks 1, 2, 3 and a lighter version of 5. Tier 3 gets a questionnaire plus BAA verification. The depth that catches real incidents lives in checks 5 and 6, which is where OSINT-based screening does the work a questionnaire cannot. Document all six checks in your vendor risk assessment template and reference them in the TPRM policy.
Tier 1 due diligence covers all six checks for every Critical vendor. The most common failures are relying entirely on self-completed questionnaires at check 5, and not verifying that the HITECH sub-contractor obligation at check 6 was operationalised. The 2025 NPRM makes annual independent verification of vendor security controls a regulatory expectation, not a programme preference.
Vendor questionnaires surface what vendors are willing and able to disclose. They can’t detect adverse media in non-English press, beneficial ownership opacity in multi-layer corporate structures, financial distress before formal disclosure, regulatory actions in other jurisdictions, sub-contractor concentration risk, or executive-level integrity issues. In healthcare, these are precisely the risks most likely to produce serious incidents. Intelligence-led OSINT screening is the control that closes this gap.
Security researchers had raised concerns about Change Healthcare’s security architecture in the months before the February 2024 ransomware attack. The information was publicly available. An annual questionnaire cycle wouldn’t have captured it. A continuous monitoring programme with adverse media and security researcher disclosure scanning would have, per Dallas Fed research (2025).
Most affected health systems had BAAs in place and current security questionnaires on file before Change Healthcare. What they lacked was independent intelligence monitoring of a vendor whose questionnaire responses attested compliance while publicly available information told a different story. This is not a failure of questionnaire content. It’s a structural limitation of self-reporting as a risk management control.
Neotas is an intelligence-led third-party risk management provider, recognised in the Chartis FCC50 2026. Healthcare teams use Neotas for the vendor-level intelligence that questionnaires and security ratings can’t reach.
| Capability | Healthcare risk category addressed | What it gives you on a vendor |
|---|---|---|
| Intelligence-led vendor due diligence | All six risk domains | OSINT-led assessment covering cybersecurity, financial health, regulatory standing, adverse media, beneficial ownership and ESG indicators simultaneously |
| Adverse media screening | Reputational and adverse media risk | 200+ languages across traditional press, social media and emerging sources. Surfaces risks weeks before structured database updates. |
| Beneficial ownership analysis | Financial crime and sanctions risk | Multi-layer corporate structure investigation to identify sanctions exposure, PEP connections and undisclosed conflicts in vendor ownership chains |
| Financial distress monitoring | Financial stability and concentration risk | Early warning signals from payment behaviour, credit indicators, executive departure patterns and regulatory filings, months before formal disclosure |
| ESG and supply chain screening | ESG, Modern Slavery and FCPA risk | API sourcing assessment, labour practice violation screening, ABAC indicators and UK Modern Slavery Act compliance evidence across vendor supply chains |
| Continuous monitoring | All six categories, ongoing | Automated alerts for adverse media, sanctions changes, regulatory actions and financial health signals. Closes the annual-review gap the Change Healthcare incident and 2025 NPRM both require addressing. |
| Financial crime compliance integration | Regulatory and financial crime risk | Sanctions screening, PEP checks and AML indicators embedded in vendor due diligence. Relevant for pharmaceutical and medical device supply chains with complex international ownership structures. |
Supply chain risk caught before a pharmaceutical partnership contracted
A healthcare procurement team needed due diligence on a prospective pharmaceutical partner beyond standard database checks. OSINT screening surfaced adverse media, undisclosed regulatory actions and reputational risk indicators invisible to structured data sources. The engagement stopped a high-value partnership with a supplier operating under regulatory scrutiny in its home jurisdiction. Read the supply chain OSINT case study
Beneficial ownership analysis reveals sanctions proximity in a procurement counterparty
Standard corporate checks on a medical device procurement counterparty returned clean results. Neotas network analysis mapped undisclosed corporate relationships through three holding company layers and identified a beneficial owner with sanctions proximity, creating direct OFAC exposure for the procuring health system. A database-only screen wouldn’t have found it. Read the network analysis case study
ESG screening uncovers vendor supply chain exposure
A global healthcare organisation commissioned ESG risk screening on its vendor population. Labour practice violations and environmental breaches were identified in a Tier 2 supplier: the kind of sub-contractor visibility healthcare TPRM programmes must demonstrate under Modern Slavery Act and CSDDD obligations. Invisible to the vendor’s self-reported ESG questionnaire. Read the ESG supply chain case study
Third-party risk surfaced through OSINT that database checks missed entirely
A regulated healthcare organisation needed vendor due diligence beyond questionnaire-based assessment for a critical technology partner. Neotas OSINT screening surfaced adverse media, undisclosed corporate connections and reputational red flags that structured data sources had missed, including foreign-language press coverage and historical regulatory proceedings in two jurisdictions. Read the full TPRM OSINT case study
If a vendor handles PHI, runs a connected device or sits in your pharmaceutical chain, a questionnaire is the floor. Neotas runs intelligence-led assessments that surface adverse media, beneficial ownership, sanctions proximity and financial distress on the vendors that matter most. Findings on a critical vendor within 5 working days.
Request a vendor gap assessment
See the healthcare TPRM platform
Healthcare TPRM programme guide
How to govern, structure and run the full healthcare third-party risk management programme: lifecycle stages, the six risk categories, board reporting and regulatory governance. The companion to this vendor-level guide.
How Neotas delivers continuous, audit-ready vendor compliance across HIPAA, FDA, CQC and GDPR for health systems, pharmaceutical companies and health-tech firms in a single intelligence-led platform.
Enhanced due diligence services
The intelligence-led vendor assessment methodology Neotas uses for Critical (Tier 1) relationships, combining OSINT investigation with structured checks across all six risk domains including beneficial ownership and sanctions proximity.
Fourth-party dependency mapping, pharmaceutical API sourcing concentration assessment, sub-contractor chain investigation and the OSINT techniques that surface supply chain risks beyond what any questionnaire can reach.
ESG and ethical supply chain due diligence covering Modern Slavery Act compliance verification, FCPA exposure mapping and pharmaceutical supply chain labour practice assessment for clinical procurement teams.
How to write and structure a TPRM policy that satisfies HIPAA OCR audit requirements, covers all five regulatory frameworks applicable to healthcare, and provides the governance documentation the 2025 NPRM requires.
Download the whitepaper that maps HIPAA, GDPR, NIS2, ESG, and governance exposure, and shows where questionnaire-led oversight leaves critical gaps.
Neotas Enhanced Due Diligence covers 600Bn+ Archived web pages, 1.8Bn+ court records, 198M+ Corporate records, Global Social Media platforms, and more than 40,000 Media sources from over 100 countries to help you screen & manage risks.
Explore how leading Healthcare organisations build continuous visibility across suppliers, outsourced providers, digital platforms, and extended third-party ecosystems.
| Cookie | Duration | Description |
|---|---|---|
| AWSALBTG | 7 days | AWS Application Load Balancer Cookie. Load Balancing Cookie: Used to encode information about the selected target group. |
| AWSALBTGCORS | 7 days | AWS Classic Load Balancer Cookie: Used to map the session to the instance. This cookie is identical to the original ELB cookie except for the attribute &SameSite=None; |
| cookielawinfo-checkbox-advertisement | 1 year | Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category . |
| cookielawinfo-checkbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
| cookielawinfo-checkbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
| cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
| cookielawinfo-checkbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
| cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
| CookieLawInfoConsent | 1 year | Records the default button state of the corresponding category & the status of CCPA. It works only in coordination with the primary cookie. |
| debug | never | Cookie used to debug code and website issues |
| shown | session | Session cookie to control number of times a pop up is shown. |
| viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |
| Cookie | Duration | Description |
|---|---|---|
| __cf_bm | 30 minutes | This cookie, set by Cloudflare, is used to support Cloudflare Bot Management. |
| AnalyticsSyncHistory | 1 month | Used to store information about the time a sync took place with the lms_analytics cookie |
| bcookie | 2 years | LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID. |
| bscookie | 2 years | LinkedIn sets this cookie to store performed actions on the website. |
| lang | session | LinkedIn sets this cookie to remember a user's language setting. |
| lidc | 1 day | LinkedIn sets the lidc cookie to facilitate data center selection. |
| UserMatchHistory | 1 month | LinkedIn sets this cookie for LinkedIn Ads ID syncing. |
| Cookie | Duration | Description |
|---|---|---|
| li_gc | 2 years | Used to store consent of guests regarding the use of cookies for non-essential purposes |
| rl_anonymous_id | 1 year | Generates an unique anonymous Id to identify a user and attach to a subsequent event. |
| rl_user_id | 1 year | to store a unique user ID for the purpose of Marketing/Tracking |
| Cookie | Duration | Description |
|---|---|---|
| _ga | 2 years | The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors. |
| _gat_gtag_UA_107495977_1 | 1 minute | Set by Google to distinguish users. |
| _gat_UA-107495977-1 | 1 minute | A variation of the _gat cookie set by Google Analytics and Google Tag Manager to allow website owners to track visitor behaviour and measure site performance. The pattern element in the name contains the unique identity number of the account or website it relates to. |
| _gcl_au | 3 months | Provided by Google Tag Manager to experiment advertisement efficiency of websites using their services. |
| _gid | 1 day | Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously. |
| attribution_user_id | 1 year | This cookie is set by Typeform for usage statistics and is used in context with the website's pop-up questionnaires and messengering. |
| CONSENT | 2 years | YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data. |
| Cookie | Duration | Description |
|---|---|---|
| _fbp | 3 months | This cookie is set by Facebook to display advertisements when either on Facebook or on a digital platform powered by Facebook advertising, after visiting the website. |
| fr | 3 months | Facebook sets this cookie to show relevant advertisements to users by tracking user behaviour across the web, on sites that have Facebook pixel or Facebook social plugin. |
| IDE | 1 year 24 days | Google DoubleClick IDE cookies are used to store information about how the user uses the website to present them with relevant ads and according to the user profile. |
| test_cookie | 15 minutes | The test_cookie is set by doubleclick.net and is used to determine if the user's browser supports cookies. |
| VISITOR_INFO1_LIVE | 5 months 27 days | A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface. |
| YSC | session | YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages. |
| yt-remote-connected-devices | never | YouTube sets this cookie to store the video preferences of the user using embedded YouTube video. |
| yt-remote-device-id | never | YouTube sets this cookie to store the video preferences of the user using embedded YouTube video. |
| yt.innertube::nextId | never | This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen. |
| yt.innertube::requests | never | This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen. |