Many compliance teams see Florida's Digital Bill of Rights (FDBR) and stop at the revenue threshold. If your business doesn't make $1 billion annually, you might think you're exempt from controller obligations. That's a mistake that could lead to compliance issues across states.
The FDBR, effective July 1, 2024, isn't just another state privacy law to fit into your existing compliance framework. It introduces unique obligations that don't align neatly with the CCPA or Virginia CDPA, and the exemptions can create blind spots that enforcement will target.
Why These Mistakes Keep Happening
Teams often treat state privacy laws like interchangeable parts. You've built a CCPA compliance program, extended it to Virginia and Colorado, and assumed Florida would fit the same way. But the FDBR's structure disrupts that pattern. It applies broadly to businesses processing data from Florida residents, carving out controller obligations for high-revenue entities while imposing sensitive data restrictions on all for-profit businesses in Florida, regardless of size.
This layered structure means you can't evaluate FDBR compliance with a simple yes/no threshold. You need separate assessments for general applicability, controller status, processor obligations, and sensitive data handling. Many teams skip this detailed analysis and assume they're either fully in or out.
Mistake 1: Assuming the Revenue Threshold Exempts You Entirely
Why it happens: Your legal team sees "$1 billion annual gross revenue" and stops there. As a $200M SaaS company, you think FDBR controller obligations don't apply.
The consequence: You're still subject to FDBR's sensitive data sale prohibition, which applies to all for-profit businesses in Florida. This provision doesn't reference the controller revenue threshold. If you're selling sensitive data like precise geolocation, biometric data, or health information without prior consent, you're violating the FDBR even if you're not a controller.
The fix: Split your FDBR compliance assessment into two tracks. Track one: controller obligations (revenue threshold applies). Track two: sensitive data sale restrictions (applies to all for-profit businesses processing Florida resident data). Audit your data flows for sensitive data categories. If you're sharing precise geolocation with ad networks or health-related data with analytics providers, implement consent mechanisms before July 1, 2024, regardless of your revenue.
Mistake 2: Treating "Processor" as a Pass-Through Role
Why it happens: In GDPR and CCPA contexts, processor obligations seem administrative. You sign a data processing agreement, follow controller instructions, and assist with DSARs when asked.
The consequence: The FDBR imposes a retention schedule obligation on processors similar to the controller requirement. You must prohibit the use or retention of personal data after (1) satisfaction of the initial purpose, (2) contract expiration, or (3) two years after the consumer's last interaction with the controller or processor. This third trigger is unusual. Most state laws tie retention to purpose, not interaction recency. If you're a processor handling Florida resident data and retaining records beyond two years post-interaction without an exemption, you're non-compliant, even if your controller client hasn't instructed you to purge.
The fix: Implement automated retention triggers tied to last-interaction timestamps, not just contract lifecycle or purpose completion. If you're a marketing automation processor, a payment processor, or a CRM vendor, track when a Florida consumer last engaged with your client's service and set a deletion flag at the two-year mark. This requires engineering work, not just contract amendments.
Mistake 3: Copying Your CCPA Consent Notice Language
Why it happens: Your privacy notice already covers California residents. You add "and Florida residents" to the scope section, update the rights list, and call it done.
The consequence: The FDBR requires a specific notice if you sell sensitive data: "NOTICE: This website may sell your sensitive personal data." This isn't a paraphrase; it's prescribed language. If you're selling sensitive data and your notice doesn't include that exact string, you're not compliant. More critically, the notice must be "reasonably accessible and clear," updated at least annually, and disclose categories of personal data processed, processing purposes, categories of third parties with whom data is shared, and methods for exercising rights. The FDBR doesn't allow you to bury rights information in a separate "Your Privacy Choices" page without linking it prominently from the main notice.
The fix: If you sell sensitive data, add the prescribed notice text verbatim to your privacy notice, positioned where Florida residents will see it before providing sensitive data. Conduct a gap analysis between your current CCPA notice and FDBR disclosure requirements. The FDBR requires disclosure of "categories of third parties to whom the controller discloses personal data," which is broader than CCPA's "categories of third parties to whom we sell or share." If you're disclosing data to analytics providers, fraud prevention vendors, or infrastructure partners, those categories need to appear in your Florida-facing notice.
Mistake 4: Treating Data Protection Assessments as a 2024 Obligation
Why it happens: The FDBR's effective date is July 1, 2024. You plan to conduct data protection assessments in Q2 2024 as part of your implementation sprint.
The consequence: The data protection assessment requirement applies to processing activities generated on or after July 1, 2023. If you're a controller engaging in targeted advertising, personal data sales, profiling that produces legal effects, or processing sensitive data, and you started those activities after July 1, 2023, you should have documented assessments already. The FDBR doesn't grandfather pre-2024 processing; it backdates the assessment obligation by a year.
The fix: Inventory all processing activities involving Florida resident data that launched after July 1, 2023. For each activity meeting the assessment trigger (targeted advertising, sales, profiling with legal effects, sensitive data processing), document the assessment now. The FDBR doesn't specify assessment format, but follow GDPR DPIA structure: describe the processing, assess necessity and proportionality, identify risks to consumer rights, and document mitigation measures. If you launched a new ad targeting feature in August 2023, that assessment should exist before enforcement begins.
Mistake 5: Assuming "Controller" Status Is Static
Why it happens: You evaluated your business against the controller definition in June 2024. You don't meet the criteria (either revenue is under $1B, or you don't derive 50%+ revenue from online ads, operate a qualifying smart speaker service, or run an app store with 250K+ applications). You document your non-controller status and move on.
The consequence: The FDBR defines controller status relationally: "An entity is also a controller if it controls or is controlled by a controller." If you're acquired by a company that meets the controller threshold, you become a controller by attribution, even if your standalone business doesn't meet the criteria. Similarly, if you acquire a business that qualifies as a controller, you may become a controller through that relationship.
The fix: Treat controller status as a dynamic attribute, not a one-time determination. If you're involved in M&A activity (as acquirer or target), re-evaluate FDBR controller status post-transaction. If your parent company starts a smart speaker product line or crosses the 50% ad-revenue threshold, your controller status changes. Build a quarterly review trigger: "Has our corporate structure or business model changed in a way that affects FDBR controller status?" This is especially critical for subsidiaries of large tech companies or private equity portfolio companies where the parent's business activities determine your obligations.
Prevention Checklist
□ Sensitive data audit complete: Identified all processing of precise geolocation, biometric data, health information, financial credentials, and special category data (racial origin, religious beliefs, sexual orientation, citizenship, genetic data)
□ Consent mechanism in place: If selling sensitive data, implemented prior consent collection before sale occurs (not post-hoc notice)
□ Retention schedule implemented: Automated deletion triggers at two years post-last-interaction for non-exempt personal data
□ Prescribed notice language added: Exact "NOTICE: This website may sell your sensitive personal data" text appears in privacy notice if applicable
□ Processor contracts updated: Data processing agreements include FDBR-specific retention obligations and assessment assistance provisions
□ Retroactive assessments documented: Processing activities started after July 1, 2023 that trigger assessment requirements have documented DPIAs
□ Controller status monitoring: Quarterly review process for M&A, structural changes, or business model shifts that affect controller determination
□ Multi-track compliance map: Separate documentation for controller obligations, processor obligations, and universal sensitive data restrictions
□ Rights request infrastructure: At least two distinct methods for consumers to submit access, deletion, correction, and opt-out requests
□ Appeal process defined: Written procedure for handling consumer appeals of denied rights requests within required timeframes
The FDBR's staggered obligations and relationship-based definitions mean compliance isn't a one-time implementation. It's an ongoing monitoring function that requires coordination between legal, engineering, and data governance teams. The mistakes above share a common root: treating Florida as another checkbox in a uniform state privacy matrix. That approach worked when state laws converged around the CCPA model. Florida's structure breaks that pattern, and the teams that recognize that early will avoid the enforcement actions that follow.
