The short answer, split in two
Freshpaint is not one thing in a consent management platform, so the classification question does not have one answer. Freshpaint ships a consent layer and a tracking layer, and they sit on opposite sides of the strictly-necessary line.
The consent layer is Freshpaint Consent Manager. It shows the banner, records the visitor's choice, and stores that preference so the site can honour it on the next page. Storing a consent choice is the textbook example of strictly-necessary storage, because the user cannot get the privacy outcome they asked for unless the preference persists. Mark it essential and you are on solid ground.
The tracking layer is Freshpaint's event collection and its server-side replacement for ad pixels. It exists to measure behaviour and feed ad platforms. That is marketing data. It is useful, often very useful, but the page renders fine without it, which is exactly the test that disqualifies it from the essential category.
The reason teams reach for the essential label is mechanical, not legal. Freshpaint's SDK loads via a script tag in the page <head>, before a typical banner appears. So when a third-party CMP starts blocking head scripts, Freshpaint can break, and the fastest way to unbreak it is to whitelist the whole thing as Essential. That fixes the symptom and creates a compliance defect, because you have now told the regulator that your measurement tool loads without consent on the grounds that the site cannot function without it.
Why the tracking layer is never strictly necessary
The strictly-necessary exemption is narrow by design, and both UK and EU regulators draw the same line: a thing is essential only if the user cannot get the service they explicitly asked for without it.
The ICO sets two conditions. The storage or access must be essential to provide the service the user requests, and it must be a service the user explicitly requested. The ICO is blunt about the rest: cookies that are helpful or convenient but not essential, or that are only essential for your own purposes, still require consent. On analytics specifically, the ICO writes that analytics cookies do not fall within the strictly-necessary exemption, because measurement is valuable for your business but is not essential for delivering the page the user requested.
The EU position is the same shape. The European Data Protection Board adopted Guidelines 2/2023 on the technical scope of Article 5(3) of the ePrivacy Directive on 7 October 2024. Article 5(3) exempts storage or access only where it is strictly necessary to provide an information society service the subscriber explicitly requested. The EDPB treats that as purpose-bound and assessed case by case. A purpose of measurement or advertising does not clear it.
The exposure behind getting this wrong is not theoretical. Under Article 83 of the GDPR, the most serious consent breaches carry administrative fines of up to 20 million euros or 4 percent of total worldwide annual turnover, whichever is higher. The UK raised its own ceiling to match: the Data (Use and Access) Act 2025 lifted the maximum PECR penalty from £500,000 to £17.5 million or 4 percent of global turnover (Data (Use and Access) Act 2025). Mislabelling a measurement tag as essential to dodge a consent prompt is the kind of self-serving classification those penalty tiers exist to catch.
| Component you tag | Essential / strictly necessary? | Why |
|---|---|---|
| Freshpaint Consent Manager SDK | Yes, defensible | Storing the consent choice is needed to honour the user's request. Standard CMP exemption. |
| Freshpaint event and analytics collection | No | Measurement. ICO is explicit that analytics is not strictly necessary. |
| Freshpaint pixel replacement and ad forwarding | No | Advertising. Marketing data never qualifies. |
| Freshpaint server-side PHI filtering | Not a cookie category | This runs server-side. It is a HIPAA control, not a browser-storage decision. |
Singapore, leapbuzz's home market, does not have a verbatim strictly-necessary cookie carve-out the way UK PECR does. The Personal Data Protection Act frames the question as a consent obligation with specific exceptions, and the Personal Data Protection Commission expects a lawful basis for collecting personal data through analytics. The practitioner shortcut of treating Essential as a global free pass does not hold under the PDPA either, so a five-market business cannot rely on one CMP toggle to cover Singapore, Australia, Canada, the United States, and the United Kingdom at once.
Why HIPAA does not settle the consent question
The most common reasoning error here is treating Freshpaint's HIPAA credentials as proof that it belongs in the essential bucket. HIPAA and cookie-consent law are separate regimes that answer different questions, and clearing one does not clear the other.
HIPAA asks whether a tool may handle Protected Health Information, which Freshpaint defines as the combination of personally identifiable information and health information, including an IP address tied to a diagnosis, treatment, or test result. Freshpaint answers that by signing a Business Associate Agreement, filtering data server-side so PHI never leaves the environment, and using a block-by-default model where data is held back until it is explicitly allowlisted. Freshpaint markets this as the safest way to avoid inadvertently sharing PHI, and for healthcare marketers it is a real improvement over a raw Meta or Google pixel.
None of that is a consent classification. Cookie-consent law asks a different question: did the user agree to this data collection, and is it essential to the service they requested. A tool can be fully HIPAA compliant and still require consent under GDPR, PECR, or the PDPA, because those laws govern agreement and necessity, not whether the data happens to be health-related.
The 2024 court ruling is worth getting right, because it changes the HIPAA risk picture without touching the consent picture. In June 2024, a federal court in American Hospital Association v. Becerra vacated the portion of the HHS Office for Civil Rights tracking guidance that treated an IP address plus a visit to an unauthenticated public health page as automatic PHI. The rest of the guidance still stands, and authenticated surfaces like patient portals and logged-in scheduling remain squarely inside HIPAA. The Office for Civil Rights later withdrew its appeal of that order. For classification purposes, the ruling shrinks when a tracker on a public page becomes a HIPAA problem; it does nothing to make that tracker strictly necessary under cookie law.
How to configure Osano, OneTrust, and Cookiebot
The configuration is the same idea in three dialects: split Freshpaint into a consent tag and a tracking tag, put the consent tag in the essential group, and gate the tracking tag behind consent. Here is how each platform names it.
Osano
Osano uses four categories: Essential, Analytics, Marketing, and Personalization. Essential is defined as content necessary for the website to function, an exception to consent requirements that can load with or without consent, with login authentication as the canonical example. Turn on Strict Mode, which runs or blocks every classified script, cookie, and iframe based on the category you assign it. Assign the Freshpaint consent SDK to Essential. Assign the Freshpaint tracking tag to Analytics or Marketing depending on its destination.
OneTrust
OneTrust groups cookies into Strictly Necessary (group C0001), Performance (C0002), Functional, Targeting, and Social Media, and supports custom groups. Strictly Necessary is defined as cookies fundamental to the site's operation, the shopping-cart-and-checkout example. Place the Freshpaint consent SDK in C0001. Place the tracking tag in C0002 or Targeting. You can move a script between groups in the admin panel, and OneTrust also exposes a recategorize API if you are managing this at scale across many properties.
Cookiebot by Usercentrics
Cookiebot uses Necessary, Preferences, Statistics, Marketing, and Unclassified. Necessary is defined as scripts needed to guarantee website functionality, where the test is that blocking the tracker would render the site inoperable or unable to provide the service it is intended to provide. Classify the consent script as Necessary. Classify the tracking script as Statistics or Marketing. Then set the tracking script's type attribute from text/javascript to text/plain so it physically cannot execute before the matching consent signal arrives. That last step is the one teams skip, and it is the difference between a banner that records a preference and a banner that actually stops the tag.
- Inventory the two tags. Find the Freshpaint consent SDK and the Freshpaint tracking call separately. If they are bundled, ask your website development team or your implementation partner to separate them before you classify anything.
- Classify the consent SDK as essential. Essential in Osano, C0001 in OneTrust, Necessary in Cookiebot.
- Classify the tracking tag by purpose. Analytics or Marketing, never essential.
- Enforce, do not just record. Strict Mode in Osano, group gating in OneTrust, and the
text/plainswap in Cookiebot. A banner that records consent while the tag still fires is the exact gap regulators target. - Resolve the double-gate. If Freshpaint Consent Manager and your third-party CMP both try to gate the same tag, pick one as the enforcer. Two systems fighting over one tag is how you end up double-blocking, or leaking.
The trade-off nobody puts in the ticket
The reason this question gets asked at all is measurement loss. When you gate analytics behind consent, the users who decline disappear from your data, and someone senior eventually asks why the conversion numbers dropped. The temptation is to relabel the tag as essential to recover the data. That does not recover anything; it just swaps a measurement gap for legal exposure.
The honest fix is to recover signal on the server side rather than relabel it on the client side. Google Consent Mode v2 keeps the consent decision intact and models conversions for users who declined, so you lose less without lying about the category. Google reports that conversion modelling through Consent Mode recovers more than 70 percent of the ad-click-to-conversion journeys lost to cookie-consent choices (Google, Conversion modeling through Consent Mode), which is signal you get back legitimately instead of by relabelling a tag. Meta's Conversions API, an Application Programming Interface that sends events from your server instead of the browser, recovers events that browser pixels miss. Both are consent-respecting ways to close the gap that a strictly-necessary mislabel would only paper over.
This is where classification stops being a CMP setting and becomes a measurement-architecture decision. The broader move, rebuilding measurement on consented first-party signal so it survives the loss of third-party cookies, is its own discipline we walk through in first-party data strategy when third-party cookies are gone. If your analytics depend on a category lie to survive, the architecture is the problem, not the consent banner. That is the work we do under analytics and insights: building measurement that stays accurate after consent, so the question of whether to cheat the category never comes up. The broader operating-model call, which data flows where and under what basis across five markets, sits in AI marketing strategy.
A decision rule you can hand to the team
Here is the rule, short enough to paste into a runbook. Ask one question of any Freshpaint component before you classify it: would the page the user requested still work if this were blocked. If yes, it is not strictly necessary, and it goes behind consent. If no, it might qualify, and the consent-capture script is the only Freshpaint piece that reliably clears that bar.
- Consent SDK: essential. Without it you cannot honour the user's choice.
- Analytics collection: behind consent. The page renders without it.
- Ad forwarding and pixel replacement: behind consent. Marketing, always.
- Server-side PHI filtering: out of scope for cookie categories. It is a HIPAA control, governed by your BAA.
Two regimes, two questions. HIPAA decides whether Freshpaint may touch health data, and the BAA plus server-side filtering answers it. Cookie law decides whether each Freshpaint tag needs consent, and the answer is yes for everything except the consent script itself. Keep those two questions apart and the classification stops being confusing. Collapse them, mark everything essential, and you have built a tidy-looking banner sitting on top of a compliance defect.
The verdict is not close. The consent layer can be strictly necessary. The tracking layer never is, and no HIPAA agreement changes that. Teams keep collapsing the two because it is convenient, and convenient is exactly what a regulator reads as intent.