The file's text, extracted by GovTribe without its formatting.
ERP Replacement Program
TECHNICAL SUBMITTAL F.1 – SAAS NON-FUNCTIONAL REQUIREMENTS MATRIX
The Proposer/SaaS Provider Must Comply with RTD’s at Minimum SaaS Service Level Requirements (SLR)
| SLR ID # |
| SAAS SERVICE LEVEL REQUIREMENT (NON-FUNCTIONAL) |
| SAAS SLR CATEGORY |
| SAAS PROVIDER COMPLIES (YES (Y) OR NO (Y)) |
| COMMENTS |
| 1 |
| SaaS Provider must comply with RTD's Supplemental Technology Terms and Conditions (Rev. 09.2023), which govern information security and management standards applicable to RTD's system acquisition, operation, and maintenance. |
| Security & Compliance |
| 2 |
| SaaS solution must be protected against malware and malicious code across all infrastructure components, consistent with RTD Supplemental Terms and Conditions (Rev. 09.2023). |
| Security & Compliance |
| 3 |
| SaaS Provider must provide technical vulnerability management processes to ensure detection and remediation of vulnerabilities in a timely manner (e.g. |
Patch Compliance).
Security & Compliance
| 4 |
| For any remote support provided by the SaaS Provider (e.g., third-party managed services, off shore access, etc.) or manufacturer, the solution must be designed to ensure that access is provided to follow the following principles: 1) multi-factor authentication; 2) remote connections are only turned on when necessary; and 3) direct connections to the applications must always be avoided, and the use of jump boxes and/or protocols such as Remote Desktop Protocol (RDP) are encouraged to minimize exposure of the target applications. |
| Security & Compliance |
| 5 |
| SaaS Provider must comply with required data privacy safeguards (including masking and access restrictions) as required by RTD. |
| Security & Compliance |
| 6 |
| SaaS Provider must maintain and provide an inventory of all information assets, including systems, components, and repositories; and provide any compliance reports to RTD, based on compliance requirements in Colorado state. |
| Security & Compliance |
| 7 |
| SaaS provider must comply with local/state/federal cloud computing policy. |
| Security & Compliance |
| 8 |
| SaaS solution must ensure all data transmissions are encrypted using Advanced Encryption Standard (AES), with a minimum of 256 bit key and TLS |
1.2 or higher.
Security & Compliance
| 9 |
| SaaS solution must not allow access to confidential data via any unsecured wireless hand-held device. |
| Security & Compliance |
| 10 |
| SaaS Provider and all subcontractors who access, process, or store RTD assets and/or data must comply with RTD's information security requirements as specified in RTD Supplemental Terms and Conditions (Rev. 09.2023). |
| Security & Compliance |
| 11 |
| SaaS Provider must broadly align and comply with RTD's technology resilience (security and risk management) standards as codified in RTD Supplemental Terms and Conditions (Rev. 09.2023). |
| Security & Compliance |
| 12 |
| SaaS Provider must conduct regular security audits and comply with RTD's annual reporting requirements as specified in RTD Supplemental Terms and Conditions (Rev. 09.2023). |
| Security & Compliance |
| 13 |
| SaaS solution and environments must be served through a FedRAMP certified or equivalent security certified hosting facilities (e.g., SOC2 Type II requirements). |
| Security & Compliance |
| 14 |
| SaaS solution must maintain an audit trail that logs data access and system processes performed by authorized users, including both successful and failed access. The logs must, at a minimum, include information on user, login date and time, location (including IP address), records accessed/viewed, records created/deleted, active session duration, administrative actions, and firewall audit events. |
| Security & Compliance |
| 15 |
| SaaS Provider must utilize automated monitoring tools to continuously monitor, measure, and manage system performance, consistent with RTD Supplemental Terms and Conditions (Rev. 09.2023). |
| Operations & Support (SLA) |
| 16 |
| SaaS Provider must provide RTD with access to system performance dashboards and operational metrics, including real-time and historical visibility into system health, performance, and usage. |
| Operations & Support (SLA) |
| 17 |
| SaaS Provider must meet the following service request/incident response times; levels are defined by severity level: |
Level 1 (Critical Business Impact): 15 Minutes Level 2 (Significant Business Impact): 1 Hour Level 3: (Some Business Impact): 4 Hours Level 4: (Minor Business Impact): 1 Day Operations & Support (SLA)
| 18 |
| SaaS Provider must meet the following service request/incident resolution times; levels are defined by severity level: |
Level 1 (Critical Business Impact): 4 Hours Level 2 (Significant Business Impact): 8 Hours Level 3: (Some Business Impact): 2 Days Level 4: (Minor Business Impact: 3 Days Operations & Support (SLA)
| 19 |
| SaaS Provider must provide service desk support/coverage of hours at the following levels, all in Mountain Standard Times (MST): |
Level 1 (Critical Business Impact): 24x7x365 support with Immediate Escalation Level 2 (Significant Business Impact): 24x7 support Level 3: (Some Business Impact): Extended business hours (7 AM-7 PM local time, Monday to Friday) Level 4: (Minor Business Impact): Standard Business Hours (8 AM – 5 PM, Monday to Friday) Operations & Support (SLA)
| 20 |
| SaaS Provider must track and report compliance with agreed upon SLA measures by service request/incident severity level. |
| Operations & Support (SLA) |
| 21 |
| SaaS Provider must track and report compliance with agreed upon SLA measures on System Uptime. |
| Operations & Support (SLA) |
| 22 |
| SaaS Provider must track and report compliance with agreed upon SLA measures on System Response Time. |
| Operations & Support (SLA) |
| 23 |
| SaaS Provider must track and report compliance with agreed upon SLA measures on RPO and RTO. |
| Operations & Support (SLA) |
| 24 |
| SaaS Provider must pay penalty fees for non-compliance, with SaaS fee credits as follows – SaaS Vendors Provide, but RTD can negotiate. |
| Operations & Support (SLA) |
| 25 |
| SaaS Provider must incorporate comprehensive logging and monitoring capabilities across all systems that store, collect, transmit, or process RTD Data, consistent with RTD Supplemental Terms and Conditions (Rev. |
09.2023). AIOps-based noise filtering is permissible provided there is no reduction in required log retention or coverage results.
Operations & Support (SLA)
| 26 |
| SaaS Provider must create regular backups and maintain retrievable exact copies of data deemed critical for business, and to fully restore the system to a known good state, and to meet the prescribed RPO and RTO objectives; and must regularly test backup and recovery processes to validate restoration capabilities |
| Availability & Resilience |
| 27 |
| SaaS Provider must guarantee a complete (all components) application/system(s) uptime of 99.9%. Unplanned downtime must be minimized. |
| Availability & Resilience |
| 28 |
| Recovery Point Objective (RPO): The maximum amount of downtime that the transactional data is not recoverable or lost, and therefore, would need to be reentered: 1-2 hours |
| Availability & Resilience |
| 29 |
| Recovery Time Objective (RTO): The maximum time allowed to restore normal and full operations after a disaster/system disruption (full system down): 2-4 hours |
| Availability & Resilience |
| 30 |
| Data Residency & Sovereignty: SaaS solutions must be served from a location and proximity within US mainland that provides high performance and alternate sites for disaster recovery and business continuity, along with fail-over redundancy/capability separated geographically. Vendor must not transfer RTD Data outside the United States without RTD’s prior written consent, consistent with RTD Supplemental Terms and Conditions (Rev. |
09.2023). The SaaS Provider must clearly disclose all data storage, processing, and backup locations, including any subcontractors or third-party hosting providers, and ensure compliance with RTD data residency requirements at all times Availability & Resilience
| 31 |
| SaaS Provider must ensure that information security controls remain valid and effective at all times, including during adverse situations and/or incidents, consistent with RTD Supplemental Terms and Conditions (Rev. 09.2023). |
| Availability & Resilience |
| 32 |
| SaaS solution must ensure relevant services to comply with accessibility needs and requirements for individuals with physical disabilities and vision impairments (Section 508 of the 1973 Rehabilitation Act (36 Code of Federal Regulations (CFR) Part 1194, 42 CFR 431.206, and 45 CFR Part 80), Web Content Accessibility Guidelines (WCAG) 2.1 (Level AA Conformance), and applicable Colorado state accessibility standards. |
| Accessibility |
| 33 |
| The SaaS solution in production must adhere to a structured release and change management process documented in accordance with RTD Supplemental Terms and Conditions (Rev. 09.2023). The SaaS Provider must provide RTD with advance written notification of updates, scheduled maintenance, and release timelines. The release process must include version-controlled change management enabling traceability and rollback capabilities. Updates must be applied in a manner that minimizes business disruption and ensures compatibility with RTD's existing workflows and integrations, with controlled deployment in a non-production environment required prior to production release. |
| Platform & Architecture |
| 34 |
| SaaS Provider must maintain separation of development, testing, staging, and production environments to control authorized access and reduce risk, consistent with RTD Supplemental Terms and Conditions (Rev. 09.2023). No live RTD Data may be used in any non-production environment. |
| Platform & Architecture |
The SaaS Provider must make available protected and secure development, test, and staging environments throughout the implementation and operational lifecycle to support system configuration, integration, testing, and acceptance activities performed by RTD's designated implementation partner. No live RTD production data may be used in any non-production environment. Access must be provisioned on a need-to-know basis with appropriate role-based controls, consistent with RTD Supplemental Terms and Conditions (Rev. 09.2023).
Platform & Architecture
| 36 |
| The SaaS application must provide device adaptive functionality across desktops, laptops, tablets, and mobile devices by automatically adjusting to the device's form factor. |
| Platform & Architecture |
| 37 |
| The SaaS application must function across platforms (Mac, Windows) and industry standard browsers, regardless of user's operating system. |
| Platform & Architecture |
| 38 |
| The SaaS application must be fully compatible with Enterprise SharePoint and Microsoft M365 commercial version. |
| Platform & Architecture |
| 39 |
| The SaaS provider must ensure that the most recently available version(s) are made available to RTD by the time of deployment for all proposed software, including third-party software. |
| Platform & Architecture |
| 40 |
| The SaaS vendor must only propose a "market proven" commercial-of-the-shelf (COTS) product, which has a strong client base and long-range maintenance and support commitment plans, and with no known end-of-life announcements. |
| Platform & Architecture |
| 41 |
| The SaaS solution must support open standards/architecture, communication protocols, and integration mechanisms to facilitate interoperability, scalability, and upgrades compatibility. |
| Platform & Architecture |
| 42 |
| The SaaS Vendor must avoid proposing any proprietary technologies that require proprietary/specialized expertise; and instead provide market friendly solutions, for which, RTD can rely and draw upon a large pool of resources available from the market. |
| Platform & Architecture |
| 43 |
| The SaaS solution must enable strong out of the box configuration capability, thereby limiting needs to customize. |
| Platform & Architecture |
| 44 |
| The SaaS Provider must natively support zero-downtime or near-zero-downtime operations for updates, maintenance, and configuration changes, with clear documentation of any exceptions and mitigation strategies. |
| Platform & Architecture |
| 45 |
| RTD recognizes that SaaS ERP solutions may operate in a multi-tenant architecture; however, the solution must provide strong logical isolation of tenant data, configurations, and security controls to ensure a tenant-level experience consistent with enterprise security and performance expectations (for example – like an “Isolated Tenant within a Multi-Tenant Environment”). |
| Platform & Architecture |
| 46 |
| SaaS Provider must enable mechanisms to allow RTD System Administrators to routinely monitor, tune, and properly manage system resources (e.g., CPU utilization, memory, bandwidth, storage capacity), consistent with RTD Supplemental Terms and Conditions (Rev. 09.2023). |
| Performance & Scalability |
| 47 |
| SaaS solutions must be able to support both User Capacity (total number of employees, affiliates, and retirees projected over the next 5-10 years) and Transaction Capacity (total number of transactions in the ERP systems projected over the next 5-10 years). The application must be architected for scalability, allowing for both planned workforce growth and unexpected spikes in system usage, such as high-traffic events or emergency communications. The infrastructure must support dynamic scaling without requiring significant downtime or reconfiguration. |
| Performance & Scalability |
| 48 |
| SaaS Provider must provide transparent reporting on user licensing, consumption metrics, and usage patterns, including the ability for RTD to monitor license utilization and optimize subscription costs over time |
| Performance & Scalability |
| 49 |
| SaaS Provider must guarantee an application response time of < 2-3 seconds for standard transactions, 99% of the time (application response/reaction time to a user's action on the application screen). |
| Performance & Scalability |
| 50 |
| SaaS Provider must provide functionality to implement Microsoft Entra single sign-on (SSO) user authentication through federated services (such as Active Directory Federated Service (ADFS) against RTD’s primary repository of credentials. The use of stand-alone repositories of credentials and non-federated authentication must be avoided. |
| Identity & Access Management |
| 51 |
| The SaaS application access and utilization must support a combination of onsite, off site, and off/near-shore workforce model, ensuring proper access and security controls. |
| Identity & Access Management |
| 52 |
| SaaS solution must control an individual user's ability to access records and perform activities/data operations (create, read, update or delete) based on assigned role or role hierarchy. |
| Identity & Access Management |
| 53 |
| SaaS solution must provide functionality to allow configuration of password policies (complexity, expiry/renewal), etc. |
| Identity & Access Management |
| 54 |
| SaaS solution must provide functionality to allow configuration of inactive session screen lock or system logoff. |
| Identity & Access Management |
| 55 |
| SaaS solution security must be designed so that no administrator-level privileges are required for performing routine operational tasks, wherever technically feasible. The application must support individual user IDs and role-based access control, consistent with RTD Supplemental Terms and Conditions (Rev. 09.2023). Secret authentication information must always be protected, and no utilities may be deployed that could bypass established access controls. Users and administrators must be able to independently manage their own credentials, including password creation and reset. |
| Identity & Access Management |
| 56 |
| The SaaS solution pertinent scripts, source code, configuration data, and documentation must be maintained in a version-controlled repository with appropriate access controls. |
| Data Management & Governance |
At all times (during the implementation in development systems, in production systems, and in any archived systems), RTD is the sole owner of data, in perpetuity and exclusively, unrestricted access and distribution rights. SaaS provider must provide RTD with full and complete access to all data without any access restrictions whatsoever. This includes but is not limited to export formats, no punitive extraction fees, continued read-only access during transition, archived license rights, audit trail export, historical entitlement/usage export, and timing/cost for post-termination assistance.
Data Management & Governance
| 58 |
| Any SaaS generated content remains the sole property of RTD and may not be shared externally without prior written authorization. |
| Data Management & Governance |
| 59 |
| The proposed SaaS solution must include a well-defined exit strategy to protect RTD’s long-term interests. Vendors must provide a documented process for data extraction, transition support, cost implications in case of termination for convenience or other reasons that lie on the vendor side and contract termination scenarios, ensuring that RTD retains control over its data and operations. |
| Data Management & Governance |
| 60 |
| SaaS solution must be able to provide a data archival and retrieval solution (data retention) for all historical data (non-production data). |
| Data Management & Governance |
| 61 |
| SaaS solution must have the capability of maintaining accurate records, avoiding discrepancies and inconsistencies. |
| Data Management & Governance |
| 62 |
| SaaS solution must have built-in checks to prevent entry errors, with rules enforcement. |
| Data Management & Governance |
| 63 |
| The SaaS solution must be designed to integrate with RTD’s broader IT ecosystem using API-first principles. All integrations must follow industry standards, support RESTful or event-driven architectures while ensuring that authentication follows enterprise security policies, such as OAuth 2.0, SAML, or OpenID Connect. APIs must be well-documented, structured for reusability, and designed to support interoperability with external applications without imposing vendor lock-in constraints; and including disclosure of any API rate limits, throttling policies, or integration constraints. |
| Integration & Interoperability |
| 64 |
| SaaS solution must have the ability to integrate seamlessly with other technology solutions and emerging AI tools. Integration capabilities must align with enterprise interoperability standards, ensuring that any solution consisting of multiple systems can exchange data reliably and securely. The solution must provide well-documented APIs or other integration mechanisms that support structured data exchange, authentication, and event-driven interactions between components. Proprietary or non-standard integration methods must be avoided. |
| Integration & Interoperability |
| 65 |
| SaaS solution must be able to communicate with external interfaces using web services protocols (e.g., HTTP and SOAP) and API (using web sockets and GraphQL), |
| Integration & Interoperability |
| 66 |
| SaaS solution must reconcile files and data sent by external system to ensure no file is missed and that the data transmission is in the correct format. |
| Integration & Interoperability |
| 67 |
| AI Capabilities Transparency: SaaS provider shall clearly delineate AI/ML capabilities included in the base offering versus optional add-on modules, along with associated pricing and licensing structures, and provide a defined roadmap for future AI/ML feature development, including timelines and enhancements. The solution must also include administrative controls enabling authorized users to enable or disable AI/ML functionalities at a granular level (for example, by module, feature, or user role) to support governance, compliance, and risk management requirements without impacting core system performance. |
| AI & Advanced Capabilities |
| 68 |
| SaaS Provider must ensure that all AI/ML capabilities within the solution adhere to responsible AI principles, including transparency, explainability, data privacy, and human oversight. The solution must provide controls to audit AI-driven decisions, prevent unauthorized data usage for model training, and allow RTD to govern and monitor AI behavior in accordance with applicable regulatory and ethical standards. |
| AI & Advanced Capabilities |
| Technical Submittal F.1 |
| Page i |
image1.png image2.png