Statement of Purpose
The purpose of the Architecture and Security Review (ASR) is to partner with campus departments to act as a consultative and advising body during the selection and negotiation of a proposed technology product or service. The ASR does not approve or disapprove products, but will identify risks and provide actions and/or strategies to mitigate those risks. Having this discussion early in the selection process will optimize the service or product’s compatibility with the University’s information technology architecture, security, compliance, accessibility, and privacy principles. The ASR is a cross-functional team that will provide suggestions and observations for a successful implementation. The result of this collaborative process will be a comprehensive report that will include recommended solutions that are compatible with University architecture and mitigates risk.
*Please Note: while the ASR is not currently a mandatory process, departments must ensure that any technology product or service involving the transmitting, accessing, or storing of customer information subject to the Gramm Leach Bliley Act (GLBA), as well as all technology additions, major architecture changes, and updated contract terms, must go through an ASR. The GLBA applies to the University in connection with the following financial activities: financial aid, student loans and accounts, parent loans, faculty and staff loans (including mortgage loans) (collectively, “University loans”). Customer information is any record containing non-public personal information about recipients of University loans, whether in paper, electronic, or other form, that is handled or maintained by or on behalf of the University.
ASR Process Steps
-
-
Complete the ASR Intake and Background Form. Once the form is submitted, an automated email will be sent to an ISO representative, who will determine if an ASR is necessary by considering potential risk to the University.
-
-
An ISO representative will reach out to the requester confirming the need for an ASR, and provide the list of documentation needed to move forward with scheduling. It is especially important that the documentation collected be as complete as possible to ensure a proper review. Requests that have absent or incomplete documentation will not move forward to scheduling.
-
-
Once complete documentation is received, the ISO representative will share the next available dates for a review meeting.
-
-
- The requester should ask that the supplier have representatives on the call that can speak to the technical components of the solutions such as, system architecture, overall IT security and compliance, accessibility, and system integrations.
- The requester should ask the supplier to join the second half of the meeting, as the first half will be internal to the Princeton team.
-
-
It is the responsibility of the requester to share the meeting invite with their team members and the supplier representatives.
-
-
- The first half of the meeting is used for the ASR team to ask the Princeton requester clarifying questions about the product/service.
- The second half of the meeting is used for the ASR team to ask the vendor clarifying questions about the product/service.
-
-
At the conclusion, of the review a report with a summary of the meeting will be supplied to the requester.
- There are several potential outcomes of an ASR. The findings include:
- Endorsed
- Conditionally Endorsed (Pending Further Action)
- Not Endorsed (Pending Documentation)
- May Need 2nd ASR
- There are several potential outcomes of an ASR. The findings include:
ASR FAQs
-
-
A: A review is useful for selecting software, designing a custom solution, or before major changes to an existing solution.
-
-
A: For cloud solutions: HECVAT lite, architecture diagram, SOC 2 Type 2, executive summary of most recent penetration test completed by a third-party, VPAT, accessibility road map
For on-premise solutions: HECVAT on-prem, SOC 2 Type 2, executive summary of most recent penetration test completed by a third-party, VPAT, software bill of materials.
-
-
A: The ASR team will ask the supplier questions based upon the documentation they have supplied.
-
-
A: We do not provide an agenda. However, some of the areas of risk that the team will be looking to evaluate include:
- Data Classifications – How sensitive is the data?
- Authentication – What attributes are needed?
- Integrations/Architecture – Will this product/solution need access to other systems at the University?
- Accessibility – Does this product offer Accessibility compliance as is required by law?
- Third-Party Assurance – Has this company/product been reviewed by a third-party, proving their compliance to IT standards?
-
-
A: Please have people on the call that can speak to the technical components of the solution like: system architecture, overall IT security compliance, accessibility and system integrations.