GuestVenueCommercePlatformRFP.pdf

Olympic Authority RFP: Enterprise Guest / Venue / Commerce Management Platform

Request for Proposals (RFP) for

Enterprise Guest / Venue / Commerce Management Platform

RFP Release Date: May 6, 2026

RFP Submissions Due: July 17, 2026

TABLE OF CONTENTS

Section 1. Definitions

Section 2. Olympic Regional Development Authority (“Olympic Authority”) Mission and Goals

Section 3. Agreement Term

Section 4. Scope of Procurement

Section 5. Registered Bidders, RFP Timetable and Proposal Submission

Section 6. Designated Contact, RFP Questions and Clarifications, and Proposal Exceptions

Section 7. Content of Proposals

Section 8. Modification / Withdrawal / Rejection of Proposals

Section 9. Contract Clauses and Requirements

Section 10. Evaluation of Proposals

Section 11. Attachments

A. Proposal Forms B. Instructions to Bidders C. Olympic Authority Insurance Requirements D. MWBE Utilization Plan

Section 1. Definitions In addition to the terms capitalized and defined in the body of this RFP, the following terms are defined as set forth below.

1.1 Agreement – The contract awarded to the successful Bidder under the terms of this

RFP.

1.2 Artificial Intelligence (AI) – A machine-based system designed to operate with varying levels of autonomy, including agentic functionality, and that may exhibit adaptiveness after deployment. For explicit or implicit objectives, such as system infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments. For the purposes of this definition, “agentic functionality” means the capability of an AI system to independently or semi-independently plan, initiate, coordinate, select, or execute on ore more tasks or workflows in furtherance of specified objectives, including through the use of connected tools, software, data sources, or other systems.

AI encompasses generative AI, which refers to systems capable of generating content such as text, images, audio, video, code, or other data, in response to prompts or inputs, typically by learning patterns from large datasets.

1.3 Application Programming Interface (API) – A defined set of protocols and tools that allow software systems to communicate, exchange data, and invoke functionality in a secure and standardized manner.

1.4 Best Value – Shall be defined in accordance with New York State Finance Law §163.

“Best Value” means the basis for awarding contracts for services to the Bidder that optimizes quality, cost, and efficiency among responsive and responsible Bidders. Such basis shall reflect, wherever possible, objective and quantifiable analysis. In accordance with this standard, the Olympic Authority will award the Agreement to the responsible and responsive Bidder whose proposal is determined to offer the most advantageous combination of cost, quality, and value-added services, as evaluated against the criteria set forth in this RFP. The award will not be based solely on the lowest price, but on the proposal deemed to provide the best value to the Olympic Authority and the State of New York.

1.5 Bidder(s) – Any person, partnership, firm, corporation or other authorized entity submitting a proposal to the Olympic Authority pursuant to this RFP.

1.6 Cardholder Data Environment (CDE) – The people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data, including any systems connected to such environments, as defined by PCI DSS.

1.7 Contractor – The successful Bidder to whom an Agreement is awarded under the terms of this RFP.

1.8 Entitlement – A digital authorization that grants a guest the right to access a specific lift, venue, event, product, or service during defined conditions.

1.9 Europay, Mastercard, and Visa (EMV) – A global standard for secure payment transactions utilizing embedded microprocessor (“chip”) technology in payment cards and devices. EMV transactions generate dynamic authentication data for each transaction, reducing fraud associated with counterfeit or cloned cards. EMV includes contact (chip insert), contactless (tap), and mobile wallet payment methods.

1.10 Guest Identity – The unique digital identifier or set of identifiers used to recognize a guest across systems and channels and to associate that guest with transactions, credentials, permissions, and preferences.

1.11 Guest Profile – The unified digital record associated with a Guest Identity that aggregates identifying information, transaction history, Entitlements, preferences, loyalty status, and other relevant behavioral or operational data across systems.

1.12 Integration – The process of connecting separate software systems, devices, or platforms to enable the exchange of data and coordinated functionality.

1.13 Model Context Protocol (MCP) – A framework or protocol that enables secure interactions between AI models and external systems, allowing AI agents to retrieve contextual information and, where authorized, perform actions across enterprise systems. References to MCP in this RFP include equivalent interoperability frameworks unless expressly stated otherwise.

1.14 Offline – A system capability that allows continued operation during network outages or disruptions, with secure storage and subsequent synchronization of transaction data once connectivity is restored.

1.15 Olympic Authority – The New York State Olympic Regional Development Authority.

1.16 Pass Pay – A functionality that allows a guest to charge purchases across multiple venues or services to a centralized account associated with the Guest Profile, typically secured through tokenized payment credentials.

1.17 Payment Card Industry Data Security Standard (PCI DSS) – A set of security standards established by the PCI Security Standards Council to protect payment card data during processing, storage, and transmission.

1.18 Point of Sale (POS) – Systems, including hardware and software, used to process in-person transactions, manage product sales, and accept payments at physical locations.

1.19 Point-to-Point Encryption (P2PE) – A validated encryption methodology that encrypts cardholder data from the point of capture (e.g., payment terminal) through transmission to a secure decryption environment, thereby reducing exposure of sensitive data.

1.20 Primary Account Number (PAN) – The full numeric identifier printed or encoded on a payment card that uniquely identifies the cardholder account. PAN is considered sensitive cardholder data and must be protected in accordance with PCI DSS.

1.21 Radio Frequency Identification (RFID) – A wireless technology used to store and transmit data between an embedded chip in a card or device and a reader, commonly used for lift ticket validation and access control.

1.22 Request for Proposals (RFP) – This Request for Proposals.

1.23 Role-Based Access Control (RBAC) – A security framework that restricts system access based on a user’s assigned role within an organization.

1.24 Tokenization – A security process that replaces sensitive cardholder data, including PAN, with a non-sensitive surrogate value (“token”) that has no exploitable meaning outside of a secure token vault. Tokenization reduces PCI DSS scope by eliminating the need for systems to store or process actual card data.

Section 2. Olympic Authority Mission and Goals

The mission of the Olympic Authority is to create economic and social benefit in the Adirondacks and Catskills by operating year-round venues that provide recreational and athletic development opportunities, achieved through a commitment to continuous improvement and emphasis on environmental stewardship, fiscal responsibility, and the delivery of world-class programs and experiences to persons of all ages and abilities.

The Olympic Authority manages, operates, and maintains multiple venues located in Ulster, Warren, and Essex Counties consisting of Belleayre Mountain, Gore Mountain, the Olympic Center and Lake Placid Conference Center, the Olympic Sports Complex at Mt Van Hoevenberg, the Olympic Jumping Complex, and Whiteface Mountain. The Olympic Authority operates these venues under various agreements with the State of New York and municipal entities, ensuring that each facility is maintained to the highest standards and serves as a vital public asset for recreation, tourism, and athletic excellence.

Each venue is maintained to provide a top-tier experience for guests and serve as a showcase for premier events and recreational activities. These venues offer a wide range of year-round activities, including alpine and Nordic skiing, snowboarding, mountain biking, sliding sports, training camps, and large-scale concerts and competitions. As a result, the Olympic Authority’s venues are positioned as cornerstone destinations for both regional and national tourism.

Olympic Authority-managed alpine resort operations encompass base lodges and guest service centers, ski and snowboard rental operations, ski school and instructional programs, retail outlets, food and beverage venues, and RFID-enabled lift access systems. Guests at these resort venues include day ticket holders, season pass holders, lesson participants, rental customers, retail shoppers, and dining guests.

In addition, the Olympic Authority-managed sport and event venues encompass, without limitation, ticketed Nordic skiing operations, winter ice experiences such as bobsled track operations and outdoor speed skating, year-round recreational attractions including zip lines and mountain coaster activities, and indoor sport and entertainment arenas with approximately 1,000-and 8,000-seat capacities. The Olympic Authority also hosts summer music festivals and large-scale public events, along with retail and food and beverage operations associated with these venues. Guests at these venues include activity ticket purchasers, festival attendees, arena event patrons, recreational visitors, and retail and dining customers.

It is the responsibility of the Olympic Authority to generate revenue to support and offset the costs associated with the maintenance and operation of its venues and facilities. A modern enterprise-grade guest, venue, and commerce management platform (the “Platform”) is therefore a critical operational and strategic tool in advancing this mission.

2.1 Strategic Technology Objective

The Olympic Authority seeks to procure and implement a comprehensive, enterprise-grade Platform to serve as the central technology foundation for Guest Identity, transactions, Entitlements, and operational coordination across all Olympic Authority-managed venues, programs, and events.

At a minimum, the Platform must:

a. Enable unified commerce across all applicable sales and service channels, including on-site POS, e-commerce, mobile, and approved third-party Integrations;

b. Support multi-venue, multi-resort operations within a single enterprise architecture;

c. Provide real-time or near real-time Integration with operational systems including access control, food and beverage, rentals, lessons, and retail, as applicable;

d. Facilitate secure, tokenized payment processing aligned with PCI DSS requirements;

and

e. Support scalable, high-availability operations during peak seasonal demand, while maintaining vendor-agnostic interoperability and avoiding dependence on a closed ecosystem.

The Olympic Authority’s objective is to deploy a future-ready Platform capable of supporting evolving guest expectations, operational complexity, and data-driven decision-making over the next decade. The selected Platform must be capable of delivering hyper-personalized guest experiences across all venues and channels and must include AI-driven capabilities that leverage MCP or equivalent frameworks for orchestration, automation, and decision support.

2.2 Existing Technology Environment

The Olympic Authority currently utilizes several operational systems and hardware environments that must be considered in the proposed solution architecture. Bidders may propose Integration strategies, coexistence strategies, or, where expressly permitted by the Olympic Authority, replacement strategies.

For purposes of proposal evaluation, the Olympic Authority will consider Bidder’s ability to interoperate with the following existing or anticipated environments:

a. Website infrastructure (WordPress Multisite preferred);

b. RFID lift access hardware (Axess preferred);

c. Existing admissions, ticketing, and commerce systems, including Accesso Siriusware, Passport, and Showare, where applicable;

d. Existing customer relationship management (“CRM”) platforms, including Inntopia

CRM or other equivalent CRM systems, where applicable;

e. Existing third-party food and beverage platforms, including Accesso Freedom, to the extent such environment remains in use;

f. Existing third-party self-checkout devices, including Mashgin, to the extent such environment remains in use;

g. Inventory management platforms, including DataWorks, where applicable;

h. Accounting and financial systems, including Sage Intacct, where applicable; and

i. Incident management systems, including 1Risk, where applicable.

Where a Bidder proposes a replacement strategy in lieu of Integration with an existing environment, Bidder must clearly identify: (i) the proposed replacement; (ii) implementation impacts; (iii) data migration implications; (iv) contractual or third-party dependencies known to Bidder; and (v) any effect on the Olympic Authority’s operational continuity.

Nothing in this Section shall be construed to require the Olympic Authority to replace any existing third-party system or to guarantee that the Olympic Authority has unilateral authority to direct changes to systems operated by third parties. Bidders must therefore describe how their proposed Platform will interoperate with third-party-operated environments to the extent such environments remain in place during the term of the Agreement.

Section 3. Agreement Term

The Olympic Authority anticipates entering into an Agreement for an initial term of five (5) years (the “Initial Term”). The Agreement may, in the Olympic Authority’s sole discretion and subject to mutual written agreement of the parties and any required approvals, be renewed for up to three

(3) additional terms of five (5) years each (each, a “Renewal Term”).

Section 4. Scope of Procurement

This Section of the RFP identifies the minimum functional, operational, technical, implementation, and security requirements that the proposed Platform will provide. Bidders may propose additional features, enhancements, or alternative technical approaches that support the objectives of this RFP, provided that any departure from a stated requirement is clearly identified. Proposals must demonstrate the Bidder’s capacity, experience, and approach to delivering each of the scope components set forth below, including detailed responses, supporting documentation where applicable, and a proposed timeline for completion of all material phases of the work contemplated by this RFP, including implementation, configuration, Integration, migration, testing, training, deployment, post-launch support, and other relevant project stages. The information provided in response to this Section will directly inform the Olympic Authority’s evaluation under one or more of the scoring categories set forth in Section 10.

The Olympic Authority reserves the right to satisfy the requirements of this RFP through a single award or through multiple awards, if it determines that more than one Bidder is capable of delivering all or part of the required scope and that such approach is in the Olympic Authority’s best interests.

Failure to sufficiently address one or more requirements in this Section may adversely affect a Bidder’s score and, where the omitted requirement is material, may render the proposal non-responsive.

4.1 Scope of Work

The selected Contractor shall be responsible for providing a fully integrated, enterprise-grade Platform and associated services, including but not limited to:

a. Platform software licensing;

b. Cloud-based hosting (Software-as-a-Service [SaaS] delivery strongly preferred);

c. Platform configuration, implementation, testing, deployment, and cutover support;

d. Data migration services, as applicable;

e. Staff training, knowledge transfer, and operational documentation;

f. Ongoing support, maintenance, patches, updates, and service management;

g. Post-implementation stabilization services.

In accordance with the Information Security Breach and Notification Act (“ISBNA”) (NY General Business Law, §889-aa and §889-bb; NY Technology Law, §208), the selected Contractor shall be responsible for complying with the provisions of the ISBNA with respect to any Private Information (as defined in ISBNA) accessed, maintained, processed, stored, or transmitted by Contractor under the Agreement that is within the control of Contractor, either on the Olympic Authority’s information technology systems or Contractor’s information technology systems.

Contractor shall be responsible for the security of any account data or payment-related data that it possesses, stores, processes, or transmits in connection with the performance of the Agreement and for maintaining adequate administrative, technical, and physical safeguards to comply with PCI DSS and all other applicable laws, regulations, and rules. During the Initial Term and any Renewal Term of the Agreement, Contractor shall, upon request, provide reasonable documentation demonstrating its PCI DSS compliance posture and applicable control environment, or whether compliance may be achieved through validated third-party service providers and payment processors within said third-party’s architecture.

In accordance with the Agreement, the selected Contractor shall comply with all current and future Olympic Authority policies, procedures, and requirements applicable to the Platform, the services, and Contractor’s performance under the Agreement, including, without limitation, Olympic Authority policies relating to information security, acceptable use of AI, and any other applicable technology, security, data governance, access, or operational policies, procedures, and standards.

All such policies shall be provided to Contractor and shall be deemed incorporated into and made part of the Agreement. The Olympic Authority reserves the right to modify, amend, supplement, replace, or adopt such policies from time to time, and Contractor shall comply with the then-current versions of all such policies as a continuing obligation under the Agreement, regardless of whether separate notice of any such change is provided. Contractor shall maintain an information security management system based on industry-recognized frameworks and practices appropriate to the services and risks involved and shall furnish related documentation to the Olympic Authority upon request.

4.2 Platform Module Requirements

Bidders must provide responses to each functional capability requirement in Sections 4.3 through

4.13 of this RFP. In responding to each such requirement, the Bidder must indicate whether the capability is:

a. Native (out-of-the-box);

b. Configurable (no code required);

c. Requires Custom Development;

d. Third-Party / Integration Required; or

e. Not Supported

Bidder responses to the functional capability requirements shall be included in the Bidder’s proposal in a clear and organized manner, with each response corresponding to the applicable Section and requirement of this RFP.

Where a Bidder indicates that a capability requires custom development, middleware, third-party tools, separate Integration, or optional licensing, Bidders must also disclose, at minimum:

i. The scope, costs, and complexity of the requirement;

ii. The architectural impact;

iii. Any PCI DSS, privacy, information security, or other compliance implications;

iv. Responsibility for implementation, licensing, support, and ongoing maintenance;

and

v. Any additional cost, time, assumptions, limitations, or third-party dependencies associated with the capability.

The Olympic Authority reserves the right to request further clarification, supporting documentation, or additional detail regarding any functional capability response provided in a proposal.

4.3 Core POS and Platform Capabilities

a. Centralized, enterprise-level database architecture;

b. Multi-resort and multi-venue operational support;

c. RBAC with least-privilege design;

d. Audit logging, configurable permissions by venue / business unit, and disaster recovery

/ business continuity;

e. Offline transaction capability with secure synchronization; and

f. High-availability architecture capable of supporting peak seasonal demand.

4.4 Admissions, Tickets, and Pass Management

a. Integration with existing admissions and ticketing systems, including Siriusware, Showare, or equivalent systems, where applicable. Bidders must describe the proposed integration approach and clearly indicate whether the proposed solution assumes coexistence with, replacement of, or synchronization with an existing system of record, together with any related data migration, workflow, reporting, or operational impacts;

b. Sale and management of daily tickets (online and on-site);

c. Season pass management, including:

i. Multiple tiers and configurable access rules;

ii. Blackout calendars;

iii. Refunds, upgrades, reprints, and transfers; and

iv. Exchanges, partial refunds, waitlists, bundled Entitlements, and scanned-use history

d. Ability to set up and administer payment plans or financing plans for eligible tickets, passes, and other admission products, including configurable installment terms, payment schedules, account status tracking, delinquency handling, suspension or revocation of related access rights for nonpayment, and reporting functionality;

e. Support for multiple pricing tiers and dynamic pricing structures for tickets, passes, and other applicable admission products across multiple venues, including the ability to configure pricing based on factors such as capacity, date, time, demand, product type, guest category, sales channel, and other business rules;

f. Configurable operator access rules governing user permissions for product setup, pricing administration, inventory and availability management, access control configuration, and reporting functions across multiple venues, business units, and operational roles;

g. Venue-specific and multi-venue enterprise-level reporting capabilities for admissions, tickets, passes, pricing, demographics, usage, and related operational data, with configurable access based on user role and business need;

h. Interactive seating map functionality supporting:

i. Fixed seating, including arena bowl seating, premium seating, and suites;

ii. General admission and standing-room configurations;

iii. Multi-configuration venues, including sports, concerts, ceremonies, and other event layouts;

iv. Seat map design and configuration tools for internal staff;

v. Management of multiple venues and seating layouts within a single system;

vi. Real-time seat availability and hold management; and

vii. ADA-compliant seating designation and management;

i. Support for admissions and ticket sales across multiple channels and use cases, including:

i. Online web and mobile sales;

ii. Box office sales;

iii. Kiosk and self-service sales;

iv. Reserved seating selection through interactive seat maps;

v. Digital ticketing, including mobile wallet and QR/barcode functionality;

vi. Print-at-home and physical ticket support;

vii. Group sales and bulk ticketing capabilities;

viii. Season passes, multi-event packages, and bundled offerings;

ix. Configurable pricing tiers by section, row, and seat;

x. Dynamic and demand-based pricing capabilities;

xi. Promotional pricing, discounts, and access codes;

xii. Add-ons and upsells, including parking, concessions, and experiences; and

xiii. Guest account and booking portal functionality, including the ability for guests to review prior purchases and re-book lift tickets, rentals, and other eligible products, where applicable;

j. Real-time ticket validation and anti-fraud protections, including support for handheld and fixed scanning devices and Offline validation capability with synchronization upon reconnection;

k. Ticket transfer, resale, and exchange functionality, where applicable;

l. Guest Profile association with all products; and

m. RFID credential Entitlement management.

4.5 RFID Lift Access Control

a. Integration with Axess or an equivalent RFID lift access system, where applicable.

Bidders must describe the proposed integration approach, system architecture, data flows, responsibility boundaries, third-party dependencies, and any operational limitations or assumptions associated with the proposed solution;

b. Support for:

i. Gate readers and turnstiles;

ii. Fixed and handheld scanners;

c. Real-time Entitlement validation;

d. RFID lift access functionality must integrate with the Platform and support the ability to block, suspend, or deactivate passes, credentials, and related access rights, together with the creation and maintenance of associated access records and audit logs;

e. Offline and degraded-mode operations; and

f. Access logs, audit trails, and exception reporting

4.6 E-Commerce and Online Sales

a. Integration with the Olympic Authority’s website and online sales environment, including WordPress Multisite where applicable. Bidders must clearly describe how the proposed Platform will interact with WordPress, including whether WordPress will be used primarily to display website content, initiate guest transactions, support online commerce functionality, or serve another role in the overall system architecture;

b. Integration with identity verification tools, including ID.me or an equivalent identity verification system, where applicable. Bidders must describe the proposed Integration approach, including authentication workflows, identity verification use cases, exception handling, data flows, third-party dependencies, and any limitations or assumptions associated with the proposed solution;

c. Integration with existing e-commerce, admissions, ticketing, and online booking systems, including Passport, where applicable. Bidders must describe the proposed integration approach and clearly indicate whether the proposed solution assumes coexistence with, replacement of, or synchronization with an existing system of record, together with any related data migration, workflow, guest account, reporting, or operational impacts;

d. Integration or interoperability with applicable CRM environments for guest communication, marketing, account recognition, purchase history, and related e-commerce functionality.

e. Online sales for tickets, passes, rentals, lessons, retail, and bundled packages;

f. Mobile-optimized user experience;

g. Guest Profile creation and management;

h. Support for the recognition, acceptance, and administration of existing in-house card liabilities, including gift cards, Debitware balances associated with season passes, snow guarantee cards, and Valutec balances, where applicable;

i. Guest self-service booking portal functionality that allows guests to access prior transactions and re-book lift tickets, rentals, and other eligible products, where applicable;

j. Promotions and dynamic pricing capabilities; and

k. Inventory and capacity synchronization across all sales channels

4.7 Rental Management

a. Inventory management by category and size;

b. Online reservations with sizing and preference capture;

c. Check-in and check-out workflows;

d. Guest self-service booking portal functionality for the collection and submission of rental-related data, including participant information, sizing, ability, and other information required for rental reservation, check-in, fitting, and equipment assignment workflows;

e. Damage tracking; and

f. Rental fleet maintenance management, including maintenance logs and automated alerts, where available.

4.8 Lesson and Activity Scheduling

a. Group and private lesson management;

b. Tracking ski school instructor certifications, hours, lesson assignments, and incentive-based compensation data, together with export functionality to the Olympic Authority’s payroll system to reduce or eliminate manual payroll data entry; and

c. Online booking, rescheduling, and cancellation functionality.

4.9 Retail POS and Inventory

a. Integration with DataWorks or an equivalent retail inventory system, where applicable.

Bidders must describe the proposed integration approach and clearly indicate whether the proposed solution assumes coexistence with, replacement of, or synchronization with an existing system of record, together with any related data ownership, workflow, reporting, or operational impacts;

b. Full retail POS functionality;

c. SKU and barcode management;

d. Inventory transfers between locations;

e. Vendor and purchase order management; and

f. Returns and exchanges.

4.10 Food & Beverage and Self-Checkout Interoperability

a. Integration with applicable food and beverage systems, including Accesso Freedom where such environment remains in use. Bidders must describe the proposed integration approach, data flows, responsibility boundaries, third-party dependencies, and any limitations or assumptions affecting transactions, reporting, guest data, loyalty functionality, or payment workflows;

b. Real-time or near-real-time interoperability with applicable self-checkout systems, including Mashgin where such environment remains in use. Bidders must describe the proposed integration approach, data flows, responsibility boundaries, third-party dependencies, and any limitations or assumptions affecting transaction processing, reporting, guest data, or payment workflows;

c. Shared or synchronized Guest Identity across systems, as appropriate;

d. Unified or coordinated loyalty and discount application, where supported;

e. Gift card interoperability, where applicable;

f. Pass Pay functionality across staffed POS terminals and self-checkout devices, where applicable;

g. Unified or consolidated reporting across food and beverage and self-checkout transactions; and

h. Bidders must clearly disclose under this Section:

i. The proposed Integration architecture and data flows;

ii. The proposed system of record designation for Guest Identity, loyalty programs, gift cards, and Pass Pay balances;

iii. Any Offline reconciliation processes;

iv. Any PCI DSS scope implications; and

v. The Bidder’s responsibility boundaries and any third-party dependencies.

4.11 Payments and Financial Processing

a. Integration with Sage Intacct, where applicable. Bidders must describe the proposed integration approach, including transaction posting, reconciliation, settlement reporting, data transfer methods, third-party dependencies, and any limitations or assumptions associated with the proposed solution;

b. Integration with fraud detection and fraud prevention tools, including Accertify or an equivalent fraud protection system, where applicable. Bidders must describe the proposed integration approach, including transaction screening, fraud scoring, exception handling, case management, third-party dependencies, and any limitations or assumptions associated with the proposed solution;

c. EMV-compliant payment processing;

d. Support for credit cards, debit cards, and mobile wallets;

e. Tokenized payment processing designed to avoid unnecessary PAN exposure to

Olympic Authority environments or non-CDE systems;

f. Split tenders, refunds, reversals, and related payment management functionality;

g. Real-time authorization support across applicable transaction channels, including POS, e-commerce, and self-checkout, where applicable; and

h. End-of-day settlement, reconciliation, and reporting capabilities.

4.12 Incident Management and Liability Documentation

a. Integration with 1Risk or an equivalent incident management system, where applicable.

Bidders must describe the proposed integration approach and clearly indicate whether the proposed solution assumes coexistence with, replacement of, or synchronization with an existing system of record, together with any related recordkeeping, workflow, reporting, or operational impacts;

b. Electronic creation, submission, storage, and retrieval of incident reports;

c. Configurable incident intake forms for different venue, activity, operational, medical, guest-service, and risk-management use cases;

d. Capture of relevant incident details, including date, time, location, personnel involved, witnesses, narrative descriptions, and associated operational or guest records;

e. Attachment and storage of supporting documentation, including photographs, videos, scanned documents, correspondence, and other evidentiary materials;

f. Electronic execution, collection, storage, and retrieval of AOR acknowledgments, waivers, releases, and other liability-related documentation;

g. Association of incident records and liability documentation with the applicable Guest

Profile, transaction, Entitlement, reservation, lesson, rental, activity, event, or other relevant record, where applicable;

h. Audit trails reflecting creation, modification, access, signature, and retention activity for incident and liability records;

i. RBAC to restrict access to incident records and liability documentation based on job function and business need;

j. Secure retention, export, and retrieval of incident records and liability documentation in accordance with applicable recordkeeping, legal, operational, and risk-management requirements; and

k. Reporting and search functionality to enable retrieval of incidents by date, venue, activity, incident type, guest, employee, or other relevant criteria.

4.13 AI and Future Readiness

a. Real-time personalization of:

i. Product recommendations (tickets, passes, rentals, lessons, retail, and bundled offerings);

ii. Pricing, promotions, and packaging; and

iii. Content and user experience across digital channels;

b. Utilization of:

i. Guest Identity and Guest Profile data;

ii. Behavioral data (purchase history, visitation patterns, preferences); and

iii. Contextual signals (location, time, device, weather conditions, and event schedules);

c. Consistent personalization across all channels, ensuring a unified and seamless guest experience;

d. AI-driven capabilities, including without limitation:

i. Predictive analytics for demand forecasting, capacity management, and guest behavior modeling;

ii. Intelligent recommendations and upsell/cross-sell optimization;

iii. Automated segmentation and audience targeting;

iv. Conversational interfaces (e.g., chatbots or virtual assistants), where applicable;

and

v. Operational decision support for staff and management;

e. The Platform should enable AI experiences capable of:

i. Executing multi-step tasks on behalf of users or operators;

ii. Interacting with multiple systems and data sources; and

iii. Adapting dynamically to changing conditions and inputs;

f. The Platform should be capable of integrating with, or supporting, modern AI interoperability frameworks, including but not limited to MCP or equivalent architectures, to enable:

i. Secure and structured interaction between AI models and enterprise systems;

ii. Retrieval and utilization of contextual data from across the Platform and integrated systems;

iii. Orchestration of workflows across multiple services, modules, and third-party systems; and

iv. Execution of automated or semi-automated actions based on AI-generated insights;

g. Bidders must describe:

i. Whether MCP or comparable frameworks are natively supported, configurable, or require third-party Integration;

ii. The architecture supporting AI model interaction with system data and services;

iii. Controls governing access, permissions, and data security within AI-driven processes; and

iv. How AI-driven orchestration aligns with system of record design principles;

h. The Platform must ensure that all AI-driven functionality operates in accordance with applicable laws, regulations, and industry best practices, including:

i. Data privacy and protection requirements;

ii. Transparency in automated decision-making, where applicable;

iii. Auditability of AI-driven actions and recommendations; and

iv. RBAC governing access to AI capabilities;

i. Bidders must describe governance mechanisms for:

i. Model training and data usage;

ii. Bias mitigation and fairness considerations;

iii. Monitoring, validation, and performance evaluation of AI systems or models;

and

iv. Human-review controls for consequential decisions affecting Olympic Authority data.

For clarity, the Olympic Authority may evaluate certain AI capabilities as innovation or future-readiness features even where such capabilities are not strictly mandatory for responsiveness, unless expressly stated otherwise elsewhere in this RFP.

4.14 PCI DSS Compliance and Payment Security

Bidders must demonstrate alignment with applicable PCI DSS v4.0 requirements and provide sufficient detail and supporting documentation to permit evaluation of the proposed payment security architecture and, where applicable, support independent audit validation. Responses must clearly distinguish among controls performed by the Bidder, controls performed by the Olympic Authority, and controls performed by any Third-Party Service Providers (“TPSPs”).

4.14.1 PCI DSS Compliance Status

a. PCI DSS compliance level, including whether the Bidder is classified as a Merchant or Service Provider, as applicable;

b. Current Attestation of Compliance (“AOC”) and the corresponding Report on Compliance (“ROC”) or Self-Assessment Questionnaire (“SAQ”) type, as applicable;

c. A description of PCI DSS scope, including all in-scope systems, environments, and services relevant to the services proposed to be provided to the Olympic Authority;

d. Validation cadence, including annual assessments, quarterly scans, and other required validation activities;

e. A description of any open findings, compensating controls, exceptions, or identified gaps; and

f. A list of all PCI-relevant services proposed to be provided to the Olympic Authority.

Bidders must also support PCI DSS v4.0-compliant authentication controls for in-scope payment environments, including multi-factor authentication (“MFA”) for all access into the CDE by administrative, supervisory, back-office, IT, remote-access, and other non-cashier user accounts, as applicable.

Bidders must describe the proposed authentication model for cashier and attended POS users, including any PIN- or badge-based authentication, and must identify the controls used to limit such accounts to cashier functions and to prevent access to administrative, supervisory, or other elevated CDE functions.

4.14.2 Responsibility Matrix and Scope Definition

a. A PCI DSS responsibility matrix clearly defining control ownership as between the Bidder, the Olympic Authority, and any TPSPs;

b. Detailed data flow diagrams showing the flow of Cardholder Data (“CHD”) and Sensitive Authentication Data (“SAD”);

c. Identification of all CDE components;

d. Identification of all systems deemed out of scope, together with the basis for such determination; and

e. A description of the controls used to establish, enforce, and maintain PCI DSS scope boundaries.

4.14.3 Scope Minimization and Architecture

Bidders must describe and provide diagrams addressing the following:

a. Network segmentation strategies and enforcement mechanisms;

b. Isolation of the CDE from corporate, guest-facing, and public networks;

c. Methods used to prevent the storage, processing, or transmission of PAN where not required;

d. Use of P2PE and/or Tokenization to reduce PCI DSS scope; and

e. Architectural diagrams reflecting production, development, and test environments.

4.14.4 Tokenization and Data Handling Requirements

a. Confirmation that PAN is not stored, processed, or transmitted outside controlled and validated environments;

b. A description of token generation, format, and uniqueness;

c. Token reuse capabilities across systems and channels, where supported;

d. Token lifecycle management, including creation, storage, rotation, revocation, and expiration; and

e. A description of token vault security and related access controls.

4.14.5 Cryptography and Data Protection

a. Encryption of CHD in transit using strong cryptography, including TLS 1.2 or higher, or any successor standard required by PCI DSS;

b. Encryption of CHD at rest, where applicable;

c. Key management processes, including:

i. Key generation, distribution, storage, rotation, and destruction;

ii. Separation of duties; and

iii. Use of secure cryptographic modules, including hardware security modules (“HSMs”), where applicable; and

d. Controls preventing the storage of SAD after authorization.

4.14.6 Access Control and Authentication

a. RBAC model;

b. Enforcement of MFA for:

i. Administrative access;

ii. Remote access; and

iii. Access to CDE systems;

c. Privileged access management (“PAM”) controls;

d. User provisioning, deprovisioning, and periodic access review processes; and

e. Session management and timeout controls.

4.14.7 Vulnerability Management and Security Testing

a. A documented vulnerability management program;

b. Frequency and scope of internal vulnerability scans;

c. Use of an Approved Scanning Vendor (“ASV”) for external vulnerability scans, where applicable;

d. Penetration testing methodology and cadence, including testing at least annually and after significant changes;

e. Defined remediation timelines for vulnerabilities based on severity; and

f. Patch management processes, including timelines for remediation of critical vulnerabilities and deployment of critical patches.

4.14.8 Logging, Monitoring, and Incident Response

a. Centralized logging of security-relevant events;

b. Log retention in accordance with PCI DSS, including retention for at least one (1) year, with at least three (3) months immediately available;

c. Real-time monitoring, alerting, and anomaly-detection capabilities;

d. Integration capabilities with the Olympic Authority’s security monitoring tools, including security information and event management (“SIEM”) tools, where applicable;

e. A documented incident response plan, including:

i. Communication and escalation protocols;

ii. Forensic investigation support; and

iii. Defined roles and responsibilities;

f. Commitment to notify the Olympic Authority of security incidents within the timeframes required by the Agreement or applicable law.

4.14.9 Secure Software Development and Change Management

a. Secure Software Development Lifecycle (“SDLC”) practices;

b. Use of code security testing tools, including static application security testing

(“SAST”), dynamic application security testing (“DAST”), and dependency scanning, where applicable;

c. Change management processes, including testing, approval, and deployment workflows;

d. Segregation of development, testing, and production environments; and

e. Controls to prevent unauthorized code changes.

4.14.10 Third-Party Service Provider Management

a. A list of all TPSPs involved in delivering the proposed services;

b. PCI DSS compliance status, including current AOC documentation where available, for each TPSP;

c. A description of how PCI DSS responsibilities are contractually allocated to TPSPs;

d. Vendor risk management and due diligence processes; and

e. Controls used to ensure that TPSPs maintain ongoing compliance.

4.14.11 Physical Security and Payment Devices

For POS, EMV, and unattended or self-checkout environments, Bidders must describe the following:

a. Use of PCI-approved and/or validated payment devices, where applicable;

b. Device inventory and tracking processes;

c. Tamper-detection and inspection procedures;

d. Chain-of-custody controls for device deployment, servicing, and replacement; and

e. Physical security requirements applicable to locations containing payment systems or payment devices.

4.14.12 E-Commerce and Payment Page Security

Bidders must demonstrate compliance with applicable PCI DSS v4.0 e-commerce requirements, including the following:

a. Protection against client-side attacks, including script injection;

b. Monitoring and control of payment page scripts;

c. Implementation of security controls such as Content Security Policy (“CSP”), where applicable; and

d. Integrity validation of third-party scripts.

4.14.13 Food & Beverage and Self-Checkout Considerations

Bidders must ensure and describe how the proposed solution supports the following:

a. Payment architecture that does not unnecessarily expand PCI DSS scope in food and beverage or self-checkout environments;

b. Consistent application of tokenized payment handling across all applicable use cases;

and

c. Secure Offline payment processing, including:

i. Encrypted storage;

ii. Controlled synchronization; and

iii. Exception handling and audit logging.

4.14.14 Audit Support and Evidence Requirements

Bidders must commit to the following:

a. Providing updated AOC documentation annually;

b. Providing PCI DSS responsibility matrices, network diagrams, and related supporting documentation upon request;

c. Supporting the Olympic Authority during PCI DSS audits, assessments, and related compliance reviews;

d. Providing evidence reasonably required for the Olympic Authority’s ROC or SAQ, as applicable; and

e. Participating in audit interviews and responding to assessor inquiries, as reasonably requested.

4.15 Reporting, Analytics, and Data Access

a. Standard and configurable reporting:

i. Revenue and sales;

ii. Product performance;

iii. Visitation and lift access; and

iv. Rentals, lessons, retail, and food and beverage;

b. Real-time dashboards; and

c. Secure APIs and data export.

4.16 Technical and Security Requirements

a. Cloud-based SaaS architecture (preferred);

b. High availability and redundancy;

c. Current security certifications, attestations, or reports, including International

Organization for Standardization (ISO 27001 and ISO 27018 if SaaS) and System Organization Controls 2 (SOC 2), where applicable;

d. Secure API framework;

e. Vulnerability management and incident response; and

f. PCI DSS-aligned architecture designed to minimize CDE scope and protect CHD.

4.17 Implementation and Project Management

a. Detailed implementation timeline;

b. Phased rollout strategy, including venue-by-venue or business-line sequencing where applicable;

c. Governance structure, including named roles, escalation paths, and meeting cadence;

d. Training and knowledge transfer plan;

e. Testing, acceptance, and cutover approach;

f. Technical support staffing and service model;

g. Go-live support and stabilization approach;

h. Servicing, repair, maintenance, support, patching, upgrading, and replacement of the proposed Platform solutions, including related hardware and software, whether performed by the Bidder or any third party, together with a description of responsibility allocations, service levels, escalation paths, and third-party dependencies; and

i. Risk identification, mitigation, rollback, and contingency planning.

Section 5. Registered Bidders, RFP Timetable, and Proposal Submission

5.1 Registered Bidders

To become a registered Bidder the following information shall be submitted to the Designated Contact: Organizational Name and Mailing Address, Primary and Secondary Contact Names, Phone Numbers and Email Addresses. A secondary contact is mandatory. Only registered Bidders shall be allowed to submit a proposal.

5.2 RFP Timetable

The following timetable is established for this RFP and is subject to change. The Olympic Authority may extend the due date for proposals by issuance of published addenda to this RFP.

Prior to submitting a proposal, Bidders should check the NY State Contract Reporter website (https://www.nyscr.ny.gov) or the Olympic Authority’s website (https://orda.org/do-business/) to confirm the issuance of any addenda relating to this RFP schedule.

Issuance of RFP: May 6, 2026 Deadline for Submission of Bidder Questions: May 20, 2026 Issuance of Responses to Bidder Questions: June 5, 2026 End of Addenda: June 12, 2026 Proposal Due Date: July 17, 2026

5.3 Proposal Submission

Only proposals from Bidders that furnish all required information and satisfy the mandatory requirements of this RFP will be considered. Proposals must be submitted electronically in PDF format to the Designated Contact(s) identified in Section 6.1, unless the Olympic Authority expressly authorizes an alternative submission format.

If the Olympic Authority permits or requests hard-copy materials, such materials shall be delivered to the mailing address identified in Section 6.1 and must clearly identify the RFP title and the submitting Bidder.

The Olympic Authority will not be not be liable for any costs incurred by a Bidder in preparing or submitting a proposal or for any work performed prior to the execution of an Agreement. Proposals must be received at the above address on or before 4:00 p.m. Eastern Time on the Proposal Due Date set forth in Section 5.2. Timeliness of receipt shall be determined by the Olympic Authority.

Bidders assume all risk of late, incomplete, or misdirected delivery.

LATE PROPOSALS

Any proposal received after the time established for receipt may be rejected as non-responsive.

Notwithstanding the foregoing, the Olympic Authority may, in its sole discretion, consider a late proposal where: (i) no timely proposals meeting the requirements of this RFP are received, or (ii) the Bidder has demonstrated to the satisfaction of the Olympic Authority that the lateness was https://www.nyscr.ny.gov/ https://orda.org/do-business/ caused solely by factors outside the Bidder’s control. The Olympic Authority shall have no obligation to accept a late proposal, and the basis for any decision to do so shall be documented in the procurement record.

FIRM OFFER

Each proposal shall constitute a firm and irrevocable offer for at least forty-five (45) calendar days following the Proposal Due Date, unless that period is extended by mutual written consent of the Olympic Authority and the Bidder. Thereafter, the proposal shall remain effective until the earlier of: (i) the Olympic Authority’s issuance of an Agreement to the successful Bidder; or (ii) written withdrawal by the Bidder, provided such withdrawal has not been made after…