Unified_Safety_and_Security_Platform_RFP_v2 (.pdf

Request for Proposals (RFP) Unified Safety & Security Platform

Video Surveillance (Bridge Existing Cameras) + Intercom + Access Control + Environmental Sensors (Future-Ready)

RFP # 012926USSP

District Griffin-Spalding County Schools Issue Date February 24, 2026 Proposals Due (ET) March 27, 2026 by 4:00 pm EST District Contact Lonny Harper

Director of Instructional Technology lonny.harper@gscs.org

Submission Method Email: lonny.harper+RFP@gscs.org

1. Notice to Proposers

2. RFP Schedule (Proposed)

3. Background and Current Environment

4. Project Objectives

5. Scope of Work (Phased)

5.1a Phase 1 - Video Platform + Recording Infrastructure (Required) 5.1b Phase 1.1 - Door Entry Intercom Systems (Required Separate Pricing)

5.2 Phase 2 - Camera Replacement (Optional Separate Pricing)

5.3 Phase 3 - Access Control Modernization Program (Required)

5.4 Phase 4 - Environmental Sensors (Required Platform Capability; Optional Purchase)

6. General System Requirements

6.1 Unified Platform Requirements (Required)

6.2 Identity, Authentication, and Authorization (Required)

6.3 Cybersecurity Requirements (Required)

6.4 Support, Maintenance, and Updates (Required)

6.4.1 24/7/365 Technical Support (Required)

6.4.2 Updates and Maintenance (Required)

6.4.3 Enhancements and New Features (Preferred / Scored)

6.5 Security Assurance and Certifications (Preferred / Scored)

7. Functional Requirements by Module

7.1 Video Management (Required)

7.1.a License Plate Recognition (LPR/ALPR) (Required in Phase 1)

7.2 Recording, Storage, and Retention (Required)

7.3 Door Entry Intercom Systems (Required Separate Pricing)

7.4 Access Control (Required)

Credential Compatibility and Transition (Required)

7.5 Environmental Sensors and Alerting (Required Capability; Optional Purchase)

8. Implementation Requirements

8.1 Installation, Configuration, and Documentation Requirements (Required)

Installation – Turnkey (Required) Future Phases / Turnkey and Pricing Structure (Informational) Installation – Existing Networks (Required) Installation – VLAN and Addressing (Required) Installation – Mounting and Materials (Required) Installation – Technical Specifications and Warranty (Required) Configuration – Video Settings (Required) Configuration – Naming and Identification (Required) Configuration – Field of View Verification (Required) Proposer Authorization (Required)

9. Proposer Questionnaire (Required Responses)

9.1 Architecture & Design

9.2 Sizing & Performance

9.3 Identity, Access, and Audit

9.4 Support, SLA, Warranty

9.5 Implementation & Training

9.6 Door Entry Intercoms & Access Control

9.6a Credential Compatibility / One-Badge Transition

9.7 License Plate Recognition (LPR/ALPR) (Required Response)

9.8 Environmental Sensors (Required Capability; Optional Purchase)

9.9 References

10. Proposal Submission Requirements

11. Pricing Requirements (Must be Separate Line Items)

11.1 Phase 1 - Required: Video Platform + Recording Infrastructure (Bridge Existing Cameras) LPR/ALPR cameras and licensing (Phase 1 required):

11.2 Phase 1.1 - Required Separate Pricing: Door Entry Intercom Systems (33 Systems).. 19

11.3 Phase 2 - Optional: Surveillance Camera Replacement

11.4 Phase 3 - Required: Access Control Modernization Program (Approx. 110 Doors)

11.5 Phase 4 - Optional Future: Environmental Sensors

11.6 Five-Year Total Cost of Ownership (5-Year TCO)

12. Evaluation Process and Selection

13. Proof of Concept (POC) Requirement (Top 3 Proposers)

14. Attachments and Appendices Attachment A - Current Camera and Recorder Inventory Appendix B - Proposer Compliance Matrix Template Appendix C - Scoring Rubric Template

C.1 Proposal Scoring (100 points) C.2 POC Scoring (Recommended 50 points)

Attachment D - License Plate Recognition (LPR/ALPR) Site Location Maps Attachment E - Door Maps & Door Entry Additions Proposer Certification and Signature

1. Notice to Proposers The District seeks proposals from qualified firms to provide a single, unified safety and security platform that consolidates:

● Video surveillance management and recording (required immediately; must bridge existing cameras).

● Front entry intercom/door entry (required; separate pricing).

● Access control (required as a modernization partnership; phased replacement as devices fail).

● Environmental sensors (not an immediate purchase requirement, but platform capability is required and will be evaluated).

All cameras are intended to be replaced either as part of this project or at a later date depending on available funding. Proposers must provide separate, itemized pricing and a phased replacement plan for full camera replacement.

The District will evaluate proposals using the scoring rubric in this RFP and will invite the top three (3) highest-scoring proposers to conduct a one (1) month Proof of Concept (POC) on District premises prior to final award.

The District reserves the right to reject any or all proposals, waive informalities, and request clarifications.

2. RFP Schedule (Proposed) RFP Issued February 24, 2026 Mandatory Pre-Proposal Meeting / Site Walk** March 10, 2026 at 9:00 am

Griffin High School 1617 West Poplar Street Griffin, GA 30223

Deadline for Written Questions March 16, 2026 by 4:00 pm EST District Responses/Addendum Issued March 19, 2026 Proposal Due March 27, 2026 by 4:00 pm EST Evaluation Period March 30 - April 3, 2026 Shortlist Notifications (Top 3) April 5, 2026 POC Window (1 Month) April 6 - May 4, 2026 Final Award Recommendation May 11, 2026 Board Approval (if applicable) May 26, 2026 **Proposals submitted by proposers that do not attend the mandatory Pre-Proposal Meeting / Site Walk will be deemed non-responsive and will not be considered for award.

3. Background and Current Environment The District currently operates security camera systems across schools and facilities. The District’s immediate goal is to replace existing recording servers/NVR infrastructure with a new system that can bridge and manage all existing cameras through the selected platform.

Key current environment metrics (see Attachment A):

● 1,475 cameras currently deployed (models vary; see Attachment A).

● 89 existing NVR/recording devices across 44 schools/facilities.

● 709 additional camera channels listed as unused capacity on current recorders (informational only).

Additional systems and goals:

● Door entry intercom system: The District currently uses Aiphone and requires replacement of 21 existing front entry intercom systems (one per school), plus installation of 12 additional net-new systems (one additional system at each elementary school and the Elementary Enrichment Center), for a total of 33 systems.

● Access control: District currently uses Kantech access control on approximately 110 doors district-wide (at least 4 doors per school) and wants to begin a phased replacement program as equipment fails/ages.

● Identity management: District uses Active Directory sync for account lifecycle management and expects group-based role assignment and auditability.

● Environmental sensors: Not a current purchase requirement, but the District wants to ensure the chosen platform includes this component for future adoption.

4. Project Objectives

1. Provide one platform (“single pane of glass”) for video surveillance, door entry intercoms, access control, and environmental sensors, with the ability to expand to additional compatible modules/components offered by the proposer as future District needs evolve.

2. Support bridging of existing cameras into the new platform without immediate camera replacement.

3. Provide an optional, itemized plan and pricing to replace all cameras district-wide, either during this project or as a later phase depending on funding.

4. Provide a scalable recording/storage architecture sized for the current camera footprint and future growth.

5. Support Active Directory (AD) synchronization and role-based access control (RBAC) aligned to

District job functions, with building/site-based scoping (e.g., users may only view/manage cameras/doors/sensors for their assigned schools/facilities) using AD groups or equivalent automated provisioning.

6. Support a phased access-control transition while maintaining a single credential for end users.

Provide a one-badge transition approach. Native support for existing P20DYE credentials is preferred; if native support is not available, proposer shall provide a priced alternate one-badge method.

7. Provide strong and efficient cybersecurity controls, auditing, identification, tracking, incident workflows, and export/retention capabilities.

8. Provide clear, separable pricing for each phase/module so the District can purchase in stages.

5. Scope of Work (Phased)

5.1a Phase 1 - Video Platform + Recording Infrastructure (Required) Proposer shall provide:

● A video management system (VMS) / platform capable of bridging and managing the District’s existing cameras listed in Attachment A.

● New recording/management infrastructure (cloud, on-prem, or hybrid) sized to support the current footprint and stated retention assumptions.

● Centralized administration, RBAC, audit logs, reporting, and secure remote access.

● Migration plan minimizing downtime and avoiding disruption to school operations.

● Include License Plate Recognition (LPR/ALPR) cameras as part of Phase 1 implementation

(permanent deployment). The District currently owns 53 Model DC-2CD7A26G0-P-1ZHS LPR cameras that have not been installed and may be used as part of the proposed solution. These existing cameras are not wireless and therefore are expected to be deployed at locations where wired connectivity to District buildings is practical. Proposers may incorporate these District-owned

LPR cameras where appropriate and shall provide any additional LPR-capable cameras required based on site conditions, connectivity needs, and performance requirements. Proposers shall install and configure all LPR/ALPR cameras within the unified platform. Final installation locations will be designated by the District or approved by the District based on proposer recommendations prior to installation.

5.1b Phase 1.1 - Door Entry Intercom Systems (Required Separate Pricing)

Proposer shall provide:

● Replacement of the District’s existing Aiphone front door entry intercom systems (21 total, one per school) and installation of 12 additional net-new systems (one additional system at each elementary school and the Elementary Enrichment Center).

● Integration with door release and access control workflows where applicable, including event logging.

● Centralized administration and user permissions aligned with District roles.

● A “system” shall include all components required for a fully functional entrance call/answer workflow (e.g., door station, answering station/client, network interface/gateway as required, power, mounts, licensing/subscriptions if applicable, required door hardware components, including required wiring accessories and disconnect hardware where needed for removable mullions or similar conditions).

Phase 1 and Phase 1.1 deliverables:

1. Video: All existing cameras are bridged/managed and operating under the proposed platform with recording, playback, and export validated by the District, and LPR/ALPR cameras installed and operational at District-approved locations with plate capture, search, and event-to-video linkage functioning as specified.

2. Intercom: Existing Aiphone front entry intercom systems are replaced (21 total) and 12 additional net-new systems (one additional system at each elementary school and the

Elementary Enrichment Center) are installed (33 total), fully functional for door entry call/answer workflows and integrated with door release/access control where applicable, with appropriate

RBAC in place.

5.2 Phase 2 - Camera Replacement (Optional Separate Pricing)

District intent: The District intends to replace all cameras either as part of this procurement or as a later phase, subject to available funding. As an initial priority, the District prefers to replace existing analog cameras, which is expected to require installation of CAT6 cabling to applicable locations. Subsequent replacement phases should be prioritized based on camera capability, beginning with models that provide the least functionality and progressing to higher-capability models. The District anticipates an increasing need for facial recognition–capable solutions (hardware/platform capability); therefore, proposers shall include, at a minimum, facial recognition capability at all building entrances. Where facial recognition capability is not included as a standard feature on other proposed camera models, proposers shall provide optional pricing for adding such capability at additional key locations and clearly identify the per-camera cost impact by model. Proposers shall provide complete optional pricing and a recommended phasing approach for district-wide camera replacement.

Proposer shall provide separate pricing for:

● Replacing some or all cameras with new models supported by the same platform.

● Phasing options by school, priority area (entry/exterior/halls), or camera type.

● Installation, configuration, acceptance testing, and disposal (if offered).

5.3 Phase 3 - Access Control Modernization Program (Required) Proposer shall provide:

1. Modernization Approach (Phased Transition)

● A modernization plan to replace the District’s current Kantech access control incrementally as components fail, are upgraded, or are prioritized by the District.

● The proposed approach must support a multi-year phased rollout (District planning horizon: up to five years), without disrupting day-to-day operations.

2. Scale and Expandability

● Support for approximately 110 doors district-wide (initial estimate) and expandability for additional doors and facilities.

● Provide recommended architecture (controllers, readers, licensing) for multi-site K-12 environments.

3. Unified Platform Management

● Provide centralized access control management within the same platform as video surveillance and door entry intercom, including roles/permissions, event history, reporting, and alerts. During the phased transition from the District’s existing Kantech system, proposers shall describe the extent to which access control events and administration can be integrated into the proposed centralized dashboard/software platform. All newly proposed access control components shall be compatible with the proposed centralized platform.

4. Credential Compatibility and “One Badge” Transition Requirement (Required)

● The District is not prepared to replace all access control doors at once due to cost and recognizes that two platforms may temporarily coexist (Kantech + new system).

● Proposer must provide a one-badge transition approach. Native support for existing

P20DYE credentials is preferred; if native support is not available, proposer shall provide a priced alternate one-badge method so staff and users are not required to carry two badges.

● Proposer must describe in detail:

i. How P20DYE credentials will be recognized/accepted in the proposed system

(reader/controller requirements).

ii. Whether any re-encoding, credential conversion, or reader replacement is required.

iii. How credentials will be issued/managed for new hires, replacements, and lost badges during the transition.

● If native compatibility is not supported, the proposer must provide a priced alternative method to maintain one badge (e.g., dual-technology credentials) as an optional line item.

5. Turnkey (when purchased): For any access control work procured under this RFP, the proposer shall provide turnkey delivery including all proposed controllers/panels, readers, required power/infrastructure components, licensing, installation, configuration, documentation, and testing/validation, unless explicitly excluded as an exception in the proposal.

5.4 Phase 4 - Environmental Sensors (Required Platform Capability; Optional Purchase) The District is not purchasing environmental sensors immediately but requires that the proposed platform supports environmental sensors within the same platform ecosystem now (or via a fully integrated module). The District intends to adopt this component in the future without replacing the core platform selected in this RFP.

Proposer shall provide:

● Supported sensor categories and roadmap.

● Alerting workflows and reporting.

● Example deployment models and pricing structure (budgetary ranges acceptable).

6. General System Requirements

6.1 Unified Platform Requirements (Required)

● Provide one platform (“single pane of glass”) for video surveillance, door entry intercoms, access control, and environmental sensors, with the ability to expand to additional compatible modules/components offered by the proposer as future District needs evolve.

● Consistent login methods and RBAC across modules.

● Central audit logging across all modules with export capability is preferred.

● Multi-site management with site-level permissions and delegated administration options.

6.2 Identity, Authentication, and Authorization (Required)

● Active Directory synchronization for user provisioning/deprovisioning and group-based role assignment.

● Support for role templates (e.g., District Security Admin, School Admin, Principal, SRO, IT, Front

Office).

● The platform must support an unlimited number of system administrative users. No additional software licenses may be required to add administrative users.

○ Proposer shall clearly define user license categories (e.g., administrative, operator, viewer, mobile, intercom answering users) and identify any category subject to per-user licensing.

● Support for MFA for remote access (preferred; proposer must describe).

● Granular permissions down to site/building/camera/door/sensor group levels.

6.3 Cybersecurity Requirements (Required)

Proposer must describe and support:

● Encryption in transit (TLS) and secure remote access methods.

● Encryption at rest (preferred; required if data stored in cloud).

● Audit log retention and export.

● Patch/firmware management process and update cadence.

● Data ownership statement: District retains ownership of all recordings and event data.

● Any dependencies on external relay/P2P services must be disclosed.

Procurement compliance: Any new equipment/software provided under this RFP must comply with applicable federal/state procurement restrictions and District security standards. The proposer must disclose manufacturer origins and compliance statements as required.

6.4 Support, Maintenance, and Updates (Required)

Proposer must describe and support the following for all proposed components (platform software, appliances/servers, gateways/bridges, surveillance cameras, door entry intercoms, access control, and sensors as applicable):

6.4.1 24/7/365 Technical Support (Required)

● Proposer shall provide 24/7/365 technical support, including weekends and holidays.

● Support must be available via phone and web/email ticketing. Chat support may be provided in addition.

● 24/7/365 support must be included in the base support plan/subscription for the solution (no separate paid add-on required to receive 24/7/365 support).

6.4.2 Updates and Maintenance (Required)

● Proposer shall provide firmware and software updates for all proposed components.

● Updates must be included in the base support plan/subscription (no separate paid add-on).

● Proposer must describe update controls, including: scheduling/maintenance windows, administrator notifications, and rollback/mitigation options.

6.4.3 Enhancements and New Features (Preferred / Scored)

● Proposer should include new features and enhancements to the platform as part of the base subscription/support at no additional cost.

● Proposer must clearly disclose any features that require additional licensing/modules and provide pricing.

6.5 Security Assurance and Certifications (Preferred / Scored)

The District prefers solutions that include independent security and safety assurance. Proposers should provide documentation for the following, if applicable:

● UL/cUL 62368-1 certification for proposed audio/video, information, and communication technology equipment (e.g., cameras, intercom hardware, access control hardware, sensors, appliances).

● ISO 27001 certification for the proposer’s information security management system (ISMS), and where cloud services are provided, ISO 27017 (cloud security controls) and ISO 27018

(protection of personal data in public clouds).

● If the proposer does not hold the ISO certifications listed above, the proposer must provide equivalent third-party assurance (e.g., SOC 2 Type II, independent penetration test summary, or comparable security controls) and describe how controls align.

7. Functional Requirements by Module

7.1 Video Management (Required)

Must include:

● Ability to bridge existing cameras at scale (e.g., ONVIF/RTSP or supported gateway/bridge methods).

● Live view, playback, synchronized multi-camera review, and investigative workflow tools (e.g., search, bookmarks/cases/incidents where supported).

● Export tools with chain-of-custody controls (preferred) and watermarking (preferred).

● Bookmarks/cases/incidents (preferred).

● Mobile access options with strict RBAC controls and MFA (preferred).

The proposer must disclose supported models and any limitations when using third-party cameras (e.g., analytics, audio, motion metadata, PTZ control, etc.).

7.1.a License Plate Recognition (LPR/ALPR) (Required in Phase 1)

The solution must support License Plate Recognition (LPR/ALPR) using LPR-capable cameras and platform software such that authorized users can capture, search, and review plate events. The District currently owns 53 Model DC-2CD7A26G0-P-1ZHS LPR cameras that have not been installed and may be used as part of the proposed solution. These existing cameras are not wireless and therefore are expected to be deployed at locations where wired connectivity to District buildings is practical.

Minimum requirements:

● LPR/ALPR cameras must be integrated into the same platform as video management and recording.

● Plate reads must be searchable within the platform by:

○ Full plate number and partial plate (where supported)

○ Date/time range

○ Camera/location

● Plate events must link directly to associated video clips for review and export.

● The system must support configurable retention for LPR events and associated video in alignment with District policy.

● Role-based permissions must restrict access to LPR cameras and plate search results by job role and site (site-scoped RBAC).

● Proposer must state performance assumptions and requirements that impact read accuracy, including:

○ Recommended placement guidelines (angle, distance, lane position)

○ Day/night performance considerations (IR/low-light/WDR)

○ Vehicle speed assumptions for reliable reads

● Optional (scored if available): “Hotlist/alert list” capability for notifications when a configured plate is detected (District-defined lists and policies).

Privacy and governance:

● Proposer must describe LPR data handling (what is stored, where, how long, who can access, and audit logs).

● Proposer must describe how the District can configure and restrict plate data access and reporting.

7.2 Recording, Storage, and Retention (Required)

Proposer must provide a sizing approach and assumptions, including:

● Retention days proposed: 30 days minimum with continuous recording.

● Proposers may also provide optional pricing for 45/60/90-day retention scenarios.

● Resolution/FPS assumptions and motion/continuous recording profiles.

● Redundancy and failover options (RAID/clustering/cloud resiliency).

● Behavior during WAN outages (site continues recording vs degraded mode).

7.3 Door Entry Intercom Systems (Required Separate Pricing)

Must include:

● Video/audio intercom appropriate for school entrances.

● Role-based answering options (front office, admins, backups).

● Door release workflows with audit logging.

● Ability to associate intercom events with video clips and/or camera views (preferred).

7.4 Access Control (Required)

Must include:

● Centralized door schedules, groups, roles, and credential management.

● Event alerts: forced open, held open, invalid credential, after-hours access.

● Reporting and searchable history.

● Phased replacement strategy that allows incremental cutovers without disrupting school operations.

● Expandability beyond initial estimated door count.

Credential Compatibility and Transition (Required)

● The District currently uses Kantech credentials and intends to phase in a new access control platform over time.

● Proposer must provide a one-badge transition approach. Native support for existing P20DYE credentials is preferred; if native support is not available, proposer shall provide a priced alternate one-badge method.

○ Proposer must explicitly state:

■ Whether P20DYE credentials are supported natively by proposed readers/controllers, and any required reader/controller models.

■ Any credential technology/format assumptions needed to ensure compatibility

(e.g., prox, smart card, facility code, card numbering scheme), and how the proposer will validate these assumptions with the District.

● The proposer must describe in detail how existing credentials will be:

○ recognized/accepted in the new system (including any needed readers/controllers)

○ enrolled/imported/mapped (if applicable)

○ managed during the transition while Kantech remains in operation for some doors

● The proposer must clearly state any limitations, prerequisites, or required changes (e.g., reader replacement, credential format changes, re-encoding, etc.).

● The proposer must describe how they prevent users from needing two badges during the transition, including any cross-compatibility approach.

● POC requirement: Proposer must demonstrate the “one badge” transition approach using a representative credential/card in the POC or in a staged environment approved by the District.

Note: If credential compatibility is not feasible, the proposer must provide an alternate solution to maintain one badge (e.g., dual-technology cards) and price it as an optional line item.

7.5 Environmental Sensors and Alerting (Required Capability; Optional Purchase) Platform must support centralized management of sensors across sites, including:

● Configurable thresholds, schedules, acknowledgements, and escalation rules.

● Notifications via email/SMS/push (proposer to specify).

● Dashboards and history reporting (exportable).

● Device health monitoring (offline, low battery, fault).

Sensor categories (proposer must mark Supported / Roadmap / Not Supported):

● Indoor air quality (CO2, VOCs, PM2.5).

● Temperature/humidity.

● Water leak/flood.

● Noise level (decibel-only preferred; proposer must clarify).

● Vape detection (if offered).

● Occupancy/presence (if offered).

● Power/equipment status (if offered).

● Other supported sensors.

Privacy requirement: If any sensors include microphones or audio capability, proposer must clearly state whether audio is recorded, how it is controlled/disabled, and how District policy can be enforced.

8. Implementation Requirements The proposer must provide:

● A project plan and timeline by phase and by site.

● A site cutover approach that minimizes downtime and disruption to school operations.

● A training plan for District Admins, School Admins, SRO/Security, and Front Office staff.

● Documentation deliverables, including as-builts, configuration standards, runbooks, and administrator guides.

● Background checks and site safety procedures for all installer staff.

● Warranty terms and a post-install validation/testing plan, including acceptance procedures.

● Commissioning of the components and systems.

8.1 Installation, Configuration, and Documentation Requirements (Required)

Proposer shall provide turnkey installation and configuration services, including all labor, materials, equipment, supplies, and documentation required to deliver a fully operational solution, except for items explicitly identified by the District as District-provided.

Installation – Turnkey (Required)

● Turnkey responsibility: Proposer shall be responsible for all hardware, software, licensing, mounting, installation, integration, and configuration of all the components and equipment required for the solution—including gateways/bridges and recording infrastructure to bridge/manage existing surveillance cameras, Phase 1 LPR/ALPR cameras, and door entry intercom systems (replacement of 21 existing Aiphone systems plus installation of 12 new systems)—including all related accessories, resulting in a fully operational system for the initial scope (Phase 1 and Phase 1.1).

Future Phases / Turnkey and Pricing Structure (Informational)

● The District may, subject to funding and at its sole discretion, implement additional phase(s) beyond the initial scope described in this RFP. Any optional or future phase proposed (including, but not limited to, district-wide camera replacement, access control expansion, and environmental sensors) must be priced and structured as turnkey, including all required hardware, software, licensing, labor, mounting, configuration, documentation, and validation/acceptance testing, unless explicitly excluded and identified as an exception in the proposal.

Installation – Existing Networks (Required)

● Coordination with District: Proposer shall coordinate with District IT staff to ensure proposed equipment functions on the District’s existing network infrastructure. Proposer shall provide network requirements (ports, protocols, bandwidth, QoS recommendations) and assist in validation/testing.

Installation – VLAN and Addressing (Required)

● VLAN: Cameras and related video equipment shall be placed in a District-designated camera/security VLAN at each site.

● Addressing: Cameras shall use DHCP for addressing unless the District approves an exception in writing.

Installation – Mounting and Materials (Required)

● Mounting: Proposer is responsible for all mounting hardware, brackets, conduit, junction boxes, and accessories required by manufacturer and/or site conditions to successfully install equipment in District-approved locations.

● Proposer shall comply with applicable codes and manufacturer installation requirements.

Installation – Technical Specifications and Warranty (Required)

● Proposer shall provide technical specifications for all proposed hardware and software components, including at minimum: manufacturer, model, description, key features, warranty term, and any special maintenance requirements. Where applicable, include environmental ratings and power/network requirements.

Configuration – Video Settings (Required)

● Frame rate/compression: Proposer shall configure frame rate and compression settings to balance video quality, storage retention, and bandwidth utilization based on District requirements and proposed retention targets.

● Motion detection: Proposer shall configure motion detection sensitivity and recording rules where applicable and document the settings used.

Configuration – Naming and Identification (Required)

● Camera identification: Proposer shall configure each camera’s name/description using a

District-approved naming standard based on the current designations that incorporates site/building and location. Proposer shall submit naming conventions for approval prior to configuration.

Configuration – Field of View Verification (Required)

● Field of view: Existing field of view for each camera should be viewed and documented prior to any changes. The new field of view for each camera shall be as good or better than the existing.

Camera placement and field of view shall be coordinated with District staff and verified/approved during installation. The proposer shall make reasonable adjustments to achieve District-approved coverage.

Proposer Authorization (Required)

● Authorized reseller/partner: The proposer shall be an authorized reseller, certified partner, or otherwise approved seller/installer for the proposed solution and shall provide documentation upon request.

9. Proposer Questionnaire (Required Responses) Proposals must include answers to all items below. These responses will be scored.

9.1 Architecture & Design

1. Describe proposed architecture (cloud/on-prem/hybrid) and include a diagram.

2. Where does recording occur (edge/on-prem/cloud) and why is it best for multi-site K-12?

3. How will you bridge the District’s existing cameras listed in Attachment A?

4. What limitations exist when bridging third-party or non-proprietary cameras vs your native cameras?

5. Describe bandwidth/WAN impacts and mitigation strategies.

9.2 Sizing & Performance

1. Provide sizing for the District’s existing camera count (1,475) including retention assumption.

2. List all assumptions (resolution/FPS, motion/continuous, retention days).

3. Maximum supported cameras per appliance/server and recommended density.

4. What happens during WAN/internet outage at a school?

9.3 Identity, Access, and Audit

1. Explain AD sync setup and operations (group-to-role mapping).

2. Do you support SSO (SAML/OIDC) and MFA? Describe.

a. User licensing: Confirm unlimited administrative users with no additional licenses required; disclose any user-based licensing if applicable.

b. Define user license categories (e.g., administrative, operator, viewer, mobile, intercom answering users) and identify any category subject to per-user licensing.

3. Explain audit logs (what, retention, export).

4. Explain remote access controls (geo/IP restrictions, MFA enforcement, device policies).

9.4 Support, SLA, Warranty

1. Provide SLA for uptime and support response times (P1/P2/P3).

2. Hardware replacement times and escalation model.

3. Warranty terms and optional extended support offerings.

a. Confirm that 24/7/365 support is included in the base support/subscription (no paid add-on).

b. List channels offered (phone/email/web/chat).

4. Describe firmware/software update process, frequency, and administrative controls

(maintenance windows, notifications, rollback).

5. Confirm whether enhancements/new features are included in base subscription/support; if not, list paid modules and pricing.

9.5 Implementation & Training

1. Implementation plan, staffing, and timeline for Phase 1.

2. Migration plan to minimize disruption.

3. Training plan by role.

4. Documentation and ongoing admin support approach.

9.6 Door Entry Intercoms & Access Control

1. Intercom models/options and call routing failover.

2. Door release workflow and audit logging.

3. Access control hardware approach, controller architecture, and phased replacement strategy.

4. Credential options (cards/mobile/PIN) and recommended K-12 approach.

9.6a Credential Compatibility / One-Badge Transition

1. The District currently uses Kantech-issued credentials/cards (P20DYE cards). Describe how your solution will allow staff/users to use one badge during the transition period when some doors remain on Kantech and some move to the new platform.

2. Confirm whether the existing credential format is supported natively by your readers/controllers.

If yes, specify reader models and configuration requirements.

3. If native support is not available, describe the recommended path to maintain one badge (e.g., dual-technology credentials, re-encoding, credential translation, etc.) and provide pricing as an optional line item.

4. Describe how credentials will be issued and managed (new hires, replacements, lost badges) during the transition while two systems may be operating.

5. Describe any data migration/import approach from Kantech (cardholder records, access levels, schedules) if available, and limitations.

9.7 License Plate Recognition (LPR/ALPR) (Required Response)

1. Describe how the existing 53 Model DC-2CD7A26G0-P-1ZHS LPR cameras can best be utilized.

2. Describe your proposed LPR/ALPR approach (camera models, platform module/software, licensing).

3. Provide recommended placement guidance for K-12 campuses (entries/exits), including distance/angle and lane coverage considerations.

4. State the expected read performance parameters and assumptions (day/night, IR, WDR, vehicle speed ranges, plate types).

5. Describe search and reporting capabilities (full/partial plate, date/time, camera/location) and how plate events link to video.

6. Describe LPR data retention options and audit logging for access to plate searches/results.

7. Describe any optional alerting/hotlist features and how they are controlled, audited, and restricted by role/site.

8. Provide at least one (1) reference where your LPR/ALPR capability is in use (preferably K-12 or public sector).

9.8 Environmental Sensors (Required Capability; Optional Purchase)

1. Describe your environmental sensor offering and how it is managed in the same platform.

2. Which sensor categories are supported today vs roadmap? Provide timelines.

3. Alerting workflows: thresholds, escalation, acknowledgement, reporting.

4. Can sensor alerts trigger relevant camera views/maps/workflows?

5. Pricing model: per sensor/per site/subscription (budgetary ranges acceptable).

6. Firmware updates/device health/offline detection.

7. Data privacy: what is collected, stored, retention, export/delete.

8. If any sensors use microphones, clarify whether audio is recorded or decibel-only.

9.9 References

1. Provide at least three (3) K-12 references of similar complexity.

2. Include at least one (1) reference where third-party cameras were bridged/managed at scale.

3. Provide at least one (1) K-12 reference for phased access control migration, including credential continuity/one-badge transition.

10. Proposal Submission Requirements Proposals must include:

● Executive summary.

● Completed Compliance Matrix (Appendix B).

● Technical narrative and architecture diagram.

● Questionnaire responses (Section 9).

● Implementation plan and timeline.

● Support/SLA/warranty documentation.

● Pricing in the required format (Section 11).

● Proposer qualifications, certifications, and references.

● Any exceptions to RFP requirements clearly stated.

● Email submissions to lonny.harper+RFP@gscs.org

11. Pricing Requirements (Must be Separate Line Items) Proposer must provide separate pricing for each phase/module:

11.1 Phase 1 - Required: Video Platform + Recording Infrastructure (Bridge Existing

Cameras)

● Hardware/appliances/servers/gateways.

● Storage (and redundancy).

● Licensing/subscriptions (itemized).

● Implementation labor (site-by-site).

● Training.

● Support/maintenance.

LPR/ALPR cameras and licensing (Phase 1 required):

Provide separate, itemized pricing for:

● LPR-capable cameras (per unit)

● Mounting/accessories (as needed)

● Any required licensing/subscriptions for LPR/ALPR

● Installation/configuration labor

● Training specific to LPR workflows (search, export, audit)

11.2 Phase 1.1 - Required Separate Pricing: Door Entry Intercom Systems (33 Systems)

● 21 to be replaced.

● 12 to be added.

● Per-unit hardware pricing.

● Installation/configuration.

● Licensing/subscription costs, if any.

11.3 Phase 2 - Optional: Surveillance Camera Replacement

District intent: Provide pricing and a phasing plan that supports full district-wide camera replacement either during this project or as a later phase depending on funding.

● Per-camera hardware pricing by model/type.

● Install labor per camera.

● Phasing options.

● Disposal/removal (if offered).

11.4 Phase 3 - Required: Access Control Modernization Program (Approx. 110 Doors)

● Controllers/panels.

● Readers/credentials assumptions.

● Door hardware assumptions (what is included/excluded).

● Installation/configuration.

● Phasing pricing (per door and/or per school).

● Access control pricing must be turnkey (hardware, licensing, installation, configuration, documentation, and acceptance testing) unless exclusions are clearly listed.

11.5 Phase 4 - Optional Future: Environmental Sensors

● Module licensing (if any).

● Per-sensor hardware and subscription pricing.

● Installation approach options.

● Budgetary starter kit suggestions per school (optional).

11.6 Five-Year Total Cost of Ownership (5-Year TCO)

Provide Year 1-5 recurring and growth costs, including subscriptions/support and estimated costs for adding new surveillance cameras/door entry intercoms/access controls/sensors/users.

12. Evaluation Process and Selection The District will: (1) score proposals using the rubric in Appendix C; (2) shortlist the top three (3) proposers; (3) conduct interviews/demos as needed; (4) require a one (1) month POC from the top three proposers; and (5) make a final award decision based on combined proposal score, POC results, reference checks and BOE approval.

13. Proof of Concept (POC) Requirement (Top 3 Proposers) The top three (3) proposers will provide a one (1) month POC on District premises.

POC must validate at minimum:

● Bridging and management of existing cameras (representative sample and/or full-site sample).

● Recording, playback, and export workflows.

● AD sync and role-based permissions.

● Audit logs and administrative workflows.

● Intercom workflow demonstration (at least one entrance or staged).

● Access control workflow demonstration (at least one door or staged).

● Environmental sensors: include at least one sensor type in POC or provide a live demonstration environment and detailed workflow documentation.

● Access control credential verification: Demonstrate that a representative District credential/card

(P20DYE) functions as the single badge across the proposed access control solution during the transition scenario, including event logging and reporting.

● LPR/ALPR demonstration: Proposer must demonstrate LPR/ALPR functionality during the one (1) month POC period, including plate capture workflow, plate search, plate-event-to-video linkage, permissions, and audit logging.

POC logistics:

● Proposer supplies and installs necessary POC equipment (unless otherwise stated).

● District provides reasonable network access and coordination.

● District will evaluate usability, reliability, administrative burden, and effectiveness.

● District does not require permanent installation of LPR/ALPR cameras for the POC; however, proposers must provide a live demonstration using either (a) a temporary test setup on District property during the POC window, or (b) a District-approved demonstration environment that clearly shows real workflows, reporting, permissions, and audit logs.

Final award may be contingent upon successful POC results. Any temporary equipment installed for the

POC must be removed by the proposer at the end of the POC unless otherwise agreed in writing.

14. Attachments and Appendices

● Attachment A: Current Camera and Recorder Inventory (provided by District).

● Appendix B: Compliance Matrix Template.

● Appendix C: Scoring Rubric Template.

● Attachment D: License Plate Recognition Maps

● Attachment E: Door Maps & Door Entry Additions

Attachment A - Current Camera and Recorder Inventory

Attachment A provides the District’s current inventory of installed cameras and recording infrastructure to support proposer sizing, compatibility validation, and migration planning. The inventory includes camera counts, models, and recorder/NVR information by site.

In addition, Attachment A includes the following supporting materials:

● Camera Inventory: This spreadsheet contains a complete inventory of current school mounted cameras and recorders. Also, each school has a separate thermal-capable camera mounted on a tripod for mobile use within the building. These devices are included for awareness and planning purposes.

○ https://docs.google.com/spreadsheets/d/1Sh_MyxUofFw-CsdEer1Fdo5LkoUCox8E/edit?

usp=sharing&ouid=110371382638008281139&rtpof=true&sd=true

● Camera location/direction maps: Maps are provided that show the installation location of existing cameras and the direction of coverage for each camera. Each camera is represented by a red dot with the arrow indicating the direction of view.

○ https://drive.google.com/file/d/1VgCL4a71AevLUlQpvxAXoxC7ri7etVf5/view?usp=drive_ link

● MDF/IDF location maps: Maps are provided for each school/facility indicating MDF/IDF locations to assist with planning connectivity, cabling, and installation logistics. Each MDF/IDF is represented by a green dot.

○ https://drive.google.com/drive/folders/1x9Blqtwv_RZ7SkKmPj4QUkaceB0bycPP?usp=dri ve_link

These materials are provided to assist proposers in developing accurate designs and pricing. Proposers remain responsible for validating site conditions and assumptions during the site walk and incorporating any required infrastructure, mounting, and configuration work into their proposals.

https://docs.google.com/spreadsheets/d/1Sh_MyxUofFw-CsdEer1Fdo5LkoUCox8E/edit?usp=sharing&ouid=110371382638008281139&rtpof=true&sd=true https://drive.google.com/file/d/1VgCL4a71AevLUlQpvxAXoxC7ri7etVf5/view?usp=drive_link https://drive.google.com/drive/folders/1x9Blqtwv_RZ7SkKmPj4QUkaceB0bycPP?usp=drive_link

Appendix B - Proposer Compliance Matrix Template Click this link for an editable copy.

Or copy and paste:

https://docs.google.com/document/d/1cjLoDt7-Jf9HaGPgLNOk2QDFA8acPSKKSAIAa5k-xXU/copy

Complete the Compliance Matrix in full. For each requirement:

1. Mark one response:

○ C = Complies (meets the requirement as written)

○ P = Partially Complies (meets some elements, with limitations or conditions)

○ N = Does Not Comply (does not meet the requirement)

2. In the Evidence / Notes column, provide a concise explanation and specific supporting detail

(e.g., product capability, configuration approach, limits/assumptions).

3. In the Proposal Reference column, cite the exact location in your proposal that supports your response (section name and page number).

4. If you mark P or N, you must also:

○ explain the limitation or gap,

○ state whether it is available via a paid option or roadmap (with timeline if applicable), and

○ describe any workaround or alternative approach.

5. Responses such as “Yes,” “Supported,” “Available,” or marketing language without supporting detail may be scored as Partially Complies at the District’s discretion.

https://docs.google.com/document/d/1cjLoDt7-Jf9HaGPgLNOk2QDFA8acPSKKSAIAa5k-xXU/copy

ID Category Requirement C/P/N Evidence / Notes Proposal Ref U-01 Unified Platform Single administrative console for video + intercom + access control + sensors

U-02 Unified Platform Consistent RBAC across modules U-03 Unified Platform Central audit logging across all modules; exportable

ID-01 Identity Active Directory sync (users + groups)

ID-02 Identity Group-to-role mapping supported ID-03 Identity MFA for remote access (describe) SEC-01 Security Encryption in transit (TLS) SEC-02 Security Encryption at rest (cloud required;

on-prem preferred)

SEC-03 Security Patch/firmware management process documented

SEC-04 Security Audit logs: admin actions + access events + exports

VID-01 Video Bridging existing cameras listed in Attachment A

VID-02 Video ONVIF/RTSP or equivalent supported bridging method

VID-03 Video Live view + playback + multi-camera sync

VID-04 Video Export tooling (watermark/chain-of-custody preferred)

VID-05 Video Mobile access with RBAC controls VID-LPR-01 Video/LPR Provide and install LPR/ALPR cameras as part of Phase 1 deliverable (itemized pricing required)

VID-LPR-02 Video/LPR Plate search (full/partial where supported), camera/location filters, and event-to-video linkage

VID-LPR-03 Video/LPR Site-scoped RBAC and audit logs for

LPR searches/results

POC-LPR-01 POC LPR/ALPR capability demonstrated during POC period (temporary setup or approved demo environment)

REC-01 Recording Sizing methodology provided for 1,475 cameras

REC-02 Recording Retention assumptions clearly stated

REC-03 Recording Redundancy/failover strategy provided

REC-04 Recording Behavior during WAN outage defined

SEC-CERT-01 Security (Preferred/Scored)

UL/cUL 62368-1 certification provided for proposed equipment (cameras, intercom hardware, access control hardware, sensors, appliances).

Provide manufacturer certification documentation and list which proposed components are covered.

SEC-CERT-02 Security

ISO 27001 certification (ISMS) for the proposer and/or platform provider (if applicable).

Provide certificate and scope statement (what entities/services are covered).

SEC-CERT-03 Security

For solutions that include cloud services: ISO 27017 certification (cloud security controls).

Provide certificate and scope; identify which cloud services are covered. If no cloud services are proposed, state “N/A – on-prem only.”

SEC-CERT-04 Security

For solutions that include cloud services: ISO 27018 certification

Provide certificate and scope; identify which cloud services are covered. If no

(protection of personal data in public clouds).

cloud services are proposed, state “N/A – on-prem only.”

SEC-CERT-05 Security (Preferred/Scored)

If ISO certifications above are not provided, proposer supplies equivalent third-party assurance (e.g., SOC 2 Type II, independent penetration test summary, or comparable) and describes alignment to controls.

Provide report type, period covered, scope, and summary of controls; note any exceptions.

SUP-01 Support 24/7/365 support included in base support/subscription (no paid add-on), incl. weekends/holidays

Channels + escalation

SUP-02 Updates Firmware/software updates included in base support/subscription (no paid add-on)

Process + controls

SUP-03 Enhancements (Preferred/Scored)

New features/enhancements included; disclose any paid modules/features

List paid modules

INT-01 Door Entry Intercom

33 door entry intercom systems supported with role-based answering

INT-02 Door Entry Intercom

Door release workflow with audit logging

INT-03 Door Entry Intercom

Intercom events link to camera views/clips (preferred)

AC-01 Access Control Supports approx. 110 doors and expandable

AC-02 Access Control Alerts: forced open, held open, after-hours

AC-03 Access Control Phased replacement strategy

AC-04 Access Control Reporting and searchable history AC-05 Access Control Provides a one-badge transition approach for phased Kantech migration, including native P20DYE support or a priced alternate method to maintain one badge

SENS-01 Sensors Sensor module supported in same platform ecosystem

SENS-02 Sensors IAQ: CO2/VOC/PM2.5 supported or roadmap

SENS-03 Sensors Temp/Humidity supported or roadmap

SENS-04 Sensors Water leak supported or roadmap SENS-05 Sensors Noise/vape/occupancy categories declared

SENS-06 Sensors Configurable thresholds…