Texas Cybersecurity Act compliance: where the controls pass and the attack surface doesn't
Julian ThorneApril 29, 2026
Key takeaways
The Texas Cybersecurity Act requires state agencies to implement controls defined in the Texas Administrative Code Chapter 202 Security Control Standards Catalog. Passing the Chapter 202 audit confirms controls are present and configured. It does not confirm they cover the external attack surface an attacker would map before attempting access.
TX-RAMP authorization -- Texas's cloud service vetting program -- evaluates cloud providers against security baselines at the time of authorization. It does not evaluate the agency's configuration of authorized services, which is where the actual exposure lives in most Vulnox assessments.
The Chapter 202 framework has no specific requirements for external attack surface visibility -- subdomain enumeration, certificate transparency monitoring, or passive recon coverage. Agencies that rely on the framework audit to define their security perimeter are working with an inside-out view of their exposure.
In Vulnox assessments of Texas state agency contractors, the most common finding was not a failed Chapter 202 control -- it was a control that passed the audit and did not cover the asset class that an attacker would find first through passive recon.
Supply chain risk under the Texas Cybersecurity Act is addressed through contractor security requirements, but the framework does not require contractors to submit to external attack surface review. A contractor with a passing security posture document can have publicly exposed development infrastructure that the agency has no visibility into.
TL;DR
Chapter 202 compliance tells you whether the controls you documented are present. It does not tell you whether those controls cover what an attacker would find. The gap between those two views is not a compliance failure -- it is a scope failure. The framework audits what agencies told it to audit. External attack surface, shadow IT, contractor-side exposure, and the misconfiguration classes that passive recon surfaces are outside that scope by design. Organizations that treat the audit as a security assessment are making a category error that attackers are well-positioned to exploit.
The agency that passed the audit and failed the recon
A Texas state agency contractor brought in for a Chapter 202 gap analysis had a clean security posture document, a current WISP, and controls implemented against the Security Control Standards Catalog. The annual review had passed. The agency's vendor oversight team had reviewed the contractor's attestation and closed the vendor risk item. Two weeks into the Vulnox engagement, passive recon against the contractor's domain space surfaced three subdomains running services that were not in the contractor's asset inventory: a Jenkins instance from a decommissioned CI/CD pipeline with default credentials, a Grafana monitoring dashboard with no authentication, and a staging environment for a previous state agency project running an unpatched version of the contractor's portal software.
None of these assets appeared in the Chapter 202 audit because none were in the asset inventory the audit was conducted against. The Jenkins instance had valid credentials for the contractor's AWS environment, where production infrastructure for the current state agency contract was running. The Grafana dashboard was scraping metrics from internal services whose names and IP ranges were visible in the metrics labels. The staging environment contained configuration files from the previous project period that included connection strings to databases that had since been migrated -- and the new connection strings followed a predictable naming pattern. The audit had passed. The attack chain was four steps from public internet to production AWS environment access.
What the Chapter 202 framework does and does not cover
Inside-out by design
The Texas Administrative Code Chapter 202 Security Control Standards Catalog is structured around controls that state agencies implement and self-assess. The catalog maps to NIST SP 800-53 control families: access control, audit and accountability, configuration management, incident response, risk assessment, system and communications protection. All of these control families are assessed from inside the organization's defined system boundary. None of them require the agency or its contractors to assess what is visible from outside that boundary through passive recon.
28%
Share of Texas state agency contractor environments that passed Chapter 202 compliance review but had at least one externally reachable asset with a viable exploitation path in Vulnox hands-on assessments. The controls were present. The asset was outside the scope those controls were applied to. (Vulnox assessment data, 2024)
TX-RAMP Level 1 and Level 2
Texas's cloud authorization tiers. Level 1 covers lower-impact cloud services; Level 2 covers services handling sensitive or mission-critical state data and requires a more rigorous security review. TX-RAMP authorization evaluates the cloud service provider's security posture against defined baselines. It does not evaluate how the agency or contractor has configured the authorized service -- which is where the misconfiguration exposure lives. An agency using a TX-RAMP Level 2 authorized cloud service with an overly permissive IAM configuration is compliant with TX-RAMP and exposed.
What the Chapter 202 framework audits versus what attackers map
The Chapter 202 audit process works through a defined system boundary. The agency or contractor identifies the systems in scope, documents the controls applied to those systems, and produces evidence that the controls are configured as documented. The auditor reviews the documentation and the evidence. The audit result reflects whether the in-scope systems have the documented controls in the documented configuration.
An attacker does not start from the system boundary. An attacker starts from a query against Shodan, a certificate transparency search, a DNS enumeration pass, or an ASN-based IP range scan. The starting point is everything internet-reachable associated with the organization's name, domain space, and IP ranges. The attacker's asset list is built from what is actually internet-reachable, not from what the organization included in its system boundary documentation.
The gap between those two lists is the attack surface the Chapter 202 audit does not cover. It is not a gap in the controls the audit reviews. It is a gap in the scope of what is being reviewed. An asset that is not in the system boundary is not in the audit. An asset that is not in the audit is not in the control framework. An asset that is not in the control framework has none of the Chapter 202 controls applied to it -- by definition, because those controls are applied to documented systems, not to everything internet-reachable.
The framework's risk assessment requirement (Chapter 202 Section 202.25) requires agencies to conduct risk assessments of their information resources. Information resources are defined as what the agency manages and documents. The external recon view -- the attacker's view -- is not a required input to the risk assessment.
Example
The AWS API Gateway misconfiguration pattern is the most common cloud-specific finding in Vulnox assessments of Chapter 202-compliant environments. The agency or contractor uses an authorized cloud service (TX-RAMP compliant), implements API Gateway to expose internal services to authorized callers, and configures CORS policy during development with a wildcard origin to simplify testing. The wildcard CORS configuration remains in the production deployment because the Chapter 202 configuration management controls apply to the documented system configuration -- and the gateway was documented with the CORS setting that was present at the time of documentation.
The external attacker sees an API endpoint with a wildcard CORS policy that accepts cross-origin requests from any domain. This is not a CVE. It is a configuration choice that the Chapter 202 audit confirmed was present and that no Chapter 202 control requires to be restricted. The agency is compliant. The endpoint is exploitable.
The CORS wildcard finding matters beyond the immediate exploitation path because of what it enables downstream. A wildcard CORS policy on a state agency API endpoint that handles authenticated requests allows a malicious site to make authenticated requests to the API on behalf of a visiting agency employee, using the employee's existing session cookies. The attack requires no credential theft -- it requires the employee to visit a page controlled by the attacker while logged into the agency system. This is a client-side request forgery path that the Chapter 202 access control requirements do not address, because they address authentication to the API, not the CORS policy governing cross-origin access to authenticated endpoints.
What Vulnox found in Chapter 202-compliant environments
Assessment base: Vulnox gap analysis and external attack surface assessments of Texas state agency contractors, 2023-2024.
Contractor external exposure invisible to agency vendor oversight
The Texas Cybersecurity Act requires state agencies to ensure that contractors handling state data meet security requirements, typically through attestation, security posture documentation, and Chapter 202 alignment reviews. In Vulnox assessments of agency contractor environments, the vendor oversight process reviewed the contractor's documented controls and attestation. It did not include external recon against the contractor's actual internet-reachable infrastructure. In the case described above -- Jenkins instance, Grafana dashboard, legacy staging environment -- the contractor's attestation was accurate for the systems it described. The exposed systems were not in the attestation because they were not in the contractor's asset inventory.
Agency vendor oversight built entirely on attestation review has the same scope limitation as the contractor's own audit: it covers what the contractor documented. An attacker running external recon against a state agency contractor is not constrained by the contractor's asset inventory. The agency's security posture is bounded by the weakest point in its contractor's external footprint, not by the strongest control in the contractor's attestation document.
WISP template adoption without environment-specific calibration
Chapter 202 requires agencies to maintain a written information security plan. In Vulnox gap analysis engagements, the most common WISP finding was adoption of a template -- provided by DIR, sourced from a peer agency, or purchased from a compliance vendor -- without calibration to the specific IT environment. Template WISPs describe control categories correctly. They do not reflect the specific systems, data flows, network architecture, or risk profile of the agency. The WISP passes review because it covers the required categories. The gap analysis finds that the documented controls do not match the actual environment.
A WISP that accurately documents a generic state agency environment is not the same as a WISP that accurately documents the specific agency's environment. When an incident occurs and DIR requests the WISP as evidence of the agency's security planning, a template that does not reflect the actual environment raises the question of whether the security program was designed for this organization or for a theoretical one. The evidentiary value of the WISP in a regulatory inquiry depends on whether it describes what actually exists.
TX-RAMP authorized services with agency-side misconfigurations
In assessments of agencies using TX-RAMP Level 2 authorized cloud services, Vulnox found that the authorization status of the cloud service was used as a proxy for the security of the agency's deployment. The service was authorized; therefore the agency's use of it was assumed to be secure. The agency-side configurations -- IAM role permissions, storage bucket access policies, API gateway CORS settings, logging configurations -- were not reviewed as part of the TX-RAMP authorization and were not reviewed in the agency's annual Chapter 202 assessment because the authorized service was treated as a compliant component rather than a configured component requiring review.
TX-RAMP authorization answers the question 'is this cloud service provider operating securely?' It does not answer the question 'has the agency configured this service securely?' Those are different questions with different answers. An agency that conflates them has a false sense of security that the TX-RAMP authorization specifically does not provide.
The compliance finding that narrows the investigation scope incorrectly
Common belief
A passing Chapter 202 compliance review means the agency's security controls are working and the risk posture is defensible. If an incident occurs, the passing review demonstrates due diligence.
What we found
In Vulnox post-incident work, the organizations that reconstructed the most accurate breach timelines were those that began with external recon -- what was internet-reachable, when it was first indexed, what it contained -- rather than with the compliance review as a starting assumption about what could and could not have been the entry point.
A passing Chapter 202 review demonstrates that the controls covering the documented system boundary were present and configured as documented at the time of review. It does not demonstrate that the controls covered the full external attack surface, that the asset inventory was complete, or that the documented configurations matched the production state at the time of the incident.
The risk of treating a passing compliance review as a security assurance statement is that it narrows the incident investigation scope in the wrong direction. When an incident occurs, the first question is how access was obtained. If the assumption is that Chapter 202 controls were working because the audit passed, the investigation may focus on what failed within the documented system boundary -- phishing, credential theft, software vulnerability -- without looking at whether the initial access came from an asset that was never in the system boundary.
In several Vulnox post-incident reviews, this narrowing produced incident narratives that attributed breach to phishing or credential theft when the more probable initial access vector was an exposed asset outside the audit scope. The phishing attribution was supportable. The exposed asset was also present, also had viable access to the production environment, and had been internet-reachable for longer than the phishing campaign had been running. The compliance review gave the investigation a frame that was too small for what had actually happened.
What agencies and contractors said before the assessment, and what the gap was
Our Qualys scan says we're passing compliance. We're not sure why we'd need an external assessment on top of that.
Root cause:The Qualys scan ran against the asset inventory -- the systems the agency had documented and included in the scan scope. The scan result was accurate for that scope. The external assessment surfaced three assets outside that scope that were internet-reachable and not in the inventory. The scan could not have found them because they were not in the list it was given to scan.
Our cloud services are all TX-RAMP authorized. That means they're vetted and secure.
Root cause:TX-RAMP authorization means the cloud service provider's security posture was reviewed against defined baselines. It does not mean the agency's configuration of that service is secure. The agency was using a TX-RAMP Level 2 authorized platform with a storage bucket configured for public read access -- not intentionally, but because the default bucket policy had not been reviewed since the service was provisioned. The TX-RAMP authorization did not cover the agency's bucket configuration. Nothing did.
We have a WISP and it covers all the Chapter 202 categories. Our annual review was clean.
Root cause:The WISP covered the required categories and had been approved. It had been sourced from a DIR template and updated with the agency's name and a few organizational details. The network diagram in the WISP did not reflect the current network architecture -- two cloud environments had been added since the WISP was last substantively updated. The Chapter 202 review had not flagged this because the reviewer had not compared the WISP's network diagram against the actual environment. The WISP was compliant in structure. It was inaccurate in content.
The Chapter 202 gaps that stay invisible longest
The contractor external footprint the agency cannot see
Agency vendor oversight reviews contractor attestations and security posture documents. It does not include external recon against the contractor's internet-reachable infrastructure. A contractor with a clean attestation and exposed development infrastructure represents a risk the agency has no mechanism to detect through the standard oversight process. The agency's security posture is bounded by its contractors' actual external footprints, not their documented ones.
Cloud service configuration drift between authorization and current state
TX-RAMP authorization is a point-in-time assessment of the cloud provider's security posture. Agency-side configurations drift from their initial state through operational changes -- new team members modifying IAM roles, storage policies updated for a project and not reverted, API gateway configurations changed during debugging. The Chapter 202 configuration management controls require documentation of changes, but they do not require external validation that the current configuration matches the documented configuration. Configuration drift accumulates between reviews.
Supply chain exposure through contractor CI/CD infrastructure
The Jenkins finding in the assessment described above is not unusual. Contractor CI/CD infrastructure -- Jenkins, GitLab CI, GitHub Actions runners -- is frequently provisioned with network access to the production environment it deploys to and with credentials for that environment embedded in the pipeline configuration. When CI/CD infrastructure is decommissioned without credential rotation, the infrastructure may be gone but the credentials remain valid. If any component of the CI/CD infrastructure was internet-reachable during its operational period, it may still be in Shodan's index with its configuration details captured.
The system boundary that excludes the initial access vector
The Chapter 202 system boundary is defined by the agency's information resources -- the systems the agency manages, documents, and applies controls to. Development environments, contractor-side infrastructure, and legacy systems from previous projects are frequently outside this boundary by definition. The controls do not apply to them because they are not in scope. An attacker does not apply a system boundary. Every internet-reachable asset associated with the agency or its contractors is in scope for the attacker's recon, regardless of whether it is in the agency's Chapter 202 system boundary documentation.
Where Texas Cybersecurity Act enforcement and attacker behavior are heading
DIR will extend Chapter 202 external attack surface requirements -- either through the Security Control Standards Catalog or through contractor security requirements -- to include mandatory external recon coverage within the next revision cycle, driven by at least one high-profile state agency breach traced to an asset outside the defined system boundary.
The trajectory of federal agency cybersecurity requirements -- CISA's Known Exploited Vulnerabilities catalog, OMB's attack surface management guidance, FISMA modernization -- consistently moves toward requiring agencies to assess what is actually internet-reachable rather than what is in the documented system boundary. Texas DIR follows federal frameworks closely, and the Chapter 202 catalog's NIST SP 800-53 alignment means federal framework updates flow into the Texas requirements over time. The breach that accelerates this shift will be one where the initial access was demonstrably through an asset that was not in the system boundary -- which is exactly the pattern Vulnox assessments find consistently.
Confidence: mediumIf the next Chapter 202 Security Control Standards Catalog revision does not include any requirement related to external attack surface visibility, asset discovery beyond the self-defined system boundary, or contractor external footprint review, the prediction is premature. Watch DIR's catalog revision notices and the language of any new contractor security requirements issued after a significant state agency incident.A compromised Texas state agency contractor CI/CD pipeline will be used to inject a malicious software update into a state agency environment within 18 months, with initial access traced to exposed CI/CD infrastructure that was outside the contractor's Chapter 202 system boundary.
The conditions are present in current contractor environments: CI/CD infrastructure with production environment credentials, internet-reachable components from decommissioned pipelines, and no Chapter 202 control requirement that explicitly covers CI/CD infrastructure security or credential rotation on decommission. The attack pattern -- CI/CD compromise as a software supply chain entry point -- is well-documented in federal incident reporting. The specific Texas context is that contractor security requirements are attestation-based and do not include external footprint review of contractor infrastructure.
Confidence: mediumIf no Texas state agency incident through 2027 involves a contractor CI/CD compromise as a contributing factor, the attack pattern has not yet been applied to this specific target class. The signal to watch: DIR incident reports or security advisories that reference software supply chain compromise or contractor pipeline access in their findings.
The framework audit that answers the wrong question
The Chapter 202 compliance audit answers a useful question: do the documented controls for the documented systems meet the minimum requirements of the Security Control Standards Catalog? That is a legitimate and necessary question. It is not the question that determines whether the agency is secure.
The question that determines whether the agency is secure is: what can an attacker reach from the internet, and what can they do with it? That question requires looking from the outside in, not from the inside out. The Chapter 202 framework does not ask it. The audit process does not ask it. The contractor attestation review does not ask it.
My position is that any state agency operating under the Texas Cybersecurity Act that has not conducted external recon against its own internet-facing infrastructure and its primary contractors' internet-facing infrastructure does not know its actual attack surface. It knows its documented attack surface, which is a different and smaller thing. The framework defines the minimum. Treating the minimum as sufficient is a choice -- one that attackers are well-positioned to take advantage of.
The counterargument is that DIR's framework is designed to be implementable across a wide range of agency sizes and resource levels, and that requiring external attack surface assessment for all covered entities would create compliance costs that smaller agencies cannot absorb. That constraint is real. But the cost of treating the Chapter 202 audit as a security assurance is paid by the agencies and the Texans whose data they hold -- not by the framework designers.
Counterargument
The Chapter 202 framework is calibrated to be implementable across agencies of very different sizes and resource levels. Requiring external attack surface assessment as a compliance element would create costs that smaller agencies and municipal governments operating under the Act cannot absorb.
One thing worth doing this week
Run a certificate transparency search on your agency's primary domain and the domains of your three highest-access contractors. Use crt.sh -- the query takes under a minute per domain. Compare the subdomain list against your Chapter 202 asset inventory and the contractor attestations on file. Any subdomain in the certificate transparency record that is not in the documented asset inventory is a system that is outside the control framework by definition. Check whether it is still internet-reachable. If it is, you have found the gap that your compliance review could not have found -- because the review was never pointed at it.
Further Reading
Vulerability Assessment
vulnerability assessment servicesGap Analysis
framework gap analysis servicesNIST 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 the Texas Cybersecurity Act require for state agencies under Chapter 202?
The Texas Cybersecurity Act requires state agencies to implement security controls defined in the Texas Administrative Code Chapter 202 Security Control Standards Catalog, which maps to NIST SP 800-53 control families including access control, audit and accountability, configuration management, incident response, and risk assessment. Agencies must maintain a written information security plan, conduct regular risk assessments, and ensure contractors handling state data meet equivalent security requirements. Cloud services used by state agencies must be authorized through TX-RAMP (Texas Risk and Authorization Management Program) at the appropriate tier.
What does TX-RAMP authorization actually cover?
TX-RAMP authorization evaluates a cloud service provider's security posture against defined baselines at the time of authorization. It does not evaluate how the state agency or contractor has configured the authorized service. An agency using a TX-RAMP Level 2 authorized cloud platform with an overly permissive IAM configuration, a publicly accessible storage bucket, or a wildcard CORS policy on an API gateway is compliant with TX-RAMP and exposed. The authorization confirms the provider's security controls. It does not confirm the agency's configuration of those controls.
What external attack surface risks does Chapter 202 compliance miss?
Chapter 202 compliance is scoped to the agency's defined system boundary -- the systems documented in the WISP and included in the compliance review. External attack surface risks outside this boundary include: contractor development and staging infrastructure with production credentials that was never in the contractor's asset inventory; decommissioned CI/CD pipelines with internet-reachable components and valid production environment credentials; legacy subdomains from previous projects running unpatched software; and cloud service misconfigurations on TX-RAMP authorized platforms. In 28% of Vulnox assessments of Chapter 202-compliant environments, at least one externally reachable asset had a viable exploitation path. (Vulnox assessment data, 2024)
How should Texas state agencies assess contractor security beyond attestation review?
Attestation review confirms what contractors have documented. External recon confirms what is actually internet-reachable. The gap between those two views is where the risk lives. Agencies should supplement contractor attestation review with certificate transparency searches against contractor domains, Shodan queries against contractor IP ranges, and periodic external recon against the subdomains associated with contractor-managed systems. The goal is not to find CVEs in contractor software -- it is to find assets that exist outside the contractor's documented system boundary and have not been assessed or controlled.
What makes a Chapter 202 WISP fail in practice even when it passes the compliance review?
The most common WISP failure in Vulnox gap analysis engagements is adoption of a DIR-provided or third-party template without calibration to the specific agency environment. Template WISPs cover the required control categories correctly but do not reflect the agency's actual systems, network architecture, data flows, or risk profile. Network diagrams in template WISPs frequently do not match the current environment -- particularly when cloud services or new contractors have been added since the last WISP update. The WISP passes review because it covers the required categories. It fails operationally because the documented controls do not match what the agency actually has.
What is the most common cloud misconfiguration in Texas state agency environments?
In Vulnox assessments of Chapter 202-compliant environments, AWS API Gateway CORS policy misconfiguration is the most consistently found cloud-specific issue. Agencies configure API gateways with wildcard CORS origins during development for testing convenience and do not restrict the setting before production deployment. A wildcard CORS policy on an authenticated state agency API endpoint allows cross-origin requests from any domain, enabling a client-side request forgery path that requires no credential theft -- only that an agency employee visit a controlled malicious page while authenticated. The Chapter 202 access control requirements address authentication to the API but not the CORS policy governing cross-origin access to authenticated endpoints.
How does the Texas Cybersecurity Act treat CI/CD pipeline security for state agency contractors?
The Texas Cybersecurity Act's Chapter 202 framework and contractor security requirements do not specifically address CI/CD pipeline security or credential rotation requirements when pipelines are decommissioned. This creates a specific supply chain risk: contractor CI/CD infrastructure with production environment credentials, if internet-reachable during its operational period, may be indexed in Shodan with configuration details visible. When the pipeline is decommissioned without credential rotation, the infrastructure is gone but the credentials remain valid. Decommissioned CI/CD components outside the contractor's Chapter 202 system boundary are outside the control framework that would require credential rotation.
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.