Writing Security Tender Specifications: Requirements, Bid Responses and Acceptance Tests

A useful security tender specification tells bidders what the system must achieve, what evidence their response must include and how the installed result will be accepted. A long list of catalogue features can still leave those questions unanswered. For NZ projects, write measurable requirements around operational tasks, interfaces and ownership, then ask bidders to explain exactly how their proposed solution meets them.

Begin with operational outcomes and boundaries

Describe the site, users, operating hours, critical areas and problems the project must address. Separate the client's required outcomes from a preferred hardware approach. For example, an entrance camera may need to support investigation of a defined approach route under stated lighting conditions. Specifying megapixels alone does not describe that outcome.

Define what is included and excluded: network changes, cabling, mains work, door hardware, monitoring, licences, training and maintenance. Identify existing systems that remain in service and any staged migration constraints. Give bidders the same available drawings and survey information, with a process for reporting assumptions and gaps rather than encouraging silent guesses.

Use unique requirement identifiers

Give each important requirement an identifier and a clear statement. Avoid combining several obligations in one sentence where a bidder can answer yes while meeting only part. State which requirements are mandatory, which are desirable and which need a proposed alternative. Keep the terminology consistent across schedules, drawings and the response form.

An illustrative requirement might read: CCTV-07, the contractor shall demonstrate playback and export of a test event from each designated entrance camera using the agreed operator workstation. Add the test conditions and required evidence in the acceptance plan. This is more assessable than describing the system as professional grade without explaining how that quality will be demonstrated.

Specify interfaces and compatibility evidence

List the exact existing platforms, versions and interfaces that matter. Ask bidders to identify supported integration methods, licences and limitations. A broad ONVIF, SIP or API claim does not establish every intended workflow. Require evidence tied to the proposed model, firmware and function, and identify any integration that still needs a witnessed demonstration.

For access control, describe the opening's operational behaviour, permission needs and relevant monitoring points. For CCTV, describe recording, retention assumptions, export and user access. For alarms and intercoms, describe destinations, fault reporting and response. Assign ownership of each cross-system interface so a gap cannot fall between the security contractor and IT provider.

Where a named product is necessary, explain the reason and handle alternatives according to the applicable procurement process. Do not call products equivalent solely because headline specifications resemble each other. Ask the bidder to map each alternative to the same requirements and disclose differences in ongoing licences, service access and migration effort.

Ask for an evidence-based response matrix

Ask bidders to reference evidence by document section, rather than attach a large brochure with no explanation. Require material assumptions to be visible in the matrix. A response that relies on a future software feature or an unconfirmed accessory should be treated as a dependency, not as an established capability.

Make acceptance conditions measurable

Define representative operating conditions and the observed result that constitutes acceptance. Include normal operation, denied or failed actions, faults and recovery. Specify who supplies test subjects, test credentials, network access and witnesses. Resolve conditions that cannot be reproduced at handover, such as seasonal lighting, through an agreed verification or deferred test arrangement.

Distinguish factory evidence, design calculations, local installation tests and end-to-end site tests. Each proves something different. A camera image on a handheld tester does not establish recording retention. A power supply datasheet does not establish voltage at the farthest lock. Ask for the right evidence at the right stage rather than demanding one generic system passed statement.

Avoid invented universal thresholds. Set response times, retention, standby and image tasks from the project's assessed need and applicable requirements. Explain the assumptions behind calculations and how variations will be approved. If the brief is silent, a bidder may reasonably price a different service level from the one the client later expects.

Evaluate capability and ownership as well as equipment

New Zealand Government Procurement guidance distinguishes evaluation criteria and methodology. For applicable procurements, confirm the current rules and the buyer's process rather than applying public-sector obligations indiscriminately to every private tender. The practical lesson is to decide in advance how evidence, capability and value will be assessed.

Ask about the proposed team, relevant experience, commissioning approach, training and support arrangements. Require clarity on account ownership, configuration backups, licence renewal and access to service information. An attractive equipment schedule can hide a dependency on one installer holding the only administrative password or recovery file.

Separate initial supply from ongoing services. Request transparent schedules for licences, monitoring, communications, maintenance and optional works where relevant. This guide does not set public wholesale prices or declare a cheapest platform. Its purpose is to make competing offers comparable against the same scope and operating assumptions.

Control clarifications and changes during procurement

Use a documented question process and issue relevant clarifications consistently to bidders under the procurement procedure. Track changes to drawings, door counts, camera locations and acceptance criteria. A late site change can affect cabling, power, storage and licences, so update the related schedules together.

Require bidders to identify departures clearly rather than bury them in general terms. After selection, carry accepted requirements and approved variations into the contract and commissioning matrix. Otherwise, the tender may promise one system while the handover tests assess another. Keep responsibility for resolving unresolved design details explicit.

Specify the handover package before work begins

Request as-built drawings, equipment and firmware schedules, configuration backups, test reports, training records and an accountable defects list. Define the secure method for transferring credentials and sensitive information. Include maintenance responsibilities and any agreed post-handover checks, especially where the system depends on external services or recurring licences.

Before releasing the tender, ask a reviewer unfamiliar with the drafting process to follow one requirement from operational need through bidder evidence to acceptance test. If the chain is unclear, rewrite it. A good security specification reduces ambiguity early and gives the installer, evaluator and client a shared basis for deciding whether the project has delivered its intended result.

Equipment selection and technical references

Use these access control options as a starting point for a project specification. The pictured items are equipment candidates, not a pre-approved complete design. Confirm model, accessories, interface support and suitability before ordering.

Related installer guidance: Security project planning checklist nz installers.

Primary references checked 24 October 2026: www.procurement.govt.nz technical guidance; www.procurement.govt.nz technical guidance.

Get project specification help

Contact Essential Security Supplies with your site layout, proposed equipment and operating requirements. Ask for model-specific technical support or a trade quotation before finalising the design.