Understanding the Third-Party Risk Management (TPRM) Process for Software Purchases

Understanding the Third-Party Risk Management (TPRM) Process for Software Purchases

When multiple faculty members or departments need to purchase the same software, the Governance, Risk, and Compliance (GRC) department assesses the Third-Party Risk Management (TPRM) approval process. Below is an overview of the key factors and guidelines provided by the GRC:

Key Factors in TPRM Assessment

The GRC evaluates the following three criteria during the TPRM process:

  1. Type of Data Involved
    Determining the nature of the data being handled.

  2. Data Storage Location
    Identifying where the data is stored (e.g., cloud storage, on-premises).

  3. Vendor Access to Data
    Understanding whether the vendor has direct access to the data.

If all three factors are deemed low-risk, the GRC will advise the submitter to proceed with the requisition process. However, if any risks are identified—such as data stored in the cloud or handling of personal/privacy data classified as P3/P4—the GRC will conduct a more thorough vendor review to ensure data security. Additionally, different use cases among users may pose challenges, as each case may require a unique risk evaluation.

TPRM Submission Requirements

Each faculty member or department must submit an individual TPRM request, even for the same software.

Potential Workaround for Identical Requests

The GRC suggests a workaround for identical software purchases with the same use case:

  • Combine Requests: Multiple requests can be consolidated into a single purchase order, allowing for the use of one TPRM approval number.

However, it is important to note that separate purchase orders cannot reuse the same TPRM approval number, as this will be flagged by Purchasing.

Additional Considerations

The GRC has identified two other reasons for maintaining individual TPRMs:

  1. Software Inventory Tracking
    This helps the institution keep track of software usage, which may be beneficial for negotiating campus-wide licenses.

  2. Security Notifications
    In the event of a security breach, the security office needs to notify the specific users affected so that appropriate actions can be taken.

    • Related Articles

    • Microsoft 365 A3 Licensing for UCLA School of Engineering

      The UCLA School of Engineering purchases Microsoft 365 A3 licenses for all full-time and part-time administrative staff, as well as full-time and part-time faculty within the school. The license term typically starts on July 1st and ends on June 30th ...
    • Class resource activation

      To learn what software and other computing resources are available for Engineering classes and how to request for them, please visit https://www.seasnet.ucla.edu/class-activation/.
    • IT Resources for MSOL

      Login: UCLA Logon IDWhere to get help: accounts.iam.ucla.edu or contact UCLA IT Services You will use your UCLA Logon ID to access the following resources: Bruin Learn for class websites Zoom for online office hours ScheduleIt for studio reservations ...
    • SEASnet Applications Support

      SEASnet offers support for specific applications developed by our department. However, there are certain applications that fall outside the scope of our support. Please view the following list of applications and type of support that we provide: ...
    • Email features, how-to and policy

      Using MyEngineering to email students Please follow the guidelines at https://my.engineering.ucla.edu/public_files/courseweb_email_policy.htm Instructions: Login to MyEngineering (https://my.engineering.ucla.edu) Click on "MyEngineering" on the upper ...