CCTV RFP Requirements: IP Camera Specification Checklist

Define the operational requirement first

State what the video must help a person decide: identify a face, read a plate, verify a transaction, observe a boundary, investigate an incident, or document a process. Record the target, distance, approach direction, height, light, movement, obstruction, operating hours, and acceptable evidence limit.

A CCTV RFP becomes easier to compare when each camera group has a scene and task brief. Ask bidders to show how their proposed position, lens, illumination, image settings, and recording workflow meet that task under the difficult condition—not only in a daytime sample image.

• Scene, target, viewing task, and required evidence
• Day, night, backlight, motion, weather, and obstruction conditions
• Camera role, mounting, lens, lighting, privacy mask, and blind-spot assumptions
• Site survey, proof-of-concept, and acceptance-test responsibility

Specify engineering and lifecycle boundaries

Include the traffic and trust-boundary questions: camera count, bitrate, codec, frame rate, PoE class, switch budget, uplinks, recorder or cloud destination, live view, playback, export, time, DNS, updates, and approved remote support. Require the bidder to state assumptions instead of hiding them in a product family label.

Add product-security and privacy requirements that can be evaluated: initial credential handling, named roles, MFA or identity integration where supported, encryption behavior, security logs, vulnerability reporting, firmware support, rollback, data location, retention, supplier access, and end-of-life. Separate a vendor’s organization certificate from evidence about the proposed product and service.

• Network, PoE, storage, retention, availability, and recovery assumptions
• Cybersecurity baseline, firmware lifecycle, vulnerability response, and support access
• Privacy, audio, analytics, masking, access, export, deletion, and transparency conditions
• ONVIF or other integration profiles, exact firmware, APIs, events, recording, and export behavior

Make every bid comparable and testable

Use a response matrix with columns for requirement, bidder response, exact model or version, evidence reference, assumption, exception, cost impact, and acceptance method. Ask every bidder the same question and score unknowns as unknowns; do not convert a missing answer into an assumed capability.

Define a proof-of-concept before award and an acceptance test after installation. Tests should cover the image task, bitrate and storage, PoE startup, denied network paths, account roles, time, recording, search, export, integration events, failure recovery, privacy controls, and handover evidence.

• Mandatory requirement, desirable feature, or future option
• Document, configuration, demonstration, proof-of-concept, or site test as evidence type
• Pass or fail condition, test owner, retest rule, and exception approval
• Warranty, service-level, license, replacement, training, and exit responsibility

Write the handover and change rules

The RFP should carry into the contract and commissioning record. Require an as-built network and camera map, asset and firmware inventory, account and support process, configuration backup or recovery method, test results, open-item list, privacy record, and named operational owner.

Define what happens when a model, firmware version, cloud region, supplier, support path, analytics function, or data flow changes. A replacement that looks similar can change codec, power, exposure, evidence quality, privacy, or integration behavior, so make material substitutions subject to review and retest.