Skip to main content
Commerce Security logo, "All 12 PCI DSS Requirements in Plain English," "Get it now for free," "Complete Survival Guide" and a button toclick to get it
Pick Your State Privacy Compliance ModelRegulations & Laws
6 min readFor Compliance Officers

Pick Your State Privacy Compliance Model

You're managing compliance across multiple U.S. states, and each one just amended its privacy law. Delaware changed its applicability threshold. Connecticut launched a data broker registry. Maryland expanded what counts as sensitive data. New Jersey banned selling sensitive information outright.

The question you're facing: Do you harmonize to the strictest requirements, implement state-specific controls, or build a hybrid model that segments by data type and business function?

Key Factors That Affect Your Choice

Your data broker status matters most. If you collect or purchase personal data about consumers you don't have a direct relationship with and sell or license that data to third parties, Connecticut's annual registration requirement (effective October 1, 2026) and New Jersey's database registration (operative 270 days post-enactment) apply directly. New Jersey's fees are the highest in the nation, affecting your budget planning.

The types of data you process drive different paths. Maryland's HB 711 now includes data a controller infers to indicate sensitive characteristics, not just data you directly collect. New Jersey prohibits selling sensitive personal data entirely. New Hampshire bars selling personal data of children under 13 (effective January 1, 2027). If your processing involves profiling, facial recognition, or child data, your compliance obligations diverge sharply by state.

Your relationship with government entities creates new constraints. Maryland's restriction on selling personal data to governmental entities involved in civil immigration enforcement within the preceding six months introduces a compliance check you didn't have before. You'll need vendor due diligence processes that can verify this.

Contract language isn't optional anymore. Delaware's HB 380 amendments (awaiting signature, effective January 1, 2027) require binding contracts with specific provisions when you're selling or sharing personal data. If your current data processing agreements don't include these provisions, you're building contract amendment workflows into Q4 2026.

Path A: Harmonize to the Strictest Standard

Choose this if you operate in at least four of these five states and your data practices are relatively uniform across jurisdictions.

You adopt New Jersey's prohibition on selling sensitive data as your baseline. You register as a data broker in both Connecticut and New Jersey. You expand your sensitive data definition to match Maryland's inference-based standard. You implement Delaware's contract provisions for all data sharing relationships, regardless of state. You apply New Hampshire's child data protection to anyone under 13 nationwide.

When this works: You're a SaaS platform with a single product offering, consistent data flows, and customers in 40+ states. Building state-specific logic into your systems costs more than adopting the highest bar everywhere. Your legal team reviews one set of rules. Your engineering team builds one set of controls.

The trade-off: You're restricting business activities in states that don't require it. If you're not selling sensitive data in California but New Jersey's ban forces you to stop nationwide, you've just limited revenue opportunities in 49 other states. Your competitors operating only in permissive states have more flexibility.

What you'll need: A cross-functional team that can implement the strictest requirements by October 1, 2026 (Connecticut's effective date). You'll update your privacy notice, consent flows, data processing agreements, and vendor contracts simultaneously. Your data mapping must identify every instance where you're inferring sensitive characteristics, not just collecting them directly.

Path B: Implement State-Specific Controls

Choose this if your business model varies significantly by state or you have the technical infrastructure to segment data processing by jurisdiction.

You build conditional logic into your systems. Connecticut and New Jersey customers trigger data broker registration checks. Maryland customers get expanded sensitive data protections. Delaware customers generate contracts with specific provisions. New Hampshire customers under 13 get sale prohibitions.

When this works: You're a data broker serving enterprise clients who need different data sets for different regions. Your platform already segments by geography for sales tax or industry regulations. You have engineering resources to maintain state-specific rule engines and your data volume justifies the investment.

The trade-off: You're maintaining five different compliance configurations (at minimum). When Connecticut updates its deletion mechanism requirements by July 1, 2028, you're updating one state's logic without breaking the others. Your QA testing multiplies. Your documentation burden increases. Every new state law means another branch in your decision tree.

What you'll need: A compliance management system that can track which requirements apply to which data subjects. You'll instrument your data flows to capture state of residence at collection. Your incident response procedures must account for state-specific breach notification rules. If you misclassify a Maryland resident as a Delaware resident, you've applied the wrong sensitive data definition.

Path C: Build a Hybrid Model by Data Type

Choose this if you process distinct categories of data with different risk profiles and business purposes.

You segment by data sensitivity and business function, not by state. All child data (under 13) follows New Hampshire's sale prohibition regardless of state. All inferred sensitive characteristics follow Maryland's expanded definition. All data broker activities comply with Connecticut and New Jersey registration. All data sharing contracts include Delaware's required provisions.

When this works: You're a marketing technology platform that processes both anonymized behavioral data and sensitive health information. The health data never gets sold, so New Jersey's prohibition doesn't constrain you. The behavioral data goes through your data broker relationships, so you register in Connecticut and New Jersey. Your child-directed properties already restrict data sales for COPPA compliance, so New Hampshire's requirement doesn't change operations.

The trade-off: You're making judgment calls about which data falls into which category. When Maryland says you're inferring sensitive characteristics, but your data science team says you're predicting product preferences, you're in a gray zone. You'll need legal review of your classification logic, and you'll need to document why you're treating certain data flows one way versus another.

What you'll need: A data classification framework that maps to these state requirements. Your data inventory must tag records by sensitivity level, not just by state. You'll run regular audits to verify your classification logic matches regulatory definitions. When a state amends its sensitive data definition (as Maryland just did), you're reviewing your entire classification scheme.

Summary Matrix

Factor Harmonize to Strictest State-Specific Controls Hybrid by Data Type
Best for Uniform data practices across states Regionally distinct business models Mixed data sensitivity levels
Technical complexity Low (one ruleset) High (multiple branches) Medium (classification engine)
Business flexibility Low (restricted everywhere) High (optimized per state) Medium (optimized by risk)
Compliance risk Low (over-compliance) Medium (configuration errors) Medium (classification disputes)
Maintenance burden Low (single update path) High (state-by-state changes) Medium (definition monitoring)
Registration requirements CT and NJ if data broker CT and NJ if data broker in those states CT and NJ for broker functions only
Contract updates All data sharing (DE standard) DE customers only All sharing relationships
Effective dates October 1, 2026 (CT earliest) Varies by state and provision October 1, 2026 for broker functions

The decision isn't permanent. You can start with Path A to meet October 2026 deadlines, then migrate to Path C once you've built classification infrastructure. But you can't start with Path B and simplify later, because state-specific systems create technical debt that's expensive to unwind.

What you can't do is wait. Connecticut's data broker registration opens October 1, 2026. If you're selling or licensing personal data about consumers you don't have direct relationships with, you're registering in 90 days.

Delaware HB 380

a promotional banner asking how ready are you for PCI DSS 4.0? With a call-to-action to get the checklist now.

You Might Also Like