Technology Acquisition FAQ

Software and devices used at SHSU, whether purchased or free, are required by Texas law to be reviewed to ensure compatibility, support, and compliance.

• Quote or Contract
  • Not required but recommended because it helps IT know exactly what needs to be reviewed (product, versions, etc.).
• VPAT or ACR (Accessibility Documentation)
  • VPAT: A template a vendor completes to describe product accessibility.
  • ACR: The completed report showing accessibility results.
• HECVAT or SOC 2 Type 2  (Security Documentation)
  • HECVAT (4.0 or higher) - A template completed by the vendor and used to assess the vendor’s data protection, privacy, and security practices.
  • SOC 2 Type 2 - An independent audit report that shows how a vendor’s security controls operated over time. SOC 2 Type 2 may be accepted as an alternative to a HECVAT in some cases.
  • Security documents may be required if:
    • the solution stores, accesses, or shares university data
    • a cloud or SaaS product
    • connects to campus systems
    • involves sensitive or regulated information
  • HECVAT is the preferred document for security assessments.

You can use these links for more detailed information about compliance requirements. 

• TAC 202 – Security Controls

• TX-RAMP – Cloud Security

• TAC 213 - Electronic and Information Services

• Section 508 of the Rehabilitation Act of 1973 

• Texas Government Code Section 552.139 – Prohibited Technology    

Standards outlined in Section 508, Title II, and TAC 213 require that all electronic and information technology (EIT) developed, purchased, maintained, or used by federal and state agencies is accessible to individuals with disabilities. This includes ensuring that people with temporary or permanent disabilities can use the requested product. To support this, we request an Accessibility Conformance Report (ACR) from your vendor. Having this information before submitting your request can help expedite the review process, though it is not mandatory for submission. 

The email address is used to address technical questions. For example, we need to contact them regarding technical documentation. Inaccurate or incomplete information will slow down the approval process.

Think about what kind of info the system will store. For example: 

• Student records, medical info, or saved credit card data? Probably Confidential. 
• Internal documents like HR files, research, operational information or non-confidential information that require additional protection. Likely Protected.   
• Info you'd be fine with putting on our public website? That's Public. 

Here's a link to the IT 06 Data Classification policy to help you decide. 

In this context, impact refers to how the university as a whole would be affected if something went wrong with the software.  For example, if it were hacked or suddenly stopped working. While the issue might cause serious problems for you or your department, it's important to think about how it could affect the entire university. Consider factors like student and employee safety, whether key services would be disrupted, how much it might cost to fix, and how it could affect the university’s reputation. To help you properly evaluate these criteria and determine the most appropriate impact level for the software, use the examples in the matrix below.