Most marketing and product teams across the U.S. spent years tuning their cookie strategy around the GDPR, the CCPA/CPRA, and a handful of state laws.

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

Then Montana joined the party. Senate Bill 297 revised the Montana Consumer Data Privacy Act, and pulled the threshold for who must comply way. Suddenly, a regional e-commerce store, a SaaS company with a few thousand Montana users, or a media site running display ads has to look at its cookies policy with fresh eyes.

This article exists to help you do exactly that.

Just a clean, careful walkthrough of how the MTCDPA Cookies Policy affects the cookies on your site, what your banner and notice need to say, how consent should work, and where Montana is stricter than people expect.

If you want the long version, keep reading. We are going to take this one piece at a time.

The Montana Consumer Data Privacy Act is Montana's comprehensive consumer privacy law. It is codified at MCA 30-14-2801, et seq., and was significantly revised by Senate Bill 297, which takes effect on October 1, 2025. SB 297 lowered the applicability thresholds, tightened the privacy notice obligations, beefed up the rules around minors, and added clear civil penalties.

If your team has been working with the CCPA, Connecticut, Virginia, or Colorado privacy laws, the MTCDPA will feel familiar.

The structure is similar: rights for consumers, responsibilities for controllers and processors, a privacy notice obligation, and an opt out for sale, targeted advertising, and profiling. The differences sit in the details, and those details show up most clearly when you look at how cookies work in practice.

A useful mental model is to think about the MTCDPA as a law about personal data flows, not about cookies themselves. The law does not ban cookies. It does not even mention them by name in most provisions. What it says is that personal data has to be processed for disclosed purposes, that consumers have rights over that data, and that controllers must offer effective ways to exercise those rights.

Because most modern cookies either contain personal data, link to personal data, or feed personal data into third party platforms, almost every meaningful MTCDPA Cookies Policy discussion ends up being a personal data discussion in disguise.

If you want a primer on how laws like this think about personal data, our explainer on general data protection law is a good companion read. The principles travel well across jurisdictions.

Under SB 297, the MTCDPA applies to entities that conduct business in Montana or deliver commercial products or services intentionally targeted to Montana residents, and that control or process the personal data of:

• 25,000 or more consumers (lowered from 50,000), or
• 15,000 or more consumers if they derive over 25 percent of their revenue from the sale of personal data (lowered from 25,000).

Notice what changed: those thresholds are roughly half of what they used to be. A business that previously sat below the line because it had 30,000 or 40,000 Montana users is now squarely in scope.

A business that monetizes through ad networks and ad exchanges, where every page view can become a sale of personal data, has to look at the lower 15,000 threshold and be honest with itself.

The exemptions also tightened. SB 297 removed the broad Gramm-Leach-Bliley Act entity exemption (banks, credit unions, insurers, and insurance producers still benefit from a data level exemption, but the entity wide carveout is gone), and limited the nonprofit exemption to organizations focused on detecting or preventing fraud in connection with insurance.

For your MTCDPA Cookies Policy, this means three practical things.

First, the people who escaped the first wave of state privacy laws will not necessarily escape Montana.

Second, even financial institutions and insurers must look at the data flows on their public marketing sites, where MCA Title 30 will reach the cookies regardless of the entity exemption that protects their core operations.

Third, the bar for what counts as a "small enough to ignore" Montana audience is now low enough that most national U.S. websites should plan for compliance by default.

If you sit on the fence and want to think clearly about thresholds, our analysis of the LGPD gives a good comparison: like the MTCDPA, LGPD scope is built around data flows rather than headcount. The intuition transfers neatly.

Cookies are the connective tissue of the modern web. Authentication, language preferences, A/B testing, session continuity, fraud prevention, attribution, retargeting, audience building, conversion tracking, lookalike modeling, and most of programmatic advertising all rely on cookies in some form. They are also the most visible privacy artifact on a website.

When a Montana resident lands on your homepage and sees a banner, that banner is the public face of your MTCDPA Cookies Policy even if you do not call it that.

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

The MTCDPA grants consumers the right to opt out of the sale of personal data, the use of personal data for targeted advertising, and the use of personal data for profiling in furtherance of decisions that produce legal or similarly significant effects.

Most of these activities, in practice, rely on cookies and similar technologies (pixels, SDKs, fingerprinting). If you want to honor those opt outs technically, you have to be able to control your cookies and the data they emit.

The MTCDPA requires the privacy notice to be posted online through a conspicuous hyperlink using the word "privacy" on the homepage. That hyperlink is also where most users will look for your cookies disclosures, especially under the new SB 297 rules that obligate controllers to disclose targeted advertising and the sale of personal data clearly and conspicuously.

The MTCDPA requires an effective mechanism for consumers to exercise their rights or revoke consent that is at least as easy to use as the mechanism for giving consent. If your banner takes one click to "Accept all" and twelve clicks to "Reject all," the law has something to say about that.

To understand how a cookie banner interacts with this kind of obligation, the AdOpt guide on choosing a cookie banner is a good starting point. The same engineering and UX principles apply when you adapt the banner for MTCDPA.

Let us slow down and be careful about terminology, because the MTCDPA 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 MTCDPA, the legal weight of a cookie depends on what it actually does with personal data, 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 MTCDPA cares about the data flow.

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

For the difference between cookies and the cousins your engineering team probably also uses (localStorage and sessionStorage), the AdOpt guide on the difference between cookies, local storage and session storage is short, useful, and surprisingly important when you draft notice text.

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

The phrase "reasonably linkable" is doing a lot of work. Online identifiers, IP addresses (especially full ones), device IDs, cookie IDs that persist across sessions, and hashed identifiers used for ad targeting are all routinely treated as personal data 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 MTCDPA Cookies Policy, the practical implication is that you cannot wave away third party advertising cookies as "anonymous." If your vendor uses the cookie ID to build a profile, match against a graph, or sync to another platform's ID, your cookies policy is in personal data territory.

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

SB 297 obligates controllers to include in the privacy notice an explanation of consumer rights under the MTCDPA, the date the notice was last updated, and clear and conspicuous disclosures of any sale of personal data or processing of personal data for targeted advertising, plus a clear and conspicuous method for consumers to opt out of those activities.

Your MTCDPA Cookies Policy is the part of that notice that translates these requirements into the cookie reality of your site. At a minimum, expect to disclose:

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

The third parties that may receive personal data through cookies, with enough detail that a consumer can recognize who those parties are. Whether any of the cookies result in a sale of personal data 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, AdOpt's primer is a good template. The structural advice transfers.

Here is where the U.S. patchwork gets confusing for teams used to GDPR style thinking. The MTCDPA, like most U.S. state privacy laws, is generally an opt out regime for the headline activities (sale of personal data, 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.

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 MTCDPA also requires that you honor opt out preference signals (sometimes called "universal opt out mechanisms" or "Global Privacy Control" in other states). If a Montana resident's browser is sending a recognized opt out signal, your cookie stack has to respect it.

Second, for processing of sensitive data the MTCDPA requires consent (an affirmative opt in). Sensitive data includes data revealing racial or ethnic origin, religious beliefs, mental or physical health diagnosis, sexual orientation, citizenship or immigration status, genetic or biometric data, precise geolocation data, and personal data of a known child. 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 minors, SB 297 strengthens the duty of care standard and obligates controllers offering an online service, product, or feature to a minor to use reasonable care to avoid heightened risks of harm. In practice, this means you should configure your cookies and ad targeting more conservatively for known minors, regardless of what the default user experience is. We talk more about consent on websites and what makes consent valid in our consent and websites primer.

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

The MTCDPA does not prescribe a specific banner layout. What it requires is that your mechanism for honoring rights and revoking consent be at least as easy to use as the mechanism for giving consent. 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 article on the operation of a cookie banner walks through the practical UX patterns. The same patterns that satisfy the GDPR satisfy the MTCDPA, with a few tweaks.

For Montana specifically, we recommend the following design choices when implementing a MTCDPA 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 that revoking consent is as easy as granting it.

Plain language descriptions of each category, with examples of vendors. A clear statement of the user's rights, with a link to your full privacy notice. A mechanism that detects opt out preference signals from the browser 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 MTCDPA 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.

These three terms are the MTCDPA's most consequential opt out categories, and all three intersect with cookies. Let us look at each.

Targeted advertising under the MTCDPA generally means displaying advertisements to a consumer where the advertisement is selected based on personal data obtained 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 MTCDPA Cookies Policy must let consumers turn this off.

Sale of personal data under the MTCDPA, like in many U.S. state laws, is broader than the dictionary definition. It means the exchange of personal data for monetary or other valuable consideration.

When a third party advertising vendor receives data through your cookies and provides analytics, identity resolution, or audience expansion in return, that exchange may qualify as a sale even though no money changes hands. Honest cookie audits routinely find selling activity in places that the marketing team did not call selling. Your MTCDPA Cookies Policy has to disclose this and offer the opt out.

Profiling under the MTCDPA, 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 MTCDPA 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 MTCDPA 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 the U.S. state law family that the MTCDPA belongs to, the AdOpt comparative explainer on GDPR, LGPD and CCPA is a good cross reference.

When personal data 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 MTCDPA 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.

SB 297 explicitly raises the bar for minors. Controllers offering an online service, product, or feature to a consumer the controller knows or willfully disregards is a minor must use reasonable care to avoid a heightened risk of harm caused by the service.

For your MTCDPA Cookies Policy, this means:

If you operate a site or feature directed to minors, you should not load advertising or profiling cookies by default. You should not infer "old enough" from browser fingerprints. You should design the experience so that even if a known minor sneaks past your gating, the data flows do not amplify risk.

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

If you sell sensitive data of any consumer, you cannot do so without consent. For minors, default settings should be even more conservative.

This is a place where the MTCDPA leans into design more than disclosure. A pristine cookies policy that still drops third party retargeting on a teen's browser fails the duty of care, regardless of how good the text is. We unpack the responsibilities of a data protection officer and the team work it takes to operationalize this kind of duty in our DPO guide.

A piece of the MTCDPA that often gets overlooked: the law expects controllers to honor opt out preference signals. If a consumer's browser is broadcasting a signal like Global Privacy Control, your MTCDPA Cookies Policy must respond. That means your CMP and tag manager have to detect the signal and translate it into the right downstream behavior: blocking sale, blocking targeted advertising, blocking profiling.

Under the hood, this looks like a few things working together. Your CMP detects the GPC header on the request. Your tag manager reads the signal and conditionally fires the necessary tags. Your server side endpoints respect the signal too, because some pipelines (server to server APIs to ad platforms) bypass the browser entirely.

Honoring universal opt out signals is one of the most under invested pieces of compliance. Many companies have a banner that "rejects" cookies on click, but their server side pixels keep firing because nobody propagated the signal upstream. The MTCDPA, like its sister laws, does not let you off the hook because the leak is in your middleware.

This is one of the reasons the choice of a consent management platform (CMP) matters so much. A CMP that does not propagate signals end to end is a CMP that will get you fined. The discipline AdOpt brings here is exactly what an MTCDPA Cookies Policy rollout needs.

Almost every cookie problem in a modern stack ends up being a vendor management problem. If your MTCDPA Cookies Policy says you do not sell personal data, 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 Montana traffic. Updated quarterly at minimum. Quarterly is the floor; for high tag count environments, monthly is more realistic. For each vendor, a documented purpose, a category, the type of personal data it receives, the legal basis, and the consent state required to fire it.

Contracts that satisfy MCA 30-14-2813. The MTCDPA 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 infamous "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, AdOpt's primer on the differences explains the legal shape of the relationship.

Reading dozens of cookie banners and notices, the same handful of mistakes show up over and over. Some are honest mistakes. Some are convenient mistakes. Either way, they create exposure. Here are the ones we most often see in early MTCDPA 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 homepage hyperlink containing the word "privacy."

Mistake two: copying and pasting from a CCPA template without adjusting for SB 297. Montana has its own thresholds, its own minor rules, and its own mention of universal opt out signals. 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 MTCDPA, like its sister laws, has no patience for this. If your reject does not reject, your 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. Our guide on why the cookie banner exists walks through the spirit of the rule.

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 MTCDPA Cookies Policy has to cover those pipelines too, even though the consumer never sees a cookie.

Mistake six: not respecting global opt out signals. We covered this above, but it is worth repeating: if you do not detect and propagate GPC and similar signals, you are not compliant. Period.

Mistake seven: the privacy notice is buried. SB 297 requires the privacy notice to be reachable through a conspicuous hyperlink using the word "privacy" on the homepage. A footer link in 9 point gray text on a white background is not conspicuous.

Mistake eight: forgetting accessibility. SB 297 requires the privacy notice to be reasonably accessible to and useable by individuals with disabilities. Your banner and your notice must work with screen readers, keyboard navigation, and adequate contrast.

Mistake nine: not localizing to the audience. The MTCDPA requires the privacy notice to be available in each language in which the controller offers the product or service. Your MTCDPA Cookies Policy has to follow.

Mistake ten: treating the MTCDPA as a one time project. The law evolves. The thresholds dropped already. They could drop again. The duty of care for minors will be tested in enforcement. Your policy is a living document, not a one and done.

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

If you are implementing or refreshing your MTCDPA Cookies Policy from scratch, here is the order we recommend. This is the same order we would walk a customer through on day one.

Step one: confirm scope. Run the numbers. How many Montana consumers do you process? Do you derive 25 percent or more of your revenue from selling personal data? Do you intentionally target Montana residents through your products or services? If yes to any of the gating questions, 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 data lands. Mark anything that touches sensitive data or minors. 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 data, disclose sale and targeted advertising, include the date of last update, and be reachable from a conspicuous "privacy" hyperlink on the homepage.

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. Consent state propagated to every tag and every server side pipeline. This is where the platform you choose matters more than anywhere else.

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. We have a separate article on the DSAR workflow you should pair with this one.

Step eight: 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 nine: 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 ten: review on a cadence. Quarterly at minimum. Update the "last updated" date in the privacy notice. Notify users when a material change occurs and offer them a reasonable opportunity to withdraw consent.

This is a lot. It is also achievable. The reason we wrote this is that getting through these ten steps with a real team and a real stack is exactly what AdOpt does for clients in Montana, 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 MTCDPA Cookies Policy.

Compared to the CCPA/CPRA, the MTCDPA looks similar in structure but lower in threshold and stricter on minors. The "do not sell or share my personal information" link in California has a sibling in Montana, but the MTCDPA bundles sale, targeted advertising, and profiling for significant decisions into a unified opt out logic. The opt out preference signal expectation is similar.

Compared to the GDPR, the MTCDPA is more permissive about cookies on the surface (opt out, not opt in, for the general case), but the gap closes when sensitive data, minors, or known children 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 MTCDPA 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.

Compared to other state laws (Connecticut, Virginia, Colorado, Texas, Oregon, Delaware, Iowa, Indiana, Tennessee, New Hampshire, New Jersey, Kentucky, Maryland, Minnesota, Rhode Island), the MTCDPA fits in the "comprehensive consumer privacy law" family with its own twists, especially around the lower SB 297 thresholds and the duty of care for minors.

If your team is building a single cookies policy for the whole U.S., you can use the MTCDPA as the floor in most cases and stay safe with most of the others. But you should still review state by state for edge cases.

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

We start with discovery. We scan the site, walk the tags, map the flows, and identify where personal data is moving and to whom. We do this with a checklist that maps to MTCDPA, 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 Montana consumer can actually understand what is happening.

We deploy and configure the AdOpt CMP, with the banner, preference center, GPC detection, 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 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 (the GPC ecosystem is evolving), and we keep the policy and the technical implementation in sync.

This is the value. A defensible MTCDPA 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 U.S. e commerce brand that sells outdoor gear, with Montana customers concentrated in towns like Missoula and Bozeman. The site uses Shopify, Klaviyo, Meta Pixel, Google Ads, GA4, Hotjar, and a dozen other vendors. The brand was outside the old MTCDPA thresholds with 30,000 Montana customers but is now squarely inside under SB 297.

Before the rollout, the brand 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 mention of universal opt out signals. 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 MTCDPA roadmap with this brand surfaces:

The brand sells personal data through Meta Pixel and Google Ads. The privacy notice does not currently disclose this in the way SB 297 requires. The privacy notice is reachable but the homepage hyperlink does not use the word "privacy" in a conspicuous way.

The cookie banner does not honor GPC. Several "necessary" cookies are actually attribution beacons. There is no separate flow for known minors, even though the brand has a youth product line. 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, and clear disclosures. The homepage gets a conspicuous "Privacy Choices" link and a "Privacy" link to the full notice. 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. A separate flow for known minors disables targeted advertising and profiling cookies by default. The DSAR portal is integrated with identity verification and a 45 day SLA. A vendor inventory is published internally, with contracts updated to MCA 30-14-2813 standards.

This brand is now defensible. Not perfect, because nothing is, but defensible. It has a real MTCDPA Cookies Policy in place of a copy pasted banner.

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.

SB 297 adds a maximum civil penalty of up to 7,500 dollars per violation. The Montana Attorney General can also seek an injunction, plus reasonable attorney fees and costs related to investigation and enforcement. That is the headline number.

But a per violation penalty in privacy law is rarely a single check. Each violation can be counted per consumer, per data type, or per incident. A few thousand affected consumers and the math gets ugly fast. Add the AG's investigation costs, your own legal fees, and the brand damage of a public enforcement action, and the real cost of a failed MTCDPA Cookies Policy is much higher than the headline.

For a wider U.S. and global view of how privacy fines compound, the AdOpt piece on fines under the LGPD is useful. The principles and the math behave the same way across jurisdictions. The AdOpt explainer on marketing risk processes lists the operational missteps that turn into enforcement headaches.

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. Privacy programs that work have a clear answer. Programs that fail have a fuzzy one.

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, drawing on lessons from LGPD compliance that translate well to MTCDPA. The titles change, the structure does not.

SB 297 says that when a material change is made to a privacy notice or practices, the controller must notify consumers and provide a reasonable opportunity to withdraw consent. That obligation matters for your MTCDPA Cookies Policy.

A material change is not "we fixed a typo." It is a substantive change to the categories of personal data collected, the purposes of processing, the third parties with whom data is shared, the opt out mechanisms, the cookie categories themselves, or the way consent is collected.

The notification mechanism can vary, but it has to be effective. Email is the strongest channel for users with accounts. A banner or modal on the next session is reasonable for anonymous traffic. Just changing the "last updated" date and hoping people notice is not enough. Our take on notification to users for terms of use walks through how to design these notifications so they actually reach the user.

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 MTCDPA Cookies Policy. They are still processing personal data. They still require the same disclosures, the same opt out mechanisms, and 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 MTCDPA 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. AdOpt's tooling treats client and server consent state as the same state, propagated end to end. That is the only architecture that holds up.

Disclosures are public. Documentation is internal. Both matter for your MTCDPA Cookies Policy.

The MTCDPA expects controllers to document their compliance. That includes records of consent, records of opt outs, records of DSARs, records of data protection assessments for high risk processing, and records of vendor due diligence. Without documentation, you cannot prove you respected a user's choice. With documentation, you can.

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, the AdOpt explainer on ROPA for LGPD is a good cross reference. The MTCDPA does not use the term ROPA, but the discipline of records of processing activities maps directly to MTCDPA expectations.

A full MTCDPA 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 Montana.

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 data. Each of these has to be inventoried and gated.

In support, chat and ticketing systems often set their own cookies. They also collect personal data 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 MTCDPA 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 data 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 MTCDPA 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. They convert better and are more durable than third party audiences anyway. 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 MTCDPA Cookies Policy is an opportunity to clean house, not a sentence.

Three documents people confuse. Quick mental model:

The privacy policy (also called privacy notice) is the comprehensive disclosure of personal data practices. It explains what you collect, why, who you share with, the rights consumers have, and how to exercise them. The MTCDPA 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 MTCDPA 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. It is not a privacy document, but it touches privacy when it talks about acceptable use, suspension, account creation, and similar. 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. A cookie that is disclosed in the cookies policy but not the privacy policy is an inconsistency. The same goes for terms of use that grant rights you cannot honor under the privacy policy.

If you run on WordPress, Shopify, or another platform, your MTCDPA 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, we have a deep dive on WordPress cookies plugins that 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 MTCDPA 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 Montana 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 MTCDPA Cookies Policy would describe them as necessary for the service to function. Be careful not to abuse this category. A cookie that "could be necessary if we cared about marketing efficiency" is not necessary.

Functional cookies: video player position, accessibility preferences (font size, contrast), theme selection (dark or light mode), 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. Your cookies policy can describe them as functional. Some regimes treat them as not requiring consent. Under the MTCDPA, the safe path is to disclose them clearly and let users opt out if they want.

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. Aggregated, anonymized analytics with short retention is typically lower risk. Personally identifiable analytics with cross site joins is squarely in the personal data bucket and needs the disclosure and opt out treatment under the MTCDPA Cookies Policy.

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

Profiling cookies: identifiers used to build behavioral profiles for high stakes decisions (credit, employment, insurance, housing). These are rarer on public marketing sites but very common in fintech and insurance. Where they exist, the MTCDPA 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. These third party widgets often set cookies that go beyond the obvious widget functionality. 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 MTCDPA 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 MTCDPA does not pick a magic number, but it does require that personal data be processed only for purposes disclosed and only for as long as necessary for those purposes.

For your MTCDPA Cookies Policy, consider:

Session cookies that expire when the browser closes are usually lower risk because they cannot accumulate cross session data. Short lived persistent cookies (a few hours to a few days) are appropriate for analytics, fraud, and similar use cases where short term context matters. 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, because they accumulate behavior over time.

When you renew a cookie (refresh its expiration), 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. That keeps the consent fresh and your cookies policy defensible.

Authentication cookies are usually labeled necessary, and that is correct, but they often carry more weight than people realize. A login cookie identifies the user. The user is identifiable. Anything you do downstream with the logged in user state is processing personal data, even if the cookie itself is technical.

For your MTCDPA Cookies Policy, this means:

The authentication cookie itself does not need consent. The downstream data flows from the logged in state (recommendations, personalization, marketing automation, lookalike export) often do. Disclose those flows clearly. Tie marketing on the logged in state to the same consent posture as on the anonymous state. Do not assume a logged in user has consented to everything just because they signed up.

This is one of the easiest places to drift out of compliance. The marketing team sees the logged in user as "ours" and starts using their data more aggressively. The MTCDPA Cookies Policy has to put guardrails on that.

Many of the cookies on a typical U.S. website send data outside the U.S. Ad networks with operations in Europe, analytics vendors with infrastructure in Asia, identity vendors with global topology, all of these can result in cross border transfers. The MTCDPA does not have an explicit cross border transfer regime in the way that the GDPR does, but if your audience or your data flows touch the EU, GDPR rules apply on top.

For your MTCDPA Cookies Policy, the practical advice is:

Disclose the categories of recipients, and where reasonable, the regions or countries where data may flow. Do not promise more locality than you can actually deliver. If a vendor moves data, your disclosure has to track. Coordinate with your cross border transfer playbook (Standard Contractual Clauses, Data Privacy Framework, transfer impact assessments) where the GDPR is in scope. Even though the MTCDPA does not require those specifically, being on top of them protects your global program.

For more on the GDPR and its core obligations, the AdOpt explainer on legal bases and the GDPR cookies deep dive cover this in detail.

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

Step one: scan. Use a privacy scanner (the AdOpt scanner is one option) 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 (homepage, category, product, cart, checkout, account, support).

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. Tag managers can introduce dynamic tags that scanners do not catch.

Step three: categorize. For each cookie or tag, document the category, vendor, data sent, retention, and consent state required. Resist the urge to default everything to "necessary" or "analytics." 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 MCA 30-14-2813? 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. Try a known minor account if you have one. Verify consent state is reflected in your data layer and propagated to server side pipelines.

Step seven: document. Produce a report with findings, severity, and remediation. Tie each finding to a specific MTCDPA provision so the program team can prioritize.

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 MTCDPA 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. The two are not at odds.

Your MTCDPA Cookies Policy should support a first party strategy. That means:

Reducing reliance on third party cookies. They are dying anyway. The phaseout has slowed and shifted, but the trajectory is unchanged. Investing in first party data collection with clear value exchange. Consented data with a real value reason gets richer responses.

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. Measuring with attribution methods that work in a consent constrained world. Modeled, incrementality, MMM. They all work better than people think.

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. AdOpt's experience is that this approach pays back in both legal defensibility and marketing efficiency.

Compliance is about the user, even when the team building it forgets that. A consumer in Helena 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 Montana consumer who feels respected on your site is a better consumer. They convert more, churn less, and complain to the AG less. Your MTCDPA Cookies Policy is, in some ways, a customer experience document as much as a legal one.

The MTCDPA is part of a larger U.S. privacy patchwork that keeps growing. By the time you finish a Montana 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 MTCDPA Cookies Policy that follows the principles of comprehensive privacy law, not one that hardcodes Montana 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 MTCDPA easier than expected. The teams that have not are finding it harder than expected. Both are normal. The work pays back in both directions.

A defensible MTCDPA Cookies Policy is not glamorous work. It is patient, careful, cross functional work. It pays back in two ways: lower regulatory risk and higher customer trust. Both 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.

The teams that handle this badly skip steps, copy templates, hope nobody looks, and find out the hard way that the Montana AG does look. The 7,500 dollars per violation cap is the floor of the cost, not the ceiling.

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

Yes, in most cases. The MTCDPA applies to entities that conduct business in Montana or deliver commercial products or services intentionally targeted to Montana residents, provided you meet the personal data thresholds (25,000 consumers, or 15,000 if more than 25 percent of revenue comes from sale of personal data). A physical Montana office is not required. An online business with Montana customers can absolutely be in scope, especially after SB 297 lowered the thresholds.

It is mostly opt out. For sale of personal data, targeted advertising, and profiling for significant decisions, consumers must be able to opt out, and you must honor universal opt out preference signals.

For sensitive data (which includes precise geolocation, health, sexual orientation, religious beliefs, biometric data, citizenship, immigration status, and personal data of known children), the MTCDPA requires opt in consent. So your MTCDPA Cookies Policy has to support both flows, depending on the cookie's data category and audience.

That is a material disclosure problem. Your MTCDPA Cookies Policy would be saying one thing while your site does another. Beyond the MTCDPA, this is also a deceptive practice under broader consumer protection law. The AG could pursue civil penalties up to 7,500 dollars per violation, plus injunctive relief, plus attorney fees. The fix is technical: a CMP that propagates the rejection to every tag, every server side pipeline, and every downstream vendor.

No, but it changes how the banner behaves. If a Montana consumer's browser sends GPC, your site should detect it, treat it as an opt out of sale and targeted advertising, and reflect that in the banner experience. You still need the banner for granular preferences, sensitive data consent, and minor flows. GPC is a baseline signal, not a replacement for the banner.

Quarterly at minimum. The cadence increases when there is a material change (new vendor, new data flow, new category, new opt out mechanism). When a material change happens, you must notify consumers and provide a reasonable opportunity to withdraw consent. A privacy program that does not have a recurring review cadence will drift. The whole point of a defensible MTCDPA Cookies Policy is to keep policy, design, and technology in sync over time.

If you read this far, you already know that a real MTCDPA Cookies Policy is more than a banner and a footer link. It is policy, design, and technology 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 Montana exposure. We will give you a clear path forward, with or without us. Better to know than to guess. The Montana AG is not in the guessing business, and neither should you be.