Texas SB 2610 compliance gaps that standard audits do not catch
Amara OkaforApril 29, 2026
Key takeaways
Texas SB 2610 uses a 'reasonable security procedures and practices' standard, which means compliance is not a checklist -- it is a defensibility argument. What counts as reasonable depends on the size and complexity of the organization and the nature of the sensitive personal information processed.
The law's self-attestation model means the gap between documented controls and functioning controls is typically not discovered until a breach. Vulnox assessments in SB 2610-regulated environments consistently find encryption configured correctly at the application layer but broken at the infrastructure layer.
Vendor risk management under SB 2610 requires ongoing monitoring, not a one-time assessment. Organizations that treat initial SOC 2 review as continuous compliance coverage are exposed when a vendor's posture changes between reviews.
Incident response plans that satisfy SB 2610 documentation requirements but have never been tested against a realistic data exfiltration scenario do not demonstrate reasonable security -- they demonstrate paperwork.
The most exploitable gap in SB 2610 compliance programs is the post-audit window: organizations with annual assessment cadences have no detection capability for controls that are disabled or misconfigured between reviews.
TL;DR
Texas SB 2610 does not tell you exactly what to implement. It tells you the outcome you are responsible for -- reasonable security for sensitive personal information -- and leaves the mechanism to you. That flexibility is a trap for organizations that optimize for audit documentation rather than functioning controls. The law's self-attestation model means you can be technically compliant on paper and operationally exposed at the same time, and nobody will notice until a breach makes the distinction unavoidable.
The client who thought CrowdStrike was the answer
A healthcare organization onboarding with Vulnox described their SB 2610 preparation with confidence: endpoints covered by EDR, a written information security plan on file, encryption enabled on all primary databases. The WISP referenced the EDR deployment as the primary technical safeguard for detecting unauthorized access to sensitive personal information. What the WISP did not mention: the EDR was deployed with default alerting thresholds, had never been tuned to the specific data flows in their environment, and had no monitoring coverage for the internal web application that sat between the database and clinical staff -- the same application that had an unauthenticated API endpoint exposing patient records to anyone on the internal network.
The EDR would have detected a ransomware deployment. It would not have detected quiet, sustained read access to that API endpoint. The WISP satisfied the documentation requirement. The technical control did not satisfy the functional requirement. Under SB 2610's reasonable security standard, the documentation alone does not close the exposure -- and in the event of a breach, the gap between what the WISP claimed and what the controls actually did would be the central question in any regulatory or legal proceeding.
What the self-attestation model produces
Self-attestation with no required third-party validation
Texas SB 2610 does not mandate independent security assessments or third-party audits. Organizations determine for themselves whether their security procedures are 'reasonable.' This is structurally different from frameworks like PCI DSS or HIPAA, which have defined validation requirements. The practical result: organizations calibrate their compliance posture to what they can document, not to what an attacker would find.
72 hours
Texas SB 2610 requires notification to affected individuals within a reasonable time after discovery of a breach. The law does not define 'reasonable time,' but Texas AG enforcement guidance and comparison with the Texas Identity Theft Enforcement and Protection Act suggest 60 to 72 hours is the practical expectation. Organizations without real-time detection capability for data exfiltration will breach this window before they know a breach has occurred.
3 failure patterns
Vulnox assessments in Texas-regulated environments consistently find the same three gaps: encryption broken at the infrastructure layer despite application-layer compliance, vendor monitoring that ends at initial onboarding, and incident response plans that have never been exercised against a realistic scenario. These are not random findings -- they are structural products of what self-attestation optimizes for. (Vulnox assessment data, 2024)
What 'reasonable security' actually requires
SB 2610's reasonable security standard is deliberately flexible. The law requires organizations to implement and maintain reasonable security procedures and practices appropriate to the nature of the sensitive personal information and the size and complexity of the organization. This means a 12-person accounting firm and a 500-person healthcare network are both subject to SB 2610, but what is reasonable for each is not the same.
The practical implication is that SB 2610 compliance cannot be reduced to a control checklist. What it requires is a documented, defensible argument that the controls in place are appropriate for the specific risk profile of the organization. That argument has two components: what the controls are, and evidence that they function as documented.
The second component is where most compliance programs fail. Organizations invest in writing the WISP, configuring the controls, and producing the documentation. They do not invest in testing whether the controls function under realistic conditions -- which is the evidence a regulator or plaintiff's attorney will request when something goes wrong.
SB 2610 also requires a written information security plan (WISP) that addresses administrative, technical, and physical safeguards, along with incident response procedures. The WISP requirement is not unique to Texas -- it mirrors requirements in Massachusetts 201 CMR 17.00 and California's CCPA regulations. What is specific to SB 2610 is that the law applies to any person who conducts business in Texas and owns, licenses, or maintains computerized data that includes sensitive personal information of Texas residents, regardless of where the organization is headquartered.
Example
The encryption requirement is where the mechanism-versus-documentation gap appears most consistently in Vulnox assessments. SB 2610 requires encryption of sensitive personal information. Organizations configure TLS on their web applications and AES-256 on their primary databases and document both in the WISP. What they do not check: whether the reverse proxy in front of the application is terminating TLS and re-transmitting unencrypted traffic internally, whether database backups are encrypted with the same key management discipline as the primary database, or whether the ETL pipeline moving data between systems uses encrypted connections or plaintext transfers.
All three of those gaps exist in environments where the WISP accurately documents the encryption controls. The documentation is not wrong -- the controls exist. The gaps exist at the interfaces between systems, where the encryption configuration was set by a different team on a different schedule and was never validated end to end.
The reverse proxy unencrypted internal re-transmission pattern is particularly common in environments running nginx or HAProxy in front of applications deployed in private subnets, where the internal network is treated as trusted. The assumption is that encryption is only needed at the perimeter. An attacker with internal network access -- through a compromised endpoint, a misconfigured VPN, or a vendor with network-level access -- can read plaintext SPI in transit without touching the application layer.
What Vulnox found in SB 2610-regulated environments
Assessment base: Vulnox gap analysis and vulnerability assessment engagements, Texas-regulated organizations across healthcare, financial services, and professional services verticals. 2023-2024.
Encryption documented as compliant, broken at the infrastructure layer
In multiple assessments of organizations with documented SB 2610 compliance programs, Vulnox found that encryption of sensitive personal information failed at the infrastructure layer despite correct application-layer configuration. The most common pattern: internal ETL pipelines and database replication streams transmitting SPI in plaintext between services within the same VPC or private network. The WISP referenced encryption controls that were real and correctly configured for the application. The infrastructure-layer gaps were not in scope for the documentation review that produced the compliance posture.
The client assumption was that application-layer encryption covered the obligation. The actual finding was that SPI was moving in plaintext across internal network segments that were accessible from multiple points of potential compromise. Under SB 2610's reasonable security standard, a gap of this type -- systematic plaintext transmission of SPI that is never examined because the compliance documentation focuses on the application layer -- is difficult to defend as reasonable when it is surfaced during a breach investigation.
Vendor monitoring that ends at onboarding
In assessments of organizations with formal vendor risk programs, Vulnox consistently found that initial vendor onboarding included SOC 2 review, security questionnaire, and contractual data protection requirements -- and that ongoing monitoring consisted of annual questionnaire renewal. Vendors whose compliance posture changed between annual reviews were not detected. One financial services client's primary payment processing vendor had experienced a significant configuration change affecting data segregation between client environments. The client had no mechanism to detect this change outside the annual questionnaire cycle.
The client believed vendor risk management was addressed. The assessment found that the program was front-loaded -- rigorous at onboarding, absent in between. SB 2610 requires ongoing vendor management, and the vendor failure mode that is most likely -- gradual configuration drift, compliance status change, personnel turnover affecting security practices -- is not the failure mode that annual questionnaires detect.
Incident response plans that have never been tested
Across Vulnox assessments in Texas-regulated environments, incident response plans that satisfied SB 2610 WISP documentation requirements were present in almost every engagement. Plans that had been exercised against a realistic scenario -- a data exfiltration event, a ransomware deployment affecting systems processing SPI, a vendor breach with downstream exposure -- were present in a small minority. The typical plan documented roles, escalation chains, and notification procedures. It did not document how long notification would take under realistic incident conditions, which systems would be taken offline during investigation, or what evidence would be preserved for regulatory purposes.
An untested incident response plan demonstrates that the organization knows what a plan should look like. It does not demonstrate that the organization can execute it. For SB 2610 purposes, the distinction matters in two ways: first, the notification timeline requirement means that execution speed is a compliance variable, not just a security variable. Second, if a breach reaches regulatory or legal review, the absence of exercise documentation is evidence that the reasonable security standard was met on paper but not in practice.
The finding that looks compliant and isn't
Common belief
Organizations with a current, documented WISP, encryption enabled, and MFA deployed have met the technical requirements of SB 2610 and can demonstrate reasonable security.
What we found
In Vulnox assessments, organizations that had conducted prior third-party assessments -- even assessments that found significant gaps -- had faster and more defensible breach response postures than organizations with clean, untested documentation. The prior assessment record demonstrated that the organization treated security as a process, not a paperwork exercise.
Documentation and deployment are necessary conditions for reasonable security under SB 2610. They are not sufficient conditions. The reasonable security standard requires that the controls are appropriate to the risk and that they function as documented. An organization with correct documentation and non-functioning controls at the infrastructure layer has not met the standard -- it has met the documentation requirement, which is a subset of the standard.
The inversion is this: organizations that have tested their controls and documented the gaps are in a stronger compliance position than organizations with clean documentation that has never been challenged. The tested organization has evidence of due diligence. The untested organization has evidence of documentation discipline, which is not the same thing.
This matters practically because SB 2610 enforcement and civil liability both center on the reasonableness determination. An organization that can show it assessed its controls, found gaps, and remediated them is making a much more defensible reasonableness argument than one that can show only that its WISP was current.
What organizations said before the assessment, and what the root cause was
We have EDR on all endpoints, encryption on the databases, and MFA on the VPN. Our WISP covers all of it. We should be in reasonable security territory.
Root cause:The controls were real and correctly configured for the scope the WISP described. The scope excluded the internal API layer, the ETL pipelines, and the vendor network segments. SPI was moving through all three. Reasonable security requires controls appropriate to where the data actually is, not where the documentation assumes it is.
We did a SOC 2 review on our main vendor at onboarding. They're a reputable company. We're not worried about vendor risk.
Root cause:The SOC 2 review validated the vendor's control posture at a point in time, typically 12 months before the assessment. The vendor had since changed their data segregation configuration in a way that was not reflected in the current SOC 2 report. SB 2610 requires ongoing vendor management. A historical SOC 2 is evidence of a prior posture, not the current one.
Our incident response plan was written by a consultant last year. It covers breach notification, roles, and escalation. We're confident in it.
Root cause:The plan was well-structured and satisfied the WISP documentation requirement. It had never been tested. When Vulnox walked through a tabletop scenario involving exfiltration from the primary SPI database, three issues surfaced immediately: the person designated as breach notification lead had left the organization, the plan did not specify which systems to preserve versus isolate during investigation, and the 72-hour notification timeline assumed discovery at the start of an incident rather than after the investigation phase. The plan was compliant. The organization could not execute it.
The SB 2610 risks that stay invisible longest
The boundary between application and infrastructure encryption
Application-layer TLS and database encryption are the controls that WISP documentation addresses. The gaps appear at the boundaries: internal service-to-service communication, database replication streams, backup pipelines, and ETL processes. These are configured by infrastructure teams on a different schedule than application security reviews and are not covered by the documentation processes that produce the WISP. They are consistently absent from the scope of self-assessments.
Shadow SPI -- sensitive personal information outside the known data map
SB 2610 obligations apply to all SPI the organization owns, licenses, or maintains. The WISP and associated controls apply to the data the organization knows about. In every Vulnox assessment, there is SPI outside the documented data map: developer environments with production data copies, analytics systems that receive raw event streams including PII, support ticket systems where customers have pasted account numbers, email archives that contain sensitive data never classified or protected. These assets are not covered by the controls the WISP describes.
The notification clock and detection capability
SB 2610 requires notification within a reasonable time after discovery. Discovery is the trigger. Organizations without real-time monitoring for data exfiltration events can experience a breach months before detection, leaving the notification clock unfired but the legal exposure accumulating. The compliance documentation addresses the notification procedure. It does not address the detection capability that determines when the clock starts.
Contractual obligations that outlast the breach
SB 2610 requires that contracts with vendors processing SPI include data protection provisions and breach notification requirements. The compliance gap is not in the contract drafting -- most organizations have standard data processing agreements. The gap is in enforcement: organizations that have no process for verifying that vendors are adhering to contractual security obligations between annual reviews. A vendor breach that exposes the organization's customer SPI will trigger SB 2610 notification obligations regardless of whether the vendor's contract was compliant.
Where SB 2610 enforcement is heading
Texas AG enforcement actions under SB 2610 will begin referencing the absence of third-party assessment records as evidence of unreasonable security within the next 24 months, shifting the de facto standard from documentation to demonstrated due diligence.
The trajectory of state privacy enforcement nationally -- California AG CCPA actions, FTC enforcement under Section 5, and early GDPR precedent -- consistently shows regulators moving from verifying control existence to verifying control effectiveness. Texas AG enforcement under the Identity Theft Enforcement and Protection Act has already cited inadequate security practices in settlements. As SB 2610 enforcement matures, the reasonableness standard will be tested in cases where documentation was present but controls were not functioning. The organizations that survive those cases will be those with assessment records.
Confidence: mediumIf Texas AG SB 2610 enforcement through 2027 focuses exclusively on breach notification timeline violations and does not cite control effectiveness or assessment adequacy in any settlement, the prediction is wrong. Watch the settlement language -- the shift will appear in how the AG characterizes the violation, not just in the penalty amount.Shadow SPI in developer and analytics environments will be the source of the first high-profile SB 2610 breach, because these environments consistently lack the controls applied to production data but contain identical data.
Every Vulnox assessment in environments with formal SB 2610 compliance programs has found SPI in non-production environments not covered by the documented controls. Developer environments with production data copies, analytics pipelines receiving raw event streams, staging environments with real customer records -- these are universal patterns in organizations that have formalized production data security but not the data lifecycle controls that prevent production data from leaking into adjacent systems. The breach will come from an environment the WISP does not mention.
Confidence: highIf no publicly disclosed SB 2610 breach notification through 2027 involves SPI that was located in a non-production or analytics environment at the time of exposure, the structural pattern is not yet producing the predicted outcome.
The problem with self-attestation
SB 2610's self-attestation model is a reasonable legislative choice for a state law that applies to organizations of vastly different sizes and resource levels. Mandating third-party audits for every Texas business handling sensitive personal information would create compliance costs that small organizations cannot absorb. I understand the policy rationale.
My position is that self-attestation produces a predictable outcome: organizations optimize for the documentation that the attestation requires, not for the controls that the law intends. The result is a large population of organizations with well-written WISPs and untested controls, and a small population of organizations that have invested in testing because they understand that the WISP is evidence, not protection.
The counterargument is that most organizations will never face enforcement and that requiring more rigorous compliance processes would impose costs that exceed the realized risk. That argument holds for organizations facing low enforcement probability. It does not hold for organizations processing significant volumes of sensitive personal information, operating in sectors where breach incidents are common, or relying on a large vendor network -- which describes most of the organizations that SB 2610 was designed to protect against the most serious failures.
For those organizations, self-attestation is a trap. It provides the documentation of compliance while leaving the conditions for non-compliance intact.
Counterargument
Most organizations subject to SB 2610 are small enough that mandating third-party assessment would create disproportionate compliance costs, and the enforcement probability for low-volume SPI processors is low enough that the marginal risk does not justify the investment.
One thing worth doing this week
Pull your current WISP and map the encryption controls it describes against your actual data flows -- not the primary application, but the pipelines around it. ETL processes, database replication, backup transfers, internal service-to-service calls, analytics feeds. For each flow that touches sensitive personal information, verify whether encryption is configured, tested, and monitored. That exercise will either confirm your compliance posture or identify the gap that your documentation is currently obscuring. Either outcome is more useful than a WISP that has never been checked against the infrastructure it claims to describe.
Further Reading
Gap Analysis
gap analysis approachDigital Footprint
digital footprint analysisNIST Vulnerability Assessment Definition
NIST's vulnerability assessment definitionNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkUnderstanding Compliance Gap Analysis
compliance gap analysis guide
Frequently Asked Questions
What does Texas SB 2610 require for sensitive personal information security?
SB 2610 requires organizations that own, license, or maintain computerized sensitive personal information of Texas residents to implement and maintain reasonable security procedures and practices appropriate to the nature of the data and the size and complexity of the organization. This includes a written information security plan (WISP) covering administrative, technical, and physical safeguards, along with incident response procedures. The law applies regardless of where the organization is headquartered -- any entity conducting business in Texas and handling Texas residents' SPI is covered.
What counts as sensitive personal information under Texas SB 2610?
SB 2610 defines sensitive personal information as an individual's first name or first initial and last name in combination with a Social Security number, driver's license or state identification number, account number, credit or debit card number with access code, or protected health information. The data elements must be unencrypted and capable of being used to commit identity theft or fraud. The combination requirement is key -- a name alone is not SPI; a name plus a financial account number is.
How does the SB 2610 breach notification requirement work?
SB 2610 requires notification to affected Texas residents within a reasonable time after discovery of a breach of system security involving sensitive personal information. The law does not define a specific hour or day limit, but Texas enforcement guidance and comparison with related Texas privacy statutes suggest 60 to 72 hours is the practical expectation regulators apply. The notification clock starts at discovery, not at the time of the breach -- organizations without real-time detection capability for data exfiltration may be in breach of the notification requirement before they know a breach occurred.
Where do SB 2610 compliance programs most commonly fail in practice?
Vulnox assessments in SB 2610-regulated environments consistently find three failure patterns: encryption configured correctly at the application layer but broken at the infrastructure layer (internal ETL pipelines, replication streams, backup transfers); vendor monitoring that ends at initial onboarding and does not detect changes in vendor posture between annual reviews; and incident response plans that satisfy WISP documentation requirements but have never been tested against a realistic data exfiltration scenario. All three are structural products of self-attestation compliance programs that optimize for documentation rather than functioning controls. (Vulnox assessment data, 2024)
Does SB 2610 require third-party security audits or assessments?
No. SB 2610 does not mandate third-party security assessments or independent audits. Organizations self-attest to their reasonable security posture. However, in the event of a breach, the absence of third-party assessment records can be significant in regulatory or legal proceedings -- it limits the organization's ability to demonstrate that controls were tested and functioning, not just documented. The reasonable security standard requires both documentation and evidence of due diligence.
What should a Texas SB 2610 written information security plan include?
A SB 2610-compliant WISP must address administrative safeguards (policies, training, access management procedures), technical safeguards (encryption, access controls, monitoring), and physical safeguards (physical access controls for systems processing SPI). It must also include incident response procedures covering breach identification, containment, notification timelines, and roles. The WISP must be appropriate to the nature of the SPI and the organization's size and complexity -- a WISP copied from a larger organization's template without calibration to the actual environment does not satisfy the reasonable security standard.
How should organizations handle vendor risk management under SB 2610?
SB 2610 requires ongoing vendor management for third parties who access or process sensitive personal information. Contracts must include data protection requirements and breach notification obligations. The compliance gap most commonly found in Vulnox assessments is not in contract drafting -- it is in ongoing monitoring. Initial SOC 2 review at onboarding does not satisfy continuous oversight requirements when vendor security posture can change between reviews. Effective vendor management under SB 2610 requires a process for detecting changes in vendor compliance status outside the annual questionnaire cycle.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.