How to Write a CCTV Technical Specification for a Tender: Structure, Parameters and Uzbek Regulations

A technical specification is the buyer’s document that sets requirements for the result: which tasks the system solves, at which facility, with which characteristics and how it is accepted. A bill of materials (specification of items) is a list of specific positions with quantities: camera, NVR, disk and switch models, metres of cable. A bill of quantities (BOQ) for works lists installation operations with units: metres of cable laid, number of cameras mounted, commissioning of each point.

In a tender these documents work together, but the order matters. The technical specification comes first; bidders then propose their own bill of materials and BOQ, and the buyer compares the bids against the requirements. Starting directly from one manufacturer’s item list turns the tender into a price comparison for a single model instead of a search for the best solution. For a public buyer it is also a matter of legal compliance — see below.

A good specification is verifiable: every requirement is either measurable (megapixels, archive days, metres of IR range) or checked by a test at acceptance. Phrases such as “high image quality” or “reliable equipment” are useless — they can be neither compared nor accepted.

For a facility with a dozen or more cameras, ten sections work well:

1. Facility and purpose. Address, building use, floor area, number of floors, operating hours and what the buyer wants to achieve: control of the perimeter, goods receiving, cash desks, the entrance checkpoint.
2. Zones and the task in each zone. Overview — you can see what is happening; recognition — actions and objects are visible; identification — a face can be recognised or a plate read. The higher the task, the more pixels must fall on the object and the closer the camera is mounted.
3. Camera requirements. Resolution, lens or field of view, IR illumination, outdoor rating, analytics.
4. Recording and archive. Recording mode (continuous, motion, schedule), archive depth in days, codec.
5. Storage and access. Where the archive physically resides, who views it and from which devices, how recordings are released.
6. Network and power. PoE, switches, backup power, a dedicated CCTV network.
7. Integration. With access control, intrusion alarm, an existing CCTV system or a management platform.
8. Installation requirements. Cable routing method (tray, conduit, trunking), mounting heights, labelling, work in an operating facility.
9. Documentation and training. As-built drawings, equipment list with serial numbers, user accounts, instructions for security staff.
10. Acceptance and warranty. List of tests, warranty on equipment and on works, warranty claim procedure.

Sections 2 and 4 drive the budget most: an “identification” task at every entrance and a 90-day archive instead of 30 days can change the estimate several times over. That is why they are agreed with the facility owner and the security service before the tender is announced, not after bids arrive.

A ready DOCX template of the specification with this structure — the parameters table, the archive formula and the acceptance tests — can be downloaded from this page.

In a specification a parameter is written as a minimum value or a range, not as a model. Sample wording:

The last row matters more than it seems. Manufacturers call the same function by different names, and a proprietary technology name in a specification effectively names a brand. Describe the function instead — “line-crossing and intrusion detection with human/vehicle classification” — and different manufacturers can offer it while the buyer checks it at acceptance.

Headroom in channels and bandwidth is a requirement, not a wish. A fully loaded NVR cannot be expanded without replacement, and high-bitrate cameras on an NVR with weak incoming bandwidth drop frames. Example: 32 cameras at 4 Mbps produce 128 Mbps; an NVR with 256 Mbps incoming bandwidth (the figure listed in the catalogue card of the 32-channel Hikvision DS-7732NI-K4) keeps twofold headroom, while at 8 Mbps per camera it runs at its limit. PoE over twisted pair is limited to 100 metres from the switch, so distant cameras are best specified straight away with fibre or a remote switch.

Archive depth is set in days for a defined recording mode, and the bidder calculates disk capacity. The formula for checking bids: capacity (TB) = number of cameras × bitrate (Mbps) × 86,400 × days / 8 / 1,000,000. Example: 32 cameras at 4 MP with H.265, continuous recording and a bitrate of about 2 Mbps give 64 Mbps — about 691 GB per day and about 20.7 TB over 30 days. The 2 Mbps bitrate is an assumption for a typical scene; the real value depends on settings and motion in the frame. It is therefore safer to write “archive of at least 30 days with continuous recording of all cameras in the main stream” and to check the actual depth at acceptance. For ordinary CCTV the 30-day period in this example is not a legal requirement but practitioners’ advice; a period set by a regulation exists for certain facilities — for example, an archive of at least 6 months for private educational organisations under CM Resolution No. 271 (see the section on regulations).

Storage location is a separate requirement. Law No. ZRU-547 “On Personal Data” defines personal data as information relating to a specific person or allowing that person to be identified (Art. 4), and biometric data as data describing anatomical and physiological features (Art. 26). Article 27-1, as amended by Law No. ZRU-1125 of 26 March 2026, requires biometric data, genetic data and data of telecom operators’ subscribers to be stored on the territory of Uzbekistan. Face templates in access-control terminals and face-recognition systems are biometrics, so their database must reside in the country.

For ordinary video recordings Article 27-1 contains no direct instruction: other personal data may be stored abroad if one of the conditions is met — recognised adequate protection in the destination country, standard contractual clauses, or international standards applied by the operator. This is not a legal requirement but practitioners’ advice: we recommend the conservative option and word it in the specification as follows: “the archive is stored on equipment installed at the facility or in a data centre on the territory of the Republic of Uzbekistan; a cloud service is used for remote viewing.” Agree the final wording for your facility with a lawyer.

For a public buyer, as a general rule, no. Article 34(3) of Law No. ZRU-684 of 22 April 2021 “On Public Procurement”, as amended by Law No. ZRU-1005 of 27 November 2024 (in force from 1 March 2025), prohibits including in a procurement description requirements for or references to a specific trademark or name, patent, design or model, source of origin or manufacturer. There are two exceptions: purchases through the electronic shop, and cases where there is no other sufficiently precise way to describe the characteristics. In the second case the description must include the words “or equivalent”, except where goods are incompatible. The law continues to be amended, so check the version in force on the date the tender is announced.

Incompatibility is a typical situation when an existing system is expanded. If the facility already runs a video management platform from one manufacturer and the new cameras must work fully in it together with analytics, the specification has to justify this: describe the existing system and the functions that must work without modifications. Naming the manufacturer then rests on a compatibility requirement rather than on preference.

A corporate buyer outside public procurement is free to choose, but a brand-neutral specification benefits it too: more bidders mean a fairer price comparison. If a reference model is still needed, a practical approach is to name the model as an example and list measurable equivalence criteria: resolution, field of view, IR range, protection class, codecs, PoE standard, analytics functions, ONVIF support for connecting to the NVR. An equivalent that meets every criterion is accepted — easy to verify and hard to dispute.

The “archive of at least 6 months” requirement for schools is the most expensive one. A single 4 MP camera at 2 Mbps records about 21.6 GB per day and about 3.9 TB over 182 days; 24 cameras recording continuously around the clock need about 94 TB. Recording on a school-day schedule and the H.265+ codec reduce the volume, so a school specification states the recording mode explicitly instead of leaving it to the bidder.

The acceptance section turns the specification into a checklist. A minimum set of tests:

1. Every camera shows an image and records to the archive; the camera list in the NVR matches the drawing and the bill of materials.
2. The actual archive depth meets the specification: the oldest recording is checked once the system completes a full cycle, or depth is calculated from the actual bitrate.
3. Night images are checked in darkness in every outdoor zone; faces or plates are distinguishable in identification zones.
4. Time on cameras and the NVR is synchronised, and archive timestamps are correct.
5. Factory passwords are changed, user accounts are created by role, firmware is updated.
6. Remote access works by role: management, security and IT see only their assigned cameras.
7. Backup power keeps the NVR and switches running during a mains outage.
8. As-built drawings, the equipment list with serial numbers, administrator credentials and instructions for security staff have been handed over.

This is also how we hand over our projects: as-built drawings, the equipment list with serial numbers, network addresses and user accounts are handed to the customer against signature.

Warranty periods for equipment and for installation works, and the warranty claim procedure, are stated as a separate line in the specification — then these terms go into the contract instead of remaining a verbal agreement.

1. A model instead of requirements: the tender shrinks to one item, and for a public buyer this contradicts Article 34 of ZRU-684.
2. No task per zone: bidders offer the same cameras for the entrance and the corridor, and the face at the entrance cannot be made out.
3. Archive stated in terabytes rather than days: disk capacity says nothing about archive depth at a given bitrate.
4. No statement of where the archive is kept and who has access: this surfaces at the first request for a recording.
5. References to Russian SP rules for fire automation instead of ShNK 2.04.09-2007.
6. No headroom in channels, PoE ports and power: expansion a year later requires replacing equipment.
7. No acceptance section: disputes about whether requirements were met are settled verbally.

Send your technical specification, bill of materials or working documentation through the “Supply and Tenders” page or to sales@satsolutions.uz — we will prepare a commercial proposal with an equipment list and a bill of quantities for works based on your requirements; the proposal comes within 24 hours.

• SAT Solutions is the brand of SUPPLY AND TRANSPORTATION LLC, TIN 308603912. Tashkent, 5 Katta Darkhon Street; +998 97 862-66-99; sales@satsolutions.uz; Mon–Fri 9:00–18:00.
• Equipment supply and installation: video surveillance, access control and turnstiles, time attendance, intrusion and fire alarm, intercom, structured cabling and LAN, Wi-Fi, fibre, server rooms. Installation by our own staff: 3 engineers and 15 installers.
• Documents: National Guard permit No. 1554491 — installation, commissioning and maintenance of security equipment; Ministry of Emergency Situations permit No. 913518 of 23 July 2025 — installation, commissioning and maintenance of fire alarm and automatic fire suppression systems; both under the notification procedure of CM Resolution No. 88 of 25.02.2022.
• 3-year warranty on installation works; equipment carries the manufacturer’s warranty of 1 to 3 years.
• satsolutions.uz catalogue: more than 2,500 items; own warehouse in Tashkent, fast-moving items in stock. We work with VAT, prices in UZS including VAT; e-invoices (ESF) are issued through an electronic document-exchange operator.