How to Comply with the Texas Data Privacy and Security Act (TDPSA) for B2B Customer Data in 2026
Texas’s TDPSA takes effect July 1, 2024 and can apply to B2B customer data depending on how you use it. In 2026, Texas businesses selling to other businesses still must evaluate whether their “consumer” data and “personal data” processing triggers TDPSA duties. This article explains coverage, B2B pitfalls, contracts, notices, security, and a practical 2026 compliance checklist.
Why TDPSA still matters for “B2B data” in 2026
Many companies assume that “B2B customer data” is outside state privacy laws. Under the Texas Data Privacy and Security Act (TDPSA), that assumption can be costly in 2026 because the law is not framed around “B2C vs. B2B” transactions. Instead, it focuses on whether you process personal data linked to a consumer (an individual acting in an individual or household context), and whether your organization qualifies as a controller or processor and meets the applicability threshold.
Even in a purely B2B sales cycle, you may still handle personal data about identifiable individuals—procurement managers, engineers, billing contacts, account admins, end users of a SaaS platform, or event attendees—some of whom may interact with your business in a way that falls within TDPSA’s “consumer” concept. Your compliance program should therefore treat B2B datasets as “mixed-use” unless clearly excluded.
Step 1: Determine whether the TDPSA applies to your organization
Applicability threshold
TDPSA generally applies to a person (including certain entities) that:
(1) conducts business in Texas or produces a product or service consumed by Texas residents; and
(2) processes or engages in the sale of personal data; and
(3) is not a “small business” as defined by the U.S. Small Business Administration (SBA), unless it sells sensitive personal data.
2026 B2B takeaway: A Texas-based B2B company may be in-scope even if it has no direct-to-consumer line, especially where it has Texas-resident users, contacts, or website visitors and is above the SBA small-business size standard for its industry.
Common exclusions that affect B2B data
TDPSA includes several entity-level and data-level exemptions that often arise in B2B settings, such as data governed by certain federal laws (e.g., GLBA for financial institutions; HIPAA for covered entities/business associates) and specific types of regulated information. But exemptions are narrow, and many companies are “hybrid” organizations where only certain lines of business or certain datasets are exempt.
Practice tip: Map exemptions by dataset and processing purpose. For example, a manufacturer’s employee-benefits data may be outside TDPSA for other reasons, but its marketing CRM for business contacts may still trigger TDPSA duties.
Step 2: Classify your B2B customer data under TDPSA definitions
Personal data vs. de-identified vs. publicly available
TDPSA centers on “personal data,” meaning information linked or reasonably linkable to an identified or identifiable individual. In B2B contexts, the following commonly qualify:
• Named corporate emails ([email protected]), direct dials, signatures, LinkedIn-sourced profiles
• SaaS admin logs tied to a specific user
• Device identifiers and online identifiers associated with an individual
• Support tickets containing contact details and usage history
By contrast, de-identified data (handled with safeguards and commitments not to re-identify) is treated differently, and publicly available information may be excluded depending on how it is obtained and used. However, “public” does not mean “free to use without compliance.” If you enrich, combine, or infer attributes in a way that becomes reasonably linkable to an individual, you may have personal data again.
Sensitive data in B2B pipelines
TDPSA imposes heightened requirements for sensitive data, which can include precise geolocation, biometric data, certain health information, data revealing racial or ethnic origin, religious beliefs, sexual orientation, citizenship/immigration status, and personal data from a known child. B2B companies encounter sensitive data more often than expected:
Example: A field-services platform collects technicians’ precise geolocation and time-stamped job photos tied to named users. Even if the customer is a business, the platform may be processing sensitive data about individuals, requiring appropriate consent mechanisms and security controls.
Step 3: Identify your role—controller or processor—and align contracts accordingly
Controller/processor roles in B2B relationships
In B2B arrangements, your company may be:
• A controller (you decide purposes and means) for your own marketing CRM, website analytics, and prospecting activities; and/or
• A processor (you process on behalf of a customer) when providing services like SaaS, managed IT, payroll tools, or analytics platforms.
Many vendors are both. TDPSA expects role clarity because contractual obligations differ.
Processor agreements (DPAs) you should have in 2026
When you act as a processor, TDPSA requires a contract with controller-directed terms. In 2026, your standard DPA should address, at minimum:
• Processing instructions, nature and purpose of processing
• Types of data and duration of processing
• Confidentiality commitments for personnel
• Subprocessor controls (authorization, flow-down terms)
• Assistance with consumer rights requests (DSARs)
• Security measures and incident/breach notification cooperation
• Deletion/return of data at end of services
• Audit/assessment rights or equivalent assurances
B2B contracting pitfall: Master service agreements often contain broad “data use” language (e.g., “vendor may use customer data to improve services”) that can drift into controller-like purposes. In TDPSA terms, that may require explicit controller authorization and careful disclosures—or restructuring the clause into permitted processor activities.
Step 4: Update privacy notices and B2B-facing disclosures
What your TDPSA privacy notice should cover
Controllers must provide a reasonably accessible, clear privacy notice. In 2026, a compliant notice for a B2B company typically covers:
• Categories of personal data processed (e.g., contact info, account credentials, usage logs)
• Purposes for processing (e.g., account administration, security, support, marketing)
• How consumers can exercise rights and appeal decisions
• Categories of personal data shared with third parties
• Categories of third parties (e.g., hosting providers, payment processors, CRM vendors)
• If you sell personal data or process it for targeted advertising, a clear disclosure
Even if your revenue is primarily B2B, your website likely collects data from Texas residents who visit, request demos, download whitepapers, or attend webinars. Those touchpoints usually make the privacy notice operationally relevant.
Targeted advertising and “sale” risks in B2B marketing
TDPSA’s concepts of “sale” and “targeted advertising” can be triggered by common marketing stacks—pixels, cross-context ad identifiers, certain data-sharing arrangements, and lead enrichment. In 2026, B2B marketers should coordinate with legal to determine whether:
• sharing hashed emails with ad platforms is a “sale” or targeted advertising; and
• retargeting demo-page visitors constitutes targeted advertising requiring opt-out mechanisms.
Operational fix: Maintain a documented adtech data flow diagram and ensure opt-out signals are honored across vendors, including suppression lists and preference centers.
Step 5: Build a TDPSA consumer rights (DSAR) workflow that fits B2B realities
Rights you must be able to administer
TDPSA grants consumers rights that typically include: access, correction, deletion, data portability, and opt-out of certain processing (targeted advertising, sale, and profiling in furtherance of decisions producing legal or similarly significant effects). Controllers must also provide an appeals process for denied requests.
B2B-specific DSAR challenges
Identity verification: If a request comes from “[email protected],” you must verify the requester is the right individual without collecting excessive new data. A reasonable approach is a tiered verification process based on risk and the sensitivity of the data requested.
Conflicts with customer confidentiality: If you are a processor, the request should generally be routed to the controller-customer, with your assistance governed by the DPA. Your public-facing process should explain when and why a requester will be directed to the relevant business customer.
Multi-tenant systems: For SaaS vendors, deletion and export must not compromise other customers’ data. Design your tooling so exports and deletions operate within tenant boundaries, and document exceptions (e.g., security logs retention) with a lawful justification.
