Security Snag List for India (2026): Tracking Every Defect to Verified Closure

Testing and commissioning always finds things. A camera that never got its final focus, a door controller wired so the lock fails the wrong way, an alarm zone that does not report, a label missing from a cable. None of that means the project failed — it means the work is not finished. The security snag list (also called a defect list or punch list) is the single tracker where every one of those items is written down, ranked, assigned, chased and — the part that matters most — verified closed before anyone signs the system off.

Without it, snags live in someone's head or a WhatsApp thread, get half-remembered, and the system is handed over with hidden problems. With it, nothing is "done" until it has been re-tested and a named person confirms closure. This resource explains where the snag list sits, gives a worked example, a blank copy-ready template, and a field guide — including the one rule that never bends: do not hand over or go live with open critical or life-safety snags.

Scope & how to read this. This is a ready-to-adapt professional template, not authoritative, legal or contractual wording. Severity thresholds, life-safety pass criteria and acceptance rules come from your project specification, the relevant code (NBC = SP 7:2026), the equipment manufacturer and the authority having jurisdiction (AHJ) — verify locally; the template does not set the standard. Snag lists that name people and locations are project records — where they reference footage or personal data, handle per the DPDP Act, 2023. Get professional or legal review before you rely on any snag list to close out a contract.

What it is and where it sits

The snag list is the bridge between "tested" and "accepted." Commissioning and inspection produce findings; the snag list turns those findings into tracked actions with owners and dates, and holds each one open until it is re-checked. It runs alongside — and is fed by — the security commissioning checklist and the device-level test records such as the CCTV testing checklist. When the list reaches zero open critical and major items and every closure is verified, the system is ready for the handover pack and documentation.

Who produces it: usually the security consultant, PMC or the commissioning engineer running the acceptance walk. Who acts on it: the installing contractor and their vendors. Who closes it: the person who raised each snag re-tests and signs it closed — not the contractor's word alone.

The columns and what each one carries

A snag list is only as good as its columns. Too few and items get vague; too many and nobody fills it in. These are the fields that earn their place:

The last column is the one people skip and the one that makes the list trustworthy. "Closed" with no verifier is just a claim.

Severity: what Critical, Major and Minor mean

Severity is what lets you triage — and it is what makes the golden rule enforceable. Adapt the thresholds to your project, but the intent is constant:

• Critical — a life-safety failure or a system-down defect. An egress or fire door that fails locked on power loss; the recorder not recording at all; the alarm not signalling; a fault that endangers people or defeats the whole system. Critical snags block handover, full stop.
• Major — a real functional shortfall that is not immediately life-safety, but must be fixed before acceptance: a camera with a large blind spot, a door held-open alarm not working, a zone mislabelled so response would go to the wrong place.
• Minor — cosmetic or documentation items that do not affect function or safety: an untidy cable loop, a missing label, a slightly off camera name. These can sometimes be closed after handover by agreement, but they are still tracked to closure.

The golden rule. Do not hand over or go live with any open critical or life-safety snag. Major snags are closed before acceptance unless the client formally accepts a documented exception with a firm date. Minor snags are tracked to closure even if handover proceeds. Severity is not a formality — it is what stops a dangerous system being signed off.

A worked example

Example only — adapt to your project. The rows below are illustrative, using generic references and dates written as "specify" or "e.g." Do not treat any value here as a real finding, price or code requirement.

Read it at a glance: two criticals still open (S-001, S-002) means this system cannot be handed over. Two majors must clear before acceptance. The two minors are already closed and each carries a named verifier and date — that is what "Closed" should always look like.

A blank copy-ready template

Copy this into your sheet or print it. Add one row per defect, never two defects on one line.

A useful header block above the table: project name, site, date of walk, who attended, and a running summary line — "Open: __ critical, __ major, __ minor. Handover blocked while any critical is open."

Field guide: filling and closing it well

• One defect per line. "Camera blind spot and cable untidy" is two snags with two severities and two closures. Split them.
• Set severity on every row — no blanks. A snag with no severity cannot be triaged and tends to be forgotten. If you are unsure, rate it up, not down.
• Write the defect, not the solution. "Door fails locked on power loss" is a defect anyone can verify; "buy new mag-lock" pre-judges the fix and hides whether the real problem was solved.
• Attach photo evidence. A photo or short clip of the defect (and later, of the fix) removes argument. Reference the file in the row. Where footage shows identifiable people, handle it per the DPDP Act, 2023.
• Name a single responsibility. "Contractor / vendor / someone" closes nothing. One owner per snag.
• Give a realistic target date. A date everyone knows is impossible is worse than an honest later one.
• Re-test and VERIFY closure — do not accept "contractor says done." The person who raised the snag (or another competent checker) re-runs the original test and signs the verified-closed column. Especially for life-safety items, closure means it was re-tested and passed, witnessed — not reported fixed over the phone.
• Keep the summary current. The count of open critical and major snags is the project's true readiness. Update it every visit.

Common mistakes

• Vague snags — "camera not good," "door problem." Nobody can fix or verify what is not specific. Say what is wrong and where.
• No severity — everything looks equal, so the dangerous item queues behind a cosmetic one. Rank every row.
• Closed without verification — the biggest trap. A "Closed" with no verifier and no date is a claim, not a fact. Re-test.
• Handover with open criticals — the failure this whole document exists to prevent. If a critical or life-safety snag is open, the system is not ready, whatever the schedule says.
• Two systems of record — half the snags in a spreadsheet, half in chat. One list, one number series, one source of truth.

How it connects to the other documents

The snag list is the connective tissue of the closeout stage. It sits inside a small family of deliverables, each of which links to the others:

• The security commissioning checklist and the CCTV testing checklist generate the findings — every failed or partial check becomes a snag with a number.
• The snag list tracks each one to verified closure.
• Only when it reaches zero open critical and major items does the handover and documentation pack get signed, with the closed snag list attached as evidence of a clean closeout.
• After go-live, recurring or newly found defects feed the maintenance and audit process, which uses the same raise-track-verify discipline.

For the full set of adaptable templates and where each one sits, see the security resources library and the professional security resources guide.

Key takeaways

• The snag list is the bridge between tested and accepted — it captures every commissioning and inspection defect and drives it to verified closure so nothing hidden is handed over.
• Every row needs a number, a location, one plain defect, a severity, an owner, a target date, a status and — critically — a named verifier and date at closure.
• Severity is Critical (life-safety or system-down), Major (fix before acceptance) or Minor (cosmetic or documentation). Set it on every row.
• Verify closure by re-test; "contractor says done" is not closed.
• Never hand over or go live with an open critical or life-safety snag — that is the one rule the whole document exists to enforce.

References

• Digital Personal Data Protection Act, 2023 — snag records that reference footage or identifiable people are personal data; keep access controlled and retention sensible.
• National Building Code of India (NBC), current edition (SP 7:2026) and the equipment manufacturer documentation — the authoritative sources for life-safety pass criteria, egress-door fail behaviour and acceptance requirements a snag is tested against; verify the current edition at https://www.services.bis.gov.in/
• Your project specification, tender and the authority having jurisdiction (AHJ) — where severity thresholds and acceptance rules are actually set; this template records against them, it does not replace them.

This is an educational, ready-to-adapt template, not legal, contractual or authoritative wording. Life-safety and code requirements come from the code, the manufacturer and the AHJ — verify locally, and get professional or legal review before relying on a snag list to close out a contract.