TX-RAMP § 6.2: the exemption a custom build may already have

The conversation goes the same way every time. A department has a workflow that nothing on the market models, a dean or a director has found money for it, and the project reaches the point where information security is looped in. The reply is a single question: what is your TX-RAMP status? The honest answer from a firm that builds bespoke software is "none", and in most tellings that answer ends the project, or postpones it by a quarter while somebody investigates provisional certification for a system that does not exist yet.

That outcome is usually wrong, and the document that says so is the program’s own manual. This piece is about where the exemption comes from, what it does not cover, and why the four conditions attached to it matter more than the exemption itself.

Who the rule actually binds¶

Worth being precise, because the obligation is often described backwards. TX-RAMP does not place a duty on vendors. The program manual points at Government Code § 2063.408, which requires state agencies to enter or renew contracts only for cloud computing services that comply with TX-RAMP requirements. The duty is the buyer’s. A vendor’s certification is simply the most common way for a buyer to discharge it.

And a university is inside that rule, which surprises people who read "state agency" narrowly. Government Code § 2054.003(13) defines the term to include a university system or institution of higher education as defined by § 61.003 of the Education Code. So a public university in Texas is bound, and so is a community college.

What § 6.2 says¶

Version 4.0 of the program manual took effect on 12 February 2026. Section 6.2 is titled "Custom Developed Applications" and it opens with two sentences that decide most of this:

Note what the test is not. It is not about whose cloud account the software runs in, or whether the vendor is small, or whether the data is sensitive. The test is whether the application was specifically designed, developed and commissioned by the institution for a customized solution. For genuinely bespoke work, that is a description of the engagement rather than a loophole in it.

The four conditions that decide whether you get it¶

The rest of § 6.2 is where the work is, and a vendor who quotes the first sentence without the rest is setting up a conversation that goes badly later.

1. Configuring a product is not commissioning a build¶

The exclusion for off-the-shelf platforms that are "simply configured" is the line most likely to be crossed by accident, and it is crossed by success rather than by carelessness. A system built for one institution is exempt on its face. The same system packaged and sold to a second and a third starts to look like a platform being configured, and at some point it is one. That is a genuine constraint on how a bespoke system may be reused, and it belongs in the conversation at the start rather than at the renewal.

2. The institution decides, documents, and keeps the record¶

The determination is the agency’s to make. It scopes the service, documents why the definition is met, and retains the record. A vendor can supply the citation and the description of what was built; a vendor cannot conclude the question. Any firm that tells you your system is out of scope has just told you something useful about how it handles the parts of compliance it does not control.

3. The infrastructure underneath is still in scope¶

The manual is explicit that component cloud services used to deploy the custom application — infrastructure-as-a-service, platform-as-a-service — must comply with the same requirements. An exempt application sitting on an uncertified platform has moved the problem rather than solved it. In practice this is the strongest technical argument for deploying into infrastructure the institution already holds certified, which is usually its own tenant, and it is one more reason the accounts should be in the institution’s name from the first commit.

4. Exempt from certification, not from security¶

This is the condition most often read as good news and is the one that adds work. The manual makes the contracting agency responsible for dictating the unique specifications and security requirements to be met before the system becomes operational, and places responsibility for assessing and securing the service solely with that agency. Read plainly: the institution’s security office will be more involved in the build, not less, and it will hand you controls rather than ask what yours are. A team that treats security review as a gate at the end will find that the exemption removed the gate it was ready for and left the one it was not.

What this is worth, honestly¶

It is a timeline argument, not a security argument, and it should be sold as exactly that. Certification is a process with a queue in front of it; removing a step that was never applicable is worth a quarter of calendar time on a project that has funding and a sponsor. It is not worth anything at all if the underlying system is careless, because the institution has just accepted responsibility for assessing it and will do so.

The reason we publish this rather than keeping it for the room is that it is checkable. The manual is public, the section number is above, and an institution’s own security office can confirm or reject the reading in an afternoon. A vendor advantage that survives the buyer reading the source is a different kind of advantage from one that does not.

One caution that applies to everything above. A program manual is a living document; 4.0 replaced 3.1, and the mandate now runs through § 2063.408 rather than the section number that circulated in earlier commentary. Provisional certification is twelve months in this version, and figures from older guidance are still in circulation. Check the section against the current manual on the day you rely on it, because the cost of being confidently out of date in front of a security office is the credibility of everything else you said.