Technical Specifications.docx

DOCX document 29 KB Posted

Attached to
Budget and Forecasting Software Solution
Solicitation number
MSU-RFP-2027-0872
Issued by
Gallatin County, Montana

About this file

This is a Technical Specifications document for Montana State University's RFP MSU-RFP-2027-0872 for a Budget and Forecasting Software Solution. The University is soliciting proposals for a vendor-hosted or cloud-based solution to support budgeting, forecasting, reporting, analytics, and dashboards across its four-campus system. Questions are due November 10, 2026, and proposals are due December 8, 2026, at 2:00 p.m. MST. The RFP opened October 27, 2026, at 11:00 a.m. MDT. The procurement carries no set-aside, preference, or sole-source restriction. The successful vendor must demonstrate a turnkey, web-based solution with higher education-specific capabilities including complex funding sources, fund accounting, multi-campus budgeting, enrollment-driven planning, strategic resource allocation, and regulatory reporting. Offerors advancing to final selection may be required to provide presentations, demonstrations, interviews, a minimum of three references, and financial stability documentation.

The technical specifications require the proposed solution to be vendor-hosted or cloud-based; on-premises deployments will not be considered. Key requirements include support for multiple authentication protocols (Shibboleth IdP SAML, Azure AD SAML, CAS, openLDAP, or Active Directory), integration with Ellucian Banner ERP system, comprehensive data security controls, PCI DSS compliance for cardholder data, SOC 2 or SSAE 16 audit compliance, encryption for data in transit and at rest, and business continuity and disaster recovery planning. The vendor must provide test environments, describe data segregation techniques for multi-tenant environments, detail onboarding support including customer success managers and training for functional users and end-users, and define support availability across four campuses with specified Service Level Agreement options. All costs must be disclosed in the Cost Proposal attachment, with pricing on a Net 30 payment term basis. The University intends to use its standard contract terms with an attached addendum and requires the successful offeror to register in SmartBuyMSU upon award.

View the file

Other files

File Type Posted
RFP_Evaluation Criteria.docx DOCX document
Attachment 2 Cost Proposal .docx DOCX document
Draft Contract.docx DOCX document
Data Security Terms.docx DOCX document
1452724-event.pdf PDF
University Contract Addendum to be applied to any supplier agreement utilized.pdf PDF
Attachment 1 Scope of Project (2).docx DOCX document
Standard Terms and Conditions.pdf PDF

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

Attachment 4 – Technical Requirements

The proposed solution must be vendor-hosted or provided as a cloud-based service. On-premises deployments will not be considered. Offerors must respond to each requirement as applicable to the proposed solution. If a requirement does not apply, the offeror must state that it is not applicable and briefly explain why.

1.0 AUTHENTICATION AND AUTHORIZATION

1.1 Authentication

Offeror’s solution must use appropriate integration protocol for authentication such as Shibboleth IdP SAML, Azure AD SAML, CAS, openLDAP, or Active Directory in parallel with local authentication to accommodate both University and outside users. If SAML or CAS authentication is not supported, explain if solution integrates with Duo Security for 2-Factor Authentication. Offeror must describe how authentication is performed in their system.

Is Offeror a member of the InCommon Federation?

Does Offeror’s solution support the use of a unique, unchanging user identifier that is not an email address?

Password Replication: Offeror’s solution must not replicate any user password credentials (hashed or otherwise) except when express permission is granted via signed contract. The offeror must describe how this requirement is met.

Password Requirements: If local accounts are used in the system, Offeror must describe support for strong password requirements or confirm that this does not apply.

1.2 Authorization

The offeror must describe how authorization is performed in their system.

User Permissions: If the system defines distinct levels of user permissions, Offeror must describe how the system controls user permissions or confirm that this does not apply.

2.0 DATA, INFRASTRUCTURE, AND INTEGRATION

2.1 Data Integration with ERP and other External Systems

Integration approach.

If the solution integrates with other vendor solutions, vendor must describe integration strategies and technical approach (e.g., API, Web Services, File-based) Describe how and what data elements can be exchanged with external systems, such as the Ellucian Banner ERP system.

What technology is used to facilitate data exchange?

What technological requirements exist in the target external system?

Integration with Ellucian Banner Describe the nature of integration, with Ellucian’s Banner Enterprise Resource Planning (ERP) software.

Is the system capable of 2-way integration with Banner? If so, describe in detail how this is accomplished.

Which components in Banner are synchronized or updated?

Describe any integration components that have already been pre-developed for Banner integration?

Is the Ellucian Ethos integration strategy supported or on the roadmap for future integration?

Describe how security privileges in the Banner ERP affect security privileges in the proposed solution (and vice versa).

Describe the integration dependencies between Banner ERP and proposed solution. How are patches monitored in Banner to ensure delivered upgrades do not negatively affect integration and functionality between the systems?

2.2 Database Infrastructure and Data Access

Data Infrastructure If hosted solution is proposed, the vendor must describe non-hosted technology components the institution must deploy, support, or maintain.

Data Access Is data accessible through vendor reporting tools or a mechanism to retrieve data via export? (If not, describe available reporting technology) Data Segregation The vendor must describe the data segregation techniques used if a multi-tenant environment is proposed.

2.3 TEST ENVIRONMENT

The vendor must describe the duration of availability and license considerations for a test environment.

The offeror must describe how the test data is created initially and maintained as current and useful.

3.0 HOSTING REQUIREMENTS

3.1 Hosting Strategy and Attributes

Hosting environment: Vendor must explain how the solution is hosted. Is the hosting environment vendor owned/operated or via a separate 3rd party (e.g., AWS, Azure, Oracle, …).

Server Hosting: Vendor must describe standard security controls in place, including, but not limited to, patch management, physical safeguards, availability monitoring, environmental controls, and system file integrity monitoring. The vendor must provide proof of audit compliance to a standard such as SOC 2 or SSAE 16.

Data Encryption: Vendor must have appropriate controls in place to prevent exposure of information. Sensitive data in transit must be protected with appropriate encryption levels. The vendor must describe how and where data encryption is used.

Data Segregation: Vendor must describe how the Institution’s research data is secured from access outside the intended owner or reviewer.

Service Availability: Vendor must describe their business continuity and/or disaster recovery plan.

3.2 CDI, PII and Cardholder Data

If the solution stores, transmits, processes, or has access to CDI/PII/Cardholder Data the following requirements apply:

a. The vendor must hold CDI/PII/Cardholder Data in strict confidence and must use appropriate security measures to preserve the confidentiality, integrity, and availability of all PII. The vendor must confirm that they will comply with this requirement.

b. The vendor must describe how all sessions transmitting CDI/PII/Cardholder Data will be protected with appropriate encryption levels.

c. The vendor must describe which data elements (student ID #, name, PAN, contact information, etc.) are being stored in the proposed solution.

d. The vendor must describe security controls in the server and database environment used to store CDI/PII/Cardholder Data, including physical security, updates, backup and restore procedures, uptime requirements, monitoring, etc.

e. The vendor must describe how CDI/PII/Cardholder Data is segregated from data of other security levels.

f. The vendor is required to adhere to the Payment Card Industry Data Security Standard (PCI DSS) promulgated by the PCI Security Standards Council. PCI DSS requires The University to maintain a written agreement that includes an acknowledgment that the vendor is responsible for the security of cardholder data that the vendor possesses and requires The University to maintain a program to monitor the vendor’s PCI DSS compliance status at least annually. The vendor agrees that it is responsible for the security of all cardholder data that it obtains or possesses, including but not limited to the functions relating to storing, processing, and transmitting the cardholder data. The vendor attests that, as of the effective date of this contract, it has complied with all applicable requirements to be considered PCI DSS compliant and has performed the necessary steps to validate its compliance with the PCI DSS. The vendor agrees to supply to The University the current status of the vendor’s PCI DSS compliance and evidence of its most recent validation of compliance upon execution of this contract to The University. The vendor must supply to The University an attestation of compliance (AoC) and sufficient evidence of its most recent appropriate compliance validation assessment for The University to ascertain the assessment scope and outcome, at least annually to PCI@montana.edu. The University has the option to terminate the contract if the vendor falls from compliance.

g. The vendor must provide proof of data center audit compliance to a standard such as SOC 2 or SSAE 16.

h. The vendor will be required to return, purge, and confirm purging of all Institutional data, CDI/PII/Cardholder Data, or otherwise, upon request and/or termination of the contract. The vendor must describe the mechanism to return, purge, and confirm purging of all Institutional data, CDI, PII, and Cardholder Data.

3.3 Business Continuity and Service Availability

If a hosted solution is proposed, the vendor must describe how the solution minimizes business disruption and maximizes system availability.

What kind of “up” time do you deliver (also define any terms within your answer as appropriate)?

What are the biggest risks to the solution in terms of availability (e.g., power outages, network outages, data corruption, software bugs, reliance on external partners), and how are these risks mitigated?

Provide any examples of large outages that have occurred, how long they lasted, and how you resolved them.

The vendor must describe the nature of scheduled downtime, or “quiet time,” the solution requires, noting the frequency, duration, and purpose. What tools are available to continue core functions during downtimes? How are jobs that are scheduled to run during downtimes handled?

Vendor to describe patch or upgrade delivery and/or deployment practices and implications for institutional support personnel. Describe the process for upgrades, expected downtime, frequency of releases, integration of partner applications that need to be rewritten, and any professional services requirements.

Vendor to describe institution’s entitlement to subsequent version deliveries and new product offerings within the solution’s product suite.

4.0 ONBOARDING AND SUPPORT OFFERINGS

4.1 Onboarding

What onboarding support is provided by the vendor?

Does the vendor have customer success managers, and how will those work with MSU to ensure successful adoption of the solution pre- and post-implementation?

What specific training is provided for functional users, technical staff, and end-users?

4.2 Operational Support

What support is available? Please list support availability (i.e., weekends and evenings)?

How will support models be structured across four campuses?

How are support offers priced?

If a hosted solution is proposed, the vendor must describe the Service Level Agreement licensing options and/or response times for issue identification, classification, resolution, as well as escalation procedures.

Describe Service Level Agreement opportunities relative to telephone and online issue reporting.

Does the vendor offer a User Support Group or any other type of End User Group events?

4.3 Consulting

What additional consulting services are available?

How are best practices from other organizations shared with MSU?

4.4 Offer Inclusion

Which of those consulting, onboarding, training, and customer success services are included in the offer, and which ones are charged separately? Provide an itemized price list for services that are charged separately.

2 | Page

File details come from the government source that posted it. Updated .