That is the regulatory weight of a DSAR (data subject access request) under the Montana Consumer Data Privacy Act. Most companies underestimate it because, individually, a single DSAR feels like a customer service ticket. The pain comes from the system: thousands of consumers, dozens of data sources, brittle identity verification, no audit trail, and a 45 day clock that does not negotiate.

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.

This article walks you through how to build, run, and harden a defensible MTCDPA DSAR Policy. Not just the public facing description in your privacy notice, but the operational machine behind it. We will cover the rights themselves, the timelines, the verification, the appeal process, the records, the technology, and the governance.

If your MTCDPA DSAR Policy is on your roadmap, treat this as a working document. Use it to scope, build, and stress test the program. We have set up DSAR programs for hundreds of brands across multiple jurisdictions, and the patterns travel.

Info

Note: this article is the third in a trio with our MTCDPA Cookies Policy and MTCDPA Privacy Policy guides. The three documents (cookies, privacy notice, DSAR) are the three public pillars of an MTCDPA program. We link between them where it helps.

A data subject access request is a request from a consumer to exercise one of the rights granted under privacy law. Under the MTCDPA, those rights include:

• The right to confirm whether a controller is processing the consumer's personal data and to access that data.
• The right to correct inaccuracies in personal data.
• The right to delete personal data.
• The right to obtain a copy of personal data in a portable, readily usable format.
• The right to opt out of the sale of personal data.
• The right to opt out of processing for targeted advertising.
• The right to opt out of profiling that produces legal or similarly significant effects.
• The right to appeal a denied request.

A MTCDPA DSAR Policy is the policy and operational machinery that handles these requests. It is more than a one paragraph description in the privacy notice. It is the workflow, the technology, the staff, the documentation, and the governance that, taken together, makes the rights real.

Why does the law care about DSARs specifically? Because rights without a working mechanism are theoretical. A privacy law that grants the right to access data but has no way for consumers to exercise it is a piece of paper. The MTCDPA, like its sister laws, ties the rights to operational obligations: clear and conspicuous mechanisms, identity verification, response timelines, appeal processes. These obligations are the MTCDPA DSAR Policy in legal form.

For background on how this family of rights came together, our explainer on the LGPD covers the analogous Brazilian framework. The MTCDPA fits the same pattern.

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 sale of personal data (lowered from 25,000).

If you fit either threshold, your MTCDPA DSAR Policy has to handle requests from Montana consumers. SB 297 also tightened the exemptions, removing the broad Gramm-Leach-Bliley Act entity exemption and limiting the nonprofit exemption.

A practical implication: companies that previously sat below the thresholds may now find themselves in scope. The DSAR workload that comes with that is non trivial. A program built reactively, in response to the first request, will struggle. A program built proactively, with a clear policy and an integrated workflow, will not.

Our explainer on the GDPR, LGPD, and CCPA sets context on how scope thresholds work across regimes.

Each MTCDPA right has its own operational profile. Let us walk through them.

A consumer asks the controller to confirm whether their personal data is being processed and to provide a copy of that data. The DSAR workflow has to:

• Verify the consumer's identity (more on this below).
• Search every system that holds personal data linked to that consumer.
• Compile the data in a usable format (typically a structured export, a PDF report, or both).
• Deliver it securely (encrypted email, secure download link, or an in app portal).
• Document the request, the search, the response, and the timeline.

This is the most operationally demanding right because it requires comprehensive coverage. A DSAR that misses a system is a partial response, and the law expects completeness.

A consumer asks the controller to correct inaccuracies. The workflow has to:

• Verify identity.
• Receive the proposed correction.
• Validate the correction (sometimes the consumer is wrong, and the controller has authoritative records).
• Apply the correction to all systems where the data lives.
• Notify downstream recipients of the correction (where reasonable).
• Document the request and the response.

The propagation step is the hardest. A correction that lands in the customer database but not in the marketing automation tool, the analytics platform, or the data warehouse leaves stale data in the wrong places.

A consumer asks the controller to delete their personal data. The workflow has to:

• Verify identity.
• Identify all systems where the data lives.
• Delete or de identify the data, balanced against legitimate retention obligations (legal hold, contractual requirement, fraud prevention).
• Notify downstream recipients.
• Document the request, the deletion, and any retained data with the basis for retention.

Deletion is not always total. The MTCDPA recognizes that some data must be retained for legitimate reasons. The MTCDPA DSAR Policy has to articulate which retention exceptions apply and document them per request.

A consumer asks for a copy of their personal data in a portable, readily usable format that allows them to transmit the data to another controller. The workflow has to:

• Verify identity.
• Compile the data in a structured, machine readable format (commonly JSON or CSV).
• Deliver the export securely.
• Document the request and the format.

Portability overlaps with the right to access but is distinct. The format requirement is more demanding. A PDF satisfies access but not portability.

A consumer asks to be excluded from any sale of their personal data. The workflow has to:

• Capture the opt out signal (web form, universal opt out signal, account setting).
• Propagate the opt out to every system where sale could happen (tag manager, ad platforms, audience graphs, server side pipelines).
• Honor the opt out persistently (it does not expire).
• Document the opt out.

This right is more of a switch than a request, but it is still part of the MTCDPA DSAR Policy. The propagation step is where most programs fall down.

A consumer asks to be excluded from targeted advertising. The workflow is similar to the sale opt out: capture, propagate, honor, document. The propagation logic touches the ad stack: pixels, conversion APIs, audience builds, lookalike modeling, programmatic vendors.

A consumer asks to be excluded from profiling used for legal or similarly significant decisions (credit, employment, insurance, housing, education). The workflow has to identify which systems do this kind of profiling and exclude the consumer.

This is rarer than the other opt outs but more consequential when it applies. Most B2C marketing personalization is not "profiling for significant decisions," but credit scoring or insurance underwriting often is.

A consumer who is denied a request (or who disagrees with the response) can appeal. The workflow has to:

• Receive the appeal through a clear and conspicuous channel.
• Re evaluate the original request with fresh eyes (often a different reviewer).
• Respond within 45 days with the result and the reasoning.
• Inform the consumer of their right to file a complaint with the Montana AG if the appeal is denied.

The appeal process is the safety valve that keeps the MTCDPA DSAR Policy honest. A controller who ignores or rushes appeals will face regulatory escalation faster.

For a deeper dive on the team that operates these rights, the AdOpt piece on the DPO and team is useful.

The MTCDPA gives controllers 45 days from receipt of the request to respond. The deadline can be extended by an additional 45 days for complex requests, provided the controller notifies the consumer of the extension and the reason.

For your MTCDPA DSAR Policy, this means:

The clock starts the day the request is received. Document that date. Define what counts as "complex" in your policy (typically requests that touch multiple systems, require legal review, involve sensitive data, or relate to a deceased consumer's estate). Do not extend by default.

Use the extension when it is needed. Notify the consumer of the extension before the original deadline, not at the last minute, and explain the reason. Build a system that tracks the clock for every active DSAR. A spreadsheet is fine for low volume, but at scale you need a proper case management tool.

Missing a deadline is a regulatory issue. Missing many deadlines is a regulatory pattern. The Montana AG will treat the latter much more seriously than the former.

Identity verification is the gatekeeper of the MTCDPA DSAR Policy. Get it wrong and you give personal data to the wrong person (a privacy breach), or you frustrate legitimate requests (a compliance failure). The MTCDPA expects the controller to use reasonable methods to verify identity, balanced against the sensitivity of the data and the cost to the consumer.

Practical patterns:

For account holders, use the existing authentication. The consumer logs in, submits the request from within the account, and the platform records both the identity and the request. This is the cleanest path.

For non account holders, use one or more of: email confirmation (a one time code sent to an email address the controller has on file), document verification (a redacted ID proof in higher risk cases), knowledge based verification (recent transaction details), or a combination. Keep the proof requested proportionate to the request. Asking for a photo ID for a simple opt out is overkill. Asking for a photo ID for a full data export is more reasonable.

For deletion or portability, the bar is generally higher. The downside of being wrong is bigger.

If you cannot verify identity, do not silently drop the request. Respond to the consumer explaining what you needed and why you could not verify. Document the failure. The MTCDPA does not require you to honor a request you cannot verify, but it does require honesty about the inability to do so.

For a primer on the responsibilities of a data protection officer and how identity verification fits into the broader role, the AdOpt explainer covers the territory.

A DSAR has to come in somehow. The MTCDPA DSAR Policy must offer a clear and conspicuous mechanism, at least as easy to use as the consent mechanism. In practice, that means:

A web form linked from the privacy notice, the cookie banner, the preference center, the footer, the account settings, and any other place a consumer might look. An email address dedicated to privacy requests ([email protected] is a common convention). A phone number where a phone channel is appropriate to your audience. Where applicable, a postal address for written requests.

The web form should:

• Capture the consumer's identity information (with proportionate detail).
• Capture the type of request (access, correction, deletion, portability, opt out, appeal).
• Allow free form notes for additional context.
• Confirm receipt with a tracking number and an estimated response date.
• Send a notification to the privacy team's case management tool.

The web form is the most efficient channel. Email and phone are fallbacks, but every channel must lead to the same case management workflow. A request received by email and one received by web form should follow the same internal process.

For the design of the request flow, the AdOpt take on consent and websites and the cookie banner covers the same UX rigor that should apply to the DSAR portal.

Let us walk through a complete MTCDPA DSAR Policy workflow, from request to closure.

Step 1: Receipt. The request arrives via the web form, email, or other channel. The case management tool creates a case with an ID, the request type, the date received, and the consumer's information.

Step 2: Acknowledgment. Within 24 hours (faster is better), the consumer receives an acknowledgment with the case ID, the expected timeline, and what additional information may be needed.

Step 3: Identity Verification. The privacy team verifies the consumer's identity using the methods described in the policy. If verification fails, the team requests additional information or denies the request with documentation.

Step 4: Routing. The verified request is routed to the appropriate workstreams. Access and portability requests route to the data extraction workflow. Correction requests route to the data update workflow. Deletion requests route to the data deletion workflow. Opt out requests route to the consent state propagation workflow.

Step 5: Search And Compile (For Access And Portability). The privacy team queries every system that holds personal data linked to the consumer. This includes the customer database, the marketing automation tool, the analytics platform, the support ticketing system, the data warehouse, the data lake, the backup snapshots (where reasonable), and any vendor systems where the controller's data resides. The data is compiled in the requested format.

Step 6: Apply Or Validate (For Correction And Deletion). For correction, the proposed update is applied to authoritative systems and propagated downstream. For deletion, the data is deleted or de identified, balanced against retention obligations.

Step 7: Propagate (For Opt Out). The opt out is captured in the consent state and propagated to all relevant systems. The propagation includes both client side (tag manager, browser) and server side (server pipelines, vendor APIs).

Step 8: Quality Check. Before the response goes out, a second reviewer validates the work. For access and portability, that means checking that all systems were searched and the export is complete. For correction, that means checking that the update propagated. For deletion, that means checking that the data is actually gone.

Step 9: Response. The consumer receives the response. For access and portability, that includes the data in the requested format, delivered securely. For correction and deletion, that includes confirmation of the action taken and any retention exceptions applied. For opt out, that includes confirmation of the opt out and information about how to revoke it.

Step 10: Closure And Documentation. The case is closed. The full record (request, verification, search, response, timing) is archived. Any lessons learned are fed back into the program.

Step 11: Appeal Window. If the consumer is dissatisfied, they can appeal. The appeal window remains open per the policy. The consumer is informed of the appeal channel and the right to complain to the Montana AG.

This workflow has to be the same regardless of whether the volume is one request a week or 100 requests a day. The discipline of the workflow is what makes the MTCDPA DSAR Policy defensible.

DSAR volume varies wildly by industry and audience. A few rough benchmarks from public reporting and our own client base:

For consumer brands with a mainstream audience, expect a baseline of 0.05 to 0.5 percent of monthly active users submitting some form of privacy request annually. Most of those will be opt outs. A smaller portion will be access, correction, or deletion.

For privacy conscious audiences (technical users, regulated industries, advocacy groups), the rate can be 5 to 10 times higher.

For audiences that have experienced a privacy incident or news event involving the brand, the rate spikes for weeks or months afterward.

The implication: build for the steady state, but make sure the system can scale. A workflow that handles 5 requests a week comfortably should also be able to handle 50 requests a week without breaking.

Your MTCDPA DSAR Policy should account for capacity planning, training, and on call coverage during peak periods.

A defensible MTCDPA DSAR Policy is paper trailed end to end. The MTCDPA does not prescribe the exact records, but the controller has to demonstrate compliance, which in practice means the following records:

• The request itself: who, what, when, channel.
• The identity verification: method used, outcome, supporting documents (retained securely and only as long as necessary).
• The search and response: which systems were searched, what was found, what was provided, what was withheld and why.
• The timeline: when received, when acknowledged, when responded, any extensions and the reason.
• The appeal (if any): when received, who reviewed, outcome, reasoning.
• Any related vendor or processor activity: which vendors were contacted, what they did.

The records should be retained for a defined period after closure (often three to five years, depending on legal advice and other regimes that apply).

For a primer on the records discipline, the AdOpt piece on ROPA for LGPD is a useful cross reference. The MTCDPA does not use the term ROPA, but the discipline is similar.

Personal data does not just live in your systems. It also lives in your vendors' systems. A MTCDPA DSAR Policy that does not coordinate with processors will produce incomplete responses.

Practical patterns:

For each vendor, document the type of personal data they hold, the purpose, and the contractually defined response time for DSARs. Build standard request templates so the privacy team does not have to start from scratch each time. For high volume vendors, automate the request through APIs where possible. For lower volume vendors, email the data protection contact with a templated request and track the response in the case management tool.

The MTCDPA requires the controller to processor relationship to be governed by a contract that satisfies MCA 30-14-2813. Among other things, the contract has to address the processor's obligations to assist the controller with rights requests. If your vendor contracts do not include this language, fix them.

For the legal shape of the controller versus processor relationship, the AdOpt explainer on controller and processor differences covers the territory.

A reliable DSAR program is built on a reliable data inventory. The inventory is the source of truth that tells the privacy team where personal data lives, who has access, who it is shared with, and how long it is retained.

Without a data inventory, every DSAR becomes a treasure hunt. The privacy team has to ask each system owner whether they have data on the consumer, wait for responses, chase laggards, and hope nothing was missed. With an inventory, the search is methodical: query each system listed in the inventory, in a defined order, and compile the results.

Building and maintaining the inventory is its own discipline. The AdOpt explainer on data mapping and data inventory walks through the methodology. The investment pays back across the entire privacy program, not just the MTCDPA DSAR Policy.

When a DSAR involves sensitive data, the bar gets higher. Sensitive data under the MTCDPA includes data revealing racial or ethnic origin, religious beliefs, mental or physical health diagnosis, sexual orientation, citizenship or immigration status, genetic or biometric data processed for unique identification, precise geolocation data, and personal data of a known child.

For your MTCDPA DSAR Policy, sensitive data implies:

A higher identity verification bar. The consequences of a wrong verification are more severe. More careful handling of the response. Encryption in transit and at rest. Restricted access. Audit logging. Special attention to retention. Some sensitive data should not be retained beyond the immediate need. The DSAR workflow can surface retention violations.

If your business processes sensitive data on Montana consumers, your MTCDPA DSAR Policy has to acknowledge this and elevate the workflow accordingly.

SB 297 strengthens protections for minors. A controller offering an online service, product, or feature to a known minor must use reasonable care to avoid heightened risks of harm.

For DSARs involving minors, your MTCDPA DSAR Policy should:

Allow parents or guardians to submit requests on behalf of a minor, with appropriate verification of the parental relationship. Apply heightened protections to the data being shared, even in the response. Coordinate with school, healthcare, or other minor specific systems where applicable. Document the special handling.

For a deeper dive on consent mechanics and minor protections, the AdOpt piece on consent on websites is a useful primer.

A common mistake in MTCDPA DSAR Policy implementation: deleting from primary systems but forgetting backups, archives, and logs. The MTCDPA expects deletion to be reasonably comprehensive, but it also recognizes that some retention is legitimate (legal hold, fraud prevention, contractual obligation, system logs for security purposes).

The right pattern is to:

Define a "data retention map" that says, for each system, how long data is retained and under what basis. When a deletion request comes in, delete from primary systems immediately. For backups and archives, mark the consumer for deletion and let the next backup rotation purge the data, documenting the timeline.

For logs and security records, document the retention basis and the duration. Do not pretend the deletion is total when it is not. Honest disclosure of retained data and the basis is part of the response.

This pattern keeps the MTCDPA DSAR Policy defensible without overpromising. The Montana AG would rather see honest, well documented partial deletion with clear retention bases than a claim of total deletion that turns out to be false.

The appeal right is the safety valve. If the consumer disagrees with the response, they can appeal, and the controller must re evaluate. If the appeal is denied, the consumer can complain to the Montana AG.

For your MTCDPA DSAR Policy, the appeal workflow:

Should be clearly described in the privacy notice. Should provide a dedicated channel (separate from the original request channel, if practical). Should be reviewed by someone other than the original reviewer (a second pair of eyes catches errors). Should respond within 45 days with the new outcome and the reasoning. Should inform the consumer of their right to file a complaint with the Montana AG, with the AG's contact information, if the appeal is denied.

A well run appeal process catches errors before they escalate to the AG. A poorly run appeal process amplifies the problem.

A MTCDPA DSAR Policy has to be operationalized with technology. The options are roughly: build (custom internal tools), buy (a privacy management platform), or hybrid (a platform plus custom integrations).

For most companies, the buy or hybrid path is the right one. Privacy management platforms have matured. They handle case management, identity verification, system integration, response generation, and audit trails. Custom builds are appropriate only for the largest enterprises with very specific requirements.

When evaluating platforms, the criteria that matter most for a Montana program:

Coverage of the eight rights, including appeal handling. Support for universal opt out signal detection and propagation. Integration with your data inventory and key systems (CRM, marketing automation, data warehouse, analytics). Response time tracking and escalation. Audit trail and reporting. Multilingual support, if your audience requires it. Accessibility, including support for assistive technologies. Vendor coordination, including standardized request templates for processors.

The AdOpt platform handles all of these for the MTCDPA, plus the cookies and privacy notice obligations covered in our companion articles. The integration is designed so the MTCDPA DSAR Policy plugs into the same consent and rights framework as the rest of your privacy program.

For more on platform selection, the AdOpt explainer on how to choose a CMP is the right starting point.

Some of the most common MTCDPA DSAR Policy mistakes we see in early implementations:

Mistake one: Treating DSAR as a customer service ticket. A DSAR is a regulated process with defined timelines and outcomes. Customer service tools can be the front end, but the workflow has to live in a privacy management system or equivalent.

Mistake two: Identity verification by best guess. Inconsistent verification leads to bad outcomes. Define the verification method, document it, and apply it consistently.

Mistake three: Forgetting downstream systems. The customer database is not the only place data lives. Marketing automation, analytics, support, finance, data warehouse, vendor systems all hold data. The DSAR has to reach all of them.

Mistake four: Over claiming on deletion. Saying "all your data is deleted" when backups still hold copies is false. Honest, scoped deletion is better.

Mistake five: Delayed acknowledgment. A DSAR submitted on Monday and acknowledged on Friday is technically within rules but feels slow. Aim for same day acknowledgment.

Mistake six: Untracked appeals. Appeals get treated as continuations of the original case rather than as separate cases with their own clock. Set up the appeal as a distinct workflow with its own record.

Mistake seven: No standard response templates. Each response is a custom write up, slow to produce, inconsistent in quality. Templates speed the work and improve consistency.

Mistake eight: No vendor coordination process. The privacy team scrambles to email vendors each time. Standardize the templates and the contacts.

Mistake nine: No reporting. The privacy team has no aggregate view of DSAR volume, response times, or denial rates. Reporting is essential for both program management and regulatory disclosure (if asked).

Mistake ten: No periodic audit. The DSAR process drifts. Quarterly audits catch the drift before it compounds.

The AdOpt piece on risky processes in marketing overlaps with several of these. The piece on ignoring privacy law is a sober reminder of where the wrong path leads.

A DSAR is also a customer experience. The consumer asking the question wants to feel respected. The brand answering the question has a chance to deepen trust or to break it.

For your MTCDPA DSAR Policy as a customer experience:

The intake form should not feel hostile. The acknowledgment should be warm. The response should be plain language, not legalese. The opt out, when applied, should be explained clearly so the consumer knows what changed. The appeal channel should feel like an offer of dialogue, not a defensive wall.

Brands that get this right find that DSARs improve trust and retention. Brands that get it wrong find that DSARs become the moment when consumers leave.

The discipline is the same as for the privacy notice and the cookie banner. Treat the consumer as a partner. Make the experience easy. Be honest about what is happening.

For a deeper take on adapting marketing under privacy law, the AdOpt piece on adapting digital marketing is a useful read. The principles apply directly to the DSAR experience.

A mature MTCDPA DSAR Policy has reporting baked in. The metrics that matter most:

Total DSAR volume by month, segmented by request type. Response time, both average and 90th percentile. Identity verification success rate. Denial rate, with reasons. Appeal volume and outcome. Vendor response time, where vendor coordination is part of the workflow. Consumer satisfaction score, where measured.

These metrics serve three purposes. First, they tell the program owner where to invest. Second, they give the executive team a clear picture of privacy operations. Third, they prepare the company to respond if the Montana AG ever asks for a snapshot of DSAR operations.

A simple monthly dashboard is enough for most companies. Larger companies will want a more structured reporting cadence with quarterly business reviews.

For clients who use AdOpt, the MTCDPA DSAR Policy plugs into a unified privacy operations framework. The same identity that opts out of cookies on the website is the identity that submits a DSAR through the portal. The same consent state that powers the cookie banner is the consent state that propagates to vendors. The same audit trail that records consent records DSARs.

In practice, what we deliver:

A DSAR portal embedded in the privacy notice and the preference center. Identity verification with a configurable bar by request type. A case management workflow integrated with the data inventory and the major systems. Vendor coordination templates and processes. An appeal workflow that runs as a distinct case with its own clock and reviewer. Reporting and metrics out of the box. Documentation and audit trail.

We also bring the experience of running these programs across hundreds of brands in multiple jurisdictions. The MTCDPA is one piece of the puzzle. The same framework handles California, Colorado, Connecticut, Virginia, Texas, the EU's GDPR, and Brazil's LGPD.

For more on the technology and the program, our explainer on how to choose a cookie banner and on what a CMP is cover the platform thinking that powers all of this.

Let us make this concrete with a simulated request.

Day 0. A Montana consumer submits a request through the privacy portal: "I would like a copy of all personal data you hold on me. I am also exercising my right to opt out of targeted advertising."

The portal records the request, sends an acknowledgment with a case ID and a 45 day target date, and routes the request to the case management tool.

Day 0 to Day 2. Identity verification. The consumer is an account holder. The system verifies via the active session and a one time code sent to the email on file. Verification succeeds.

Day 2 to Day 7. Search and compile. The privacy team queries the customer database, the marketing automation tool, the analytics platform, the support ticketing system, the data warehouse, and the email marketing vendor. The data is compiled in JSON and PDF formats. Sensitive data, if any, is flagged and reviewed.

Day 7. Quality check. A second reviewer validates that all systems were searched, the data is complete, and the format meets portability requirements.

Day 7. Opt out propagation. The opt out for targeted advertising is captured in the consent state and propagated to the tag manager, the ad platforms, and the server side pipelines. The propagation is verified.

Day 8. Response. The consumer receives the data via a secure download link, with a plain language explanation of what is included, what was retained, and on what basis. The opt out is confirmed.

Day 8. Closure and documentation. The case is closed. The record is archived.

Day 8 onwards. Appeal window. The consumer is informed of the appeal channel and the right to file a complaint with the Montana AG. The portal stays open for any follow up.

This is what a clean MTCDPA DSAR Policy workflow looks like in practice. Eight days is faster than the 45 day deadline, and that is intentional. Beating the deadline by a wide margin builds trust and gives the program room for the harder cases.

For a story driven take on what happens to companies that skip this work, the AdOpt piece on a company that got fined is worth reading.

SB 297 adds a maximum civil penalty of up to 7,500 dollars per violation, plus injunctive relief and attorney fees. A failed DSAR can be a violation. A pattern of failed DSARs is a much bigger problem.

The Montana AG, like other state attorneys general, tends to escalate based on patterns rather than single incidents. A single missed deadline is unlikely to draw an enforcement action. A pattern of missed deadlines, denied requests without proper basis, or false claims about deletion will draw attention.

The cost compounds. AG investigations are expensive. Legal fees pile up. Brand damage is hard to quantify but very real. Consumer trust, once lost, is slow to rebuild.

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

If you have customers in multiple jurisdictions, your MTCDPA DSAR Policy has to coexist with other rights frameworks. The CCPA has its own definitions and timelines. Colorado, Connecticut, Virginia, Texas each have their own. The GDPR (for European customers) has different timelines and additional rights (objection, restriction). The LGPD (for Brazilian customers) has its own.

The smart pattern is to design a single workflow that satisfies the strictest requirements across the regimes you are subject to. The 30 day GDPR baseline is a stricter timeline than the 45 day MTCDPA baseline. Building to 30 days as a target makes the MTCDPA DSAR Policy automatically compliant on timing.

The same applies to other elements: the strictest identity verification, the most thorough appeal process, the broadest response set. Building to the highest bar makes cross jurisdictional compliance easier, not harder.

For a comparison of the LGPD versus GDPR on DSAR mechanics, the AdOpt explainer is a useful reference.

In a low volume program, every DSAR can get the same level of attention. In a higher volume program, triage matters. Not every request requires the same workflow.

For your MTCDPA DSAR Policy, a useful triage model:

Tier 1: Opt out requests. These are usually simple to process. Capture, propagate, confirm. Most can be automated end to end. Volume tends to be high. Response time can be near real time for the propagation, with a confirmation email within 24 hours.

Tier 2: Access and portability requests. These require a search across systems and a compiled response. Volume is lower but each request takes more effort. Aim for a 10 to 14 day turnaround as the internal target, well inside the 45 day legal deadline.

Tier 3: Correction requests. These require validation of the proposed correction and propagation across systems. Volume tends to be very low but each request is precise work. Aim for a 14 to 21 day turnaround.

Tier 4: Deletion requests. These are the most complex, with the most retention edge cases and the most propagation steps. Aim for a 21 to 30 day turnaround.

Tier 5: Appeals and escalations. These require fresh review. Allocate a senior reviewer who was not involved in the original decision. Track the appeal as a distinct case. Aim for a 21 day turnaround.

Triage lets a small privacy team handle a large volume without dropping requests. It also lets the program scale predictably as the customer base grows.

Privacy programs that do not forecast volume tend to scramble. The MTCDPA DSAR Policy should include a capacity model that links expected volume to staffing and tooling.

A simple capacity model:

Estimate annual DSAR volume as a percentage of monthly active Montana users. Adjust for industry baseline (regulated industries see higher volume). Convert to weekly volume for staffing purposes. Estimate average effort per request by tier (a Tier 1 opt out might be 5 minutes, a Tier 4 deletion might be 4 hours). Multiply weekly volume by effort per request, summed across tiers, to get total weekly hours. Add buffer for appeals and complex cases. Translate to FTE.

For most mid sized companies, the steady state DSAR workload is a fraction of a full time equivalent. The peaks (after a privacy news event, a regulatory change, or a brand incident) can spike to several FTE for a few weeks. The capacity model should cover both the steady state and the peak.

The right tooling reduces the FTE estimate dramatically. Automated identity verification, integrated system queries, and standard response templates can cut the effort per request by 50 to 80 percent. Investing in tooling pays back fastest at the higher tiers.

A MTCDPA DSAR Policy that produces unreliable responses creates regulatory and trust exposure even if the timelines are met. Quality assurance is essential.

A simple QA program:

Sample 5 to 10 percent of DSAR responses for review by a senior privacy team member. Use a standardized rubric: was identity verification proportionate, was the search comprehensive, was the response complete, was the timeline met, was the documentation complete. Track defect rates by tier. Investigate any tier where defect rate exceeds a defined threshold. Feed lessons learned into training, templates, and process updates.

A higher level QA review should happen quarterly. The privacy officer reviews aggregate metrics, samples specific cases, and produces a quality report. The report becomes part of the audit trail.

QA is the difference between a program that looks compliant on paper and a program that is actually compliant. It is also the difference between a program that improves over time and one that drifts.

DSARs do not arrive in a vacuum. They tend to cluster around specific lifecycle moments:

Onboarding. Some consumers want to verify what data was collected during signup. These DSARs are usually simple. Use them as an opportunity to build trust.

Mid lifecycle. Active customers occasionally submit DSARs to update or correct information. Most are routine.

Churn moment. A consumer about to cancel or has just canceled often submits a deletion request. This is a sensitive moment. Handle the DSAR cleanly, but also try to understand the underlying reason for churn.

Post incident. If the brand experiences a privacy news event, DSAR volume spikes. The handling has to be especially careful in this period.

News event affecting the broader industry. Even if your brand is not directly involved, a high profile privacy incident in your industry can drive a spike in DSARs across the market.

Your MTCDPA DSAR Policy should anticipate these patterns and plan accordingly. Customer support, marketing, and the privacy team should coordinate so the consumer experience is consistent across the lifecycle.

The MTCDPA does not include a general "right to object" the way the GDPR does, but it includes specific opt out rights that function similarly. The opt out of targeted advertising, the opt out of sale, and the opt out of profiling for significant decisions are all forms of objecting to specific kinds of processing.

For your MTCDPA DSAR Policy, treat each opt out as a distinct workflow with its own propagation logic. The opt out of sale touches the ad stack and any data sharing pipeline. The opt out of targeted advertising touches the ad stack but not necessarily other sharing. The opt out of profiling for significant decisions touches specific systems (credit scoring, insurance underwriting) but not general personalization.

Consumers often submit a generic "opt out of everything" request. Your policy should describe how generic requests are interpreted and applied. The default is usually to apply all available opt outs unless the consumer specifies otherwise. Be transparent about what you applied and let the consumer adjust if they want a finer grained outcome.

Many companies operate as a family of related entities (parent, subsidiaries, affiliates). The MTCDPA does not exempt intra family data sharing from disclosure obligations, and a DSAR has to reach the data wherever it lives.

For your MTCDPA DSAR Policy:

Document the data sharing arrangements within the corporate family. Each affiliate that holds data should be on the search list for access requests, the propagation list for opt outs, and the deletion list for deletion requests. Standardize the request templates and contacts within the family. Coordinate appeals across the family so the consumer gets a unified response.

This area gets bureaucratic fast in larger groups. The discipline pays back. A consumer who gets contradictory answers from different entities of the same group quickly loses trust and is more likely to escalate to the AG.

The records of a DSAR are personal data themselves. The consumer's name, request, and any verification documents are linked to them and reasonably linkable. Your MTCDPA DSAR Policy has to handle this data carefully.

Best practice:

Store DSAR records in a secure system, with access limited to the privacy team. Encrypt at rest and in transit. Define a retention period for DSAR records (typically three to five years after closure, depending on legal advice and applicable regimes). Apply the same access, correction, deletion, and portability rights to the DSAR records themselves.

The principle of minimal data and clear retention applies recursively. The records of the rights process should themselves be subject to the rights they describe.

The tone of DSAR communication matters as much as the content. Brands that get this right write in plain language, treat the consumer as an adult, and keep the legal language to the minimum required.

A few examples of tone we recommend for an MTCDPA DSAR Policy experience:

The acknowledgment email: "Hi [name], we received your privacy request on [date]. Your case ID is [ID]. We will respond within 45 days, but we usually move faster. If we need anything else from you, we will email this address. Thank you for reaching out."

The response email for an access request: "Hi [name], here is the personal data we hold on you, organized by category. We have included a JSON file (machine readable) and a PDF (easier to read). If you find anything that is incorrect, you can submit a correction request through this same portal. If you want to opt out of any of this processing, the preference center is here."

The denial email: "Hi [name], we received your request to [delete / port / correct / etc.]. We are not able to fully honor it for the following reasons: [specific, plain language reasons]. You have the right to appeal this decision. You can do so by [link or instructions]. You also have the right to file a complaint with the Montana Attorney General's Office of Consumer Protection. Thank you for your patience."

Plain. Honest. Respectful. The tone says more about the brand than any disclosure does.

A defensible MTCDPA DSAR Policy is only as good as the vendors that support it. Vendors that hold personal data have to honor the controller's DSARs reliably. If they do not, the controller is on the hook.

A vendor audit cadence:

Annually, review each vendor's privacy and security posture, including their support for rights requests. For high volume vendors, test the vendor's DSAR process directly (submit a test DSAR through the channel and time the response). Document the audit results. Update vendor contracts where the audit reveals gaps. Add the audit calendar to the broader privacy program audit.

Vendor audits are tedious but valuable. They surface problems before a real DSAR exposes them. They also give the privacy team data to use in vendor renewal negotiations.

A small terminology note. Some commentators distinguish between the "right to know" (the right to learn what data is being processed) and the "right to access" (the right to obtain a copy of the data). The MTCDPA bundles these into a unified right.

For your MTCDPA DSAR Policy, treat the bundled right as a single workflow. The consumer can ask whether you have data on them; you confirm. They can ask for a copy; you provide. The two questions almost always come together, and the workflow handles both.

The customer support team often receives DSARs by accident. A consumer emails support asking what data the company has on them, or asking to be deleted, or asking to opt out of marketing. The customer support team has to recognize these as DSARs and route them to the privacy team.

For your MTCDPA DSAR Policy:

Train the customer support team on what a DSAR looks like. Provide a simple decision tree (if the consumer is asking about their personal data, route to privacy). Build a standard handoff process from the support tool to the case management tool. Document the handoff for the audit trail.

Without this training, DSARs get lost in the support queue and the 45 day clock runs out. With it, the customer support team becomes an extension of the privacy program.

Sales teams sometimes receive DSARs in unusual contexts. A prospect during the sales cycle asks about data handling. A customer renewing a contract asks for an audit of their data. An enterprise prospect submits a DSAR style request as part of due diligence.

For your MTCDPA DSAR Policy:

Train the sales team to recognize DSAR signals during the sales cycle. Have a privacy enablement deck that the sales team can share. Route any actual DSAR through the privacy program, even if it came in through sales.

This is a small but important detail. Enterprise buyers in regulated industries often look at how the vendor handles privacy as part of the procurement decision. A clean MTCDPA DSAR Policy can be a competitive advantage.

When a controller is under legal hold for litigation or regulatory investigation, deletion requests interact with the hold. Personal data under legal hold typically cannot be deleted, even in response to a DSAR.

For your MTCDPA DSAR Policy:

Coordinate with the legal team on the current legal hold inventory. When a deletion request arrives, check whether the consumer's data is under hold. If it is, document the basis and respond honestly to the consumer (the data cannot be deleted because it is subject to a legal hold; the hold will be reviewed periodically; once the hold is lifted, the deletion will be applied).

This kind of honesty is required by the MTCDPA. The consumer is entitled to know why deletion was not applied. Hiding behind generic "legal reasons" language is not enough.

A DSAR can sometimes intersect with a data breach. A consumer who suspects their data has been compromised may submit a DSAR to confirm what was held. A consumer affected by a breach may submit a deletion request as a result.

For your MTCDPA DSAR Policy:

Coordinate with the incident response team. If the consumer is in scope of a recent breach, the response should reflect that (for example, by including breach notification information in the DSAR response). Track DSARs received in the wake of a breach as a distinct cohort. Volume often spikes. Consider whether proactive communication with affected consumers is appropriate. Sometimes a well crafted breach notification reduces inbound DSAR pressure.

The intersection between breach response and DSAR response is a high stakes area. Get it wrong and the regulatory exposure compounds. Get it right and the consumer experience can actually be reassuring even in a difficult moment.

Some industries have heightened DSAR considerations. Healthcare adjacent businesses (even those not regulated by HIPAA) often see sensitive data in DSARs. Financial services, even with the GLBA data exemption preserved by SB 297, see complex DSARs that touch both regulated and non regulated data. Education businesses handling student data see DSARs that intersect with FERPA. Insurance and real estate businesses see DSARs that touch profiling for significant decisions.

For your MTCDPA DSAR Policy in a sensitive industry:

Map the regulatory overlay carefully. The MTCDPA may not be the only regime that applies. Coordinate with industry specific compliance functions (HIPAA, FERPA, GLBA). Apply the strictest applicable standard for identity verification and response handling. Document the multi regime treatment in case of regulatory inquiry.

The investment in a careful program pays back across all the regimes that apply, not just the MTCDPA.

A good MTCDPA DSAR Policy improves over time. The first version handles the basic flow. The second adds automation. The third adds reporting. The fourth adds proactive consumer experience. The fifth integrates with the broader customer journey.

For continuous improvement:

Quarterly review of DSAR metrics and qualitative feedback. Annual review of the policy itself. Periodic benchmark against industry peers. Engagement with privacy professional communities (IAPP and similar) to learn from peers. Investment in tooling, training, and team capacity as the program matures.

The teams that compound improvement on the MTCDPA DSAR Policy find that DSARs become an asset, not a burden. The consumer experience improves. The regulatory exposure shrinks. The program becomes a quiet source of differentiation.

A DSAR will often intersect with cookie based tracking. A consumer asking what data is held may want to see the cookie identifiers tied to their browser. A consumer asking for deletion may want the cookie based profile cleaned up. A consumer opting out wants the cookies and the downstream pipelines to stop firing.

For your MTCDPA DSAR Policy:

Tie the cookie identifier to the customer record where possible. For account holders, this is straightforward through login state. For anonymous browsers, the link is harder, but the consumer can provide the identifier via the preference center if they want to exercise rights tied to it.

When deletion is requested, the cookie based profile linked to the customer record should be cleaned up across the ad and analytics stack. This includes both the cookies stored in the browser and the corresponding records in the vendor systems (audience graphs, profile databases, attribution stores).

When opt out is exercised, the cookie based pipelines for sale, targeted advertising, or profiling should stop. The propagation should be verified. The companion AdOpt explainer on cookies and privacy walks through the cookie side of this in detail. Our explainer on the difference between cookies, local storage, and session storage is also relevant when the consumer asks about all the local browser based data the controller may have stored.

For consumers who want to clean up their browser side state independently, our short guide on how to delete cookies and cache is a useful link to share. It does not replace your DSAR obligations, but it gives the consumer self service options for the browser side.

Universal opt out signals (Global Privacy Control and similar) are a form of DSAR by automation. The consumer is, in effect, sending a standing opt out signal that the controller must honor.

For your MTCDPA DSAR Policy:

Detect the signal at the request level. Treat the signal as a valid opt out for sale and targeted advertising, applied automatically and without requiring the consumer to confirm. Where possible, log the signal so the consumer has a record of when the opt out took effect. Coordinate the signal with any account level opt out so the consumer experience is consistent.

The signal does not replace the rest of the MTCDPA DSAR Policy. The consumer can still submit access, correction, deletion, or portability requests. The signal is a baseline. Our explainer on how to choose a CMP covers the signal handling architecture in more detail.

Some DSARs come from authorized agents acting on behalf of the consumer. The MTCDPA permits authorized agents, with appropriate verification of the agent's authority.

For your MTCDPA DSAR Policy:

Define the authorized agent process: how the agent identifies themselves, what proof of authorization is required (typically a signed letter or power of attorney), and how the consumer is verified independently to confirm the agent is in fact authorized.

Treat agent submitted DSARs with the same care as direct submissions, but with the additional verification step. Document the agent's role in the case file.

This pattern is important for accessibility. Consumers who are unable to navigate the request process directly (older adults, individuals with disabilities, individuals with limited English proficiency) often rely on agents. A program that handles agent requests well is more inclusive.

A surprisingly common reason for failed DSARs is consumer misunderstanding. A consumer asks for "everything you have on me" but does not realize that anonymous web traffic from before they became a customer is hard to link to them.

A consumer asks for deletion but does not realize that financial records have to be retained for tax purposes. A consumer asks for portability but does not realize that the data they want is not in the controller's systems but in a connected vendor.

For your MTCDPA DSAR Policy:

Build a consumer education layer into the request portal. Plain language explanations of what each right covers and what to expect. FAQ that addresses the common misunderstandings. Examples of typical responses. A quick chat or guidance feature for consumers who want to understand before they submit.

This layer reduces frustration, reduces appeal volume, and improves trust. It also reduces the operational burden on the privacy team.

Behind every DSAR workflow is a set of engineering decisions. The systems where data lives. The query patterns to extract data. The deletion logic. The audit logging. The propagation pipelines.

For your MTCDPA DSAR Policy to be defensible, the engineering layer has to support it:

System inventory mapped to the data inventory. Each system has a defined query interface for DSARs (an API, a script, a manual procedure). Deletion logic that handles the long tail (backups, archives, logs) reasonably. Propagation pipelines that respect consent state end to end. Audit logging that captures every DSAR action with sufficient detail for review.

The engineering investment is real. It is also reusable. The same machinery serves CCPA, Colorado, Connecticut, Virginia, Texas, GDPR, LGPD, and any other rights regime. Once built, it is the durable foundation of the privacy program.

For more on the broader DPO and team that owns this engineering layer in coordination with the privacy office, the AdOpt explainer is a useful reference.

The marketing team feels the impact of DSARs more directly than most other functions. Opt outs reduce reachable audience. Deletions remove records. Corrections require list cleansing. Each one is an operational ripple.

For your MTCDPA DSAR Policy in the context of marketing:

Build deletion logic that reaches every marketing system. CRM, marketing automation, email service provider, ad platform audiences, lookalike sources, attribution stores. Build opt out propagation logic that touches the same systems with appropriate consent state. Build correction propagation logic so updated email addresses or phone numbers reach every list. Train the marketing team on what changes mean for campaign planning and reporting.

A privacy aware marketing team reads DSAR metrics as feedback on the program, not as a tax. The right tooling makes the operations almost invisible.

For more on adapting marketing under privacy law, the AdOpt take on adapting digital marketing and on risky marketing processes cover the territory.

A defensible MTCDPA DSAR Policy is the operational heart of a Montana privacy program. The privacy notice describes the rights. The cookies policy describes the cookies. The DSAR policy is what makes the rights real for the consumer.

Building this well is a discipline, not a project. It takes the right technology, the right team, the right documentation, and the right cadence. The investment pays back in lower regulatory exposure, higher consumer trust, and a stronger position across every other state and global privacy law.

If your MTCDPA DSAR Policy is on your roadmap, AdOpt has been doing this work for years across hundreds of brands. We bring the framework, the templates, the technology, and the team. We adapt to your stack, your audience, and your timeline.

You have 45 days from receipt of the request, with the option to extend by an additional 45 days for complex requests, provided you notify the consumer of the extension and the reason. The clock starts the day the request arrives, regardless of channel. Your MTCDPA DSAR Policy should track the clock for every active request and trigger extension notifications well before the original deadline.

You are not required to honor a request you cannot reasonably verify, but you must respond to the consumer with a clear explanation of why verification failed and what would be needed to retry. Document the verification attempt and the outcome. The MTCDPA expects reasonable methods proportionate to the sensitivity of the data, so your policy should define the verification standard and apply it consistently.

Reasonable comprehensive deletion is the standard. You delete from primary systems immediately, mark backups for deletion as they rotate, and document any retention exceptions (legal hold, fraud prevention, contractual obligation, system logs for security). The MTCDPA DSAR Policy must be honest with the consumer about what was retained and why. False claims of total deletion are a regulatory risk.

You coordinate with your vendors. Each vendor contract should require the vendor (as processor) to assist you with DSARs. Build standard request templates and document each vendor's response time. The vendor's response feeds into your overall response to the consumer. The MTCDPA DSAR Policy treats vendor coordination as part of the core workflow, not as an afterthought.

The consumer can appeal. Your MTCDPA DSAR Policy must offer a clear and conspicuous appeal channel, ideally separate from the original request channel. The appeal must be reviewed (preferably by someone other than the original reviewer) and responded to within 45 days.

If the appeal is denied, you must inform the consumer of their right to file a complaint with the Montana Attorney General, including how to do so. A well run appeal process is the safety valve that catches mistakes before they escalate to enforcement.

A real MTCDPA DSAR Policy is more than a paragraph in your privacy notice. It is the workflow, the technology, the team, the documentation, and the governance that, taken together, makes consumer rights real. The investment pays back across every state law and every other jurisdiction your business touches.

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

Book a meeting with the AdOpt team and we will walk through your current rights workflow, your data inventory, and your Montana exposure. You will leave with a clear plan, with or without us. The Montana AG is not in the guessing business, and neither should you be.