The Montana Consumer Data Privacy Act (MCDPA, often shortened to MTCDPA) was meaningfully revised by Senate Bill 297 in 2025. SB 297 lowered the applicability thresholds, tightened the privacy notice requirements, raised the duty of care for minors, and added a clear civil penalty regime. The privacy notice obligation, in particular, is more demanding under SB 297 than under the original MCDPA, and that is what this article is about.

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.

We are going to take you through the MTCDPA Privacy Policy end to end. What it must say. How it must be presented. Where it must live. How to keep it current. How to harmonize it with your CCPA, GDPR, and LGPD obligations. How to write it so a consumer can actually read it. And how to operate it so the words on the page match the reality of your stack.

If your MTCDPA Privacy Policy is on your roadmap (and if you process Montana data, it is, even if you have not put it there), keep reading. We have been doing this kind of work across jurisdictions for years, and the lessons translate.

Info

Note for readers: this article is a sibling to our MTCDPA Cookies Policy and MTCDPA DSAR Policy guides. We will link to those where it helps you assemble the full program.

A privacy policy, sometimes called a privacy notice, is the public document a controller publishes to tell consumers what personal data is collected, why, who it is shared with, what rights consumers have, and how those rights are exercised. Under the MTCDPA Privacy Policy rules, that document is not optional, not generic, and not a single sentence buried in the footer.

SB 297 codified a stricter set of expectations. Specifically, the privacy notice must include an explanation of the rights consumers have under the MTCDPA. It must include the date the privacy notice was last updated. It must clearly and conspicuously disclose any sale of personal data and any processing of personal data for targeted advertising, and it must provide a clear and conspicuous method for consumers to opt out of those activities.

The notice also has to be posted online through a conspicuous hyperlink using the word "privacy" on the homepage. It has to be available in each language in which the controller offers the product or service. And it has to be reasonably accessible to and useable by individuals with disabilities.

If you read those requirements quickly, they sound similar to what other state privacy laws require. They are. The trick of an MTCDPA Privacy Policy is in the specifics: the conspicuous "privacy" hyperlink, the obligation to notify consumers of material changes and offer a reasonable opportunity to withdraw consent, the way the disclosure of sale and targeted advertising must be paired with the opt out method on the same page, and the duty of care for minors that informs the entire stack.

Our explainer on what a privacy policy is is a good companion read for anyone who has never written one before. The structure travels well across regimes, and it makes the MTCDPA Privacy Policy easier to scaffold.

The Montana Consumer Data Privacy Act is a comprehensive consumer privacy law codified at MCA 30-14-2801, et seq. SB 297, effective October 1, 2025, revised the act significantly.

Under the MTCDPA, Montana consumers have a familiar set of rights:

• The right to know what personal data is collected and processed.
• The right to correct inaccuracies in personal data.
• The right to delete personal data.
• The right to obtain a copy of personal data (portability).
• The right to opt out of the sale of personal data.
• The right to opt out of the use of personal data for targeted advertising.
• The right to opt out of the use of personal data for profiling in furtherance of decisions that produce legal or similarly significant effects.

Controllers and processors must provide consumers with clear and conspicuous means to exercise these rights. The MTCDPA also imposes responsibilities on controllers and processors: collect only data needed for disclosed purposes, secure that data, contract with processors using terms that satisfy MCA 30-14-2813, conduct data protection assessments where high risk processing is involved, and provide an effective opt out mechanism that is at least as easy to use as the consent mechanism.

For comparison and context, our piece on the GDPR, LGPD, and CCPA walks through how this family of laws compares. The MTCDPA Privacy Policy lives in the same neighborhood as those.

The MTCDPA applies to entities that conduct business in Montana, or that intentionally target their commercial products or services to Montana residents, and that meet one of the following thresholds:

• Control or process the personal data of 25,000 or more consumers (lowered from 50,000 by SB 297).
• Control or process the personal data of 15,000 or more consumers if more than 25 percent of revenue comes from the sale of personal data (lowered from 25,000).

If you fit either threshold, you need an MTCDPA Privacy Policy that meets the act's requirements. Note that "consumers" here is a defined term and refers to Montana residents acting in a non commercial context. B2B contacts and employees are scoped differently.

SB 297 also tightened the exemptions. The Gramm-Leach-Bliley Act entity exemption is gone, replaced with a narrower data level exemption for banks, credit unions, insurers, and insurance producers. The nonprofit exemption now only protects organizations that detect or prevent fraud in connection with insurance.

The thresholds are low enough now that most U.S. businesses with a national footprint should plan for MTCDPA Privacy Policy compliance by default. The cost of building a defensible policy is much lower than the cost of being wrong about whether you needed one.

For a comparison with the LGPD on scope thresholds, the AdOpt explainer is a useful reference. The reasoning that drove the LGPD on this question informs how the MTCDPA approaches it too.

Let us walk through the components a complete MTCDPA Privacy Policy should contain. Some are explicitly required by the statute. Others are best practice. We will note which is which.

Open with a short, plain language introduction that names the controller, identifies the scope (the products, services, websites, and apps the policy covers), and gives the date the policy was last updated. SB 297 expressly requires the date of last update. Skipping it is non compliant.

The introduction is also where you tell the consumer what they will find in the document. A short table of contents or list of sections helps. The goal is to set expectations.

List the categories of personal data the controller collects. The MTCDPA does not prescribe a specific category schema, but the categories should be specific enough that a consumer can recognize what is happening.

Common categories include:

• Identifiers (name, email address, postal address, account ID, IP address, device ID).
• Commercial information (purchases, returns, browsing history within the service).
• Internet or other electronic network activity (interactions with the website or app, search history within the service, usage telemetry).
• Geolocation data (general or precise).
• Audio, electronic, visual, or similar information (uploaded photos, recorded calls).
• Professional or employment related information (where applicable, for example a B2B service or careers site).
• Inferences drawn from the above (preferences, segments, lookalike audiences).

For each category, the MTCDPA Privacy Policy should disclose the source of the data (collected from the consumer directly, collected from cookies and similar technologies, received from a third party). Our deep dive on data mapping or data inventory walks through how to discover and document those sources reliably. Without that mapping, the categories list is guesswork.

Tell the consumer where the data comes from. Direct collection (form fills, account creation, transactions, support interactions). Automated collection (cookies, pixels, SDKs, server side telemetry). Third party sources (data enrichment vendors, identity graphs, partners). Be specific enough to be useful, general enough to remain accurate as your stack evolves.

List the purposes for which each category of personal data is processed. The MTCDPA expects controllers to limit collection and processing to disclosed purposes. The privacy notice is where those purposes are disclosed.

Common purposes:

• Providing the service or product the consumer requested.
• Maintaining account security and preventing fraud.
• Communicating with the consumer about the service.
• Marketing and advertising (broken into subpurposes if needed: first party marketing, targeted advertising via third parties, lookalike modeling, attribution).
• Personalization of the experience.
• Analytics, research, and product improvement.
• Compliance with legal obligations.
• Enforcement of terms and protection against legal claims.

Be specific enough that a consumer can match the data they share to a reason that data is being processed. Vague purposes ("for legitimate business reasons") are a hallmark of weak privacy notices and a magnet for regulatory scrutiny.

The MTCDPA Privacy Policy should disclose the categories of third parties with whom personal data may be shared. Common categories:

• Service providers and processors (hosting, analytics, customer support tools, payment processors).
• Advertising and marketing partners (ad networks, retargeting platforms, email service providers).
• Affiliates of the controller.
• Government, regulatory, or law enforcement entities (with appropriate legal process).
• Successors in the event of a corporate transaction.

For each category, identify the purpose of sharing. If the sharing constitutes a sale of personal data or processing for targeted advertising, the MTCDPA Privacy Policy must clearly and conspicuously say so and pair the disclosure with the opt out mechanism. SB 297 is explicit on that pairing.

For more on the legal shape of those relationships, the AdOpt primer on controller, processor, and the difference between them sets the foundation.

Under SB 297, the MTCDPA Privacy Policy must include clear and conspicuous disclosures about any sale of personal data and any processing for targeted advertising, and it must provide a clear and conspicuous method for consumers to opt out of those activities.

This is where many privacy notices fail. The disclosure is buried in a long paragraph. The opt out method is on a different page, three clicks away. The "Do Not Sell" link is in 9 point gray text. None of that is conspicuous.

Best practice for the MTCDPA Privacy Policy:

• Place the sale and targeted advertising disclosures in their own clearly titled section, not buried in a generic "how we share" paragraph.
• Provide the opt out method in line with the disclosure. A button or link to a preference page. A description of the universal opt out signal (Global Privacy Control) the controller honors.
• Repeat the opt out access points in places where the consumer is most likely to look: footer link, banner preference center, account settings.

The disclosure has to be honest. If your audit shows that your ad tags share device identifiers with an audience graph, that is a sale under most U.S. state laws, and your MTCDPA Privacy Policy has to disclose it. Hiding behind a marketing word for the same activity ("partnership," "data exchange") will not survive scrutiny.

Under the MTCDPA, processing of sensitive data requires consent. Sensitive data includes data revealing racial or ethnic origin, religious beliefs, mental or physical health condition or diagnosis, sexual orientation, citizenship or immigration status, genetic or biometric data processed for the purpose of uniquely identifying an individual, precise geolocation data, and personal data of a known child.

Your MTCDPA Privacy Policy must:

• Identify which sensitive data categories you process, if any.
• Identify the purposes for which sensitive data is processed.
• Identify the consent mechanism (where the consumer is asked, what they see, how they confirm).
• Identify how the consumer can withdraw consent.

If you do not process sensitive data, say so. Affirmatively. Consumers and regulators read the absence of a sensitive data section as either a weakness or an oversight. Being explicit closes that loop.

For the underlying logic of consent, the AdOpt piece on consent on websites is a useful primer. The mechanics translate.

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

Your MTCDPA Privacy Policy should:

• State whether the service is directed to minors (and what age threshold applies).
• Describe age screening or verification (if any).
• Describe the heightened protections for minors (no targeted advertising by default, no profiling, sensitive data excluded, conservative default settings).
• Describe how a minor or their parent or guardian can exercise rights.

Be careful not to claim heightened protections you do not actually deliver. The duty of care under SB 297 is judged by what your stack does, not what your policy says.

This section is the MTCDPA Privacy Policy counterpart to the law's grant of rights. It should clearly explain:

• The right to know (access).
• The right to correct.
• The right to delete.
• The right to data portability.
• The right to opt out of sale.
• The right to opt out of targeted advertising.
• The right to opt out of profiling for significant decisions.
• The right to appeal a denied request.
• The right to withdraw consent (where consent is the basis).

For each right, the policy should describe how to exercise it (web form, email, phone, in app), what identity verification is required, and what timeline applies (typically 45 days, extendable by 45 days for complex requests, with notice).

Our companion article on the MTCDPA DSAR Policy goes deep on the rights workflow and how to operate it. The disclosures in the MTCDPA Privacy Policy must align with the workflow you actually run.

The MTCDPA, like several of its sister state laws, gives consumers the right to appeal a denied request. Your MTCDPA Privacy Policy must describe how to appeal, including the channel and the timeline. Consumers must also be informed of their right to file a complaint with the Montana Attorney General if the appeal is denied.

This is more than legalese. A real appeal process protects consumers and protects the controller from regulatory escalation. Build it. Document it. Disclose it.

For each category of personal data, describe how long it is retained. The MTCDPA expects retention to be limited to what is necessary for the disclosed purposes. Where exact periods are not feasible, describe the criteria used to determine retention (active account, contractual requirement, legal hold, defined retention schedule).

A common mistake is to write "as long as necessary" and call it done. That phrase, on its own, is too vague. Pair it with criteria.

Describe the technical and organizational measures the controller takes to protect personal data. Encryption in transit and at rest. Access controls. Logging and monitoring. Incident response. Staff training. The MTCDPA does not prescribe specific controls, but it expects reasonable security practices.

Avoid the temptation to oversell. Saying "we use bank grade security" is not meaningful and is hard to defend if the implementation does not match. Be honest, be specific where you can, be general where you must, and keep the section short.

If personal data flows outside the United States, describe the circumstances and the safeguards. The MTCDPA does not have a GDPR style transfer regime, but if your audience or your data flows touch the EU, GDPR rules apply on top. The MTCDPA Privacy Policy should be honest about transfers regardless.

For the GDPR side, our deep dive on GDPR cookies and GDPR legal bases covers the mechanics.

Describe how changes are made and how consumers will be notified. SB 297 requires that when a material change is made, the controller notify consumers and provide a reasonable opportunity to withdraw consent. The MTCDPA Privacy Policy must explain that mechanism.

Common notification mechanisms: email to account holders, banner or modal on the next session, in app message, or all of the above. Whatever you choose, it has to be reasonable and effective.

The companion AdOpt article on user notification of terms changes is useful here. The same patterns apply.

Provide a way for consumers to contact the controller about privacy. Typically:

• An email address (for example, [email protected]).
• A web form for rights requests.
• A postal address.
• The name of the privacy officer or DPO, where applicable.

Make the contact options easy to find and easy to use. The MTCDPA requires the rights mechanism to be at least as easy to use as the consent mechanism. The contact information section is part of that.

For the role of the privacy officer, see our explainer on the responsibilities of a data protection officer and the team that supports them.

Tone matters more than people think. A privacy notice that sounds like a contract written by lawyers for lawyers will be ignored. A privacy notice that sounds like a friendly explainer will be read. Read notices generate fewer complaints, fewer DSARs based on misunderstanding, and more trust.

For your MTCDPA Privacy Policy, we recommend:

• Plain English. Short sentences. Common words. Define jargon once and only when necessary.
• Active voice. "We collect" not "personal data is collected by the company."
• Concrete examples. Where appropriate, name the categories of vendors, the kinds of cookies, the specific scenarios.
• Headings and subheadings that mirror what the consumer is looking for, not what the lawyers want to organize around.
• Visual structure: short paragraphs, lists where useful, summaries at the top of each section.
• A glossary or definitions section if you must use defined terms, but keep it small.

This is one place where AdOpt's copywriting baselines for cookie banners and privacy notices come in handy. The same conversational, no-nonsense voice works for the MTCDPA Privacy Policy as for the banner.

A modern MTCDPA Privacy Policy is rarely one long document. It is layered.

The first layer is the cookie banner or short privacy summary. It tells the consumer the most important things, gives them a chance to act, and links to deeper content.

The second layer is the main privacy notice. It contains all the elements we listed in the anatomy section. It is the document that satisfies the legal requirements.

The detail layer can include supplemental documents: a separate cookies policy, a CCPA notice (if applicable), a children's privacy notice, a candidate privacy notice for the careers site, and so on. These detail documents do not replace the main notice. They complement it.

The MTCDPA does not require the layered structure, but it allows it, and it is the structure that performs best. Consumers who want a quick answer get one. Consumers who want the full text find it.

SB 297 requires the privacy notice to be reasonably accessible to and useable by individuals with disabilities. That has practical consequences.

For your MTCDPA Privacy Policy:

• Use HTML, not just a PDF. PDFs are hard for screen readers and difficult to update.
• Use proper heading structure (H1, H2, H3, etc.) so screen readers can navigate.
• Use sufficient color contrast and avoid relying on color alone to convey meaning.
• Make sure links are descriptive (no "click here").
• Use semantic markup for lists, tables, and emphasis.
• Test with at least one screen reader before publishing.

The same accessibility rules apply to your cookie banner and preference center. The "as easy to use" requirement is meaningless if half your audience cannot use the controls at all.

The MTCDPA requires the privacy notice to be available in each language in which the controller offers the product or service. If your site is in English and Spanish, the MTCDPA Privacy Policy must be in English and Spanish.

Translation should be professional, not machine. Privacy terminology has specific meanings that machine translation often gets wrong. A bad translation creates inconsistency between language versions, and inconsistency is a regulatory and trust problem.

If your audience extends to other languages (Portuguese for Brazilian users, French for Canadian users, etc.), translate accordingly. The principle is consistency: every consumer should see the same notice in the language they use to interact with the service.

SB 297 requires the privacy notice to be posted online through a conspicuous hyperlink using the word "privacy" on the homepage. This sounds straightforward, but the word "conspicuous" is doing the work.

Conspicuous means easily noticeable. A 9 point gray "Privacy" link in a footer of similar gray text is not conspicuous. A clearly contrasting "Privacy" link in the footer, with adequate font size and surrounding white space, is.

For your MTCDPA Privacy Policy placement, we recommend:

• A "Privacy" link in the footer, clearly visible.
• A "Privacy Choices" link (or similar) in the footer for the opt out controls.
• A link in the cookie banner pointing to the full notice.
• A link in the account settings (if you have accounts).
• A link in any other place where personal data collection is happening (form pages, signup flows, checkout pages).

When the consumer is most likely to ask the question, the answer should be one click away.

A "material change" is a substantive change in the policy: new categories of personal data collected, new purposes of processing, new third party recipients, new opt out mechanisms, new sensitive data, or significant changes to consumer rights or contact methods. Cosmetic edits, typo fixes, and reorganizations are not material.

When a material change is made to the MTCDPA Privacy Policy, SB 297 requires the controller to notify consumers and provide a reasonable opportunity to withdraw consent.

In practice:

• Update the "last updated" date in the privacy notice.
• Send an email to account holders summarizing the change and linking to the new notice.
• Show a banner or modal on the next session for anonymous traffic.
• Allow consumers to revisit their consent in the preference center.

The reasonable opportunity to withdraw consent matters. If a consumer's previously granted consent no longer covers the new activity, you cannot rely on the old consent for the new activity. The notice and the operational reality have to be in sync.

A privacy notice on a website is not a privacy program. The notice is the public artifact. The program is what makes the notice true.

The operational layer for an MTCDPA Privacy Policy includes:

A complete data inventory that maps personal data through the stack, from collection to processing to sharing to retention to deletion. The notice has to reflect what the inventory shows. The discipline of data mapping is the foundation here.

A vendor management function. Every processor and every recipient must be in a documented relationship. Contracts must satisfy MCA 30-14-2813. Vendor changes must trigger a review of the notice.

A consent management platform that captures, stores, propagates, and respects consent state. The notice describes the consent and opt out mechanisms; the platform makes them real. AdOpt's CMP guide walks through what to look for.

A rights workflow that handles access, correction, deletion, portability, and opt out requests, with identity verification, timelines, and appeal channels. The notice describes the workflow; the operational team runs it.

A data protection assessment function for high risk processing. Targeted advertising, sale of personal data, processing of sensitive data, and processing involving minors are all candidates for an assessment. The assessment is internal documentation that proves the controller thought through the risks.

A training and awareness program. Marketing, product, engineering, customer support, sales, and legal each need to know how the privacy program affects their work.

A monitoring and audit function. Quarterly at minimum, the controller should verify that the notice reflects reality and that the operational layer is doing its job.

When all of these are in place, the MTCDPA Privacy Policy becomes more than words. It becomes the public face of an actual program.

Reading a lot of privacy notices, the same mistakes show up over and over. Here are the most common, with their fixes.

Mistake one: copying a CCPA notice and changing the names. California has its own structure, language, and rights set. Some of the language carries over to Montana, but the MTCDPA Privacy Policy has its own SB 297 specific language (the conspicuous "privacy" hyperlink, the date last updated, the opt out method paired with the disclosure). Adapt, do not copy.

Mistake two: vague purposes. "We process personal data for legitimate business purposes" is not a purpose. Be specific.

Mistake three: no rights section. Every required right must be listed, with a description of how to exercise it. Skipping a right is a violation.

Mistake four: opt out hidden. The opt out method must be clear and conspicuous and paired with the disclosure. A footer link in tiny gray is not.

Mistake five: no last updated date. SB 297 explicitly requires it. Skipping it is non compliant.

Mistake six: no language alignment. The notice must be available in each language in which the service is offered. Skipping a language is non compliant.

Mistake seven: no accessibility. Screen reader, keyboard navigation, and contrast all matter. A PDF only notice is a problem.

Mistake eight: stale notice. Notices that have not been touched in years almost always misrepresent current practice. Quarterly review at minimum.

Mistake nine: misuse of "necessary" or "legitimate interest." These words have specific meanings and cannot be used to bless any processing the controller wants to do. Map them carefully.

Mistake ten: no operational alignment. The notice describes what the program does. If the program does not do it, the notice is materially false. Build the program first.

The best counter to most of these is a healthy program. Our piece on ignoring the law is a sober reminder of what happens when programs are absent.

SB 297 adds a maximum civil penalty of up to 7,500 dollars per violation. The Montana Attorney General can also seek injunctive relief and reasonable attorney fees and costs related to investigation and enforcement.

A per violation penalty in privacy law tends to compound. Each affected consumer can be a separate violation, especially when the violation is a structural defect of the MTCDPA Privacy Policy itself. A few thousand consumers and the math gets uncomfortable quickly. Add the AG's investigation costs, the controller's own legal fees, and the brand impact of a public enforcement action, and the real cost of a bad notice is significantly higher than the headline.

For a comparative view of how privacy fines work in practice, the AdOpt piece on fines under the LGPD is a useful reference. The math behaves similarly in the U.S.

If you operate at scale, you almost certainly publish more than one privacy notice today. A general privacy notice. A CCPA specific notice (often a separate addendum or page). A GDPR notice for European audiences. An employee or candidate privacy notice. A children's privacy notice if you serve minors.

The MTCDPA Privacy Policy can either be a separate Montana specific notice or a section within a larger U.S. or global notice. Both approaches are acceptable as long as the SB 297 specific requirements are met.

We generally prefer a single comprehensive notice that includes Montana specific disclosures clearly labeled. It is easier for consumers to read, easier for the controller to maintain, and easier to keep consistent.

If you do publish a separate Montana notice, link to it from the homepage with a conspicuous "privacy" hyperlink and from any other place where Montana specific disclosures matter. Consistency between the global and the state specific notice is non negotiable.

A small but important terminology note. Some commentators and lawyers distinguish between a "privacy policy" (an internal document describing how the organization processes personal data) and a "privacy notice" (the public document delivered to consumers). The MTCDPA uses "privacy notice" for the public document.

In common usage, "privacy policy" and "privacy notice" are often used interchangeably for the public document. We treat them as synonyms in this article. What matters is that the public document meets the SB 297 requirements.

The internal version of a privacy policy (the document for staff) is also valuable, but it is not the document the MTCDPA regulates. Our explainer on what a privacy policy is covers both senses of the word.

A defensible MTCDPA Privacy Policy is the natural output of a privacy by design culture. When privacy is considered at the design phase of every feature, every campaign, and every vendor decision, the privacy notice almost writes itself.

Privacy by design principles applied to the notice:

• Default to minimal collection. The notice describes less because the program processes less.
• Embed privacy controls into the product. The notice describes controls that the consumer can actually use.
• Make the notice transparent. No tricks. No buried disclosures. No misleading wordsmithing.
• Treat the consumer as a partner. The notice respects their time and attention.
• Document the choices. The notice points to a real program, not a wish list.

The teams that approach the MTCDPA Privacy Policy as a privacy by design exercise tend to produce notices that are shorter, clearer, and easier to defend. The teams that treat the notice as an afterthought produce long, defensive, hard to read documents that fool nobody.

To make this concrete, here is the workflow we use at AdOpt to draft an MTCDPA Privacy Policy for a client.

Discovery. We sit with the client, walk the product surfaces, identify all the places personal data is collected, and map the categories. We pull from the existing privacy notice, terms of use, vendor list, and tag inventory.

Inventory. We build (or refresh) the data inventory. Categories, sources, purposes, recipients, retention, sensitive data flags, minor flags. The inventory is the source of truth for the notice.

Outline. We draft an outline that covers all the SB 297 required elements: rights, last updated, sale and targeted advertising disclosures with paired opt out, conspicuous "privacy" hyperlink reference, sensitive data, minors, contact, appeals.

First draft. We write a plain language draft that follows the outline. Short sentences. Active voice. Concrete examples.

Review. Legal reviews for accuracy and completeness. Marketing reviews for tone. Engineering reviews for technical accuracy. Customer support reviews for usability.

Operational alignment. We confirm that every claim in the draft matches the operational reality. Anything that does not match either changes in the draft or triggers operational work.

Accessibility check. We test with screen readers and keyboard navigation. We check contrast and font size. We make sure the document renders well across devices.

Translation. We translate into every language in which the service is offered. Professional translation, not machine.

Publication. We publish to the site, place the conspicuous "privacy" hyperlink on the homepage, link from the banner and the preference center, and update the "last updated" date.

Notification. If this is a material change, we trigger the notification flow.

Audit trail. We document the draft, the reviews, the approvals, and the publication. The next time someone asks how the MTCDPA Privacy Policy was developed, we have a paper trail.

Cadence. We add the notice to a quarterly review cadence. Anything that changes in the inventory or the operational layer triggers a review.

This workflow takes weeks, not days. That is normal. A real MTCDPA Privacy Policy is not produced in a sprint.

Imagine a mid sized SaaS company with 60,000 Montana B2C users (yes, B2C, even though SaaS is often B2B). The company runs a content marketing engine, a freemium model, and an ad supported tier. It uses Google Analytics, Mixpanel, Meta Pixel, Google Ads, HubSpot, Intercom, Stripe, Sentry, Hotjar, and a dozen other vendors.

Before SB 297, the company had a generic CCPA notice that mentioned Montana in a state law section. The notice listed three rights, mentioned cookies in passing, and had no explicit opt out for targeted advertising. The "Privacy" link in the footer was small. The notice had not been updated in 18 months.

Walking through the MTCDPA Privacy Policy workflow with this company surfaces:

The 60,000 Montana users put the company well over the 25,000 threshold. The ad supported tier likely puts the company over the 25 percent revenue from sale of personal data threshold for the lower tier (15,000 consumers), but at 60,000 it does not matter. The company is in scope by either path.

The notice does not include an explicit opt out for targeted advertising. SB 297 requires it. Gap.

The notice does not include the date last updated. SB 297 requires it. Gap.

The Meta Pixel and Google Ads integrations result in sale of personal data and targeted advertising. The notice does not disclose this clearly and conspicuously. Gap.

The "Privacy" hyperlink in the footer is in 9 point gray text. Not conspicuous. Gap.

The notice is not available in Spanish, even though the product is offered in Spanish. Gap.

The notice does not address minors, even though the freemium tier has known users in the 13 to 17 range. Gap.

After a four week engagement, the company has a new MTCDPA Privacy Policy that addresses each gap. The footer link is rebuilt. The Spanish version is published. The opt out for targeted advertising is in line with the disclosure, with a button that takes the user to the preference center. The minor protections are documented and operationalized. The "last updated" date is current.

The company is now defensible. Not perfect, because nothing is, but defensible. And the workflow for keeping it that way is documented.

For a story driven take on what happens to companies that skip this kind of work, our piece on a company that got fined is worth a read.

Marketing teams are often nervous about privacy notices because they read like restrictions. The right reading is that the notice is a description of what you can do, written carefully to reflect what you are actually doing. A clean MTCDPA Privacy Policy removes ambiguity. Marketing knows what is in scope and what is not, and the rest follows.

For a deeper take on adapting marketing under modern privacy law, the AdOpt explainer on adapting digital marketing covers the operational shifts. The piece on risky processes in marketing lists the specific behaviors that turn into privacy problems. Both apply directly to the Montana context.

The MTCDPA Privacy Policy is also a marketing asset. A clean, well written notice signals to consumers that the brand cares. Trust is a competitive advantage. Brands that have invested in transparent privacy practices have, in study after study, higher engagement and lower churn. The notice is part of that signal.

For more on the agency side of marketing under privacy law, our piece on agencies and privacy compliance is a good read.

The MTCDPA Privacy Policy has to address cookies, but it does not have to do it alone. A common pattern is to have a dedicated cookies policy (linked from the privacy notice and from the cookie banner) that handles the granular detail, while the privacy notice covers the conceptual framing.

Both documents are subject to the SB 297 requirements. The privacy notice is the umbrella. The cookies policy is the specific application of the umbrella to cookies and similar technologies.

If you want the deep dive on cookies under Montana law, our companion article on the MTCDPA Cookies Policy walks through every detail. The framing here is short on purpose.

For broader context on cookies and privacy law, the AdOpt deep dive on cookies and privacy and on the cookie banner cover the underlying ideas.

The MTCDPA grants consumers rights to access, correct, delete, port, and opt out of certain processing. The MTCDPA Privacy Policy must describe these rights and how to exercise them. The actual handling of the requests is a workflow, not a document.

Our companion article on the MTCDPA DSAR Policy walks through the workflow in detail. A few highlights for the privacy notice:

• The notice should state the timeline (45 days, extendable by 45 days for complex requests with notice).
• The notice should describe identity verification (what proof is required, what fallback is available if the consumer cannot verify).
• The notice should describe the appeal process and the right to complain to the Montana AG.
• The notice should describe the format in which data is provided for portability requests (commonly, machine readable like JSON or CSV).

The notice and the workflow have to match. A notice that promises a 30 day response while the workflow takes 60 is non compliant by misrepresentation.

For more on the DPO and team that operates the rights workflow, the AdOpt explainer is useful.

The MTCDPA does not have a GDPR style "records of processing activities" obligation by name, but it expects controllers to be able to demonstrate compliance, conduct data protection assessments for high risk processing, and document the operations of the program.

The internal records that support the MTCDPA Privacy Policy typically include:

• The data inventory.
• The vendor list and contracts.
• The consent and opt out records.
• The DSAR records.
• The data protection assessments.
• The training records.
• The audit records.

For a primer on the discipline of records of processing, the AdOpt piece on ROPA for LGPD is a good cross reference. The mechanics translate.

The MTCDPA does not have a regulatory body the way the LGPD has the ANPD or the GDPR has the EDPB. Enforcement comes from the Montana Attorney General. There is no formal guidance issuing body that publishes opinions on cookies, privacy notices, and DSARs.

That said, controllers can still draw on guidance from analogous regulators when designing the MTCDPA Privacy Policy. The ANPD has published orientative guidance on cookies and personal data protection that the Montana AG would likely consider sensible. The European Data Protection Board has published similar guidance for the GDPR. Building toward that bar is a way to future proof the MTCDPA Privacy Policy against tighter U.S. interpretations down the road.

To make this practical, here are a few plain language examples of how sections of an MTCDPA Privacy Policy can read.

Example: introduction.

Info

"This notice describes how [Company] collects and uses personal data when you visit our website, use our app, or interact with us. It applies to consumers in the United States, including residents of Montana. We last updated this notice on [date]. If you only want the highlights, the summary at the top of this page covers them. If you want the full picture, read on."

Example: rights.

Example: targeted advertising disclosure.

Info

"We use cookies, pixels, and similar technologies that allow third party advertising partners to show you ads on other websites based on your activity on ours. The Montana Consumer Data Privacy Act calls this 'targeted advertising,' and you have the right to opt out. To opt out, [click here] or use the preference center. We also honor the Global Privacy Control signal sent by some browsers. When we detect that signal, we treat it as an opt out of targeted advertising and the sale of personal data."

These examples are short, plain, and concrete. A reader knows what is happening and what they can do about it. That is the bar.

The MTCDPA expects controllers to conduct data protection assessments for processing activities that present a heightened risk of harm. The categories that trigger an assessment typically include processing for targeted advertising, sale of personal data, processing of sensitive data, and processing involving minors, among others.

The assessment itself is an internal document. The MTCDPA Privacy Policy does not need to publish the contents of the assessment, but the notice should reflect the conclusions. If the assessment determines that a particular processing activity should be opt in rather than opt out (because it touches sensitive data, for example), the notice has to describe that opt in mechanism. If the assessment identifies safeguards that should be applied to minors, the notice has to describe those safeguards.

A practical pattern: the assessment is the engine, the notice is the dashboard. The engine does the work. The dashboard tells the consumer what is happening and how they can interact with it.

For more on the discipline of risk assessments and the data protection officer that oversees them, the AdOpt explainer on the responsibilities of a DPO is a useful starting point.

A small but valuable practice: maintain a change log for the MTCDPA Privacy Policy. Each material change gets a dated entry that summarizes the change, the reason, and the effective date. The change log can live at the bottom of the notice or on a separate page linked from the notice.

The change log serves three purposes. First, it satisfies the SB 297 requirement to display the date the notice was last updated, with a richer audit trail. Second, it gives consumers a way to understand what changed without reading the full document side by side. Third, it gives regulators (and your own legal team) a clear paper trail of how the notice has evolved.

For high traffic sites, we recommend keeping the last several versions of the notice in an archive. If a consumer signed up under an earlier version and is asking about their rights at that time, you have the answer.

The MTCDPA includes inferences within the definition of personal data. An inference is a derived data point, drawn from observed behavior, that says something about the consumer (interests, propensity to buy, demographic segment, lookalike score, lifetime value prediction).

For your MTCDPA Privacy Policy, inferences require their own attention:

Inferences are personal data and need the same disclosure as raw data. The notice should call them out as a category. Inferences feed targeted advertising, profiling, and personalization. The notice should describe how inferences are used in each of these activities. Inferences are subject to the same rights as raw data. If a consumer requests deletion, the inferences derived from their data should also be deleted (or at least disconnected from them). The notice should describe this.

The inference category is one of the most underdisclosed pieces of typical privacy notices. Cleaning it up under the MTCDPA Privacy Policy is a useful forcing function for the rest of the program.

Many controllers run identity resolution systems that match consumers across devices, sessions, and channels. These systems often use first party data (login state, email address, phone number) to maintain a unified identity. The MTCDPA does not prohibit identity resolution, but it does expect honest disclosure.

Your MTCDPA Privacy Policy should describe:

That the controller maintains a unified identity for each consumer (where it does). The categories of data used to resolve the identity. The purposes for which the unified identity is used (analytics, personalization, advertising, customer service). The consumer rights that apply to the unified identity (access to the merged record, correction, deletion, opt out).

This area gets technical fast. Engineering teams often think of identity resolution as plumbing. From a privacy perspective, it is also a substantive data flow. The notice has to reflect that.

The MTCDPA defines "consumer" in a way that excludes individuals acting in a commercial or employment context. That means a B2B contact (a buyer at a customer organization) is not a consumer for MTCDPA purposes. An employee or contractor is also not a consumer for MTCDPA purposes.

Practically, this matters for SaaS companies and services with mixed audiences. If your service has both consumer users and B2B users, the MTCDPA Privacy Policy should be clear about which protections apply to which group. A common pattern is to publish a comprehensive notice that addresses consumer rights, with a separate note explaining that B2B contacts and employees are scoped under different documents (a B2B addendum, an employee privacy notice).

Be careful with the line between B2B and consumer. A solo professional who buys a product for personal and business use blurs the line. The conservative posture is to treat the data as consumer data unless the context is unambiguously commercial.

A clean MTCDPA Privacy Policy has implications for every stage of the marketing funnel. At the top of the funnel, paid acquisition needs to be configured for opt out, with universal opt out signal detection in place. In the middle, lead capture and lead nurturing have to be tied to disclosed purposes and consented audiences. At the bottom, sales handoff and customer onboarding have to respect the consumer's privacy choices.

A well written MTCDPA Privacy Policy is also a sales asset. Enterprise buyers, especially in regulated industries, increasingly review privacy notices as part of vendor due diligence. A clean, plain language notice signals that the brand has its house in order. A messy, defensive, copy paste notice signals the opposite.

For a deeper dive on LGPD inbound marketing impact, the AdOpt explainer covers the same shift in a Brazilian context. The lessons translate.

We will close with a brief tour of how AdOpt works with clients on the MTCDPA Privacy Policy specifically.

We start with a discovery sprint. Two to four weeks, depending on complexity. We map the data, inventory the cookies and vendors, review the existing notice, and identify gaps against the SB 297 requirements.

We draft the notice. Plain language, structured the way consumers actually read, with the SB 297 specific elements clearly addressed. We work with your legal team to validate the disclosures and with your marketing team to validate the tone.

We deploy the technical layer. The CMP, the preference center, the rights workflow, the consent state propagation, the universal opt out detection. The notice describes what the technical layer does. The technical layer makes the notice true.

We train the team. Marketing, product, engineering, customer support, sales, and legal each get a briefing tailored to their role.

We set up the maintenance cadence. Quarterly review, material change triggers, and an audit calendar.

The clients who work with us tend to find that the MTCDPA rollout is less painful than they expected, mostly because we have done it before. The work scales. The framework holds up across other state laws. The investment pays back.

To make this fully concrete, here is a skeleton outline that an MTCDPA Privacy Policy can follow. Use it as a starting point and adapt to your stack.

1. Introduction and last updated date.
2. Quick summary (the highlights for consumers who do not have time to read the whole thing).
3. Categories of personal data we collect and the sources of that data.
4. How we use personal data (purposes).
5. How we share personal data (categories of recipients).
6. Sale of personal data and targeted advertising disclosures, with the opt out method.
7. Sensitive data and consent.
8. Children and minors.
9. Cookies and similar technologies (with a link to the dedicated cookies policy).
10. Your privacy rights and how to exercise them.
11. Right to appeal.
12. Retention.
13. Security.
14. International transfers (where applicable).
15. Changes to this notice.
16. Contact information.
17. State specific addenda (Montana, California, Colorado, Connecticut, Virginia, Texas, etc.).
18. Change log.

This outline is more comprehensive than a minimum compliance notice, but it sets you up for cross state durability and consumer readability. The MTCDPA Privacy Policy sections (or addendum, if you go that route) can plug into this skeleton without rewriting the whole document.

Most U.S. businesses cannot afford to maintain a separate privacy program for every state. The smart pattern is to harmonize across the comprehensive consumer privacy law family and treat state specifics as deltas on top of a shared baseline.

For your MTCDPA Privacy Policy, the harmonization approach looks like this:

Build the baseline notice using the strongest set of expectations across the comprehensive state laws. That usually means honoring the most demanding right (often access or portability), the broadest sensitive data category, the strictest minor protection, and the most prominent opt out display. Add state specific deltas where the law diverges.

Montana's lower thresholds and conspicuous "privacy" hyperlink are deltas. California's "Do Not Sell or Share My Personal Information" and "Limit Use of Sensitive Personal Information" are deltas. Colorado's universal opt out signal mandate is a delta. Maintain a single internal source of truth (the data inventory and the program documentation) so the deltas can be derived rather than maintained by hand.

This approach scales. Each new state law is an incremental delta, not a from scratch rebuild. The MTCDPA Privacy Policy plugs into the same framework that handles California, Colorado, Connecticut, Virginia, Texas, Oregon, Delaware, Iowa, Indiana, Tennessee, New Hampshire, New Jersey, Kentucky, Maryland, Minnesota, and Rhode Island.

For a comparative read on the key differences between LGPD and GDPR, AdOpt's explainer is a good model. The same exercise applied to U.S. state laws produces a manageable list of deltas.

There is a piece of all this we have only touched on indirectly: customer trust. Privacy notices are not just compliance artifacts. They are signals to the consumer about the brand's posture. Brands that publish honest, plain language privacy notices earn more trust, and trust is a hard to fake competitive advantage.

The MTCDPA Privacy Policy is, in this sense, a marketing document as much as a legal document. It is read by potential customers, by procurement teams at enterprise prospects, by journalists writing about the brand, by competitors looking for weakness, and by regulators looking for liability.

Brands that get this right tend to invest in the notice the way they invest in the homepage. Plain language. Real examples. Visual structure. Tone that matches the brand. The result is a notice that consumers actually read and respect.

Brands that get this wrong copy a template, paste it into a footer link, and forget about it. The notice contradicts the product. The product contradicts the promise. The promise erodes trust. And eventually, a regulator notices.

Investing in the notice is not a charity. It is a return on investment.

A defensible MTCDPA Privacy Policy is the work of more than one team. The notice describes what the program does, and the program is operated by people across the organization. A short rundown of who owns what:

The privacy officer or DPO owns the notice content, the legal interpretation, and the alignment with regulatory obligations. They write or review the draft, approve material changes, and sign off on the final version.

The legal team reviews the notice for accuracy and consistency with contracts, terms of use, and regulatory positions.

The marketing team reviews the notice for tone, for alignment with marketing operations, and for clarity of disclosures around advertising and analytics.

The engineering team validates that the technical layer (CMP, tag manager, rights workflow, consent state propagation) supports the notice's claims.

The product team validates that the user experience reflected in the notice is what the product actually delivers.

The customer support team validates that the contact and rights mechanisms described in the notice are what they actually handle.

The security team validates the security claims in the notice.

When all of these are aligned, the MTCDPA Privacy Policy is defensible. When they are not, the notice contains claims that nobody operationally supports, and that is where compliance failures hide.

For more on the DPO and the team that supports them, the AdOpt explainer is a useful reference.

The first version of an MTCDPA Privacy Policy does not have to be perfect. It has to be honest, complete, and aligned with the operational program. Once it is published, the next steps are iteration: testing readability with real consumers, cleaning up areas where the language is fuzzy, adjusting as the program evolves.

Treat the privacy notice the way a product team treats a landing page. Measure how consumers interact with it. Measure how often consumers contact privacy support. Measure DSAR volume and nature. Where the data shows misunderstanding, refine the notice. Where the data shows the program needs adjustment, adjust the program.

The MTCDPA Privacy Policy is a living document. The teams that treat it that way build trust over time. The teams that treat it as a one time deliverable lose ground. The discipline pays back.

A defensible MTCDPA Privacy Policy is not a single document. It is a discipline. It pairs honest disclosures with an operational program that makes the disclosures true. It updates on a cadence. It listens to the consumer. It survives regulatory scrutiny because it has nothing to hide.

The teams that build this kind of policy find that the work pays back across the entire privacy program. The work done for Montana flows into California, Colorado, Connecticut, Virginia, Texas, and the rest of the patchwork. The work done for the U.S. flows into the EU and Brazil. Privacy compliance is not a state by state expense; it is a portfolio investment.

If you are starting fresh or refreshing a stale notice, the AdOpt team has done this hundreds of times. We bring the templates, the workflows, the technology, and the patience to do it well. We would love to help.

You can do either. The MTCDPA Privacy Policy requirements (date last updated, conspicuous "privacy" hyperlink, sale and targeted advertising disclosure paired with the opt out method, sensitive data consent, minor protections, rights and appeals) can be satisfied either by a Montana specific notice or by a section within a comprehensive notice. We generally prefer a comprehensive notice that clearly addresses Montana specifics, because it is easier to maintain and easier for consumers to read.

It means a link in a visible location (typically the footer, but sometimes in the top navigation), with adequate font size, color contrast, and white space, using the word "privacy" in its label (for example, "Privacy," "Privacy Notice," or "Privacy Choices"). It cannot be hidden in 9 point gray text indistinguishable from the surrounding background. The point is that a consumer who wants to find the MTCDPA Privacy Policy can find it without effort.

Within 45 days of receipt, with the option to extend by an additional 45 days for complex requests, provided you notify the consumer of the extension and the reason. If you deny a request, the consumer has the right to appeal, and you must respond to the appeal within 45 days. The MTCDPA Privacy Policy must describe these timelines clearly.

For most cookies, an opt out is enough, paired with a conspicuous disclosure and respect for universal opt out signals. For cookies that process sensitive data (precise geolocation, health, sexual orientation, religious beliefs, biometric data, citizenship or immigration status, personal data of known children) you need affirmative consent. The MTCDPA Privacy Policy must explain which mechanism applies to which type of cookie. Our companion MTCDPA Cookies Policy article goes deeper on this.

That is a structural compliance problem. The notice is supposed to describe what the program does. If the program is doing something different (sharing more data than disclosed, retaining longer than disclosed, using sensitive data without consent), the notice is materially false.

The Montana AG can pursue civil penalties up to 7,500 dollars per violation, plus injunctive relief and attorney fees, for misleading or false disclosures. Beyond regulatory exposure, brand damage and consumer trust loss tend to be larger costs. The fix is to keep the notice and the program aligned through quarterly review and a clear material change notification process.

If you got this far, you have a sense of what a real MTCDPA Privacy Policy looks like. It is not a paragraph in the footer. It is the public face of a working privacy program, anchored in honest disclosures, supported by an operational layer, and refreshed on a cadence. It takes work to build. It pays back across every other state law and every other jurisdiction your business touches.

AdOpt builds and maintains this kind of program for hundreds of brands across the U.S., Brazil, and Europe. We bring the templates, the technology, and the team. We adapt to your stack, your audience, and your timeline.

Schedule a working session with the AdOpt team and we will walk through your current privacy notice, your data inventory, and your Montana exposure. You will leave with a clear plan, with or without us. Better to know than to guess. The AG is not in the guessing business, and neither should you be.