7-Attachment 4 - Technical Architecture and IMS Requirements - Amended.xlsx

XLSX spreadsheet 32 KB Posted Aug 10, 2026

Attached to: Salt Lake City Request for Proposals SLCI26082 Citywide Cashiering and Point of Sale Solution
Solicitation number: SLCI26082
Issued by: Salt Lake County, Salt Lake City, Utah

About this file

Written by GovTribe AI · Sep 29, 2026

This is a Technical Architecture and IMS Requirements attachment for Salt Lake City Corporation's Request for Proposals (SLCI26082) for a Citywide Cashiering and Point of Sale Solution. The City seeks a Software-as-a-Service (SaaS) solution to replace its existing cashiering systems across 8-10 departments (excluding the Department of Airports and Department of Public Utilities). The proposed solution must support comprehensive payment processing capabilities including in-person and online transactions, accepting cash, checks, credit cards, debit cards, ACH payments, and emerging mobile wallet methods. The system must integrate with Chase Paymentech for merchant services, support multiple merchant IDs by department, and accommodate the City's current USB-connected peripherals including 15 check scanners, 15 contactless credit card terminals (Ingencio Desk 3500), 16 receipt printers, and 11 barcode scanners, while also supporting network-addressable (IP-based) devices for future scalability. Critical requirements include single-tenant SaaS deployment (preferred), secure VPN connectivity, Microsoft Entra ID integration with multi-factor authentication, and comprehensive security controls aligned with PCI DSS v4.0, NACHA Operating Rules, and applicable Utah state data protection laws.

The technical requirements emphasize robust cybersecurity governance with NIST CSF/800-53 or ISO 27001 alignment, AES-256 encryption for data at rest and TLS 1.2 or higher for data in transit, immutable and encrypted backups, and Business Continuity/Disaster Recovery plans with 99.9 percent uptime SLAs. The solution must support partial and split-tender payments, partial refunds, same-day voids, and comprehensive chargeback management with fraud detection and prevention capabilities including real-time risk scoring and configurable fraud rules. All City data must remain stored within the continental United States with 60-day advance notice required for data storage location changes. The system must provide audit trails with 12-month retention (3 months online), integration with Workday Financials via RESTful APIs and OAuth 2.0, WCAG 2.1 Level AA accessibility compliance, and support for Utah Consumer Privacy Act (UCPA) obligations including consumer access, deletion, and opt-out rights. The solution must provide daily settlement reporting, reconciliation between transactions and Workday postings, and configurable retention schedules compliant with GRAMA (Government Records Access and Management Act).

View the file

Other files

File	Type	Posted
8-SLCI26082 - Amended 2.docx	DOCX document	Aug 10, 2026
1-Confidential+and+Proprietary+Info+Declaration+Form.pdf	PDF	Aug 10, 2026
6-Attachment 6 - Score Sheet.xls	XLS spreadsheet	Aug 10, 2026
2-Attachment 1 - Sample Agreement.docx	DOCX document	Aug 10, 2026
3-Attachment 3 - Scope of Work.docx	DOCX document	Aug 10, 2026
5-Attachment 7 - System Diagram.pdf	PDF	Aug 10, 2026
4-Attachment 2 - Introduction and Background.docx	DOCX document	Aug 10, 2026
9-Attachment 5 - Cost Sheet - Amended 3.xlsx	XLSX spreadsheet	Aug 10, 2026

On GovTribe

Work with this file

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

Try for free Login

Text version

The file's text, extracted by GovTribe without its formatting.

Technical Requirements

Citywide Cashiering and Point of Sale Solution

Attachment 4 - Technical Architecture and IMS Requirements

	Requirement ID	Topic	Response Type	Requirement	Offeror Response	Offeror Narrative or Additional Comments
	1.1	Governance
	1.1.1	SaaS Solution	Requirement	The proposed Solution is an Offeror hosted SaaS Solution.
	1.1.2	Network Requirements	Requirement	Offeror shall provide a high level detailed architecture diagrams, PCI scope diagrams, integration diagrams, and a clearly defined shared-responsibility matrix.
	1.2	Cyber Security & Networking
	1.2.1	Deployment Model - Solution Type	Narrative	Offeror shall identify whether the proposed Solution is a single tenant SaaS (preferred), multi-tenant Saas, or Hybrid.
	1.2.2	Deployment Model - Secure Connectivity	Requirement	The proposed Solution must support secure connectivity from City facilities via:
•	Site-to-site VPN
•	Private endpoints and/or ExpressRoute where applicable All field locations connect via VPN. The system must operate reliably in VPN-based environments.
	1.2.3	Network Security & Segmentation	Narrative	Offeror shall:
•	Provide logical and physical network diagrams.
•	Identify all inbound and outbound ports and protocols.
•	Enforce TLS 1.2 or higher.
•	Provide Web Application Firewall (WAF) protections.
•	Provide DDoS mitigation capabilities.
	1.2.4	Network Security & Segmentation	Narrative	Because payment devices are not currently segmented at field locations, the Proposer shall:
•	Provide a PCI scope minimization strategy.
•	Describe segmentation controls separating Cardholder Data Environment (CDE) systems.
•	Identify compensating controls if segmentation is not immediately implemented.
	1.3	Microsoft Entra ID Single Sign-On & Multifactor Authentication
	1.3.1	Microsoft Entra ID Single Sign-On & Multifactor Authentication	Requirement	The City uses Microsoft Entra ID as its authoritative identity provider.

The proposed Solution must:

•	Support SAML 2.0 and/or OpenID Connect (OIDC).
•	Support OAuth 2.0 for API authentication.
•	Support SCIM 2.0 for automated provisioning and deprovisioning.
•	Support RBAC mapped to Entra ID groups.
•	Enforce Entra ID Conditional Access policies.
	1.3.2	Multifactor Authentication (MFA)	Requirement	The proposed Solution must:
•	Enforce Microsoft Entra ID MFA.
•	Require MFA for all administrative access.
•	Require MFA for all access into the Cardholder Data Environment (CDE) (PCI Requirement 8).
•	Support phishing-resistant methods (FIDO2 preferred).
	1.3.3	Shared & Kiosk Devices	Requirement	The proposed Solution must support:
•	Intune-managed Windows devices.
•	Shared kiosk environments (identify any restrictions of models supported).
•	Automatic session timeout.
•	Prevention of credential persistence.
	1.4	Peripherals (Point-of-Sale Devices and Network Connectivity)
	1.4.1	Peripherals (Point-of-Sale Devices and Network Connectivity)/Currently Used Devices	Requirement	The proposed Solution shall support a range of standard cashiering peripherals, including but not limited to payment terminals, receipt printers, cash drawers, barcode scanners, and related point-of-sale (POS) devices used across City locations.

The City currently utilizes USB-connected peripheral devices in its existing cashiering environment. The proposed Solution must support USB-connected peripherals. Identify if the proposed solution supports network-addressable (IP-based) devices, which are preferred for future-state flexibility, centralized management, and scalability. The City currently uses these general types and quantities of devices across 8-10 departments:

•	Currently being used with Teller
o	15 Check Scanners
o	15 Contactless Credit Card Terminals - Ingencio Desk 3500
o	16 Receipt Printers
o	11 Barcode Scanners
•	Currently being used with TMS
o	Receipt Printers
o	Credit Card Terminals (mag stripe)
o	Barcode Scanners
o	Check Scanners (post transaction)
	1.4.2	Supported Connectivity Options	Requirement	The Offeror shall support peripherals that operate via:
•	Direct connection (e.g., USB), consistent with the City’s current environment, and/or
•	Network-addressable (IP-based) connectivity
	1.4.3	Supported Connectivity Options	Requirement	The Offeror shall clearly identify:
•	Supported connection types (USB, Ethernet, Wi-Fi)
•	Any limitations or requirements associated with each connectivity method
	1.4.4	Supported and Preferred Peripheral Devices	Requirement	The Offeror shall provide a detailed list of:
•	Supported peripheral devices (fully compatible with the proposed solution), and
•	Preferred or recommended devices that are optimized for performance, security, and long-term support
	1.4.5	Supported and Preferred Peripheral Devices	Narrative	For each device, the Offeror shall include:
•	Manufacturer and model number
•	Device type (e.g., payment terminal, receipt printer, check scanner)
•	Supported connectivity (USB, Ethernet, WiFi)
•	PCI compliance status (for payment devices)
•	Any dependencies (drivers, middleware, firmware requirements)
	1.4.6	Supported and Preferred Peripheral Devices	Narrative	The Offeror shall also identify any devices that are required for full functionality of the solution.
	1.4.7	Network-Addressable Devices	Narrative	For peripherals that support network-based operation, the devices shall:
•	Be capable of operating as standalone, network-addressable device
•	Support IP-based communication over the City’s network
•	Be capable of being assigned a static IP address where required
•	Support remote configuration, monitoring, and diagnostics where available

The Offeror shall describe the advantages and any additional infrastructure requirements associated with network-addressable peripherals.

	1.4.8	Wireless Connectivity Requirements	Narrative	For peripherals that connect via wireless networks, devices must:
•	Support WPA2-Enterprise and/or WPA3 security protocols
•	Support operation on 5 GHz wireless networks
•	Support secure authentication methods consistent with City wireless network policies

The Offeror shall describe any limitations or considerations for deploying peripherals over wireless connections.

	1.4.9	Security and Compliance	Requirement	All payment-related peripherals must:
•	Comply with PCI DSS requirements for secure handling of cardholder data
•	Support end-to-end encryption (E2EE) or Point-to-Point Encryption (P2PE) where applicable
•	Prevent transmission of unencrypted sensitive data across City networks
	1.4.10	Device Management and Support	Narrative	The Offeror shall describe:
•	Methods for provisioning and configuring peripherals
•	Firmware update and patch management processes
•	Remote diagnostics and troubleshooting capabilities
•	Compatibility with City network security controls and segmentation
	1.4.11	Exceptions and Constraints	Narrative	If any required peripherals are limited to a single connectivity method (e.g., USB-only or network-only), the Offeror shall:
•	Clearly identify such limitations
•	Provide justification
•	Describe any operational or support implications
	1.5	Cybersecurity Governance & Insurance
	1.5.1	Cybersecurity Governance	Requirement	Offeror shall maintain:
•	Cybersecurity program aligned to NIST CSF, NIST 800-53, ISO 27001, or equivalent.
•	Annual risk assessments.
•	Documented vulnerability and patch management program.
	1.5.2	Insurance	Requirement	Offeror shall maintain insurance as described in Attachment 1 - Sample Agreement.
	1.6	Payment Processing & Merchant Services
	1.6.1	Supported Payment Methods (Core Requirements Only) Required Capabilities	Requirement	The proposed Solution must support in-person cashier payments.
	1.6.2	Supported Payment Methods (Core Requirements Only) Required Capabilities	Requirement	The proposed Solution must support online payment processing.
	1.6.3	Supported Payment Methods (Core Requirements Only) Required Capabilities	Requirement	The proposed Solution must accept:
o	Cash
o	Check
o	Credit card
o	Debit card
o	ACH (electronic check)
	1.6.4	Supported Payment Methods (Core Requirements Only) Required Capabilities	Requirement	The proposed Solution should support emerging payment methods such as mobile wallets (e.g., Apple Pay, Google Pay).
	1.6.5	Supported Payment Methods (Core Requirements Only) Required Capabilities	Requirement	The proposed Solution must allow partial payments.
	1.6.6	Supported Payment Methods (Core Requirements Only) Required Capabilities	Requirement	The proposed Solution shall allow departments to configure which payment channels (e.g., in-person, online, kiosk, IVR, mobile) are available for specific fee types, services, or transaction types.
	1.6.7	Supported Payment Methods (Core Requirements Only) Required Capabilities	Requirement	The proposed Solution must allow split-tender transactions.
	1.6.8	Supported Payment Methods (Core Requirements Only) Required Capabilities	Requirement	The proposed Solution must generate a receipt, print, reprint and email the receipts for all payment types.
o	Receipts shall include transaction ID, payment method, amount, date/time, department, and payment breakdown(including any surcharge as a separate line item).
	1.6.9	Partial Payment Processing	Requirement	The proposed Solution must allow partial payments against an outstanding balance when permitted by City policy.
	1.6.10	Partial Payment Processing	Requirement	The proposed Solution must allow partial payments using any supported payment type, including:
o	Credit card
o	Debit card
o	ACH
o	Check
o	Cash
	1.6.11	Partial Payment Processing	Requirement	The proposed Solution must maintain the remaining balance due after a partial payment is processed.
	1.6.12	Partial Payment Processing	Requirement	The proposed Solution must record the original amount due, the payment amount applied, and the remaining balance.
	1.6.13	Partial Payment Processing	Requirement	The proposed Solution must support multiple partial payments over time until the balance is fully paid.
	1.6.14	Partial Payment Processing	Requirement	The proposed Solution must prevent overpayment beyond the total amount due.
	1.6.15	Partial Payment Processing	Requirement	The proposed Solution should allow departments to configure whether partial payments are allowed for specific fee types or services.
	1.6.16	Partial Payment Processing	Requirement	The proposed Solution shall support corresponding partial refund functionality consistent with partial payment processing.
	1.6.17	Merchant Services and Processing Model	Requirement	The City will continue using its current merchant services provider. The proposed Solution must integrate with an existing merchant services provider (Chase Paymentech).
	1.6.18	Merchant Services and Processing Model	Requirement	The proposed Solution must support multiple merchant IDs if required.
	1.6.19	Merchant Services and Processing Model	Requirement	The proposed Solution should allow merchant IDs to be assigned by department/division.
	1.6.20	Merchant Services and Processing Model	Requirement		The proposed Solution shall allow the Treasurer’s Office to centrally manage merchant account configurations across departments.
	1.6.21	Credit Card, Debit Card, and ACH Processing	Requirement	The proposed Solution must support EMV-compliant card processing (chip enabled, dip or tap).
	1.6.22	Credit Card, Debit Card, and ACH Processing	Requirement	The proposed Solution must support ACH payment processing in compliance with NACHA operating rules, including authorization, return handling, and transaction processing requirements.
	1.6.23	Credit Card, Debit Card, and ACH Processing	Requirement	The proposed Solution must encrypt payment data in transit.
	1.6.24	Credit Card, Debit Card, and ACH Processing	Requirement	The proposed Solution must prevent storage of sensitive card data within City systems.
	1.6.25	Credit Card, Debit Card, and ACH Processing	Requirement	The proposed Solution shall comply with PCI DSS requirements for all card payment processing.
	1.6.26	Credit Card, Debit Card, and ACH Processing	Requirement	The proposed Solution shall support handling of failed or declined payments, including retry and alternative payment options.
	1.6.27	Voids, Refunds, Chargebacks, and Check Voids	Requirement	The proposed Solution must allow same-day voids.
	1.6.28	Voids, Refunds, Chargebacks, and Check Voids	Requirement	The proposed Solution must allow refunds with appropriate security controls.
	1.6.29	Voids, Refunds, Chargebacks, and Check Voids	Requirement	The proposed Solution must maintain an audit trail of all voids and refunds.
	1.6.30	Voids, Refunds, Chargebacks, and Check Voids	Requirement	The proposed Solution should allow configurable approval thresholds.
	1.6.31	Voids, Refunds, Chargebacks, and Check Voids	Requirement	The proposed Solution must allow a single check to be voided within a transaction that contains multiple checks.
	1.6.32	Voids, Refunds, Chargebacks, and Check Voids	Requirement	The proposed Solution shall associate chargebacks to original transactions.
	1.6.33	Voids, Refunds, Chargebacks, and Check Voids	Requirement	The proposed Solution shall support configurable approval workflows for voids, refunds, and adjustments.
	1.6.34	Partial Credit Card Refund	Requirement	The proposed Solution must allow authorized users to process partial credit card refunds for previously completed transactions.
	1.6.35	Partial Credit Card Refund	Requirement	The proposed Solution must ensure that the total refunded amount cannot exceed the original payment amount.
	1.6.36	Partial Credit Card Refund	Requirement	The proposed Solution must enforce refund-to-original-tender, meaning partial refunds must be issued back to the same credit card used for the original transaction unless an authorized override is applied.
	1.6.37	Partial Credit Card Refund	Requirement	The proposed Solution must update the remaining refundable balance associated with the original transaction after a partial refund is processed.
	1.6.38	Partial Credit Card Refund	Requirement	The proposed Solution must allow staff to print an adjusted receipt or generate a new receipt reflecting the partial refund and any associated fee adjustments.
	1.6.39	Partial Credit Card Refund	Requirement	The proposed Solution must automatically calculate and refund with the partial refund.
	1.6.40	ACH Returns and Returned Checks	Requirement		The proposed Solution must allow returned ACH transactions to be recorded.
	1.6.41	ACH Returns and Returned Checks	Requirement		The proposed Solution must support reversal of related accounting entries.
	1.6.42	ACH Returns and Returned Checks	Requirement	The proposed Solution must allow City to assess return fees for check and EFT.
	1.6.43	ACH Returns and Returned Checks	Requirement		The proposed Solution must track returned payments by customers and department.
	1.6.44	ACH Returns and Returned Checks	Requirement		The proposed Solution shall track ACH return codes and support reporting for returned transactions.
	1.6.45	Credit Card Surcharging and Fee Collection	Requirement	The City applies a surcharge on transactions in which a credit card is used, in accordance with State law and City policy.

The proposed Solution must support configurable credit card surcharge fees.

	1.6.46	Credit Card Surcharging and Fee Collection	Requirement	The proposed Solution must disclose fees prior to customer authorization.
	1.6.47	Credit Card Surcharging and Fee Collection	Requirement	The proposed Solution must record surcharge fees separately from the base payment amount
	1.6.48	Credit Card Surcharging and Fee Collection	Requirement	The proposed Solution should allow fee configuration by department.
	1.6.49	Ordinance-Based Fee Exemptions	Requirement	Certain payments may be exempt from fees. The proposed Solution must allow fee exemptions by transaction type or department.
	1.6.50	Ordinance-Based Fee Exemptions	Requirement	The proposed Solution must maintain an audit trail of fee exemptions.
	1.6.51	Ordinance-Based Fee Exemptions	Requirement	The proposed Solution should allow supervisor approval for fee overrides.
	1.6.52	Ordinance-Based Fee Exemptions	Requirement		The proposed Solution shall support reporting on all fee exemptions and overrides.
	1.6.53	Deposit Timing, Settlement, and Reconciliation (High-Level Only)	Requirement	The proposed Solution must provide daily settlement reporting.
	1.6.54	Deposit Timing, Settlement, and Reconciliation (High-Level Only)	Requirement	The proposed Solution must create deposit totals by merchant account.
	1.6.55	Deposit Timing, Settlement, and Reconciliation (High-Level Only)	Requirement	The proposed Solution must support export of settlement data for reconciliation.
	1.6.56	Deposit Timing, Settlement, and Reconciliation (High-Level Only)	Requirement	The proposed Solution shall support reconciliation between cashiering transactions, merchant settlement, and postings to Workday.
	1.6.57	Deposit Timing, Settlement, and Reconciliation (High-Level Only)	Requirement	The proposed Solution shall provide traceability between individual transactions, settlement batches, and deposit totals.
	1.6.58	Deposit Timing, Settlement, and Reconciliation (High-Level Only)	Requirement	The proposed Solution shall support identification and tracking of discrepancies between transaction totals and settlement amounts.
	1.6.59	Deposit Timing, Settlement, and Reconciliation (High-Level Only)	Requirement	The proposed Solution shall support inclusion of externally imported transactions in reconciliation and settlement reporting.
	1.6.60	Testing and Production Environments (Credit Card, Debit Card, ECheck, and Check Payments)	Requirement	The Offeror must provide a Testing Environment that allows the City to test system functionality without impacting live financial transactions. The test environment must be an updated live replica of production.
	1.6.61	Testing and Production Environments (Credit Card, Debit Card, ECheck, and Check Payments)	Requirement	•	The testing environment must support testing of:
o	Payment workflows
o	Refund and adjustment procedures
o	Integration with other City systems
o	Configuration changes
	1.6.62	Testing and Production Environments (Credit Card, Debit Card, ECheck, and Check Payments)	Requirement		The testing environment should allow the use of simulated payment data and test transactions.
	1.6.63	Testing and Production Environments (Credit Card, Debit Card, ECheck, and Check Payments)	Requirement		The Offeror must ensure testing activities cannot impact production financial data.
	1.6.64	Testing and Production Environments (Credit Card, Debit Card, ECheck, and Check Payments)	Requirement	The proposed Solution should support testing of configuration changes and integrations prior to deployment in production.
	1.7	Security, Compliance, and Risk Management
	1.7.1	Security, Compliance, and Risk Management	Requirement	The proposed Solution must comply with:
•	Payment Card Industry Data Security Standard (PCI DSS) (current version, v4.0 or later)
•	National Automated Clearing House Association (NACHA) Operating Rules
•	Utah Data Breach Notification Act (Utah Code § 13-44-101 et seq.)
•	Utah Government Records Access and Management Act (GRAMA), Utah Code § 63G-2
•	Utah State Archives and Records Service Act, Utah Code § 63A-12
•	Utah Cybersecurity Affirmative Defense Act, Utah Code § 78B-4-701 et seq.
•	Utah Consumer Privacy Act (UCPA), Utah Code § 13-61-101 et seq.
	1.7.2	Data Residency and Sub Processors	Requirement	Offeror shall store all City data within the continental United States.
	1.7.3	Data Residency and Sub Processors	Requirement	Offeror shall identify all sub processors.
	1.7.4	Data Residency and Sub Processors	Requirement	Offeror shall provide advance notice of sixty (60) days of data storage location changes to the Treasurer's Office .
	1.7.5	Data Portability & Termination	Requirement	Upon termination of contract, the award Offeror shall:
•	Provide complete data export in machine-readable format.
•	Provide data schema documentation.
•	Certify destruction of City data upon written authorization.
	1.7.6	Data Loss Prevention & Exfiltration Controls	Requirement	The awarded Offeror shall implement comprehensive DLP controls to prevent unauthorized access, disclosure, or exfiltration of sensitive data.

The proposed Solution must:

•	Mask PAN (display last four digits only).
•	Mask ACH account numbers except where operationally required.
•	Restrict export permissions by role.
•	Log and alert on bulk data exports.
•	Enforce scoped API permissions and rate limiting.
•	Prevent caching sensitive data on endpoints.
•	Support compatibility with Microsoft Intune, and Defender for Endpoint where applicable.
•	Maintain tamper-evident logs of sensitive data access.
	1.7.7	Data Loss Prevention & Exfiltration Controls	Requirement	Offeror shall not use, monetize, or share City data without written authorization.
	1.7.8	Utah Breach Notification & Incident Response	Requirement	Offeror shall comply with Utah Code § 13-44-101 et seq.
	1.7.9	Utah Breach Notification & Incident Response	Requirement		Offeror must notify the City within 24 hours of:
o	Unauthorized access
o	Ransomware
o	Compromise of payment or ACH data
	1.7.10	Utah Breach Notification & Incident Response	Requirement	Offeror shall:
•	Not independently notify affected individuals.
•	Support Attorney General notification when 500+ Utah residents are affected.
•	Provide draft notification materials.
•	Provide credit monitoring services if required.
	1.7.11	Encryption & Cryptographic Controls	Requirement	The Offeror shall implement and maintain strong cryptographic controls to protect all sensitive data processed, transmitted, or stored in connection with the Citywide Cashiering System.

Sensitive data includes, but is not limited to:

•	Cardholder data (PCI)
•	ACH routing and account numbers
•	Personally Identifiable Information (PII)
•	Financial transaction records
•	Authentication credentials and tokens
•	Backup and archival data
	1.7.12	Data at Rest Encryption	Requirement	The proposed Solution must:
•	Encrypt all sensitive data at rest using AES-256 or equivalent strong cryptography.
•	Utilize cryptographic modules validated to FIPS 140-2 or FIPS 140-3.
•	Encrypt databases, file storage, backups, and replicated storage.
•	Prohibit storage of CVV, PIN, or full magnetic stripe data.
•	Support tokenization for stored payment references.
	1.7.13	Data at Rest Encryption	Requirement	For multi-tenant SaaS environments, the Offeror shall ensure logical tenant isolation and encryption of data unique to the City.
	1.7.14	Data in Transit Encryption	Requirement	The proposed Solution must:
•	Enforce TLS 1.2 or higher (TLS 1.3 preferred).
•	Disable insecure protocols and cipher suites.
•	Support secure VPN connectivity for City locations.
•	Support mutual TLS (mTLS) for system-to-system integrations where feasible.
•	Prevent protocol downgrade attacks.

All API integrations, including Workday integrations, must use encrypted transport mechanisms.

	1.7.15	Cryptographic Key Management	Requirement	The Offeror shall implement formal key management practices consistent with NIST SP 800-57 and PCI DSS requirements.
	1.7.16	Cryptographic Key Management	Requirement	The proposed Solution must:
•	Store encryption keys separately from encrypted data.
•	Utilize Hardware Security Modules (HSM) or cloud-native equivalent.
•	Enforce key rotation policies.
•	Enforce separation of duties for key management.
•	Prohibit storage of encryption keys in application source code.
•	Provide documented key revocation and destruction procedures.
	1.7.17	Backup & Replication Encryption	Requirement	The Offeror shall ensure:
•	Encryption of all backups at rest.
•	Encryption of database snapshots.
•	Encryption of replicated and archived storage.
•	Protection of backups using immutable storage controls.
•	Secure key management for backup encryption keys.
	1.7.18	Payment Device Encryption	Requirement	Payment terminals must:
•	Support PCI-approved P2PE or end-to-end encryption.
•	Ensure that cardholder data is encrypted immediately upon entry.
•	Prevent unencrypted PAN from traversing City networks.
	1.7.19	Cryptographic Governance	Requirement	The Offeror shall:
•	Document encryption standards and algorithms used.
•	Provide evidence of cryptographic compliance during security reviews.
•	Notify the City of any cryptographic vulnerability affecting the system.
•	Maintain procedures for rapid cryptographic algorithm replacement if required by industry standards.
	1.7.20	Fraud Prevention and Chargeback Management	Requirement	The Offeror shall provide comprehensive fraud prevention, detection, and chargeback management capabilities for all payment channels supported by the proposed Citywide Cashiering System, including card-present, card-not-present, online, ACH, and any future digital payment methods.
	1.7.21	Fraud Prevention and Chargeback Management	Requirement	The proposed Solution must implement risk-based fraud controls designed to reduce financial loss, minimize operational burden, and protect residents while maintaining compliance with PCI DSS v4.0 and NACHA Operating Rules.
	1.7.22	Fraud Prevention and Chargeback Management	Requirement	At a minimum, the Offeror shall provide:
•	Real-time fraud detection and transaction risk scoring.
•	Configurable fraud rules (velocity checks, dollar thresholds, geolocation anomalies, device fingerprinting, duplicate detection, and high-risk BIN/country controls).
•	Address Verification Service (AVS) and CVV validation for card-not-present transactions.
•	3-D Secure (2.x) support for e-commerce transactions, where applicable.
•	Account validation controls for ACH transactions (e.g., micro-deposit verification or real-time account validation).
•	Configurable transaction limits by department, channel, or payment type.
•	Automated blocking or step-up authentication for high-risk transactions.
	1.7.23	Fraud Prevention and Chargeback Management	Narrative	The Offeror shall describe:
•	Fraud monitoring tools and dashboards available to City staff.
•	Alerting and case management workflows.
•	Ability to suspend accounts or payment privileges.
•	Integration of fraud data into audit logs and SIEM systems.
•	Reporting capabilities, including fraud rate metrics, false positive rates, and trend analysis.
	1.7.24	Chargeback Management	Requirement	The proposed Solution must support end-to-end chargeback management, including:
•	Automated receipt and tracking of chargeback notifications.
•	Workflow management for evidence collection and dispute response.
•	Ability to assess return fees.
•	Integration with acquiring banks and payment processors.
•	Configurable templates for representment documentation.
•	Reporting on chargeback ratios, win/loss rates, and aging.
•	Identification of root causes contributing to chargebacks.
	1.7.25	Chargeback Management	Narrative	The Offeror shall identify:
•	Whether fraud liability is shifted under 3-D Secure or other mechanisms.
•	Responsibilities of Offeror vs. City in managing disputes.
•	SLA commitments for chargeback response timelines.
•	Any additional fees associated with fraud tools or dispute management services.
	1.7.26	Chargeback Management	Narrative	The Offeror shall describe commercially reasonable fraud prevention practices consistent with NACHA requirements and industry best practices and shall notify the City of emerging fraud trends or material increases in fraud risk affecting the system.
	1.7.27	Audit Trails and Logging	Narrative	The Offeror must identify which of the following are currently supported or will be supported by the end of implementation:
•	Maintain centralized logging.
•	Log authentication events, administrative actions, payment transactions, ACH activity, configuration changes, and API calls.
•	Retain logs for minimum 12 months, with at least 3 months immediately available online (PCI DSS v4.0 Requirement 10).
•	Provide real-time alerting for suspicious activity, bulk exports, and privilege escalation.

Logs must be tamper evident.

	1.7.28	Business Continuity and Disaster Recovery	Requirement	The Offeror shall maintain and document a comprehensive Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) designed to ensure the availability, integrity, and recoverability of the Citywide Cashiering System and all associated data and integrations.
	1.7.29	Business Continuity and Disaster Recovery	Requirement	The Offeror shall ensure that critical payment processing, ACH processing, and financial posting functions remain available or are recoverable within defined time objectives in the event of system failure, cyber incident, infrastructure outage, or natural disaster.
	1.7.30	Business Continuity and Disaster Recovery	Requirement	At a minimum, the Offeror shall:
•	Maintain documented BCP and DRP policies aligned to recognized industry frameworks (e.g., NIST, ISO 22301, or equivalent).
•	Define and commit to Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for:
o	Payment processing
o	ACH processing
o	Workday integrations
o	Reporting and reconciliation functions
•	Provide minimum uptime SLA of 99.9% or higher.
•	Deploy high availability architecture with redundancy at the infrastructure, application, and database layers.
•	Support multi-zone deployment (and multi-region failover preferred).
•	Ensure encrypted and immutable backups.
•	Test disaster recovery procedures at least annually.
•	Provide summary results of the most recent DR test upon request.
	1.7.31	Business Continuity and Disaster Recovery	Narrative	The Offeror shall describe:
•	Primary and secondary hosting locations.
•	Failover mechanisms and automated recovery capabilities.
•	Estimated restoration timelines following various disruption scenarios.
•	Manual fallback procedures for cashiering operations in the event of extended outage.
•	Communication protocols during service disruption.
•	Coordination procedures with City IT during incident response.
	1.7.33	Business Continuity and Disaster Recovery	Requirement	The Offeror shall notify the City within 24 hours of any event triggering disaster recovery activation and shall provide ongoing status updates until full-service restoration. Failure to maintain adequate business continuity and disaster recovery capabilities may be grounds for contract termination.
	1.7.34	Protection of Cardholder Data	Requirement	The proposed Solution must:
•	Render PAN unreadable using strong cryptography (FIPS 140-2 validated).
•	Prohibit storage of CVV, PIN, or full track data.
•	Provide tokenization capability.
•	Enforce secure retention and deletion policies.
	1.7.35	Secure Transmission	Requirement	The proposed Solution must:
•	Enforce TLS 1.2+.
•	Disable insecure cipher suites.
	1.7.36	Secure Development & Testing	Narrative	Offeror will identify which of the following software development and testing practices are supported:
•	Follow secure Software Development Life Cycle (SDLC) practices.
•	Undergo Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) testing.
•	Conduct quarterly vulnerability scans.
•	Conduct annual penetration testing.
•	Conduct annual segmentation testing where applicable.
	1.7.37	Incident Response	Requirement	Offeror shall:
•	Maintain documented incident response procedures.
•	Notify the City within 24 hours of suspected compromise.
•	Engage PCI-approved forensic investigators when required.
	1.7.38	Record Retention & Public Records Compliance/GRAMA	Requirement	All City data remains property of Salt Lake City.
	1.7.39	Record Retention & Public Records Compliance/GRAMA	Requirement	Offeror shall comply with GRAMA (Utah Code § 63G-2).
	1.7.40	Record Retention & Public Records Compliance/GRAMA	Requirement	The proposed Solution must:
•	Support configurable retention schedules.
•	Support legal hold functionality.
•	Maintain immutable audit trails.
•	Support exports in non-proprietary formats.
•	Prevent unauthorized deletion or destruction.
	1.7.41	Record Retention & Public Records Compliance/GRAMA	Requirement	Offeror shall not destroy City data without written authorization.
	1.7.42	Accessibility and ADA Compliance	Requirement	The proposed Solution shall comply with applicable accessibility requirements of the Americans with Disabilities Act (ADA), Section 504 of the Rehabilitation Act of 1973, Section 508 of the Rehabilitation Act, and other applicable federal and State of Utah accessibility requirements. The City requires that the proposed cashiering solution be accessible to City staff, residents, customers, and other users with disabilities.
	1.7.43	Accessibility and ADA Compliance	Requirement	At a minimum, the proposed Solution, including all user interfaces, customer-facing payment portals, administrative interfaces, self-service functions, mobile-responsive interfaces, and integrated components, shall conform to the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA standards.
	1.7.44	Accessibility and ADA Compliance	Narrative	The Offeror shall describe how accessibility has been incorporated into the design, development, testing, and ongoing maintenance of the proposed solution.
	1.7.45	Accessibility Requirements	Requirement	The proposed Solution shall:
•	Support keyboard-only navigation without requiring a mouse or touchscreen.
•	Support compatibility with commonly used assistive technologies, including screen readers.
•	Provide sufficient color contrast and visual accessibility features consistent with WCAG 2.1 Level AA.
•	Support scalable text and responsive layouts without loss of functionality.
•	Provide accessible error messaging, form labels, and navigation structures.
•	Avoid reliance solely on color, sound, or visual cues to convey information.
•	Support accessible authentication workflows where feasible.
	1.7.46	Accessibility Requirements	Narrative	The Offeror shall identify any known accessibility limitations or exceptions.
	1.7.47	NACHA ACH Processing & Compliance	Requirement	The proposed Solution must comply with current NACHA Operating Rules.
	1.7.48	ACH Data Protection	Requirement	The proposed Solution must:
•	Encrypt routing and account numbers in transit and at rest.
•	Restrict access to authorized personnel.
•	Log all ACH data access.
	1.7.49	ACH Data Protection	Requirement	Offeror shall conduct:
•	Annual ACH Security Audit.
•	Annual ACH Risk Assessment.
	1.7.50	Fraud Controls	Requirement	The proposed Solution must provide:
•	Velocity controls.
•	Duplicate detection.
•	Dollar threshold alerts.
•	Account validation mechanisms.
•	Return code processing (R01–R85).
•	Dual control for ACH batch release (preferred).
	1.7.51	Authorization Retention	Requirement	The proposed Solution must retain ACH authorizations for minimum two (2) years or longer per City retention policy.
	1.7.52	Workday Integration	Requirement	The proposed Solution must:
•	Provide real-time API-based integration with Workday Financials.
•	Use RESTful APIs and OAuth 2.0.
•	Support idempotent transaction processing.
•	Provide reconciliation workflows.
	1.7.53	Utah Consumer Privacy Act (UCPA)	Requirement	The Offeror shall comply with the Utah Consumer Privacy Act (UCPA), Utah Code § 13-61-101 et seq., effective December 31, 2023, to the extent applicable to the services provided under this Contract.
	1.7.54	Utah Consumer Privacy Act (UCPA)	Requirement	The Offeror shall implement and maintain appropriate administrative, technical, and physical safeguards to protect personal data processed on behalf of Salt Lake City Corporation (“City”) and shall process such data solely for authorized governmental purposes.
	1.7.55	Utah Consumer Privacy Act (UCPA)	Requirement	The Offeror shall support the City in fulfilling consumer rights established under UCPA, including the right to access, delete, and obtain a copy of personal data, and the right to opt out of targeted advertising or the sale of personal data, where applicable.
	1.7.56	Utah Consumer Privacy Act (UCPA)	Requirement	The Offeror shall not sell personal data, use personal data for targeted advertising, or process personal data beyond the scope of services authorized by the City without prior written consent.
	1.7.57	Utah Consumer Privacy Act (UCPA)	Requirement	The Offeror shall:
•	Enter into a written data processing agreement as required under UCPA.
•	Ensure that personal data is subject to appropriate confidentiality obligations.
•	Implement data minimization and purpose limitation principles.
•	Provide reasonable assistance to the City in responding to verified consumer requests within statutory timelines.
•	Notify the City without unreasonable delay of any unauthorized access to personal data, consistent with Utah Code § 13-44-101 et seq.
•	Flow down UCPA obligations to any subcontractors or sub processors that process City data.
	1.7.58	Utah Consumer Privacy Act (UCPA)	Narrative	The Offeror shall describe its UCPA compliance program, including internal policies, training, risk assessments, and controls implemented to safeguard personal data.
	1.8	Optional Features, Customizations, and Enhancements
	1.8.1	Offeror may add additional lines as needed.	Narrative
	1.8.2
	1.8.3
	1.8.4
	1.8.5
	1.8.6
	1.8.7
	1.8.8
	1.8.9

Formulas

Public Body can complete task or Ticket/Support Required	Offeror Response
Public Body	Base Functionality - Proposed Version
Ticket Needed	Base Functionality - Upcoming Version
	New Modification Required
	Cannot Meet Requirements

File details come from the government source that posted it. Updated Sep 29, 2026.