HIPAA Cookie Compliance: A 2026 Guide for Busy Teams with Examples

Healthcare websites often rely on cookies and other tracking technologies to deliver personalised experiences or gather analytics. When those cookies collect or transmit electronic protected health information (ePHI), the HIPAA Privacy Rule, Security Rule and Breach Notification Rule apply. In December 2024 the Office for Civil Rights (OCR) updated its bulletin on online tracking, emphasising that regulated entities must ensure tracking technologies do not lead to impermissible disclosures of PHI. 

The revision followed a federal court decision vacating part of the bulletin that had tied PHI obligations to any connection between an IP address and visits to a public page about specific conditions. Yet the core message remained: healthcare sites must treat cookies and trackers as potential conduits for sensitive data. This article dives into why cookie compliance matters, what the rules require, how to conduct an audit, and how a managed security program can make compliance sustainable.

What Is a Cookie (or Tracking Technology)?

A cookie is a small text file stored by a website on a user's device. It identifies the browser and retains state across requests. The U.S. Federal Deposit Insurance Corporation (FDIC) explains that session cookies are temporary and expire when the browser closes, while persistent cookies remain on the user's computer until a specified expiration date or deletion. Third‑party cookies are created by domains other than the one the user is visiting. Mozilla notes that third‑party components can store information across sites and aggregate it to build detailed profiles, sometimes revealing sensitive attributes. Cookies can be first‑party (set by your own domain) or third‑party; the latter pose greater risks because they may send data to vendors beyond your control.

Tracking technologies go beyond cookies. The OCR bulletin lists web beacons or tracking pixels, session‑replay scripts and browser fingerprinting among tools that gather data. Web beacons are invisible one‑pixel images that let site owners or third parties collect information about page usage. Session replay scripts record user actions—mouse movements, clicks and keystrokes—and replicate the session for analysis. Fingerprinting uses unique browser or device configurations to identify users without storing files. Together, these technologies form a complex landscape that, if mishandled, can expose sensitive health behaviour.

HIPAA’s Scope for Web Tracking

HIPAA predates modern web analytics; its rules don’t name “cookies.” However, the Privacy Rule covers individually identifiable health information in any form. The OCR bulletin clarifies that HIPAA applies when tracking technologies collect or transmit information that relates to an individual’s past, present or future health or health care and that reasonably identifies them. Individually identifiable health information includes demographic data, IP addresses, device identifiers and any combination that can identify a person. Even on unauthenticated pages, such as a hospital’s informational site, data like IP addresses and page views can become PHI if linked to a health inquiry or appointment request. The revised bulletin notes that visits to generic pages—e.g., job postings or visiting hours—do not create PHI, but visits seeking second opinions on medical conditions might.

In June 2024 a federal court vacated the portion of the guidance that connected IP addresses on public pages to PHI. Yet the OCR continues to enforce disclosures of PHI via tracking technologies on authenticated portals or forms. This tension underscores the need for precise risk assessments and sound legal advice.

Why Cookies and Trackers Are Risky for Healthcare Sites

1) Collection of Identifiers on Public Pages

Cookies and pixels on public pages often collect IP addresses, device details and browsing paths. In healthcare, those identifiers can become PHI if they reveal a user’s interest in services or conditions. Goodwin’s analysis points out that visiting a page for treatment advice could produce PHI, whereas browsing a hospital’s visiting hours may not. The updated bulletin adds that information is PHI when the purpose of the visit relates to an individual’s health. Hospitals using analytics platforms should assume that user behaviour could relate to care, especially when pages link to appointment forms or patient portals.

2) Leakage to Third Parties

Third‑party pixels and scripts send data to vendors for analytics or advertising. Without safeguards, they may transfer identifiers with health‑related context, enabling cross‑site profiling. For example, a mental‑health provider might embed a marketing pixel on a resources page; the pixel vendor could infer that visitors are interested in mental health and retarget them with ads. That scenario not only violates trust but may constitute an impermissible disclosure if the data qualifies as PHI.

3) Increasing Breach and Enforcement Costs

Healthcare breaches are expensive and protracted. The HIPAA Journal reports that between 2009 and 2024, 6,759 breaches affected over 846 million records. In 2024 alone, 276 million individuals were affected, with an average of 758,000 records exposed daily. Major incidents like the Change Healthcare breach exposed 190 million records. IBM’s 2025 Cost of a Data Breach report shows that healthcare breaches cost an average of $7.42 million, with U.S. breaches averaging $10.22 million, and they take 279 days to contain—five weeks longer than the global average. OCR enforcement remains active: 22 investigations concluded with financial penalties in 2024 and several risk‑analysis related penalties were issued by mid‑2025. These figures emphasise that mismanaging cookies and tracking can attract regulatory scrutiny and severe financial consequences.

HIPAA Requirements for Cookie and Tracker Use

1) Privacy and Security Rules: No Impermissible Disclosures

The HIPAA Privacy Rule mandates that covered entities (providers, health plans and clearinghouses) may not disclose PHI without authorization or a permissible legal basis. The Security Rule requires appropriate administrative, physical and technical safeguards to protect ePHI’s confidentiality, integrity and availability. When using tracking technologies, regulated entities must ensure that data sent to analytics vendors does not include PHI unless the disclosure is permitted and properly documented. Disclosing PHI for marketing requires explicit authorization.

2) Technical Safeguards

Regulated entities must implement technical safeguards such as encryption in transit and at rest, access controls, audit controls and data integrity mechanisms. The OCR bulletin references the requirement to encrypt ePHI where reasonable and appropriate and to document alternative measures when encryption is not feasible. Audit controls and regular monitoring of scripts are critical to detect unauthorized disclosures.

3) Risk Assessment and Risk Management

Under the Security Rule, organisations must conduct a risk analysis to identify potential threats and vulnerabilities to ePHI. This includes mapping where ePHI is stored and transmitted, assessing the likelihood and impact of threats, and documenting risk levels. The analysis must be updated periodically. NIST’s Risk Management Framework (RMF) provides a structured approach with seven steps: Prepare, Categorize, Select, Implement, Assess, Authorize and Monitor. Integrating RMF into HIPAA programs helps ensure risks from cookies and trackers are systematically identified and mitigated.

4) Business Associate Agreements

Third‑party analytics or marketing vendors may become business associates if they handle PHI on behalf of a covered entity. HIPAA requires covered entities to obtain a Business Associate Agreement (BAA) that specifies permissible uses of PHI, implements required safeguards and mandates breach reporting. The OCR bulletin stresses that cookie banners do not suffice as authorization and that vendors must commit to HIPAA compliance. Sample BAA clauses, discussed later, outline key protections.

5) Breach Notification and Documentation

If tracking technologies lead to an unauthorized disclosure of PHI, the Breach Notification Rule requires affected individuals and HHS to be notified. Organisations must maintain documentation of risk analyses, decisions about trackers, BAAs, consent logs and mitigation steps. With privacy lawsuits on the rise, detailed documentation can demonstrate good‑faith compliance and reduce liability.

Evaluating Your Site: A Practical HIPAA Cookie Compliance Checklist

Effective compliance starts with a systematic assessment. Below is a step‑by‑step process you can adapt for your organisation. Each step aligns with HIPAA’s risk management obligations and draws on patterns we’ve seen across thousands of audits.

1. Inventory All Tracking Technologies

Create an inventory of all cookies, pixels, session‑replay scripts, SDKs and fingerprinting techniques running on your website and mobile apps. Document the page URL, tracker name, vendor, data collected (IP, device ID, page content, form inputs), first‑party/third‑party status, PHI risk level, consent mechanism, BAA status and notes. A simple table helps multiple teams (IT, marketing, compliance) visualise the landscape and assign ownership. For large sites, use automated scanning tools as a starting point but validate results manually.

2. Segment Pages by Risk

Categorise pages as authenticated (patient portals, appointment scheduling, results delivery) or unauthenticated (general information, careers). The risk of PHI disclosure is higher on authenticated pages and forms where users input health details or account credentials. However, don’t assume public pages are safe—consider context. A page describing treatment for depression with a call‑to‑action to “Book an appointment” may yield PHI if IP addresses and referral URLs are logged.

3. Map Data Flows

For each tracker, trace what data it collects and where the data flows. Does it send IP addresses, referrer URLs or unique identifiers to a third‑party server? If the data includes or may include PHI, mark it as high risk. Data flow diagrams reveal hidden exposures, such as a script that transmits appointment form fields to an analytics vendor. If you use customer data platforms (CDPs) or tag managers, document the chain of vendors. The OCR bulletin notes that some CDP vendors may be willing to sign BAAs and offer de‑identification services.

4. Conduct a Risk Assessment and Classification

Leverage the NIST RMF: Prepare by defining the scope; Categorize systems based on impact; Select controls (encryption, access controls, logging); Implement and Assess them; obtain leadership Authorization; and Monitor continuously. Assign risk levels (high, medium, low) based on the likelihood and impact of PHI exposure. Document the rationale—auditors will ask. In our experience, high‑risk items include trackers on appointment forms or portals, unencrypted session‑replay scripts and marketing pixels on disease‑specific pages.

5. Evaluate Consent and Authorization

A generic cookie banner may satisfy GDPR or CCPA requirements but doesn’t equal a HIPAA authorization. Determine whether the data collection qualifies as a permitted disclosure under HIPAA (e.g., for health care operations). If not, obtain explicit authorization from users before sharing PHI with vendors. Provide transparent disclosures about what data is collected, why, and who receives it. Record consent decisions and ensure that scripts respect those choices. On high‑risk pages, consider blocking third‑party scripts until consent is granted.

6. Assess Vendors and BAAs

For each third‑party vendor receiving potentially identifiable health information, verify that a HIPAA‑compliant BAA exists. Evaluate the vendor’s security posture: Do they encrypt data? How do they enforce least privilege? What breach notification timelines do they commit to? During negotiations, incorporate control obligations and audit rights. Our sample clauses below illustrate essential terms drawn from OCR’s sample BAA.

7. Implement Technical Safeguards

Apply encryption for data in transit and at rest; configure SameSite and Secure attributes on cookies; enforce Content Security Policy (CSP) to restrict script sources; and implement access controls to limit who can configure tags. Use pseudonymisation or aggregation to remove identifiers before sharing analytics. For session‑replay tools, mask inputs that may contain PHI (e.g., typed text fields). Keep software dependencies updated and disable unnecessary scripts.

8. Monitor and Audit

Set up logging to track when cookies and scripts are loaded, what data they transmit and whether errors occur. Use automated alerts for unusual data flows or new trackers added without review. Conduct periodic audits—quarterly at minimum—to verify that inventory, consent and BAAs are up to date. Document decisions, risk ratings and remediation actions. In our managed programs, continuous monitoring with dashboards reduces the mean time to detect misconfigurations by over 50% compared with annual audits.

9. Remove or Disable Non‑Essential Trackers

If a tracker is not essential to your mission and poses a PHI risk, disable it—especially on authenticated or sensitive pages. Replace marketing pixels with privacy‑preserving alternatives that aggregate data. If the vendor will not sign a BAA, remove their script from pages collecting health information. Sometimes the simplest solution is to reduce the attack surface.

Examples and Scenarios: What’s Allowed and What’s Risky

Example 1: First‑Party Session Cookies on Informational Pages

A hospital’s home page uses only first‑party session cookies to remember language preferences and track anonymous traffic. No user login or health information is captured. In this scenario, there is minimal HIPAA risk. Session cookies expire when the user leaves the site. Still, document the purpose and ensure the data is not combined with other identifiers that could turn it into PHI.

Example 2: Appointment Booking Form with Analytics Scripts

A clinic offers an appointment‑booking form on a public page where users enter names, contact details and choose services (e.g., cardiology vs. dermatology). The page also loads a third‑party analytics script that records IP addresses, referral URLs and form interactions. Even though the page is unauthenticated, the combination of IP address and selected service may qualify as PHI. Without a BAA and explicit authorization, sending this data to a third‑party analytics provider constitutes an impermissible disclosure. Best practice: remove the third‑party script, use a first‑party analytics tool, or obtain a BAA and mask identifying fields.

Example 3: Patient Portal with Session Replay

A health system embeds a session‑replay script in its logged‑in portal to troubleshoot user experience issues. The script captures mouse movements and keystrokes while patients view lab results and messages. Because the portal contains ePHI, any data collected is inherently PHI. Unless the vendor is a business associate with an appropriate contract, using session‑replay violates the Privacy Rule. Even with a BAA, the vendor must implement strong encryption and masking, and the covered entity should justify the necessity of session replay.

Example 4: Aggregated Analytics Without Identifiers

A provider wants to measure page performance but avoid PHI risk. They implement an in‑house analytics solution that logs page views and device categories without IP addresses or cookies. Data is aggregated across sessions and cannot be re‑identified. This design aligns with the principles of data minimisation and integrity and confidentiality under GDPR and reduces HIPAA obligations. For added protection, use a privacy‑focused vendor willing to sign a BAA and confirm that no raw identifiers are stored.

Example 5: Mental‑Health Resource Page with Marketing Pixel

A mental‑health clinic adds a pixel from an advertising platform to retarget visitors who viewed articles about depression. The pixel collects IP addresses and page titles, then shares them with the platform to create look‑alike audiences. Even though the site is public, this scenario is risky. It exposes highly sensitive browsing behaviour tied to mental‑health interest to an advertiser. The OCR bulletin suggests this may be considered PHI. Unless a BAA exists and users provide HIPAA‑compliant authorization, this practice should be avoided. A safer approach is contextual advertising that doesn’t rely on individual tracking.

Templates and Resources for Busy Teams

Cookie & Tracker Inventory Template

Risk Assessment Checklist

1. Scope Identification – List websites, mobile apps and internal tools where cookies and trackers operate.
   
   
2. Data Inventory – Describe what data each tracker collects (IP address, device ID, form contents, page content, search terms).
   
   
3. Identify Systems of Record – Map where collected data is stored and processed. Are analytics data integrated with CRM or EHR systems?
   
   
4. Threats and Vulnerabilities – Identify threats (unauthorized access, vendor misuse, cross‑site tracking) and vulnerabilities (insecure script loading, lack of encryption).
   
   
5. Likelihood and Impact Assessment – Assign likelihood and impact values and classify risks (high, medium, low).
   
   
6. Control Selection – Determine controls to mitigate each risk (encryption, pseudonymisation, least privilege, CSP).
   
   
7. Residual Risk Evaluation – Evaluate remaining risk after controls and decide if it’s acceptable.
   
   
8. Documentation and Approval – Document findings, decisions and approvals. Keep evidence for auditors.
   
   
9. Continuous Monitoring – Establish ongoing logging, consent tracking, vendor assessments and periodic reviews.

Sample Business Associate Agreement Clauses for Tracking Vendors

Here is a distillation of OCR’s sample provisions tailored to tracking vendors:

• Permitted Uses and Disclosures – The vendor may use PHI only to provide analytics services for the covered entity and may not use or disclose the information other than as permitted by the agreement or by law.
  
  
• Safeguards – The vendor must implement administrative, physical and technical safeguards to protect ePHI per the Security Rule. This includes encryption, access controls and audit logging.
  
  
• Breach Reporting – The vendor must report any security incident or breach of unsecured PHI to the covered entity without unreasonable delay.
  
  
• Subcontractors – The vendor must require any subcontractors who receive PHI to agree to the same restrictions and conditions.
  
  
• Access and Amendments – Upon request, the vendor must provide access to PHI to the covered entity or individual and incorporate any amendments.
  
  
• Return or Destruction – Upon termination, the vendor must return or destroy all PHI. If return or destruction is not feasible, the vendor must extend protections indefinitely.

Consent Statement / Disclosure Template

We use cookies and similar technologies to understand how our website is used and to improve your experience. Some of these technologies collect information that may relate to your health or the services you seek. We do not share individually identifiable health information with third parties without your authorization or as permitted by law. You can choose to allow or decline specific categories of cookies at any time. For more details, view our Cookie Policy and Notice of Privacy Practices.

Adapt this statement to your organisation’s specific purposes and ensure it is consistent with your HIPAA Notice of Privacy Practices. Provide granular options (e.g., analytics, functional, marketing) and block high‑risk trackers until the user opts in.

Draft Cookie Policy for Healthcare Websites (HIPAA‑Aligned)

1. Purpose of Cookies – Explain that cookies help deliver core functionality (e.g., session management), remember preferences, and provide aggregated analytics.
   
   
2. Types of Cookies – Describe first‑party session cookies, persistent cookies, and third‑party cookies and their purposes. Clarify that the organisation uses session cookies for navigation and does not collect personally identifiable information.
   
   
3. Other Tracking Technologies – Disclose use of web beacons, pixels, session replay and fingerprinting. Explain how data is collected and used.
   
   
4. Protected Health Information – State that information related to a person’s health or treatment is considered PHI and will not be shared with third parties unless permitted by HIPAA. Emphasise that PHI is encrypted and protected by administrative, physical and technical safeguards.
   
   
5. Third‑Party Vendors – List vendors that receive cookie or pixel data, describe the services they provide, and state whether they have signed BAAs. Provide links to vendor privacy policies.
   
   
6. Consent and Control – Explain how users can manage cookies (consent banner, browser settings) and the impact of blocking them. Note that some cookies are necessary for site functionality and cannot be disabled.
   
   
7. Data Security – Outline security measures: encryption, anonymisation, access controls, and periodic risk assessments. Mention the organisation’s commitment to continuous monitoring and compliance.
   
   
8. Updates – Indicate that the policy is reviewed regularly and updated when practices or regulations change.

Challenges, Grey Areas and Uncertainty

1) Ambiguity in PHI Definitions on Public Pages

The line between mere web analytics and PHI is blurry. The court’s partial vacatur of the OCR guidance emphasises that connecting an IP address with a visit to a public page about a specific condition doesn’t automatically trigger HIPAA obligations. Yet OCR still warns that if the purpose of the visit relates to health, the data may be PHI. This ambiguity forces organisations to adopt conservative assumptions or seek legal counsel for each scenario.

2) Legal and Regulatory Flux

The American Hospital Association (AHA) sued HHS in November 2023, arguing that the original bulletin restricted hospitals from using essential analytics technologies. Despite updates, AHA claims the revisions still impede standard tools. Court cases and enforcement actions will continue shaping the interpretation of PHI in web tracking. Organisations must stay abreast of developments and adjust policies accordingly.

3) Limitations of Consent Management Platforms

Cookie banners and consent management platforms (CMPs) often record user consent but do not block scripts until consent is given. The OCR bulletin notes that consent alone does not permit disclosure of PHI; a HIPAA‑compliant authorization or business associate relationship is required. CMPs may need customisation to enforce this requirement, such as default blocking of third‑party pixels on high‑risk pages.

4) Monitoring Complexity

Modern websites load multiple scripts asynchronously and through tag managers. Third‑party code can dynamically load additional scripts, making it difficult to ensure that no PHI leaks to unknown domains. Real‑time monitoring tools and frequent audits are necessary to maintain visibility. Smaller organisations often lack the expertise to configure and review these tools.

5) Balancing Marketing Needs with Compliance

Healthcare marketers want to track campaign effectiveness and target patients with relevant messages. However, retargeting and cross‑site tracking conflict with HIPAA’s restrictions. There is tension between data‑driven growth and privacy. A risk‑based approach, favouring aggregated analytics and first‑party data, is essential. When in doubt, choose patient privacy over micro‑targeting.

Recommended Approach for Healthcare Companies

Drawing on our experience implementing SOC 2, ISO 27001 and HIPAA programs, here are pragmatic steps to achieve sustainable HIPAA Cookie Compliance.

1. Start with a Comprehensive Audit

Assess all web and mobile properties for cookies and trackers. Use scanning tools to build an initial inventory, then validate manually. Identify high‑risk pages, such as patient portals and appointment forms. Without an audit, you’ll miss shadow scripts and vendor tags added by marketing teams.

2. Adopt a Privacy‑First Mindset

Assume that any data collected via cookies may be PHI unless you can demonstrate otherwise. This conservative stance helps avoid inadvertent disclosures. Apply data minimisation principles from GDPR—collect only what you need—and design analytics to operate on aggregated data. Where possible, avoid storing IP addresses or unique identifiers; use truncated or hashed values instead.

3. Implement Technical Controls in Your Stack

Integrate security controls directly into your website and infrastructure. Enforce TLS everywhere, implement secure cookie attributes (Secure, HttpOnly, SameSite), set up Content Security Policy (CSP) to restrict external scripts and use Subresource Integrity (SRI) to ensure scripts aren’t tampered with. Deploy Web Application Firewalls (WAFs) and intrusion detection systems. For session‑replay or analytics tools, configure them to mask PHI fields by default. These controls align with both HIPAA and SOC 2 Trust Services Criteria (security, confidentiality, privacy).

4. Require BAAs and Vet Vendors

Treat tracking and analytics vendors as potential business associates. Execute BAAs specifying permissible uses, requiring encryption and breach notifications, and granting you audit rights. Evaluate vendor compliance with SOC 2 Type II or ISO 27001 certifications. Ask about their vulnerability management process, patch cadence and incident response times. For high‑risk vendors, request evidence of internal audits.

5. Leverage Control Mapping Across Frameworks

Map HIPAA safeguards to controls in SOC 2 and ISO 27001. For example, HIPAA’s requirement for audit controls corresponds to SOC 2 CC7 (monitoring), while encryption aligns with ISO 27001 Annex A 10.1. Control mapping reduces duplication and accelerates multi‑framework compliance. In our managed programs, a single evidence set supports multiple standards, reducing effort by 75% compared with separate initiatives.

6. Embrace Continuous Monitoring and Automation

Static compliance snapshots are no longer sufficient. Implement continuous control monitoring to detect new or changed cookies, track vendor updates and log anomalies. Use automated compliance dashboards that alert teams when a script runs without a BAA or consent. Combine this with vulnerability scanning and patch management. IBM’s report shows that extensive use of AI and automation reduces breach lifecycle and cost. Similarly, continuous monitoring reduces observation periods in SOC 2 and speeds HIPAA audits.

7. Document Decisions and Evidence

Maintain meticulous records: inventories, data flow diagrams, risk assessments, BAAs, consent logs and audit trails. Documentation demonstrates good‑faith compliance and is crucial during audits or investigations. In my experience, teams that document decisions see fewer auditor findings and faster buyer approvals. Use central repositories and version control to keep records organised and accessible.

8. Update Policies and Train Staff

Policies must evolve as regulations change. Review your cookie policy, privacy notice and HIPAA practices at least annually. Train developers, marketers and content managers on the risks of adding third‑party scripts and the process for vetting vendors. Make sure leadership understands the trade‑offs between marketing and compliance.

9. Seek Expert Support

HIPAA Cookie Compliance is complex, especially when you layer in SOC 2, ISO 27001 and GDPR requirements. Managed service providers like Konfirmity bring dedicated expertise and operational capacity. We embed control implementation into your stack, monitor year‑round, and handle evidence collection so you can focus on healthcare innovation. Our human‑led, outcome‑as‑a‑service model differs from software-only tools; we execute the work, not just advise. On average, organisations working with us achieve SOC 2 Type II readiness in 4–5 months instead of 9–12 months, and reduce internal effort from over 550 hours per year to about 75 hours.

CTA: Book a demo

Conclusion

HIPAA Cookie Compliance matters because it protects patients and enables healthcare organisations to operate confidently in a world of complex privacy regulations. Cookies and trackers can be useful tools, but when they collect or transmit ePHI without safeguards they become liabilities. The OCR’s updated guidance and ongoing enforcement actions underscore that compliance is not optional. Following the steps outlined here—inventorying trackers, mapping data flows, conducting risk assessments, securing BAAs, implementing technical controls, and engaging in continuous monitoring—will help your organisation build a program that stands up to auditors, buyers and attackers. In my experience leading thousands of audits, the organisations that invest in durable security controls and ongoing operations not only meet regulatory requirements but also accelerate sales cycles and earn patient trust. Don’t wait for a breach or an enforcement action to evaluate your web tracking; start with security and compliance will follow.

FAQs

1) What is cookie compliance?

Cookie compliance refers to using cookies and tracking technologies in a manner consistent with privacy laws and data‑protection regulations. For healthcare sites subject to HIPAA, it means ensuring that cookies and trackers do not collect or disclose protected health information without a permissible basis, a Business Associate Agreement or explicit authorization. Compliance also involves implementing security safeguards, obtaining informed consent when required and maintaining documentation.

2) What are the five main HIPAA rules?

The primary HIPAA rules are: (1) the Privacy Rule, which governs the use and disclosure of PHI; (2) the Security Rule, which sets standards for protecting ePHI; (3) the Breach Notification Rule, which mandates reporting of breaches; (4) the Enforcement Rule, detailing penalties and investigations; and (5) the Omnibus Rule, which incorporates provisions of the HITECH Act and strengthens privacy protections.

3) Are cookies first‑party, second‑party or third‑party data?

Cookies themselves are not “data parties” but are classified by who sets them. First‑party cookies are set by the domain you visit and help with session management and functionality. Third‑party cookies are set by external domains and can aggregate data across sites to build profiles. HIPAA risks increase with third‑party cookies because data flows to vendors outside your control.

4) Who is responsible for cookie compliance?

For a healthcare organisation covered by HIPAA, responsibility for cookie compliance rests with the covered entity—but it spans multiple teams. Compliance officers ensure policies align with regulations; IT and security teams implement technical controls and monitoring; legal teams negotiate BAAs; marketing teams select analytics tools; and leadership provides resources. When third‑party vendors handle data, they become business associates and share responsibility under the BAA. A coordinated, human‑led program is essential for enduring compliance.