Most marketing and product teams in the U.S. have been adapting their cookie posture for years to keep up with the GDPR, the CCPA/CPRA, and a steady drip of new state laws (Virginia, Colorado, Connecticut, Utah, Oregon, Texas, Montana, and now Tennessee).

The TIPA fits into the same comprehensive consumer privacy law family, with one quirky and very business friendly twist: the law includes a voluntary affirmative defense for controllers and processors that maintain a written privacy program reasonably aligned with the NIST Privacy Framework. That defense, plus a 60 day cure period and a clear set of consumer rights, makes the TIPA Cookies Policy worth doing right.

This page covers one piece of the picture. For the full scope of the TIPA — who must comply, the thresholds, the consumer rights and the penalties — start with our complete guide to the TIPA and cookies.

This article exists to walk you through every piece of the cookies side of TIPA compliance. What the law expects. What your banner and notice need to say. How consent and opt out should work. Where Tennessee differs from California, Virginia, Colorado, Connecticut, Texas, and Montana. How the NIST aligned defense changes your cookie posture. How AdOpt builds a defensible TIPA Cookies Policy for clients with a Tennessee footprint.

If you would rather skim, the short version is this: cookies that touch personal information now need a clear disclosure, an effective opt out for sale and targeted advertising, a privacy notice that consumers can find, and an operational program that keeps the words on the page in sync with the actual behavior of your stack. If you want the long version, keep reading.

Info

Companion reads: this is the cookies focused guide. We have separate, dedicated TIPA Privacy Policy and TIPA DSAR Policy articles that complete the picture. We will link between them where it helps.

The Tennessee Information Protection Act, often shortened to TIPA, is Tennessee's comprehensive consumer privacy law. It is codified at Title 47, Chapter 18, Part 33 of the Tennessee Code and took effect on July 1, 2025. The Tennessee Attorney General is responsible for enforcement.

If your team has worked with the Virginia Consumer Data Protection Act (VCDPA), the Colorado Privacy Act (CPA), or the Connecticut Data Privacy Act (CTDPA), TIPA will feel like a cousin. The structure is the familiar one: consumer rights (access, correction, deletion, portability, opt out of sale, opt out of targeted advertising, opt out of profiling for significant decisions), controller and processor responsibilities (data minimization, purpose limitation, security, contracts, data protection assessments), and enforcement by the state AG.

What sets the TIPA Cookies Policy discussion apart from its siblings is two specific elements:

The applicability threshold is unusual. TIPA only covers entities that exceed 25 million dollars in annual revenue and meet one of two consumer based thresholds (175,000 Tennessee consumers, or 25,000 Tennessee consumers plus more than 50 percent of gross revenue from the sale of personal information). The 25 million dollar floor is a real filter. Many smaller U.S. businesses are out of TIPA's scope entirely, even if they would be covered in California or Colorado.

The affirmative defense is unique. Controllers and processors that voluntarily create, maintain, and comply with a written privacy program that reasonably conforms to the NIST Privacy Framework (or comparable framework) can use that program as an affirmative defense in a TIPA enforcement action. This is, in privacy law, an unusual and explicit incentive to invest in program documentation.

For comparison and broader context across the comprehensive privacy law family, our explainer on the GDPR, LGPD, and CCPA is a good orientation. The TIPA Cookies Policy lives in the same neighborhood as those, with Tennessee specific dialect.

The TIPA applies to entities that conduct business in Tennessee or produce products or services targeted to Tennessee residents, and that meet all of the following:

• Exceed 25 million dollars in annual revenue.
• Control or process personal information of at least 175,000 Tennessee consumers during a calendar year, or
• Control or process personal information of at least 25,000 Tennessee consumers and derive more than 50 percent of gross revenue from the sale of personal information.

The 25 million dollar floor is the most important filter for the TIPA Cookies Policy scoping question. If your annual revenue is below that line, you are out of TIPA's scope, period, regardless of how many Tennessee consumers you process. If you are above the line, the consumer threshold becomes the next gate.

That is unusual among state privacy laws. California, Virginia, Colorado, Connecticut, and Texas do not have a revenue floor of that size. Many small to mid market U.S. companies with Tennessee customers will be in scope under those laws but out of scope under TIPA. The reverse is not common.

There are also entity exemptions. Government agencies, financial institutions subject to GLBA, covered entities or business associates under HIPAA, nonprofits, higher education institutions, registered insurance companies, and a few other categories are excluded. Some data is also exempted (PHI under HIPAA, consumer reports under FCRA, employee or B2B data acting in commercial or employment context, etc.).

For your TIPA Cookies Policy, the practical implication is that scoping needs to be done thoughtfully. If you fall below the 25 million dollar floor, your cookie posture is governed by other state laws (and the federal patchwork), but not by TIPA. If you fall above the floor, the TIPA Cookies Policy becomes a real obligation.

For a primer on how scope thresholds work in this family of laws, our piece on the LGPD is a useful comparator. Like TIPA, the LGPD scopes by data flow and processing volume, just with different cutoffs.

Cookies are the connective tissue of the modern web. Authentication, session continuity, language preferences, A/B testing, fraud prevention, attribution, retargeting, audience modeling, and most of programmatic advertising rely on cookies in some form. They are also the most visible privacy artifact on a website. When a Tennessee resident lands on your homepage and sees a banner, that banner is the public face of your TIPA Cookies Policy, even if you do not call it that.

A few specific TIPA mechanics make cookies an obvious focal point:

The TIPA grants Tennessee consumers the right to opt out of the sale of personal information, the use of personal information for targeted advertising, and the use of personal information for profiling in furtherance of decisions that produce legal or similarly significant effects. Most of these activities, in practice, rely on cookies, pixels, or device IDs to function. Honoring the opt outs technically requires controlling the cookies and the data they emit.

The TIPA requires a privacy notice that is reasonably accessible, clear, and meaningful, that includes the categories of personal information processed, the purposes of processing, the categories of recipients, the categories of personal information shared with third parties, and a description of how consumers can exercise their rights and appeal decisions. That notice is where most consumers will look for your cookie disclosures.

The TIPA requires that the means for consumers to exercise their rights be "reasonably accessible" and that the controller establish a method to authenticate the requestor, including for opt out preference signals. The mechanism has to be at least as easy to use as the consent mechanism. If your banner takes one click to accept and twelve clicks to reject, the law has something to say about that.

To anchor the design conversation, our guide on choosing a cookie banner is a good starting point. The same engineering and UX principles apply when you adapt the banner for Tennessee.

The TIPA defines "personal information" as any information that is linked or reasonably linkable to an identified or identifiable natural person, and excludes de identified data, aggregated data, and publicly available information.

The phrase "reasonably linkable" is doing serious work. Online identifiers, IP addresses (full ones especially), device IDs, persistent cookie IDs used for ad targeting, hashed identifiers used for audience matching, and similar pieces of information are routinely treated as personal information under modern privacy law because they are reasonably linkable to a person, especially when combined with other data points already in your stack.

For your TIPA Cookies Policy, the practical implication is that you cannot dismiss third party advertising cookies as "anonymous." If your vendor uses the cookie ID to build a profile, match against a graph, or sync with another platform's ID, you are processing personal information. The discipline of data mapping is what surfaces these flows reliably.

Our deep dive on cookies and personal data goes through why almost every persistent cookie used for marketing or analytics qualifies as personal data under modern privacy regimes. TIPA fits that pattern.

For the mechanics behind the cookie versus storage distinction, our explainer on the difference between cookies, local storage, and session storage is short, useful, and matters when you draft notice text.

The TIPA requires the privacy notice to include several elements. Translating those into the cookies layer of your TIPA Cookies Policy:

• The categories of personal information processed by the controller, including the cookie based categories (identifiers, online activity, inferences).
• The purposes for which the categories are processed, in plain language.
• The categories of personal information shared with third parties, organized so a consumer can recognize who the parties are.
• The categories of third parties to whom personal information is sold or with whom personal information is shared for purposes of targeted advertising, with a clear and conspicuous opt out method.
• A description of consumer rights and how to exercise them, including the appeal mechanism.
• A clear and conspicuous link to the controller's website that allows consumers to opt out of the sale of personal information and processing for targeted advertising.

For your TIPA Cookies Policy specifically, expect to disclose:

The categories of cookies and similar technologies you use, organized in a way the consumer can understand (necessary, functional, analytics, advertising, profiling), with examples of vendors in each category. The purposes for which each category is used, in plain English. The duration each cookie persists, where reasonable, or at least the maximum duration.

The third parties that may receive personal information through cookies, with enough detail that a consumer can recognize who those parties are. Whether any cookies result in a sale of personal information or are used for targeted advertising, and how to opt out. Whether any are used for profiling that produces legal or similarly significant effects, and how to opt out. The mechanism for revoking consent, with the same prominence as the mechanism for giving consent.

If you want a model for how to frame the privacy policy section that contains your cookies disclosures, our primer is a good template. The structural advice transfers to Tennessee.

Here is where the U.S. patchwork gets confusing. The TIPA, like most U.S. state privacy laws, is generally an opt out regime for the headline activities (sale, targeted advertising, profiling). It is not a pure opt in regime for cookies in the way the European GDPR ePrivacy framework is.

But "opt out by default" is not the whole story. Three layers matter for your TIPA Cookies Policy.

First, for activities that fall under the opt out rights (sale, targeted advertising, profiling for significant decisions), you need to provide a clear and conspicuous opt out mechanism. The TIPA requires controllers to establish two or more methods for consumers to submit a request to exercise their rights, and one of those methods has to take into account the ways consumers normally interact with the controller. The opt out has to be operational, not theoretical.

Second, for processing of sensitive data the TIPA requires consent, which is defined as a freely given, specific, informed, and unambiguous agreement. Sensitive data includes personal information revealing racial or ethnic origin, religious beliefs, mental or physical health diagnosis, sexual orientation, citizenship or immigration status, genetic or biometric data processed for the purpose of uniquely identifying a specific individual, personal information collected from a known child, and precise geolocation data. If your cookies, pixels, or SDKs feed any of these categories into a third party, you cannot rely on opt out. You need consent.

Third, for known children (under 13), the TIPA refers to and incorporates the Children's Online Privacy Protection Act (COPPA) standard. Processing personal information of a known child requires processing in accordance with COPPA, which generally means verifiable parental consent. Your TIPA Cookies Policy must support that workflow.

The right way to read all of this is to assume that your TIPA Cookies Policy must support both opt out and opt in flows, depending on the data category and audience. A modern CMP makes that possible without separate code paths. Without one, you will end up with brittle, hard to defend logic.

For more on how consent can be designed to be valid and durable, our explainer on consent on websites is a useful reference.

Let us slow down and be careful about terminology, because the TIPA Cookies Policy discussion is full of words that look interchangeable but are not.

A cookie is a small text file that a website asks the browser to store. The browser sends the cookie back to the website (or sometimes to third party domains) on subsequent requests. Cookies can be first party (set by the domain you are visiting) or third party (set by another domain that the page loads, like an ad network or analytics provider).

Cookies can be strictly necessary (without them the site would not function: session ID, load balancer hash, anti CSRF token, language preference, secure login state), functional (preferences, video player state, region selection), analytical (page view counts, behavior funnels, A/B tests), advertising (retargeting, attribution, audience segmentation), or profiling (cross context behavioral profiles used to make decisions about people).

Under the TIPA, the legal weight of a cookie depends on what it actually does with personal information, not on the marketing label your vendor put on it. A "first party analytics" cookie that pipes pseudonymous identifiers into an ad partner is, for compliance purposes, an advertising cookie. A "necessary" tag from a payment processor that doubles as an attribution beacon is, for compliance purposes, an attribution cookie. The TIPA cares about the data flow.

This is why categorization matters so much for the TIPA Cookies Policy. Our deep dive into tag categorization best practices walks through the discipline. If you cannot categorize tags correctly, you cannot operate a defensible TIPA Cookies Policy.

These three terms are the TIPA's most consequential opt out categories, and all three intersect with cookies.

Targeted advertising under the TIPA generally means displaying advertisements to a consumer where the advertisement is selected based on personal information obtained or inferred from that consumer's activities over time and across non affiliated websites or online applications, used to predict consumer preferences or interests.

If you run retargeting campaigns, lookalike audiences, programmatic display ads, or social platform conversion APIs that build profiles, you are doing targeted advertising. Most of those activities use cookies, pixels, or device IDs to function. Your TIPA Cookies Policy must let consumers turn this off.

Sale of personal information under the TIPA, like in many U.S. state laws, means the exchange of personal information for monetary consideration by the controller to a third party. The TIPA's definition of sale is narrower than California's broader "sale or share" framing.

TIPA's sale definition is monetary only, not "valuable consideration." That said, many vendor relationships still meet the monetary bar, and if you are using ad exchanges, retargeting platforms, or audience marketplaces, you should assume some sales are happening through your cookies.

Profiling under the TIPA, when used in furtherance of decisions that produce legal or similarly significant effects, is also subject to opt out. If you use cookie based behavior to feed a model that approves or denies someone for credit, employment, insurance, housing, education, or other consequential outcomes, that is the profiling the TIPA worries about. Most marketing personalization is not in that bucket, but credit scoring, insurance underwriting, and similar use cases are.

The interaction between these three categories and cookies is why we say the TIPA Cookies Policy is really a data flow policy. The cookies are the visible plumbing. The actual obligations live one layer down, where the data is going and what it is used for.

For more on how state laws compare on these definitions, our piece on the GDPR, LGPD, and CCPA is a useful cross reference.

This is the part of the TIPA Cookies Policy discussion that is unique to Tennessee. The TIPA includes an affirmative defense for controllers and processors that voluntarily create, maintain, and comply with a written privacy program that reasonably conforms to the NIST Privacy Framework or a comparable framework.

What does that mean in practice for cookies?

The NIST Privacy Framework is a voluntary, risk based framework with five core functions: Identify, Govern, Control, Communicate, and Protect. Each function has categories and subcategories that describe what a mature privacy program should cover. A program that is "reasonably conformed" to the framework documents how the controller implements each relevant subcategory and adapts to the volume and sensitivity of processing.

For a TIPA Cookies Policy specifically, the NIST defense changes the conversation in three ways:

It rewards investment in documentation. A controller with a well documented cookie inventory, vendor management, consent management, and audit trail is in a much stronger defensive position. It reframes cookie compliance as a privacy program component, not a stand alone task.

Cookie management ties into Identify (cookie inventory), Govern (policy and roles), Control (consent and opt out), Communicate (privacy notice and banner), and Protect (security of cookie data). It encourages calibrated risk management. The size and shape of the cookie program should match the volume and sensitivity of cookie based processing. Smaller, less sensitive operations need less infrastructure. Larger, more sensitive operations need more.

The defense is voluntary. You do not have to align with NIST to operate under TIPA. But if you do, and you can demonstrate the alignment with documentation and operational evidence, you have an affirmative defense in any TIPA enforcement action. That is, in privacy law, a meaningful incentive.

For more on the discipline of building a privacy program, our explainer on the responsibilities of a data protection officer and on the DPO and team covers the territory.

The TIPA does not prescribe a specific banner layout. What it requires is that the means for consumers to exercise rights be reasonably accessible. That is a UX rule with teeth. It means you cannot bury the "Reject all" or "Manage preferences" buttons.

It means dark patterns ("Accept all" highlighted in a bright color, "Reject" in tiny gray text) are not acceptable. It means the path back to changing your mind has to exist and has to be easy to find.

We treat that as a design rule, not just a legal one. AdOpt's piece on the operation of a cookie banner walks through the practical UX patterns. The same patterns that satisfy the GDPR satisfy the TIPA, with a few tweaks.

For Tennessee specifically, we recommend the following design choices when implementing a TIPA Cookies Policy:

Two visible primary actions on the first layer: "Accept all" and "Reject all" (or equivalent), with equal visual weight. A clear "Manage preferences" link that opens a granular layer with toggles for each cookie category. A persistent way to revisit preferences, typically a small floating icon or a link in the footer, so revoking consent is as easy as granting it.

Plain language descriptions of each category, with examples of vendors. A clear statement of consumer rights, with a link to the full privacy notice. A mechanism that detects opt out preference signals (Global Privacy Control and similar) and applies them automatically, with a visible confirmation to the user that the signal was honored.

If you treat the banner as a one time popup and forget about it, your TIPA Cookies Policy is incomplete. The banner is the front door. The preference center, the privacy notice, the DSAR portal, and your back end vendor controls are the rest of the house.

For broader background on the role of the cookie banner under modern privacy regimes, our piece on why the cookie banner exists is a useful read.

When personal information flowing through your cookies includes sensitive data, the rules flip from opt out to opt in. You need consent before processing.

Common ways this can happen without anyone realizing it:

A health publisher places ad pixels on pages dedicated to specific conditions. The combination of the URL and the cookie ID can reveal a health condition. That pairing becomes sensitive data the moment it leaves your domain. Without consent, you have a problem.

A consumer reads articles about a specific religion or sexual orientation, and a third party tag captures the URL and the cookie ID, building a profile. Same problem.

A precise geolocation pixel fires on a mobile site. The location is reasonably linkable to the user. That is sensitive data. Without consent, the pipeline is non compliant.

Your TIPA Cookies Policy has to identify these flows, isolate them in your tag management system, and gate them behind consent. The discipline of a data mapping exercise is what keeps these surprises out of your stack.

The TIPA refers to the Children's Online Privacy Protection Act for the processing of personal information of known children under the age of 13. That means the COPPA framework (verifiable parental consent, limited data collection, parental access rights) governs the processing.

For your TIPA Cookies Policy, this means:

If you operate a site or feature directed to children, you cannot load advertising or profiling cookies without verifiable parental consent. You should not infer "old enough" from browser fingerprints. You should design the experience so that even if a known child sneaks past your gating, the data flows do not amplify risk. Cookies tied to children should be limited to those necessary for the service.

If you operate a general audience site, you should think about how your cookies behave when a known child account is logged in. Even if your analytics infer adult behavior, your account flag is the source of truth.

The COPPA layer is well established. The TIPA reference makes the COPPA standard the floor for children's data under TIPA. There is no separate TIPA standard.

For a broader take on how privacy laws treat consent and children, our piece on consent on websites is a useful primer.

The TIPA, unlike some other state laws (Colorado, California, Connecticut), does not require controllers to honor universal opt out signals like Global Privacy Control. The TIPA is silent on the question, which means there is no statutory obligation to detect and respond to GPC.

That said, honoring GPC is best practice for a few reasons:

Many of your other state law obligations (California, Colorado, Connecticut, soon Texas and others) require you to honor GPC. Building a single posture that honors GPC across all consumers reduces complexity. Tennessee consumers benefit from the same baseline opt out posture, even though TIPA does not require it.

Honoring GPC is a strong signal of good faith. The TIPA's voluntary affirmative defense (the NIST aligned program) is strengthened by signal handling that goes beyond the literal requirements. Future Tennessee legislative or regulatory updates may mandate GPC handling. Building it in now is future proofing.

So even though the TIPA Cookies Policy does not strictly require GPC handling, we recommend implementing it. Our explainer on how to choose a CMP covers what to look for in a platform that handles signals well.

Almost every cookie problem in a modern stack ends up being a vendor management problem. If your TIPA Cookies Policy says you do not sell personal information, but your tag manager loads a third party SDK that quietly sells device IDs into an audience graph, your policy is fiction.

To avoid this, you need three things:

A complete inventory of every tag, pixel, SDK, and server side integration that touches Tennessee traffic. Updated quarterly at minimum. For each vendor, a documented purpose, a category, the type of personal information it receives, the legal basis, and the consent state required to fire it.

Contracts that satisfy TIPA's processor contract requirements. The TIPA requires the controller to processor relationship to be governed by a contract that addresses confidentiality, processing instructions, return or deletion of data at end of contract, audit rights, and similar provisions. For each vendor where you are the controller and they are a processor, that contract has to exist.

Configuration of tags so that they only fire when consent or the absence of an opt out signal is present, and so that they pass the right signals downstream. The familiar "Marketing wants this turned on for everyone" demand has to be told, politely, that the law disagrees.

For background on the controller vs processor question and why the contract piece matters, our primer on the differences explains the legal shape of the relationship.

The TIPA includes a 60 day cure period for controllers and processors who receive notice of an alleged violation from the Attorney General. If the controller cures the violation within 60 days and provides written notice to the AG that the violation has been cured, the AG cannot bring an enforcement action for that violation.

Unlike some other state laws where the cure period is sunset (the cure right disappears after a certain date), the TIPA's cure period is permanent. It is built into the statute.

For your TIPA Cookies Policy, this is a meaningful design consideration:

The cure period rewards controllers who can identify and fix violations quickly. A privacy program that surfaces issues early and fixes them within 60 days is in a strong defensive position. The cure period does not reward delay or denial.

If you receive a notice and ignore it, the 60 day clock runs out and the AG can bring an enforcement action. Documentation of the cure is essential. The written notice to the AG has to demonstrate that the violation is actually cured, not just promised.

An operationally mature TIPA Cookies Policy treats the cure period as a feature, not as a backstop. The goal is to build a program where violations are rare and curable, not to rely on the cure period as a safety net.

For more on building a mature privacy program that catches issues early, our piece on privacy by design is a useful starting point.

Reading dozens of cookie banners and notices, the same handful of mistakes show up over and over. Here are the ones we most often see in early TIPA Cookies Policy drafts.

Mistake one: treating the cookie banner as the entire policy. The banner is a small piece of the disclosure. The full policy has to live in a privacy notice that is reachable from a clear and conspicuous link.

Mistake two: copying and pasting from a CCPA template without adjusting for TIPA. Tennessee has its own threshold (the 25 million dollar revenue floor), its own affirmative defense, its own narrower sale definition, and its own cure period. A copy paste loses those nuances.

Mistake three: implementing a "Reject all" button that does not actually reject. This is shockingly common. Click "Reject all," check the network tab, and watch a dozen tags fire anyway. The TIPA, like its sister laws, has no patience for this. If your reject does not reject, your TIPA Cookies Policy is materially false.

Mistake four: treating "necessary" as a category that can absorb anything. Necessary means the cookie is required for the site to function. Marketing pixels are not necessary. Attribution cookies are not necessary. Calling them necessary to avoid the consent obligation is a disclosure problem.

Mistake five: forgetting server side pipelines. Many advertising stacks today bypass the browser entirely. They fire from your server to the ad platform, often using first party identifiers harvested at login. Your TIPA Cookies Policy has to cover those pipelines too, even though the consumer never sees a cookie.

Mistake six: not building toward the NIST defense. The TIPA's affirmative defense is a real strategic asset. Skipping the NIST aligned program is leaving that defense on the table.

Mistake seven: the privacy notice is buried. The TIPA requires a reasonably accessible privacy notice. A footer link in 9 point gray text on a white background is not reasonably accessible.

Mistake eight: forgetting accessibility. A privacy notice that does not work with screen readers, keyboard navigation, and adequate contrast is not reasonably accessible to all consumers.

Mistake nine: not tracking the cure period. When a TIPA notice arrives, the 60 day clock starts. A program without a tracking mechanism risks running out the clock without a cure.

Mistake ten: treating the TIPA as a one time project. The law evolves. The thresholds may change. The Attorney General's enforcement priorities may change. Your TIPA Cookies Policy is a living document.

For a complementary read on what happens when companies try to ignore comprehensive privacy law, our piece on ignoring the law is a sober reminder.

If you are implementing or refreshing your TIPA Cookies Policy from scratch, here is the order we recommend.

Step one: confirm scope. Run the numbers. What is your annual revenue? How many Tennessee consumers do you process? Do you derive 50 percent or more of your gross revenue from selling personal information? If you are above the 25 million dollar revenue floor and meet one of the consumer thresholds, you are in scope.

Step two: inventory the cookies and similar technologies. Use a scanner, then validate manually. Tag each item with category, purpose, vendor, data types, retention, and any cross border transfer.

Step three: map the data flows. For each tag, walk the data through your stack and out to vendors. Note every place personal information lands. Mark anything that touches sensitive data or known children. The discipline of data mapping or data inventory is the foundation of every reliable cookies policy.

Step four: build the privacy notice. It must explain rights, list categories of personal information, disclose sale and targeted advertising, include the appeal mechanism, and be reachable from a conspicuous link.

Step five: build the cookies policy as either a standalone page or a clearly delineated section of the privacy notice. Mirror the categories and purposes from your inventory. Be specific about vendors.

Step six: configure the CMP. Banner with equal weight Accept and Reject. Granular preference center. Persistent reopen mechanism. GPC detection (best practice). Consent state propagated to every tag and every server side pipeline.

Step seven: build the rights workflow. Even though this article is focused on cookies, the cookies opt out is one piece of a broader rights workflow. Access, correction, deletion, portability, and opt out all need processes. Our companion TIPA DSAR Policy article covers the rights workflow in depth.

Step eight: build the NIST aligned program. Document each NIST Privacy Framework function and how your controls map to it. This is what unlocks the affirmative defense.

Step nine: train the team. The marketing team needs to know what changed. The product team needs to know what tags are conditional. Legal and engineering need a shared vocabulary.

Step ten: test, then monitor. Click Reject all and verify nothing fires. Send a GPC header and verify the right downstream behavior. Set up monitoring so a new tag introduced by a marketing manager does not break the policy.

Step eleven: review on a cadence. Quarterly at minimum. Update the privacy notice. Refresh the cookie inventory. Re audit vendor contracts.

This is a lot. It is also achievable. Getting through these eleven steps with a real team and a real stack is exactly what AdOpt does for clients in Tennessee, the rest of the U.S., Brazil, and Europe.

Most teams reach for an analogy when they meet a new law. Here are the most useful ones for the TIPA Cookies Policy.

Compared to the CCPA/CPRA, the TIPA looks similar in structure but with a higher applicability bar (the 25 million dollar revenue floor) and a narrower sale definition (monetary consideration, not "valuable consideration"). California's "Do Not Sell or Share My Personal Information" link has a sibling in Tennessee, but TIPA does not require GPC handling by statute, and TIPA includes the NIST aligned affirmative defense and the 60 day cure period.

Compared to the VCDPA, CPA, CTDPA, the TIPA is structurally very close. The opt outs are similar. The rights are similar. The processor contract requirements are similar. The differences sit in the details: thresholds, cure periods, GPC handling, and the NIST defense.

Compared to the GDPR, the TIPA is more permissive about cookies on the surface (opt out, not opt in, for the general case), but the gap closes when sensitive data, known children, or specific use cases come into play.

For European audiences, the GDPR cookies framework still applies on top of any U.S. state law if the same site serves both. Our explainer on GDPR legal bases is useful when you have to reason about where consent is required versus where another basis works.

Compared to the LGPD in Brazil, the TIPA shares the structure of consumer rights and controller responsibilities, but the LGPD has a broader concept of legal bases. Brazilian readers can ground the comparison in the legal bases of the LGPD primer.

If your team is building a single cookies policy for the whole U.S., you can use the TIPA's structure as a backbone and layer in the state specific requirements where they diverge. The NIST aligned program is portable across regimes.

We are biased, of course, because this is what we do. But here is the honest version of how AdOpt approaches a Tennessee rollout.

We start with discovery. We scan the site, walk the tags, map the flows, and identify where personal information is moving and to whom. We do this with a checklist that maps to TIPA, CCPA, GDPR, and LGPD obligations, so you do not have to redo the work for the next state law.

We help draft or review the privacy notice and the cookies disclosures, in plain language. We strip out the legalese and rebuild the disclosures so a Tennessee consumer can actually understand what is happening.

We deploy and configure the AdOpt CMP, with the banner, preference center, GPC detection (best practice even though TIPA does not require it), consent propagation, server side support, and analytics that you need. We integrate with your tag manager. We build the consent state into your data layer so your engineering team has a single source of truth.

We build the NIST aligned documentation. The framework's functions and categories are mapped to your controls, with evidence of operation. This is what gives you the affirmative defense if a TIPA enforcement action ever comes.

We set up the rights workflow. The cookies opt out is one piece, but consumers also need access, correction, deletion, and portability. We connect the dots so the same identity can be honored across all rights.

We train your team. Marketing, product, engineering, legal, and customer support each need a slightly different briefing. We deliver them and document them.

We monitor and maintain. The work does not stop on launch day. We watch for new tags, new vendors, regulatory updates, and signal changes, and we keep the policy and the technical implementation in sync.

This is the value. A defensible TIPA Cookies Policy is not a PDF. It is the alignment of policy, design, technology, and operations. AdOpt brings that alignment.

Let us make this concrete. Imagine a national retailer with 200 million dollars in annual revenue, 300,000 Tennessee customers, and a typical e commerce stack: Shopify, Klaviyo, Meta Pixel, Google Ads, GA4, Hotjar, plus a dozen other vendors. The retailer is squarely in TIPA scope.

Before the rollout, the retailer has a generic CCPA banner and a privacy policy that mentions cookies in passing. There is a "Do Not Sell or Share My Personal Information" link in the footer. There is no NIST aligned documentation. The cookie banner has an "Accept all" button and a "Settings" link in tiny text. The Reject path is three clicks deep.

Walking through the TIPA roadmap with this retailer surfaces:

The retailer sells personal information through Meta Pixel and Google Ads. The privacy notice does not currently disclose this in the way TIPA requires. The privacy notice is reachable but the link is not conspicuous enough by TIPA's "reasonably accessible" standard.

The cookie banner does not honor GPC (best practice gap). Several "necessary" cookies are actually attribution beacons (categorization gap). There is no NIST aligned documentation, which means no affirmative defense. The DSAR process is an email address in the privacy policy, not an integrated portal.

After the rollout: the privacy notice is rewritten in plain language, with rights, last updated date, appeal mechanism, and clear disclosures. The footer gets a more conspicuous "Privacy" link and a "Privacy Choices" link. The cookie banner is rebuilt with equal weight Accept and Reject buttons, GPC detection, and a persistent reopen icon.

Tag categorization is fixed: attribution beacons move into the advertising bucket. The DSAR portal is integrated with identity verification and a 45 day SLA. A vendor inventory is published internally, with contracts updated to TIPA standards. A NIST aligned program is documented with controls mapped to each function.

This retailer is now defensible. Not perfect, because nothing is, but defensible. It has a real TIPA Cookies Policy in place of a copy pasted banner, and it has the NIST defense in place if the AG ever comes calling.

For a story driven take on what happens when brands skip this work, our piece on a company that got fined is a useful gut check.

The TIPA grants the Tennessee Attorney General exclusive enforcement authority. There is no private right of action. Enforcement actions can result in civil penalties up to 7,500 dollars per violation, plus treble damages for willful violations, plus reasonable attorney fees and costs.

A few details about enforcement that affect your TIPA Cookies Policy:

The 60 day cure period is meaningful. If the AG sends a notice, the controller has 60 days to cure. A controller with a tight feedback loop and an active privacy program can usually cure within that window. The treble damages provision is significant. Willful violations can be punished at three times the actual damages. That can compound quickly, especially when the violation affects many consumers.

The NIST aligned affirmative defense is real. A controller with a documented program that reasonably conforms to NIST has a defense, regardless of whether the violation was technically cured. The lack of a private right of action means consumer led class actions cannot proceed under TIPA itself. This reduces some of the risk vectors that exist in other states.

For more on how privacy fines compound across regimes, our piece on fines under the LGPD is a useful comparator.

The single most useful question to ask inside your organization is "who owns this?" Not in a finger pointing way. In a "who is accountable" way.

The owner can be a Chief Privacy Officer, a Data Protection Officer, a privacy program manager, or a designated counsel. The role matters less than the clarity. The owner makes the final call on whether a tag fires, what category it belongs to, and how the disclosure reads. They also coordinate with marketing, product, engineering, customer support, and finance, because each of those teams interacts with cookies in a different way.

Our take on the DPO and team work walks through the team shape that supports this kind of accountability.

Modern advertising and analytics stacks lean heavily on server side or hybrid pipelines. Conversions API for Meta. Enhanced Conversions and server side GTM for Google. Custom pipelines that ingest first party data, hash it, and push it to an ad platform.

Server side pipelines are not exempt from the TIPA Cookies Policy. They are still processing personal information. They still require the same disclosures, the same opt out mechanisms, and (best practice) the same respect for universal opt out signals. The fact that the user does not see a cookie set in their browser does not change the underlying data flow.

If your team has been adopting server side as a way to "get around" cookie restrictions, that strategy will not survive contact with the TIPA or its sister laws. The right way to think about server side is as a more efficient, more reliable transport for the same data, governed by the same rules.

Disclosures are public. Documentation is internal. Both matter for your TIPA Cookies Policy. Documentation also feeds the NIST aligned affirmative defense.

Practical advice: store consent receipts that include the version of the banner shown, the categories accepted, the timestamp, and the resulting consent state. Store opt out events with similar fidelity. Run a quarterly audit that reconciles the documentation with the live behavior of the site. Treat any discrepancy as an incident.

For a primer on the kind of records modern privacy law expects, our explainer on ROPA for LGPD is a good cross reference. The TIPA does not use the term ROPA, but the discipline of records of processing activities maps well to the NIST framework's Identify and Govern functions.

A full TIPA Cookies Policy also has to think about the customer lifecycle, not just the homepage. Each phase has its own data flow.

In acquisition, the cookies running on landing pages, ad campaigns, and search traffic are mostly advertising and analytics. The opt out and consent posture has to be configured before the first paid impression hits Tennessee.

In conversion, the checkout or signup flow tends to use functional and necessary cookies, plus analytics. Care here is mostly about not letting marketing tags pollute the checkout context (or, if they have to be there for attribution, gating them on consent).

In retention, account areas, dashboards, and product surfaces use functional and analytical cookies. Subtle errors creep in: a "session replay" tool that records sensitive data, a "feature flag" tool that profiles users for experiments, a CRM enrichment that quietly resells personal information.

In support, chat and ticketing systems often set their own cookies and collect personal information for support purposes. Make sure the cookies disclosure covers them.

In offboarding, when a customer deletes their account, your cookies and downstream pipelines should not retain identifiers indefinitely. Tie the deletion event to consent revocation across the stack.

A defensible TIPA Cookies Policy is not the result of one sprint or one document. It is the result of privacy by design culture. Every new feature, every new vendor, every new campaign should be evaluated for privacy impact before it ships, not after.

The privacy by design discipline asks teams to:

Default to the privacy preserving option. Only collect personal information necessary for the disclosed purpose. Embed privacy controls into the architecture, not bolted on. Make the user experience transparent. Treat the user as a partner, not as data.

Applied to cookies, this means picking analytics that does not need to track individuals when aggregated metrics are enough. Choosing CDPs and ad platforms that support consent state natively. Designing experiments that do not require profiling at all when an A/B with random assignment will do. Documenting these decisions.

The marketing team usually feels the most heat when a new privacy law lands. The list of things they cannot do gets longer. The list of things they have to disclose grows. Attribution gets harder. Ad performance dips during the transition.

The honest answer is that good marketing under the TIPA is still possible, and often better. Our explainer on adapting digital marketing covers the operational shifts. The same playbook works.

In short: lean into first party data and consented audiences. Use server side pipelines (with consent state) to improve match rates without dropping a fingerprintable third party cookie everywhere. Invest in measurement that respects the consent state. Modeled conversions are a real thing now. Use them. Re evaluate the marketing tech stack. Tools that cannot operate inside a clean consent regime are tools that will hurt you.

The sky is not falling. The marketing team will be fine. Your TIPA Cookies Policy is an opportunity to clean house, not a sentence.

For more on the risky processes in marketing that turn into compliance problems, our explainer is a useful read.

Three documents people confuse. Quick mental model:

The privacy policy (also called privacy notice) is the comprehensive disclosure of personal information practices. It explains what you collect, why, who you share with, the rights consumers have, and how to exercise them. The TIPA mandates the existence and content of this document. Our explainer on what a privacy policy is gives the structure.

The cookies policy is a focused subset that explains the cookies and similar technologies you use. It can live as a standalone page or as a section within the privacy policy. The TIPA Cookies Policy discussion sits here.

The terms of use (or terms of service) is the contract between you and the user about how the service is used. Our piece on terms of use and the companion piece on user notification walk through the differences.

You need all three. They have to be consistent.

If you run on WordPress, Shopify, or another platform, your TIPA Cookies Policy still applies, but the implementation often runs through plugins or apps. The danger here is that platform plugins ship with default configurations that may not reflect your actual data flows.

For WordPress specifically, our deep dive on WordPress cookies plugins walks through what a good plugin looks like and how to avoid the bad ones. The same principles apply to Shopify apps, Webflow templates, and Squarespace builders.

Whatever platform you use, do not let the plugin decide your cookies policy. The plugin executes your decisions. You decide.

It helps to ground the TIPA Cookies Policy discussion in specific cookies you are likely to find on your site. Below is a tour of common cookies and how each one fits into the Tennessee framework.

Strictly necessary cookies: session ID, CSRF token, load balancer hash, language and currency selection, cart contents on an e commerce site, secure login state, fraud prevention identifiers tied to authentication. These do not require consent under any major privacy regime, and your TIPA Cookies Policy would describe them as necessary for the service to function.

Functional cookies: video player position, accessibility preferences, theme selection, recently viewed products, region or store selection, customer support widget identifiers used to route the user back to the same agent on return. These improve the experience but the site still works without them.

Analytics cookies: page view identifiers, session continuity for analytics, custom event identifiers used by GA4 or another analytics vendor, A/B test bucket assignments. Whether these cookies need consent depends on the configuration.

Advertising cookies: ad network identifiers, retargeting pixels, conversion tracking pixels, audience segmentation cookies, lookalike modeling identifiers. These almost always involve sale of personal information or targeted advertising as defined by the TIPA. They go behind the opt out.

Profiling cookies: identifiers used to build behavioral profiles for high stakes decisions (credit, employment, insurance, housing). Where they exist, the TIPA Cookies Policy must offer the explicit opt out of profiling for significant decisions.

Social plugin cookies: Facebook Like, Twitter share, LinkedIn share, embedded YouTube videos. Treat them like advertising cookies for compliance purposes unless your vendor has documented otherwise.

A complete cookie audit walks each cookie on your domain, identifies its category, identifies the vendor, identifies the data sent, identifies the retention, and produces a row in your inventory. Without that table, your TIPA Cookies Policy is theory.

Cookie lifetime is more than a technical detail. It is a privacy lever. A cookie that expires in 24 hours has a much smaller surface area than a cookie that persists for 24 months. The TIPA does not pick a magic number, but it does require that personal information be processed only for purposes disclosed and only for as long as necessary for those purposes.

For your TIPA Cookies Policy, consider:

Session cookies that expire when the browser closes are usually lower risk. Short lived persistent cookies (a few hours to a few days) are appropriate for analytics, fraud, and similar use cases. Medium lived cookies (a few weeks to a few months) often cover retargeting and attribution windows. Long lived cookies (a year or more) require the strongest justification.

When you renew a cookie, document why. The renewal logic should be tied to the disclosed purpose. A cookie that quietly extends itself into a multi year identifier is an integrity problem.

Renewal also matters for consent. If you rely on consent for an advertising cookie, the consent record itself has a lifetime. Best practice is to expire the consent on a defined cadence (often annually) and reprompt.

Here is a workflow we use at AdOpt when running a cookie audit for a client preparing their TIPA Cookies Policy.

Step one: scan. Use a privacy scanner to crawl the site and enumerate cookies, pixels, and SDKs. The scan should cover authenticated and unauthenticated paths, multiple device types, and key user flows.

Step two: validate. Manually walk the most important pages. Open the developer tools, watch the network tab, and look for tags that the scanner missed.

Step three: categorize. For each cookie or tag, document the category, vendor, data sent, retention, and consent state required. Be strict.

Step four: cross reference with the disclosures. Open the current cookies policy and privacy notice. Are all the categories represented? Are the vendors named? Are the purposes disclosed? Mark every gap.

Step five: cross reference with vendor contracts. For each vendor, do you have a contract that satisfies TIPA? If not, that is a finding.

Step six: simulate. Click "Reject all" on the banner and verify nothing fires. Send a Global Privacy Control header and verify the right downstream behavior. Try the preference center and toggle each category.

Step seven: document. Produce a report with findings, severity, and remediation. Tie each finding to a specific TIPA provision and to the relevant NIST function so the program team can prioritize and the affirmative defense documentation gets updated.

Step eight: remediate. Fix the gaps. Most are configuration. Some are contract. A few are architectural and take longer.

Step nine: re audit. Quarterly is the right cadence for a healthy program. Monthly for a high tag count environment in active growth.

Step ten: keep the audit trail. The next time someone asks "how do you know your TIPA Cookies Policy is up to date?", you have a paper trail.

The privacy era is also the first party data era. Brands that lean into first party data, with consented audiences and clean activation pipelines, tend to do better both in compliance and in marketing performance.

Your TIPA Cookies Policy should support a first party strategy. That means reducing reliance on third party cookies, investing in first party data collection with a clear value exchange, building a CDP or equivalent that respects consent state from end to end, activating that data only through pipelines that support consent enforcement and signal propagation, and measuring with attribution methods that work in a consent constrained world.

A first party strategy also tends to reduce the complexity of your cookies policy simply because there are fewer third parties to disclose. That makes the policy more honest and easier to maintain.

For more on how marketing agencies adapt to privacy law, our explainer on LGPD as opportunity for digital marketing agencies translates well to the TIPA context.

Compliance is about the user, even when the team building it forgets that. A consumer in Nashville should be able to land on your site, see a banner that does not insult their intelligence, click a single button to reject what they want to reject, and trust that the rest of the experience will respect that choice.

That trust is built one detail at a time. The wording of the banner. The visual weight of the buttons. The promptness of the response when someone opts out. The clarity of the privacy notice when they go looking. The follow through when a tag is removed and stays removed.

When users want to know what to do on their side, our short guide on how to delete cookies and clear cache is a useful link to share. It is a small kindness in your support center that signals the brand cares.

A Tennessee consumer who feels respected on your site is a better consumer. They convert more, churn less, and complain to the AG less. Your TIPA Cookies Policy is, in some ways, a customer experience document as much as a legal one.

The TIPA is part of a larger U.S. privacy patchwork that keeps growing. By the time you finish a Tennessee rollout, another state will have a new law, or an existing law will be amended. The federal landscape may also shift.

The right posture is to build a program that absorbs change without rewriting itself. That means a TIPA Cookies Policy that follows the principles of comprehensive privacy law, not one that hardcodes Tennessee specific phrases everywhere. It means a CMP and stack that can adapt to new signals and new categories. It means documentation that answers the next regulator's questions, not just today's.

The teams that have invested in good privacy hygiene over the last few years are finding the TIPA easier than expected. The teams that have not are finding it harder than expected. Both are normal. The work pays back in both directions.

For broader context on how privacy laws compare and where the TIPA fits, our explainer on the GDPR, LGPD, and CCPA is the right starting point. The piece on the key differences between LGPD and GDPR shows how subtle differences in definitions matter, which is exactly the kind of analysis you need across U.S. state laws too.

A defensible TIPA Cookies Policy is not glamorous work. It is patient, careful, cross functional work. It pays back in three ways: lower regulatory risk, the affirmative defense if the AG ever knocks, and higher customer trust. All three compound.

The teams that handle this well treat it as a recurring discipline, not a one time project. They build the muscle. They train the team. They invest in tools that propagate consent state end to end. They keep the disclosures honest. They document the program against NIST so the affirmative defense is real, not theoretical.

The teams that handle this badly skip steps, copy templates, hope nobody looks, and find out the hard way that the Tennessee Attorney General does look. The 7,500 dollars per violation cap is the floor of the cost, not the ceiling, especially with the treble damages provision for willful violations.

If your TIPA Cookies Policy is on your plate today, the right move is to start with discovery, build the foundation, document against NIST, and pick partners who know what they are doing. AdOpt is one of those partners. We would love to help.

Yes, in most cases, but only if you exceed the 25 million dollar annual revenue threshold and meet one of the consumer based thresholds (175,000 Tennessee consumers, or 25,000 plus 50 percent of revenue from sale of personal information).

The TIPA applies to entities that conduct business in Tennessee or produce products or services targeted to Tennessee residents who meet those thresholds. A physical Tennessee office is not required. An online business with Tennessee customers can absolutely be in scope, but the revenue floor filters out a large number of smaller companies that would be in scope under California or Colorado.

It is mostly opt out. For sale of personal information, targeted advertising, and profiling for significant decisions, consumers must be able to opt out. For sensitive data (which includes precise geolocation, health diagnosis, sexual orientation, religious beliefs, biometric data processed for unique identification, citizenship or immigration status, and personal information of known children) the TIPA requires consent.

Known children's data is also governed by COPPA, incorporated by reference. So your TIPA Cookies Policy has to support both opt out and opt in flows, depending on the cookie's data category and audience.

The TIPA includes a unique provision: controllers and processors that voluntarily create, maintain, and comply with a written privacy program reasonably aligned with the NIST Privacy Framework (or comparable framework) can use that program as an affirmative defense in a TIPA enforcement action.

It is voluntary. But for a controller that is in TIPA scope, the defense is a real strategic asset. Our recommendation is to align with NIST and document the alignment. The work also strengthens your posture across other state laws and global regimes.

Strictly speaking, no. The TIPA is silent on universal opt out signals, and there is no statutory obligation to detect and respond to GPC. However, honoring GPC is best practice, especially if you operate in other states (California, Colorado, Connecticut, Texas) that do require it.

Building a single posture that honors GPC across all consumers reduces complexity. It also strengthens your NIST defense by demonstrating good faith beyond the literal requirements. Our TIPA Cookies Policy recommendation is to honor GPC.

You have 60 days to cure the violation. If you cure it within 60 days and provide written notice to the AG that the violation has been cured, the AG cannot bring an enforcement action for that violation. The cure period is permanent under TIPA, not sunset.

To take advantage of it, you need a privacy program that can identify the violation, fix it, and document the cure within the window. If you have a NIST aligned program, you also have the affirmative defense to fall back on if the cure is contested. A good TIPA Cookies Policy treats the cure period as a feature, not a backstop.

If you read this far, you already know that a real TIPA Cookies Policy is more than a banner and a footer link. It is policy, design, technology, and a NIST aligned program working together, end to end, across your stack. AdOpt builds and maintains that for hundreds of brands across the U.S., Brazil, and Europe.

The fastest way to find out what your specific compliance gap looks like and how AdOpt can close it is a quick conversation with our team.

Book a meeting with the AdOpt team and let us walk through your site, your stack, and your Tennessee exposure. We will give you a clear path forward, with or without us. Better to know than to guess. The Tennessee AG is not in the guessing business, and neither should you be.