TX-RAMP Penetration Testing Requirements: A Guide for SaaS Companies

Landing a contract with a Texas state agency is a significant moment for a SaaS company. It signals credibility and opens the door to long-term revenue. It also introduces a regulatory reality that many private-sector teams underestimate.

If your software handles data for a Texas agency, university, or community college, you are in scope. The state views any SaaS platform processing their information as a Cloud Service Provider. They will not sign a contract or a renewal without a TX-RAMP authorization.

For companies already pursuing SOC 2, this often raises a practical question: Can we use the same penetration test to satisfy both frameworks? The answer is yes, but only if the engagement is structured correctly from the beginning.

How TX-RAMP Levels Are Determined

TX-RAMP levels are based on data sensitivity and impact, tied directly to the state agency you are working with. The impact level is derived from FIPS 199 impact categorization, which determines which NIST SP 800-53 control baseline applies to your environment.

In practice, the state agency defines the data classification based on the sensitivity of the data your system handles, evaluating potential impact across confidentiality, integrity, and availability. Your system is then categorized as Low, Moderate, or High impact.

TX-RAMP maps those impact levels into program tiers:

• Level 1: Corresponds to Low impact systems.
• Level 2: Covers Moderate and High impact systems. Despite the difference in data sensitivity, both are held to the same control baseline.
• Provisional Certification: Available for up to 18 months to expedite compliance during active procurements. If you are mid-sales-cycle and do not yet have full authorization, this is the path that keeps the deal moving.

The Texas Department of Information Resources (DIR) reviews these categorizations and authorization materials before certification is granted. If your SaaS platform handles regulated data, confidential agency information, healthcare records, criminal justice information, or financial data, assume Level 2 requirements apply until proven otherwise.

Where TX-RAMP and SOC 2 Diverge

SOC 2 is built around the Trust Services Criteria defined by the American Institute of Certified Public Accountants. It is principle-driven. You design controls that meet the criteria, and your auditor evaluates whether they are suitably designed and operating effectively.

TX-RAMP is based on NIST SP 800-53. It is control-prescriptive. The baseline defines specific security controls that must be implemented based on your system’s impact level. You do not choose your own adventure. You implement the required controls and provide evidence.

This philosophical difference changes how penetration testing is viewed. In a SOC 2 context, pentesting is typically evaluated under the CC7 criteria. The auditor looks for evidence that testing occurs, is performed by an independent party, and that findings are remediated. The framework allows for flexibility in scope and methodology.

In a TX-RAMP context, at Level 2, penetration testing is a required component of the authorization package. It is part of a broader security assessment aligned to NIST 800-53.

The Pentest Requirement

For Level 2 systems, an independent security assessment that includes penetration testing is required. A vulnerability scan alone is insufficient, and a self-assessment will not satisfy the DIR.

One of the most common misconceptions is that hosting in a major cloud environment eliminates much of this burden. Teams often say, “We are on AWS, so we inherit most of the controls.” It is true that providers like Amazon Web Services handle a large portion of the infrastructure stack. That is the shared responsibility model at work.

However, TX-RAMP cares about the entire authorization boundary. That includes the application layer you built, the APIs you exposed, the authentication flows you designed, and the business logic that governs access to data. The state expects you to test the components you control.

Using One Pentest for Both SOC 2 and TX-RAMP

It is entirely possible to structure a single engagement that satisfies both your SOC 2 auditor and your TX-RAMP assessor. However, a “standard” SOC 2 pentest rarely qualifies by default.

In many SOC 2 engagements, scope is driven by perceived risk and budget. A company might test the primary web application while leaving internal admin interfaces or auxiliary services out of scope. That may be sufficient to demonstrate reasonable coverage for SOC 2.

Under TX-RAMP, the concept of the authorization boundary changes the equation. The boundary includes all components that store, process, or transmit state data. For a typical SaaS platform, that can include the main application, administrative portals, API endpoints, authentication services, background processing systems that interact with sensitive data, and any externally accessible subdomains tied to the system.

A pentest scoped narrowly around “the main app” may not meet the expectations of a NIST-aligned assessment.

The process starts with clearly defining the authorization boundary in writing. This ensures there is no ambiguity about which systems touch state data. From there, using a recognized methodology like the Penetration Testing Execution Standard (PTES) provides a structured roadmap that auditors recognize.

For the application layer, aligning your testing with the OWASP ASVS is a high-value move. It provides a standardized yardstick for depth in critical areas like session management and access control. Finally, mapping your findings directly to NIST 800-53 control families bridges the gap between a technical exploit and the compliance evidence the state requires.

Avoiding the Two Common Failure Modes

There are two types of vendors that frequently cause problems for SaaS companies during this process.

The “Technical Purist”

These testers are often highly skilled and may demonstrate impressive exploit chains or technical fireworks. However, they frequently look down on compliance as boring paperwork. A founder might hire a “rockstar” hacker for street cred, but they often end up with a report that is functionally useless for a state audit.

Finding a critical bug is only half the job. For TX-RAMP, you need a formal Security Assessment Report (SAR) that provides specific evidence for state auditors. If the tester is good at hacking but fails to map findings to NIST controls or explain business risk, the DIR may reject the report.

The “Checkbox Shop”

On the other end of the spectrum are firms that sell a pentest but deliver a glorified vulnerability scan. These shops rely almost entirely on automated tools and skip the manual testing of business logic or authorization flaws. A report built on unvalidated scanner findings will not pass a DIR review. It also will not protect your platform from a real adversary.

Planning for a Successful Deal

TX-RAMP should not be the reason your deal stalls in procurement. The three steps that keep it from becoming one:

1. Define your authorization boundary early. Before scoping any testing engagement, document in writing every component that touches state data. Gaps here create delays later, often at the worst possible moment in a sales cycle.
2. Scope your pentest to NIST standards from the start. Make sure your testing partner understands TX-RAMP requirements before the statement of work is signed, not after the report is delivered. The right firm will ask about your authorization boundary and NIST control mapping upfront. If they don’t, that tells you something.
3. Align your audit cycles so you are not paying for the same work twice. A well-structured engagement can satisfy your SOC 2 auditor and your TX-RAMP assessor simultaneously. The key is coordinating timelines and making sure the scope, methodology, and report format are acceptable to both before the testing begins.

State contracts are lucrative, but they require a level of documentation that standard security testing does not provide. If you run the right test once with the correct scope, your developers get actionable fixes and your sales team gets the signature they need.

The Checklist Your Auditor Wishes You Had

If your current reports leave auditors asking follow-up questions, it is time to raise your expectations.

Our free guide, Audit-Proof Your Pentest, gives you 17 questions that reveal whether you are working with a real security partner or just another checkbox vendor.

Learn how to spot shallow testing hidden behind polished reports, identify red flags in communication, and choose a partner who delivers evidence your auditor will actually trust.