Exhibit A - Functional Specifications.pdf

Exhibit A

FUNCTIONAL SPECIFICATIONS

For each module or functional component of a comprehensive VRM system, the Respondent must provide both a macro‑level and a micro‑level response. The topics included in this section are:

1. Voter Module (Registration)

2. Election Setup and Candidate/Petition Module(s)

3. Absentee Voting Module

4. Poll Worker Module

5. Logistics (Polling Locations)

6. Information Services and Technology o Public Website Widget Documentation o Backup and Disaster Recovery

The macro‑level responses should be written in narrative form. There is no space limitation on the content that a Respondent may provide. These questions are intended to provide the

Respondent with an opportunity to:

• Demonstrate their understanding of, and experience with, the functional areas relevant to a complex and large‑scale board of elections.

• Address all applicable aspects of the topic and include any additional information the Respondent considers relevant to the County.

• Provide answers that clearly convey the usefulness and quality of the

Respondent’s solution.

The micro‑level responses allow the County to identify specific functions or tasks it considers important to the VRM System and give the Respondent the opportunity to respond in more detailed, technical terms. As with the macro‑level responses, there is no space limitation on the content that may be included for the micro-level responses.

VOTER MODULE (REGISTRATION)

Macro-Level

Describe, and provide screenshots where applicable, how the Voter module is accessed within the system’s overall navigation structure and how it relates to other modules. The response should explain how voter records interact with other functional components of the VRM System

(e.g., Poll Worker, Absentee, Polling Locations), including any shared data elements, real-time updates, or cross module validations.

Detail, and provide screenshots to illustrate, how both online and paper voter registrations are entered, processed, and maintained in the VRM System, and how the VRM System identifies and prevents the merging of duplicate records.

Demonstrate how to access the provisional portion of the Voter module and describe how this tool is used to validate provisional ballots.

Micro-Level

Please address each bulleted item below. Items are grouped into subcategories within the Voter module. Respondents are encouraged to include screenshots and/or examples to support their responses.

Data Entry/Maintenance

• Safeguards/prompts that reduce chances of data entry error.

• Procedure(s) to identify voters with a street exception (e.g., commercial, P.O. Box, bad address).

• Mechanism to incorporate un-processable registration cards/information as its own section in the VRM System.

• Means to identify/mark confidential and Safe-at-Home voters.

Voter Search (Find Tool)

• Ability to set or “lock in” search parameters during a session so the user does not have to keep repeating this process.

• Increase/decrease both the size of the font and windows in the VRM System.

• Prominently display the most recent voter signature.

• Include a “prior name” and “prior address” search field.

• Wildcard feature available for all search fields.

• Search into/through the transaction log (separately, which modules include a separate transaction log?).

Miscellaneous

• Provide a smooth and robust scanning process that interacts with the VRM System (e.g., provisional envelopes and registration forms).

• Ability to select multiple records at a time from the Online Voter Registration portal for movement and/or removal.

• Captured signatures from EPBs import directly into voter record in the VRM System.

• Option to archive voter records that have been cancelled for six years or more.

• Automatically remove 17-year-old pending code when a voter turns 18 years old.

• Include public view component to the VRM System, which also provides current voting status.

ELECTION SETUP AND CANDIDATE/PETITION MODULE(S)

Macro-Level

Indicate whether the Election Setup and Candidate/Petition module(s) are included in the base contract of the VRM System or offered as optional add‑ons. This includes the entry of ballot issue language. Describe, and provide screenshots where applicable, how these modules or features are accessed within the system’s overall navigation structure and how it relates to other modules.

Describe, and provide screenshots to illustrate, the full workflow for how the VRM System handles the setup of elections and address the various requirements of that process. Provide examples of reports that can be produced by the VRM System, and indicate its compatibility with other reporting systems such as SAP/Crystal Reports.

Explain and provide screenshots to demonstrate how petitions and candidate/issue filings are entered and maintained in the VRM System. If the VRM System supports campaign finance filings or integrates with a third-party program that does so, describe this functionality.

Micro-Level

Please address each bulleted item below. Items are grouped into subcategories. Respondents are encouraged to include screenshots and/or examples to support their responses.

Election Setup

• Clear instructions on how to define districts in the VRM System.

• Interface with all Ohio certified Election Management Systems.

o Create election export file(s) that will integrate with all Ohio certified voting systems (particularly Clear Ballot’s ClearVote).

• Support multiple and overlapping simultaneous elections.

• Permit the setup or editing of an election without affecting the concurrent use of other modules/functions of the VRM System.

• Allow the creation of election contests in batches vs. a manual one-by-one process.

Candidates

• Ability to process candidate filings, including:

o Contact information o Both registered and mailing addresses o Tracking status

• Support voluminous catalog of public offices, contests, etc.

• Automatically move candidates that won a primary election to the general election.

• Link candidates to their voter registration profile.

• Display current election officials (and contact info) via voter lookup on or through the

County website.

Ballot Issue Language

• Clear instructions on how to enter ballot issue language into the VRM System.

• Ability to order/sort the ballot issues according to formulas adopted by the SOS and the

County.

• Support the entry of both English and Spanish text for the same ballot issue.

Petitions

• Provide a mechanism to identify and process cross-referenced petitions.

• Provide the flexibility to change, upon review, the status of a petition signer (including overriding a rejection code that may automatically be triggered).

ABSENTEE VOTING MODULE

Macro-Level

Indicate whether the Absentee Voting module is included in the base contract of the VRM

System or offered as an optional add‑on. Describe, and provide screenshots where applicable, how the Absentee Voting module is accessed within the system’s overall navigation structure and how it relates to other modules.

Describe, and provide screenshots to illustrate, the full workflow of the absentee Vote-by-Mail

(VBM) process in the VRM System. Further, explain how the system supports realtime transfer of voter activity from Ohio certified electronic pollbooks (EPBs) to the VRM System during

Early InPerson (EIP) voting period (the Respondent is welcome to include architecture/security notes to demonstrate this process).

Micro-Level

Please address each bulleted item below. Items are grouped into subcategories within the

Absentee Voting module. Respondents are encouraged to include screenshots and/or sample files/exports to support their responses.

Core Absentee Processing

• Record and fulfill requests for VBM applications, which generates an application that is inclusive of voter's name, address, precinct, and voter-specific barcode.

• Allow absentee requests to be entered, maintained, and categorized (e.g., Civilian/InPerson, Civilian/Mail, UOCAVA/Email, Hospital, Jail).

• Enable tracking for ballot mailing, return, and status codes (e.g., Good; Rejected—no signature/ID), including configuration of rejection/challenge codes.

• Comply with Federal Voting Assistance Program (FVAP) requirements, including support for PIN fields and specialized UOCAVA workflows.

• Temporary electionspecific mailing addresses can be recorded without altering permanent voter registration data.

• Expand, if needed, upon the Macro-Level description of the EIP process, detailing how the VRM System interacts with ballot on demand (BOD) printers (specifically the Clear

Ballot system) to issue ballots, as well as how to check-in voters and issue ballots when not using EPBs.

Mail Production and Returns

• Generate ballot print files that are addressed, mailed, and reconciled with returnedmail data.

• Collect returned ID envelope images for ID/signature verification, and use return source codes (Mail, Drop Box, etc.) for tracking.

• Utilize Intelligent Character Recognition (ICR) to assist with intake, envelope verification, and scanned absentee applications (Runbeck Agilis).

Data Handling and Labeling

• Support barcode scanning and bulk import/export (CSV/XML) for largescale updates and systemtosystem data sharing.

• Provide customizable reporting and label generation, including barcoded labels.

POLL WORKER MODULE

Macro-Level

Indicate whether the Poll Worker module is included in the base contract of the VRM System or offered as an optional add‑on. Describe, and provide screenshots where applicable, how the Poll

Worker module is accessed within the system’s overall navigation structure and how it relates to other modules.

Describe, and provide screenshots to illustrate, how the VRM System maintains poll worker profile data. This should include, at a minimum, precinct and polling‑location assignments, mailing addresses, training assignments and completion status, work history, and linkage between a poll worker profile and their voter registration record.

Explain how poll worker profiles and historical worker‑election data currently stored in DIMS will be incorporated into your VRM System. Describe the migration process, including how your solution avoids manual re‑entry of existing data.

Micro-Level

Please address each bulleted item below. Items are grouped into subcategories within the Poll

Worker module. Respondents are encouraged to include screenshots and/or examples to support their responses.

Worker Profiles

• Seamlessly transfer all poll worker profile data from election to election.

• Offer customizable workers statuses, tags and/or flags.

• Provide a Comments/Notes field that includes:

o Automatic timestamps for each entry (including date/time and username) o A user‑friendly interface for entering and reviewing notes

• Allow manual creation of worker profiles for individuals who are not registered voters

(e.g., rovers, high school students).

• Provide a flexible and robust poll worker search function.

• Support the ability to email or text poll workers, both individually and in bulk.

• Ensure that any changes made to a poll worker’s voter registration record automatically update their corresponding worker profile.

Training Classes

• Support the creation and management of training classes, including setting class size, marking attendance, and related administrative functions.

• Allow class grades or completion statuses to be assigned to poll worker profiles.

• Generate class roster reports.

• Allow poll workers to self‑schedule their training classes online.

• Provide or integrate with an online Learning Management System (LMS) to support virtual training.

Poll Worker Pay

• Assign pay rates to specific job titles.

• Allow editing of pay rates and support miscellaneous or supplemental payment amounts

(e.g., adding an additional pay rate to an individual worker profile beyond the standard job‑title rate)

• Generate paper payroll sheets for polling locations and reports used to create poll worker paychecks.

Miscellaneous

• Generate Notice-to-Serve letters and track their return.

• Provide an online poll worker application that syncs directly with the VRM System.

LOGISTICS (POLLING LOCATIONS)

Macro-Level

Indicate whether the Polling Locations module is included in the base contract of the VRM

System or offered as an optional addon. Describe, and provide screenshots where applicable, how the Polling Locations module is accessed within the system’s overall navigation structure and how it relates to other modules — particularly the Poll Worker module.

Detail, and provide screenshots to illustrate, how the VRM System maintains polling locations and assigns precincts, including the creation of new voting sites and the removing of old/inactive locations. Describe any additional logistical features or tools the VRM System offers.

Micro-Level

Please address each bulleted item below. Respondents are encouraged to include screenshots and/or examples to support their responses.

• Permit the temporary assignment or adjustment of polling locations and precincts

(including split precincts) for a single election, then reverting these changes to their default setting.

• Allow contact information to be stored within a polling location record, including the ability to record notes or comments.

• Support the attachment of images (e.g., polling location diagram) and/or other file types.

• Easily identify the number of registered voters assigned to a precinct.

• Impact or restrictions of the VRM System as it pertains to polling locations and the poll workers assigned to them (i.e., does a location change or assignment impact an already assigned poll worker to the affected precincts, and if so, how).

INFORMATION SERVICES AND TECHNOLOGY

Note: For the Information Services and Technology portion, in addition to the macro-level and micro-level responses the will provide, there is an additional Public Website Widget

Documentation and Backup and Disaster Recovery sections each Respondent should address.

Macro-Level

Describe, and provide specifications, diagrams or other resources to demonstrate the hardware, network products, and cloud infrastructure that comprise the VRM System. List any additional recommended and/or required hardware or software to compliment your VRM System. Detail the reporting and analytics capabilities included in the VRM System and the flexibility of the system to allow the County to create their own reports.

Micro-Level

Please address each bulleted item below. Items are grouped into subcategories. Respondents are encouraged to include screenshots, specifications, or other documentation to support their responses.

Database/Servers

• Provide physical and/or cloud-based data storage.

o For cloud-based data storage, detail the level of control the County has over the database.

o Outline what changes/scripts are completed by the Respondent compared to what can be done by the County.

• Detail the process to convert data from the County’s existing VRM System to the new product.

o Include the role(s) County staff will play in this process.

Reliability and Performance

• Ability to handle high-traffic bursts (up to 500% of average load) during the 48 hours preceding an election.

• 99.9% uptime during the election cycle.

Security

• Provide multi-factor authentication (MFA) for administrative accounts.

• Use of AES-256 for data at rest and TLS 1.3 for data in transit.

• Immutable logs for ballot requests to ensure a transparent paper trail.

GIS

• Inform how map software (such as ArcGIS) integrates with the VRM System.

o Integrate with County geographical data for precinct accuracy.

• Detail how the VRM System handles split precincts.

Usability and Accessibility

• Provide a clean, "mobile-first" dashboard consistent with Cuyahoga County branding.

• Common voter functions (e.g., Voter Search, Where do I Vote, Sample Ballot, Track

Your Ballot, Current Elected Officials, etc.) available in a “one-stop shop” portion of the

County website, bypassing the need for separately develop County web applications.

• Integrated search functionality for quick access to FAQ and specific forms.

• Strict adherence to WCAG 2.1 Level AA standards.

Miscellaneous

• Provide the ability to set user permissions to allow/disallow certain areas/modules of the

VRM System.

• Support for English and Spanish language across all modules of the VRM System.

• All voter registration processes/maintenance is done within the VRM System.

PUBLIC WEBSITE WIDGET DOCUMENTATION

The CCBOE site is not just a set of static information pages. It includes task-based widgets that let voters, candidates, campaigns, and the public search election data, request Vote-by-Mail materials, track ballot activity, find polling locations, view sample ballots, export voter outreach data, and submit page-level feedback. What follows are the key elements of the current CCBOE website, and the capability the Respondent must provide to integrate with these functions.

1. Home page task cards

Official page: https://boe.cuyahogacounty.gov/

The BOE homepage presents major election tasks as prominent user-facing cards. These cards help visitors quickly choose a path without needing to understand the site structure first.

Respondent capability expectations

• Provide configurable task-card components with title, short description, icon/image support, destination URL, display order, and publish/unpublish controls.

• Support mobile-responsive layout and accessible focus states.

• Allow emergency or election-cycle messaging near high-volume tasks when needed.

2. Get Your Voting Information

Official page: https://boe.cuyahogacounty.gov/voters/get-your-voting-information

This is a personal voter lookup tool. It helps a registered Cuyahoga County voter find their current voting details in one place before voting.

Respondent capability expectations

• Support voter-record lookup using last name and date of birth.

• Return election-aware precinct, district, polling location, sample ballot, and party-affiliation data.

• Handle protected voter records and redacted address scenarios safely.

• Provide an address-change handoff to the appropriate state system.

• Support clear validation, no-result, and alternate-contact messaging.

3. Request a Vote-by-Mail Application

Official page: https://boe.cuyahogacounty.gov/voters/Request-a-Vote-by-Mail-Application

This tool helps registered voters begin the Vote-by-Mail process. It should be documented carefully because the online step requests or provides access to an application; it does not mean the voter has already received or cast an absentee ballot.

Respondent capability expectations

• Support an online application-request workflow and/or printable application handoff.

• Explain the difference between requesting an application, submitting an application, receiving a ballot, and returning a voted ballot.

• Display current election-law deadline messaging in an easily updateable way.

• Support state/federal links for registration, military/overseas voters, remote ballot marking, and official forms.

• Provide audit-friendly transaction/status messaging without exposing unnecessary personal data.

https://boe.cuyahogacounty.gov/ https://boe.cuyahogacounty.gov/voters/get-your-voting-information https://boe.cuyahogacounty.gov/voters/Request-a-Vote-by-Mail-Application

4. Track Your Vote-by-Mail Ballot

Official page: https://boe.cuyahogacounty.gov/voters/track-my-ballot

This widget lets voters monitor the status of their vote-by-mail ballot. It gives voters reassurance that the request and returned ballot are moving through the process, and it helps them identify when follow-up may be needed.

Respondent capability expectations

• Support secure voter lookup and election-specific ballot status retrieval.

• Display status stages in plain language, with dates where available.

• Provide next-step or contact instructions for rejected, challenged, missing, late, or protected-record scenarios.

• Allow BOE staff to update explanatory text, videos, deadlines, and contact instructions without code changes.

• Avoid exposing more voter information than needed to communicate status.

5. Find Voting Information by Address

Official page: https://boe.cuyahogacounty.gov/voters/Find-Voting-Information-by-Address

This is an address-based lookup tool. It helps users locate polling information without needing to know a voter’s name or date of birth.

Respondent capability expectations

• Support address parsing using separate address-number, direction, street-name, street-type, and city fields.

• Return polling location, precinct, district, and sample ballot information for the resolved address.

• Support GIS or address-range data integration, including odd/even street ranges and jurisdiction boundaries.

• Provide map/directions links in an accessible way.

• Display clear correction messages for invalid, ambiguous, or out-of-county addresses.

6. Get a Sample Ballot

Official page: https://boe.cuyahogacounty.gov/voters/Get-a-Sample-Ballot

This tool helps voters preview what will appear on their ballot before voting. The current public page also needs to handle the “not yet posted” state, because sample ballots are published based on election timing.

Respondent capability expectations

• Support election-specific sample ballot publishing windows.

• Allow sample ballots to be grouped and searched by jurisdiction, ward, precinct, and ballot type.

• Support PDF/file management, accessible file labels, and optional language variants if provided by BOE.

• Integrate with voter and address lookup tools for users who do not know their precinct.

• Provide clear not-yet-available, no-ballot, and contact-us states.

7. Get Vote-by-Mail Labels and Lists

Official page: https://boe.cuyahogacounty.gov/candidates/Get-Vote-by-Mail-Labels-and-Lists https://boe.cuyahogacounty.gov/voters/track-my-ballot https://boe.cuyahogacounty.gov/voters/Find-Voting-Information-by-Address https://boe.cuyahogacounty.gov/voters/Get-a-Sample-Ballot https://boe.cuyahogacounty.gov/candidates/Get-Vote-by-Mail-Labels-and-Lists

This is a public data and export tool primarily for candidates, campaigns, political parties, and civic organizations. It supports outreach by allowing users to filter vote-by-mail data and generate lists or labels.

Respondent capability expectations

• Support large public data queries with multiple filters and predictable performance.

• Generate CSV/data exports and print-ready PDF label formats.

• Provide clear labels for party, district type, district, precinct, and date-issued filters.

• Support historical elections and current elections as defined by BOE policy.

• Allow supporting documentation links, such as vote-by-mail codes and label-printing instructions.

8. Campaign Finance Reports

Official page: https://boe.cuyahogacounty.gov/candidates/campaign-finance-reports

This public lookup tool lets users find campaign finance records using keyword search. It supports transparency by making campaign finance filings easier to locate.

Respondent capability expectations

• Support keyword search across candidate names, committee/PAC names, and report metadata.

• Return results quickly with enough context for the user to choose the right filing.

• Support document viewing/downloading if report files are attached.

• Provide reset/clear behavior and no-result guidance.

• Allow BOE staff to update help text and examples.

9. Sitewide “Was This Page Helpful?” feedback widget

Official page: https://boe.cuyahogacounty.gov/

This widget appears across BOE pages and captures simple user feedback about page usefulness.

It is not an election lookup, but it is important because it gives the County a direct signal when a page is confusing, incomplete, or not working for the user.

Respondent capability expectations

• Support reusable page-level feedback collection across templates.

• Capture page URL/context automatically so staff know which page the feedback relates to.

• Support yes/no metrics and optional comment/email fields.

• Provide reporting/export options for content and quality teams.

• Include spam prevention and privacy-aware data handling.

BACKUP AND DISASTER RECOVERY

Backup and Disaster Recovery (DR) specifications must align with SOS Directive 2026-20 and the NIST Cybersecurity Framework.

1. Backup Strategy (Compliance & Integrity)

In accordance with Ohio SOS mandates, the VRM System must follow a rigorous daily backup cycle to prevent data loss.

1.1 Data Frequency & Retention

https://boe.cuyahogacounty.gov/candidates/campaign-finance-reports https://boe.cuyahogacounty.gov/

• Daily Incremental Backups: The VRM System server and all processed transaction data must be backed up daily.

• Weekly Full Backups: A full system image and file server backup must occur at least once per week.

• Retention Period: Backups must be retained for a minimum of three weeks to allow for point-in-time recovery from "silent" data corruption or ransomware.

1.2 Storage Standards

• The 3-2-1 Rule: Maintain 3 copies of data, on 2 different media types, with 1 copy located off-site and off-network.

• Immutable Storage: Use WORM (Write Once, Read Many) or "Air-Gapped" storage to protect against unauthorized deletion or encryption by malicious actors.

• Encryption: All backup data, both at rest and in transit, must be encrypted using AES-

256 standards.

2. Disaster Recovery (DR) Operations

The DR plan is designed to transition services to a secondary environment if the primary

Cuyahoga County infrastructure fails.

2.1 Recovery Objectives

Metric Requirement Justification

RPO (Recovery Point

Objective) < 24 Hours

Limits data loss to the previous day’s backup (per

Directive 2026-20).

RTO (Recovery Time

Objective) < 4 Hours

Ensures the portal is restored quickly during critical election windows.

2.2 Continuity Procedures

• Hot/Warm Site Configuration: Maintain a secondary, geographically diverse site (e.g., a state-approved cloud environment or a reciprocal county agreement) capable of assuming the production load.

• Failover Automation: Use automated DNS failover to redirect citizen traffic to the DR site if the primary server becomes unreachable.

3. Testing & Validation

• Annual Restoration Test: At least once per year, the Respondent must perform a full-scale restoration of the VRM System from an off-site backup to verified hardware.

• Integrity Checks: Implement automated Hash Validation to ensure that restored data exactly matches the original records.