Security Specification Template for India (2026): Defining What Good Looks Like

A bill of quantities can tell you a project needs twelve cameras, four readers and one recorder. What it cannot tell you is whether those twelve cameras will actually let you recognise a face at the gate at night, survive a monsoon on an external wall, or hand you clean footage a year later. That job belongs to the security specification template — the technical document that defines the required standard, performance and quality of every part of the system, so that bidders quote the same thing and the installer builds to a bar everyone agreed in advance.

This resource is part of Studio Matrx's professional security resources library, and it is the natural partner to the security BOQ template and the security tender template. If the BOQ is the shopping list, the specification is the quality brief that stands behind it.

Scope & how to read this. This is a ready-to-adapt professional template and an explainer, not authoritative or contractual wording. A real specification carries legal and commercial weight, so get professional and legal review before it goes into a tender. All requirements, standards, pass criteria and compliance obligations must come from your project, the relevant Indian codes and your Authority Having Jurisdiction (AHJ) — the template does not set the standard. Nothing here is legal advice, and no exact model numbers, prices or standard clause numbers are stated as mandatory facts.

What a specification is, and where it sits

In the procurement chain — brief, design, tender, award, install, commission, handover — the specification is written during design and issued as part of the tender pack, alongside the drawings and the BOQ. The two documents do different jobs and must never contradict each other:

• The specification says WHAT and HOW WELL — the required outcome, standard and quality of each item and of the system as a whole.
• The BOQ says HOW MANY and PRICE — the itemised quantities each bidder puts a rate against.

A bidder reads the spec to understand the bar, then prices the BOQ to meet it. When the two disagree — the BOQ lists a camera the spec never described, or the spec demands an outcome the BOQ never counted — you get variation claims, disputes and a system that does not do what you thought you bought.

The structure of a good specification

A specification reads best when it moves from the general to the specific and then to the commercial. The framing sections wrap every project the same way; the subsystem sections carry the technical requirements; the closing sections cover how the work is proved and supported.

1. General and scope. What the system is for, the site, the boundary of supply, who does what, and how the document is organised.

2. Standards and compliance. The codes and certifications the equipment and installation must satisfy — Bureau of Indian Standards certification where it applies, the fire-alarm interface which defers to the National Building Code and the fire officer, and data protection under the Digital Personal Data Protection Act, 2023. Rather than asserting specific standard numbers here, point bidders to the current, verified editions and let the BIS standards for security equipment guide and the product certification guide carry the detail. Always confirm the live status of any standard before you cite it.

3. Acceptable equal (the "or approved equal" clause). State that where a brand or model is named it is indicative of the required standard, and an equal product that a bidder can demonstrate meets the stated performance may be offered for approval. This keeps competition open and avoids an unjustified single-brand lock-in.

4. Subsystem performance requirements. The technical heart, written as performance or outcome wherever you can — CCTV, access control, intrusion alarm, power and backup, network and cabling. Say the result you need ("recognise a face at the main gate in day and low light", "no single point of failure on system power") rather than pinning a single make and model, unless there is a genuine, recorded reason to.

5. Workmanship and installation standards. How the work is to be done — cable routing and protection, mounting, labelling, earthing, weatherproofing, neatness and safety on site.

6. Testing and commissioning. What must be demonstrated before acceptance, and the principle that pass criteria trace back to the spec and the code, not to the installer's convenience.

7. Documentation and training. As-built drawings, schedules, passwords, warranties and the handover training the client must receive.

8. Warranty and AMC. The warranty period, response times and the scope of any annual maintenance contract.

A worked example: a spec extract

Below is an illustrative extract showing how a few requirement lines might read. Notice the language — "specify", "recognise", "no single point of failure" — and that the standards column points to a verified source rather than asserting a number.

Example only — adapt to your project. These lines are illustrative to show the style and structure. They are not a set of mandatory requirements, and they contain no fabricated exact specifications or standard numbers. Write your own against your project, your site and your AHJ, and get them reviewed.

Every line answers a "how well", and every "Ties to BOQ item" reference links the requirement to a priced line so nothing is specified but unpriced, or priced but undefined.

A blank, copy-ready template

Copy the structure below into your own document and fill it. Keep the two levels — a section list for the whole spec, and a requirement table for each subsystem.

Specification section list (copy this skeleton):

Subsystem requirement table (repeat per subsystem — CCTV, access, alarm, power, network):

Field guide: making the specification work

Prefer performance over prescription. A prescriptive line names one brand and model; a performance line names the outcome. Performance language lets several qualified vendors bid, keeps pricing honest, and — most importantly — can be tested on site. Reach for a named product only when there is a genuine reason (an existing system to match, a specific integration), record that reason, and always add "or approved equal".

Make every requirement testable. Before you write a line, ask: can I stand on site at commissioning and check whether this was met? If you cannot, rewrite it. "Good quality cameras" is untestable; "recognise a face at the gate, day and low light, at a specified distance" is something you can verify. Requirements you cannot test are requirements you cannot enforce.

Tie the spec to the BOQ, both ways. Every BOQ line should trace to a spec clause, and every spec item should appear in the BOQ. A cross-reference column in both documents is the cheapest insurance against scope gaps and variation claims. Choosing the right systems to specify in the first place is the job of the how to choose a security system guide.

Carry compliance and DPDP through. Because cameras and access logs capture personal data, the specification should require the installer to support data-protection obligations under the DPDP Act, 2023 — access control, retention, signage and secure handling — and should defer any fire-egress interface to the National Building Code and the fire officer. State the obligation and point to the verified source; do not invent the clause.

Common mistakes

• Pasting a brand datasheet in as the spec. A manufacturer's marketing sheet is written to sell one product, not to define your project's outcome. Copying it locks you to one vendor and often specifies things you do not need while missing things you do.
• Untestable requirements. Adjectives like "high quality", "robust" or "state of the art" cannot be checked or enforced. Replace them with a stated outcome you can demonstrate.
• No standards or compliance section. Without it, "certified" and "compliant" mean nothing, and there is no agreed basis for rejecting sub-standard equipment.
• Spec and BOQ that disagree. Items in one and not the other are the single most common source of variation claims. Cross-reference both.
• Copying another project's spec wholesale. A spec written for a different site, climate and risk will quietly carry the wrong requirements into yours. Adapt every line.

How it connects to the rest of the pack

The specification does not travel alone. It is issued inside the security tender template, priced through the security BOQ template, and proved at commissioning against the very requirements it sets. For the wider set of professional deliverables and how they fit together, see the professional security resources guide.

Key takeaways

• The specification defines what and how well; the BOQ defines how many and price. They travel together in the tender and must agree line for line.
• Structure it from general to specific to commercial: scope, standards and compliance, acceptable-equal, subsystem performance requirements, workmanship, testing, documentation, warranty.
• Write requirements as performance outcomes wherever you can, avoid unjustified single-brand lock-in, and make every line testable — if you cannot test it, you cannot enforce it.
• Carry standards, certification and DPDP compliance through, but defer the actual requirements to verified Indian codes and your AHJ. Do not assert standard numbers you have not confirmed.
• This is a template to adapt, not copy. A specification is a contract-adjacent document — get professional and legal review before you issue it.

References

• Digital Personal Data Protection Act, 2023 — security systems capture personal data; the specification should require support for lawful access, retention and handling.
• National Building Code of India and the local fire officer — the authority for any fire-alarm and egress interface; the specification defers to them, it does not set the standard.
• Bureau of Indian Standards catalogue — verify the current edition and status of any standard before citing it in a specification, at https://www.services.bis.gov.in/

This is an educational template and overview, not legal advice or contractual wording. A security specification carries legal and commercial weight — engage a qualified security consultant and obtain legal review, and defer all requirements to your project, the relevant codes and your Authority Having Jurisdiction.