IT departments in higher education are increasingly being tasked with evaluating requests to connect systems using integrations. System integrations can connect two enterprise-managed systems or an enterprise system and a third-party application or add-on. Examples of systems that these requests pertain to are Microsoft 365, Google Workspace, a learning management system (LMS), and a customer relationship management (CRM) system. Many institutions have been challenged by requests for integrations or add-ons when vendors are unable or unwilling to supply HECVAT information, and IT decision-makers find themselves unequipped to assess the risk of allowing such add-ons. In January 2023, EDUCAUSE convened a group of campus IT administrators and professionals to define a framework and generate a toolkit that institutions can use to develop a systematic process to evaluate and make decisions about allowing integrations or add-ons.

This series of best practices can guide institutional efforts to manage third-party integrations efficiently while ensuring a secure technology environment.

Disable User Ability to Self-Install

IT departments should first restrict the ability for their users to self-install any integrations or add-ons into managed systems. The success of an institution's process to evaluate and control integrations and add-ons depends on IT being the sole gatekeeper for the environment.

Once this control has been established, the remainder of the best practices should be considered, and an institution can move toward establishing governance.

Establish Approval and Governance Processes

IT departments should form appropriate committee(s) and/or approval teams to handle requests for system integrations and add-ons. These committees should include the relevant stakeholders in the IT approval chain and should work to build a request type into their ticketing system as an established standard request for users to submit.

The governance process should be applied to any system managed by the institution that allows third-party integrations. Some common examples are collaboration and meeting platforms, LMSs, and CRMs. These systems should have an environment/applications manager who sits at the front of the approval workflow to research the business needs and technical details of the integration or add-on being requested.

Other common stakeholders in the approval processes include departments and groups such as IT security (CISO), systems engineering, applications management, IT risk and compliance, procurement, and IT leadership. When the integration or add-on involves critical systems, sensitive data, large-scale scope of implementation, or any other major factor, then the institution’s IT leadership team should always be aware and involved in the final decision-making process.

Generate Software Catalog

IT departments should compile and publish a comprehensive catalog of all approved systems and system integrations or add-ons in use on campus (figures 1 and 2 show examples of software catalogs). This will help educate members of the campus community about what is already available for certain types of software. It will also reduce the duplication of efforts resulting from redundant requests or requests for integrations or add-ons for which a similar option already exists. Institutions should consider the risks and rewards of making a software catalog publicly available on the web versus restricted to their users only.

Conduct Periodic Review

IT departments should task the appropriate staff member (or team) identified in your governance process with an annual review to contact integration owners (the original requesters) and determine whether the integration is still needed. In addition, the IT department should be performing another technical review to ensure that the nature of the integration has not changed.

The software catalog mentioned above should be the guiding checklist document that IT uses to ensure all systems receive annual reviews.

This Integration Workflow Example (figure 3) illustrates a general process for evaluating and approving third-party integration requests. The flowchart can be modified to fit different organizational structures and needs.

The Integration Workflow Narrative provides detailed considerations for developing a workflow.

1. The end user submits a request to use an app, service, or plug-in. If possible, the request intake process should be built into your existing ticketing system. The information you require the requester to provide during this initial step should be general enough to apply to most scenarios.
2. The request is passed to an oversight group for analysis and consideration. Ideally, this group will comprise people from different areas of your institution. For example, it might include individuals from your information security team, your application support team, your procurement team, and data stewards.
3. At this point, the oversight group should come to one of the following decisions:
   1. Request approved: Continue to the next step.
   2. Request denied: The requester should be informed of the group's decision and the reason it came to this conclusion. The workflow process ends at this point.
   3. More information needed: A representative of the group should contact the requester to ask for additional information. The group should then reconvene to consider the request. Examples of additional questions:
      1. Has a HECVAT or other business analysis been performed, and, if so, can you provide a copy?
      2. Is there an existing app/service that the institution currently supports that can perform the same function as the requested app/service?
      3. Present the permissions requested by this app/service to the requester. Do they understand the effect of the granted permissions on their and the institution's data?
4. As part of the decision process, the oversight group should consider whether it is appropriate to approve use of the app, service, or plug-in for all end users at the institution. The group would come to one of the following decisions:
   1. Request approved for all end users: Continue to the next step.
   2. Request approved, but use should be restricted: A representative of the group should contact the requester to determine the appropriate range of end users allowed to use the app, service, or plug-in. After applying restrictions, continue to the next step.
5. The requester is contacted and is provided with a summary of the approval findings made by the oversight group.
6. Details of the application, service, or plug-in should be recorded in the institution's software catalog.
7. Use existing institutional processes to make the app, service, or plug-in available to end users. For example, this may include piloting use with a "test" set of end users prior to making it available to everyone.
8. Perform a periodic review of the application, service, or plug-in. It is recommended to return to the step of this workflow where the oversight group performs the initial analysis and then proceed with the subsequent steps. In this way, the workflow is considered a continuous, life-cycle process. The group might also consider the following questions as part of the periodic review:
   1. Is the service provider still in business or has it been purchased by another company?
   2. Have there been any changes to the privacy or terms of use policies since the app/service was initially reviewed?
   3. Is the app/service still used? Each institution will need to determine an appropriate usage window (e.g., no one has logged in to the app/service in the past 90 days).