Maryland Online Data Privacy Act: what happens when the cure period stops covering violations after 1 April 2027, and what evidence should your own agents be assembling now?

Most privacy teams talk about Maryland's cure period as if it were a safety net.

It is not a net. It is a door the regulator may choose to open.

And the statute already says which violations that door can open for. Anything alleged to occur after 1 April 2027 falls outside the section entirely.

That changes the question. Not "will we get time to fix it?" but "what can we show on the day someone asks?"

What does MODPA's cure provision actually promise, and why is it not a right?

The Maryland Online Data Privacy Act puts its cure mechanism in §14-4614. Read the verbs carefully.

Under §14-4614(B), before starting an enforcement action, "THE DIVISION MAY ISSUE A NOTICE OF VIOLATION TO THE CONTROLLER OR PROCESSOR IF THE DIVISION DETERMINES THAT A CURE IS POSSIBLE."

Two conditions sit in that sentence. The Division must decide a cure is possible. And even then, it "may" issue a notice. Nothing obliges it to.

Only if a notice is issued does the clock start. §14-4614(C)(1) says the controller or processor "SHALL HAVE AT LEAST 60 DAYS TO CURE THE VIOLATION AFTER RECEIPT OF THE NOTICE." If the cure fails, §14-4614(C)(2) lets the Division bring an enforcement action.

So the Maryland privacy law cure period is a discretionary offer with a guaranteed floor once made. It is not an entitlement.

§14-4614(D) lists what the Division may weigh when deciding whether to offer it:

• the number of violations
• the size and complexity of the controller or processor
• the nature and extent of its processing activities
• the likelihood of injury to the public
• the safety of persons or property
• whether the alleged violation was likely caused by human or technical error
• the extent to which the controller or processor has violated this subtitle or similar laws in the past

Look at factor six. "Human or technical error" is a factual claim. You make it with records, not with a policy.

Which violations does the 1 April 2027 line cover, and which fall outside it?

§14-4614(A) scopes the whole section: it "APPLIES TO AN ENFORCEMENT ACTION UNDER § 14-4613 OF THIS SUBTITLE FOR AN ALLEGED VIOLATION THAT OCCURS ON OR BEFORE APRIL 1, 2027."

The date is attached to when the alleged violation occurs. Not to when the Division investigates, and not to a compliance deadline.

Three practical readings follow:

→ A violation alleged to occur on or before 1 April 2027 is within the section. The Division may still decline to issue a notice.

→ A violation alleged to occur after 1 April 2027 is outside §14-4614. The text offers no notice mechanism for it.

→ A continuing practice that straddles the date is the hard case. The statute does not say how the Division will date it, so your own records of when a practice started and stopped matter.

What sits behind the door is §14-4613(A). A violation is "AN UNFAIR, ABUSIVE, OR DECEPTIVE TRADE PRACTICE WITHIN THE MEANING OF TITLE 13 OF THIS ARTICLE," subject to Title 13 enforcement and penalties, "EXCEPT FOR § 13-408 OF THIS ARTICLE." Under §14-4613(B), the section "DOES NOT PREVENT A CONSUMER FROM PURSUING ANY OTHER REMEDY PROVIDED BY LAW."

Who is in scope at all? §14-4602 reaches persons that conduct business in Maryland or target its residents and, in the preceding calendar year, controlled or processed the personal data of at least 35,000 consumers (excluding data processed solely to complete a payment transaction), or at least 10,000 consumers while deriving more than 20% of gross revenue from selling personal data.

What will the Division ask to see first: the data protection assessment?

If an investigation opens, the document with its own production clause is the data protection assessment.

§14-4610(D)(1): "THE DIVISION MAY REQUIRE THAT A CONTROLLER MAKE AVAILABLE TO THE DIVISION A DATA PROTECTION ASSESSMENT THAT IS RELEVANT TO AN INVESTIGATION CONDUCTED BY THE DIVISION."

Under §14-4610(D)(2), the Division may evaluate it for compliance, and the assessment "MAY BE USED IN AN ACTION TO ENFORCE THIS SUBTITLE."

Two protections apply. §14-4610(D)(3) makes the assessment confidential and exempt from disclosure under the federal Freedom of Information Act and the Public Information Act. §14-4610(G) says disclosing privileged material in it to the Division does not waive attorney-client privilege or work product protection.

That is the Division's evidence path in plain terms. A MODPA data protection assessment is not a filing. It is the record you hand over when asked, and it can be used against you.

Which processing triggers a data protection assessment under §14-4610, and from what date?

§14-4610(B): a controller "SHALL CONDUCT AND DOCUMENT, ON A REGULAR BASIS, A DATA PROTECTION ASSESSMENT FOR EACH OF THE CONTROLLER'S PROCESSING ACTIVITIES THAT PRESENT A HEIGHTENED RISK OF HARM TO A CONSUMER, INCLUDING AN ASSESSMENT FOR EACH ALGORITHM THAT IS USED."

§14-4610(A) defines heightened-risk processing as:

• processing for targeted advertising
• the sale of personal data
• the processing of sensitive data
• profiling that presents a reasonably foreseeable risk of unfair, abusive or deceptive treatment, unlawful disparate impact, financial, physical or reputational injury, offensive intrusion on seclusion, or other substantial injury

"Each algorithm that is used" is the phrase most inventories will miss. A ranking model, a lookalike audience, a fraud score. If it sits inside a heightened-risk activity, the text asks for an assessment of it.

The date is narrow and specific. §14-4610(H): an assessment "SHALL APPLY TO PROCESSING ACTIVITIES THAT OCCUR ON OR AFTER OCTOBER 1, 2025" and is not required for processing before that date. Today, that window is already a year deep.

Content is prescribed too. §14-4610(C) requires weighing benefits against risks to consumer rights, as mitigated by safeguards, and the necessity and proportionality of the processing. The controller must factor in de-identified data, consumer expectations, context, and the controller-consumer relationship.

Reuse is allowed, within limits. §14-4610(F) accepts an assessment done for another law if it is "REASONABLY SIMILAR IN SCOPE AND EFFECT." §14-4610(E) lets one assessment cover a comparable set of similar operations. A GDPR DPIA may qualify. Whether it does is a scope comparison you should document, not assume.

On sensitive data Maryland draws a hard line. Under §14-4607(A), a controller may not "SELL SENSITIVE DATA," and may not collect, process or share it except where that is "STRICTLY NECESSARY TO PROVIDE OR MAINTAIN A SPECIFIC PRODUCT OR SERVICE REQUESTED BY THE CONSUMER." §14-4607(B)(1)(I) limits all collection to what is "REASONABLY NECESSARY AND PROPORTIONATE." An assessment that cannot show the strict-necessity reasoning for each sensitive data flow is the weakest page in the file.

Can your opt-out and authorized-agent handling be shown as evidence, or only described in a policy?

Most privacy notices describe opt-out handling. Fewer teams can replay it.

§14-4606(A)(2) lets a consumer designate an authorized agent "BY AN INTERNET LINK OR A BROWSER SETTING, BROWSER EXTENSION, GLOBAL DEVICE SETTING, OR OTHER SIMILAR TECHNOLOGY." Call it the universal opt-out authorized agent channel.

§14-4606(B): the controller "SHALL COMPLY" with an opt-out request from an authorized agent if, "USING COMMERCIALLY REASONABLE EFFORTS," it can authenticate the consumer's identity and the agent's authority to act.

That creates a record you will want to produce:

→ the signal or request received, and when → the authentication steps taken for consumer and agent → the decision, and the systems the opt-out propagated to

Timing is the second record. §14-4605(E)(2) requires a response "NOT LATER THAN 45 DAYS AFTER THE CONTROLLER RECEIVES THE CONSUMER REQUEST." One extension of 45 days is allowed if it is reasonably necessary and the controller tells the consumer, with the reason, within the initial 45-day period.

A policy says you do this. A log shows you did. If you ever argue "technical error" under §14-4614(D)(6), the log is the argument.

What must your processor contracts contain, and can you show it per vendor?

§14-4608(A) requires a binding contract between controller and processor. Paragraph (2) requires it to set out processing instructions, the nature and purpose of processing, the type of data, the duration, and the rights and obligations of both parties.

Paragraph (3) lists the processor contract requirements. The contract must require the processor to:

• ensure each person processing the data is subject to a duty of confidentiality
• maintain reasonable administrative, technical and physical security practices
• stop processing on the controller's request made in accordance with a consumer's authenticated request
• at the controller's direction, delete or return all personal data at the end of the service, unless retention is required by law
• on reasonable request, make available all information necessary to demonstrate compliance
• engage subcontractors only after giving the controller an opportunity to object, under a written contract carrying the same obligations
• allow and cooperate with reasonable assessments by the controller, its designated assessor, or a qualified independent assessor

§14-4608(B) adds that the processor must provide the information needed for the controller to conduct and document data protection assessments.

The evidence question is per vendor, not per template. Can you show, for each processor touching Maryland consumers' data, which clause covers each item and when it was signed? That is the register a reviewer can test, and it is what third-party risk and data registries are built to hold.

Why should your own agents assemble the evidence while a source-grounded engine checks it?

Everything above is evidence that already lives in your systems. Consent and opt-out logs in your CMP and request tooling. Contracts in your CLM. Algorithm inventories in your data platform.

The labor is gathering it. The risk is trusting a model to say what the law requires.

So split the jobs.

→ Your agents run inside your perimeter, under your IAM and logging, and assemble the records: the data protection assessment inputs per heightened-risk activity, the opt-out and authorized-agent logs, the processor clauses per vendor.

→ The engine holds the obligations. Every one traces to a verbatim quote from §14-4605 through §14-4614, not to a model's memory of Maryland law.

→ What your agents submit lands on that record. A gap shows as a gap against a quoted sentence.

Bring your own agent: Claude Code, or any MCP client. The platform is open over MCP and API, and designed so we receive findings, not credentials. See how it is built at agrc.ai/platform.

Your agents do the work. Our engine keeps it honest.

Answer once. Assess everything. Inside 60 minutes you'll see your exposure mapped to the obligations that actually apply to you, across 295+ regulations in 34 jurisdictions: agrc.ai.

FAQ

Is the Maryland cure period a right? No. Under §14-4614(B), the Division "may" issue a notice of violation if it determines a cure is possible. Only once a notice is issued does §14-4614(C)(1) guarantee at least 60 days to cure.

Is 1 April 2027 a compliance deadline? No. §14-4614(A) uses the date to bound which alleged violations the cure section covers: those that occur on or before 1 April 2027. It does not set a date by which you must comply.

When is a MODPA data protection assessment required? For each processing activity that presents a heightened risk of harm, including each algorithm used, under §14-4610(B). Under §14-4610(H), it applies to processing activities that occur on or after 1 October 2025.

Can a GDPR DPIA satisfy Maryland? Possibly. §14-4610(F) accepts an assessment done for another law if it is "reasonably similar in scope and effect." Document the comparison rather than assuming it.