IRM 2.0 Reference for ISMs

This field will default to the logged-in user's primary affiliation. If needed, users can select a different department by clicking the field and searching by Name or Department ID.

ISMs should specify which department they prefer their users to use if multiple apply.

Only departments that have an ISM will appear in the list of options. If a department is needed but not shown, choose "Department Isn't Listed". Then, contact us to clean up, add, or correct the listing.

Data Types

PHI: This is data collected as part of treatment by the covered entity – in the hospital or clinic. This is subject to HIPAA

Research Health Information: The same kind of data as PHI, but collected for the purposes of research instead of treatment. HIPAA does not apply.

De-Identified Health Information: Users should only select this if they are removing all 18 identifiers according to HIPAA Safe Harbor, or using statistical methods to remove identifiers. For more information, see How to De-Identify Data.

Pseudo-Anonymized: This is only in the context of the European Union GDPR. As of right now, this is still treated as Restricted Data.

Anonymized: Also GDPR, when all identifiers have been removed and no longer considered ’personal data’.

Credit/Debit Cards: Select only when you or your vendor are collecting credit and debit cards as a form of payment, not when making a purchase using a p-card.

Financial Account Information: When collecting information on individual’s financial accounts, such as bank account information.

Data Classification

Open vs Sensitive: Open data is published and actively made public – such as information on a public website or a newsletter. Anything not ready to publish is Sensitive – that means research in progress, internal notes and documents, software code that is being developed.

For questions about how to classify data, see the UF Data Guide or contact the UF Privacy Office.

Will be combined with data classification to determine the impact axis of the project risk heatmap. Can be estimated.

Examples:

• How many individuals will have their data collected and stored?
• How many research subjects are involved?
• How many observations will be recorded (if not humans)?

This field is important for Privacy to understand if other privacy laws will apply.

Federal regulation limits transferring data to these countries. For the initial submission, choose "Yes" if any data will be stored in or accessed by anyone in a listed country.

The specific "amounts of data" per type that require additional review and approval will need to be collected. Some data types, such as human genomic data, are completely prohibited.

Used to determine what types of additional review are needed. For human research data, an IRB number must be provided. In the next step, ISMs will need to attach the research protocol.

The ISM will need to follow up with the customer to obtain the requisition number.

Start by reviewing the request details. Verify the submitter, project owner and department are correct.

You will most likely have to edit the project name and description. Researchers often use these fields to describe the science and outcomes of a project, but these fields should capture the technology and data they're using. You can edit these fields shortly after receiving the request.

For the project name:

• Name the technology and possibly reference the general usage of it.
• Come up with a naming convention you'll use for all requests, perhaps to identify sub-units, labs, etc.
• Don't make it vague like 'Project Review'.
• Avoid using the long title of the paper this technology is supporting.
• Don't duplicate an existing project name.

For the description:

• Describe what the technology is and how data will interact with it.
• Describe any other user interactions, such as external collaborators, data transfers and third parties.

Pre-Check Solutions is our database of products that have been assessed and for which we already have the vendor's security documentation (like a SOC2). Whenever possible, try to direct users towards a pre-checked solution to save time and risk assessment effort. Even when using a pre-checked solution, we will still need to do an assessment to verify that the solution is appropriate for the project's data and to review other aspects of the project.

If using a pre-checked solution, you will be asked to select the specific solution(s) being used. Click "Lookup" and check the boxes for any and all items that will be used for this project.

Enterprise Alignment and Enterprise Integration are related concepts that have been combined into one field for ISM Review.

Enterprise Alignment is the implementation of the UF IT Rationalization Policy. You will need to be aware of UF's enterprise services and try to get your users to use them whenever possible. For instance, if a user wants to purchase a meeting transcription service, direct them to use Zoom AI Companion instead.

If you believe there is a strong reason to use something other than the enterprise solution, select "Yes" for the Enterprise Alignment & Integration field and enter a justification as to why. This will be sent to the Enterprise Service Owner, who may contact you and the user to understand the needs and make a decision.

Enterprise Integration occurs whenever a solution being assessed needs to integrate with an enterprise service or data source. For example, a cloud service that helps students register for classes would need to integrate with Campus Solutions.

If the project requires Enterprise Integration, select "Yes" for the Enterprise Alignment & Integration field and explain the required integration. This will be sent to the Enterprise Service Owner to determine if the integration is acceptable.

For the AI Integration field, provide documentation of known AI features the technology offers, if any. Include the known ways this project intends to use AI features, as well as restrictions that should be placed on the use of AI features in the solution to ensure data security.

For the Project Scope field, select all options that describe what this request is evaluating. Options labeled as "unit validation" will open additional questions to determine if this request qualifies for local review within your unit.

• Restricted or Sensitive Data FPS Usage: Customer wants to use a solution from the Fast Path Solutions list with Restricted or Sensitive Data.
• UFIT ISO Risk Assessment: If you have security concerns with this project or otherwise know the use case will require ISO review, check this box. This will essentially bypass further acknowledgement questions and direct the request to ISO.
• Related to Integration with UFIT Solution or Data: See the Enterprise Alignment & Integration section above.
• New FPS Request: If you think this solution is a good candidate for Fast Path Solutions. Consider this if multiple users in your unit request the same solution over time. The technology must meet the following criteria for a Fast Path Solution:
  
  • The solution does not create any issues with enterprise alignment. 
  • The solution does not require UFIT service integration before it can be used.
  • The solution offers native Single Sign-On (SSO). 
  • A recent third-party security assessment can support the solution, an actively supported application.
    • For sensitive and Restricted Data
  • The solution is versatile and supports multiple purposes, such as administration, research, and teaching and learning.
  • The solution has undergone the appropriate reviews, including Privacy Policy, End User License Agreement (EULA), Terms and Conditions, etc.

 

Based on the answers to the Hardware questions, a determination will be made about who needs to review a project involving hardware. For example, an end-user laptop with standard configuration is eligible for unit review. However, a project where a non-UF server will store UF data must undergo ISO review.

Additional guidance for the hardware questions:

• Standard computer managed by IT: Your unit’s standard build that has had a risk assessment.
• Tablet: Similar, the key is that it is managed by IT.
• Drone: Drones used by state agencies are subject to very detailed and specific regulations that we verify along with EH&S.
• Persistent Storage: This question is not applicable to a standard computer or tablet. This might be something like a webcam or headset. If it saves data to an SD, select "No".
• Network connections: This probably means there’s some kind of login, data transfer, or other concerns we need to look at.
• Peripherals: Basically, "dumb" peripherals like keyboards, mice, webcams; anything that doesn’t store data or require a network connection. Normally we wouldn’t ask for a risk assessment for these, but sometimes they come up.
• No other security concerns: This is your judgement. If the solution seems to fit the above criteria, but there’s something that these questions don’t catch, select "No".

Like hardware, some software applications are eligible for local review if they meet certain criteria. For example, a standard application that runs on a unit-managed device and does not use the network is eligible for local review. Conversely, a cloud application that stores UF data will need to undergo ISO review.

Data access patterns also generally determine what is eligible for local review. For instance, the purchase and pulling of a data set (like a news subscription) can be evaluated in local review. However, ISO review is necessary for projects where UF data will be made available to a third-party.

The Not Permitted Solutions list can be accessed in Fast Path Solutions by selecting the "Not Permitted" filter.

This question checks whether any project component will require the user to login to a user account.

If the answer is No, then there are no more questions about accounts. If the answer is Yes, some SSO-related questions will appear.

The UF Single Sign-On Usage question asks if and how SSO will be used. Authentication only means that the vendor uses the subject in the SSO token (like name, email, or EPPN) to grant access to the system. Both Authorization and Authentication goes a step further by having the vendor also check roles and group memberships to control the level of access a user has in the system.

If you selected "No" for the Account Usage question, you will still get the following questions.

SSO Technology Support describes the underlying SSO protocols the vendor can use to integrate with UF's login system. Even if you selected that SSO will not be used, we still want to know whether the vendor supports it. If you are working with a vendor that supports SSO, but your unit will not use it, the project will be flagged for review by the UF IAM team.

If SSO will not be used, you will need to provide an SSO Non-Use Reason:

• Not Supported: The vendor does not support SSO
• License Limitation: The vendor only provides SSO with an enterprise license, but the project is using a "pro" license or other tier that doesn't include SSO.
• Cost: It is too expensive to configure SSO for only a few users.
• Limited Use-Case: Very few users, maybe will only need to login once or twice.

Regardless of SSO status, if you select "Yes" for Account Usage, you will get the Account Management Details textbox.

If using SSO, you can state that in this box. If you know the UF attributes needed for SSO integration, list them in this box. 

If not using SSO, include details such as:

• What is this account for?
  • “The account is only needed for the cloud service; the hardware and software for this project do not require user login”
• How many users will need accounts?
• Who will manage these accounts (PI, IT Team, vendor)?

In-House should only be selected when the technology was developed at UF. This includes solutions such as MyAssets and the University of Florida app, as well as internal efforts like your unit developing a new website.

Third-Party is when the project or at least one component of the overall project is outsourced to a vendor or developer. This includes cloud-based systems, vendor-controlled hardware and software, and contracted web development. If a third-party is involved, this section will ask you for the company's name and web address, as well as the vendor representative's name and email address. These fields do not have character limits, so you can include details on multiple vendors if necessary.

With the remote access question, we want to know if the vendor will have remote access to the system (or component of the system) for any reason, including maintenance or support. This does not include cloud services, where the vendor technically always has access to the data.

Use the Direct System Interaction field to estimate the total number of users that are involved with the project. This is an open text field, so please provide additional context if you have any.

This field relates to projects that have critical components whose malfunctions could endanger people. If you select "Yes" a box will appear for you to enter comments. For example, "if the device goes offline, unmonitored carbon monoxide levels in the lab could be deadly."