Factory Video Analytics RFP Template (India): Acceptance Criteria, DPDP and Exit Clauses
An RFP for video analytics should buy outcomes you can test, not features on a slide. Write each use case as a measurable test run on your own footage. Name the factory as data fiduciary and the vendor as processor under a written contract. Fix where video sits, and price the exit before you sign.
By the Mama Editorial Team. Mama scopes camera and floor-visibility projects for Indian factories. This is a working template, not legal advice: paste and edit the clauses, then have your lawyer review them before they go to bidders.
Key takeaways
- A CCTV tender buys hardware; an analytics RFP buys a result. Keep hardware clauses in the CCTV tender specification template.
- Each use case needs three things before bidding: what counts as an event, how it is measured, and the pass mark.
- Accuracy is proven on your cameras, lighting and shifts, not on a demo video.
- Under the DPDP Act the factory stays responsible "irrespective of any agreement to the contrary".
- Exit terms cost nothing to agree before signing and a lot after.
Why the CCTV tender template is the wrong starting point
A CCTV tender covers BIS CRS registration, STQC ER test reports, pixel density, PoE and retention, not whether software can tell you a moulding machine sat idle for 47 minutes on the second shift.
Analytics fails differently: a misread slow machine, a dropped cloud link, your footage training the vendor's next model, history locked in a vendor-only format. So use the tender template for cameras and this one for the analytics service. For the meeting with shortlisted vendors, the 17 questions to ask a CCTV/AI vendor work alongside it.
Part A: use cases as measurable acceptance criteria
The commonest mistake is a list of nouns ("idle detection, people counting, heat maps") that every bidder ticks. Write tests with pass marks instead.
| Use case | What counts as an event | How it is measured | Pass mark (fill in) |
|---|---|---|---|
| Machine idle time | Machine not cycling for more than [5] minutes during a shift | Vendor's daily idle minutes per machine vs a manual log or controller data over [10] shifts | Daily total within ±[10]% on [8] of [10] shifts |
| Line stoppage | Whole line stopped for more than [3] minutes | Each stoppage start and end time vs a supervisor log | ≥[90]% of stoppages caught; start time within [2] minutes |
| Material waiting | Pallet or WIP held in a marked zone for more than [30] minutes | Count of events vs a sample reviewed by your staff | ≥[85]% of alerts are real |
| Headcount on a line | Number of people at the line, never named | Hourly count vs a physical count at [20] random times | Within ±[1] person on ≥[85]% of checks |
Fill the brackets before the RFP goes out and attach the table as Annex A.
Part B: accuracy proof on your own footage
B1. Proof of accuracy. "Before any order beyond the pilot, the Bidder shall run the proposed analytics on the Purchaser's own cameras for [14] consecutive working days, covering all shifts including at least [3] night shifts. The Purchaser will mark a ground-truth sample of [N] events per use case, drawn from footage the Bidder has not seen in advance. The Bidder shall report, per use case, (a) the share of its alerts that were real events and (b) the share of real events it caught, with the raw event list in CSV. Results below the pass marks in Annex A allow the Purchaser to end the evaluation with no further payment."
A single "accuracy" figure hides two numbers. Of the alerts raised, how many were real (precision)? Of the real events, how many were caught (recall)? Alerting on everything catches every event and buries the supervisor in noise. Ask for both, per use case. Sample your worst conditions: dust, glare, night shift. The 30-day pilot plan shows how to take a baseline first.
Part C: architecture and integration
C1. Camera access. "The solution shall read video from the Purchaser's cameras over RTSP and/or ONVIF (Profile T preferred) using a read-only account. It shall not require a firmware change, a password change or admin rights on any camera or NVR without the Purchaser's written approval. NVR recording shall continue unaffected."
C2. Where processing runs. "The Bidder shall state whether video is processed on equipment inside the plant (edge), in a cloud, or both. For each, state what leaves the premises (video, still images, metadata or text only), the upload bandwidth needed per camera, the city and country where any data is stored, and what happens if the internet link drops."
C3. Data export. "Results shall be exportable at any time as CSV or JSON through a documented API or scheduled file drop, with machine ID, event type, start and end time. No export shall carry a fee."
ONVIF lists Profile S as being deprecated, last conformance submissions 31 March 2027 (ONVIF Profile S), hence C1 prefers Profile T. The bandwidth and downtime trade-offs behind C2 are in cloud vs edge AI for Indian factories.
Part D: data ownership, storage and DPDP
Recognisable worker video is personal data under the Digital Personal Data Protection Act, 2023. The factory decides why and how it is processed, so it is the data fiduciary; the vendor processing it on the factory's behalf is a data processor. Section 8(1) keeps the fiduciary responsible "irrespective of any agreement to the contrary", section 8(2) requires "a valid contract" for processing a vendor does on its behalf, and Rule 6(1)(f) wants security safeguards written into that contract. This section is it.
The DPDP Rules, 2025 were notified on 13 November 2025; Rule 1(4) brings Rules 6, 7 and 8 into force eighteen months later, on 14 May 2027, while a contract signed now is still running.
D1. Roles. "The Purchaser is the Data Fiduciary and the Bidder is a Data Processor within the meaning of the DPDP Act, 2023. The Bidder shall process personal data only on the Purchaser's documented instructions and only for the purposes in Annex A."
D2. No secondary use. "The Bidder shall not use the Purchaser's video, images or derived data to train, test or improve any model, or for any other customer, without the Purchaser's prior written consent for that specific use."
D3. Aggregate people data. "Outputs about people shall be counts or zone totals only. The solution shall not identify, name, rank or score individual workers and shall not use face recognition, unless the Purchaser separately instructs it in writing."
D4. Security safeguards. "The Bidder shall maintain at least the safeguards in Rule 6(1) of the DPDP Rules, 2025: encryption or masking, access control, access logs with monitoring and review, and backups. Access logs shall be kept for [one year] and supplied to the Purchaser on request."
D5. Breach notice. "The Bidder shall notify the Purchaser of any personal data breach within [12] hours of becoming aware of it, with the facts the Purchaser needs to inform the Board and affected persons under Rule 7."
D6. Storage location. "Personal data shall be stored and processed in [India / the plant only]. No transfer outside India without the Purchaser's prior written approval, and in any case subject to section 16 of the Act."
D7. Retention and erasure. "Raw video held by the Bidder shall be erased after [N] days. On termination, the Bidder shall erase all personal data received from the Purchaser and issue a signed deletion certificate within [30] days, except where a law requires retention, which the Bidder shall name in writing."
Why these numbers. Rule 7(2) gives the fiduciary seventy-two hours after becoming aware of a breach to send the Board its detailed report, so the vendor's window in D5 must be much shorter. Rule 6(1)(e) asks for logs to be kept for one year. Rule 8(3) also asks fiduciaries to keep personal data, traffic data and processing logs for at least a year, for its Seventh Schedule purposes; how that sits with a short CCTV overwrite window is a question for your lawyer. Section 8(7)(b) requires the fiduciary to make its processor erase data once the purpose is served, which D7 does. The worker-facing side is separate: post a worker CCTV notice.
Part E: pilot terms, exit and data return
E1. Pilot. "Pilot of [30] days at a fixed all-inclusive fee of ₹[X], creditable against the first year if the Purchaser proceeds. No automatic conversion to a paid term."
E2. Termination for convenience. "After the first [12] months, either party may terminate on [60] days' notice without penalty."
E3. Exit assistance. "On termination, the Bidder shall deliver within [15] days all derived data (events, reports, settings, zone definitions) in CSV or JSON, at no charge, and remove any equipment it owns at its own cost."
E4. Price lock. "Fees for years 2 and 3 are fixed in this contract, or capped at [5]% annual increase."
Quote structures (per camera, per site, licence plus AMC) are compared in how factory video analytics is priced in India.
Part F: support SLAs
F1. Service availability. "The daily report shall be delivered by [08:00] on at least [95]% of working days in each month."
F2. Fault response. "Faults reported between [09:00 and 18:00] shall be acknowledged within [4] working hours and fixed within [2] working days, or a service credit applies."
F3. Service credits. "For each full working day beyond the fix window, a credit of [10]% of that month's fee applies, capped at [50]% of the monthly fee. Re-tuning within [5] working days after a camera move or layout change is included for up to [4] changes a year."
Worked ₹ example: what the clauses are worth
Illustrative assumptions only, not market prices: a 24-camera deployment at ₹1,200 per camera per month, a ₹50,000 pilot, 20% of year-one fees held back until the Part A tests pass, and one 4-working-day analytics outage in year one.
| Item | Working | ₹ |
|---|---|---|
| Monthly fee | 24 × ₹1,200 | 28,800 |
| Year-one fees | 28,800 × 12 | 3,45,600 |
| Holdback until acceptance (20%) | 3,45,600 × 0.20 | 69,120 |
| Pilot fee credited on go-live (E1) | assumed | 50,000 |
| Service credit for the outage (F3) | 2 days beyond the 2-day fix window × 10% × 28,800 | 5,760 |
| Export fee on exit (C3, E3) | set at nil | 0 |
| Years 2–3 at a 5% cap (E4) | 28,800 × 12 × (1.05 + 1.05²) | 7,43,904 |
The holdback is the lever: ₹69,120 held until the system passes on your footage changes how a vendor staffs the first months. Without E4, year-two pricing is the vendor's call once your team relies on the reports.
A suggested scoring split: results on your own footage 40%, data and exit terms 20%, integration 15%, support 10%, three-year cost 15%.
What an RFP, and the cameras, cannot settle
- Cameras see that a machine stopped, not why. Tool change, missing material or breakdown usually needs an operator entry or controller data. Do not make "reason for stoppage" a pass mark unless you supply that data.
- People are counted, not judged. Headcount at a line is measurable; whether people worked well is not for video to decide, and D3 keeps it out.
- Blind spots stay blind. A machine behind a pillar or in a dark bay cannot pass Part A. Fix coverage or drop the use case.
- A 14-day test is a sample. Monsoon light or a new product mix can change results, which is why F3 covers re-tuning.
- Contracts do not transfer DPDP duty. Section 8(1) is explicit. The vendor shares the work; the factory stays answerable.
Where Mama fits
Mama reads a factory's existing cameras over RTSP/ONVIF and sends the owner a short morning note on where machine hours leaked the day before, with people only ever counted, never named. Mama can draw a camera plan for the machines and zones in your Annex A, so coverage gaps show up before bidders do. Leave an email or phone in the form below.
FAQ
What should an RFP for factory video analytics include? Use cases as measurable tests with pass marks, an accuracy run on your own footage, integration terms, DPDP processor clauses, pilot and exit terms, and SLAs with service credits.
Is the analytics vendor a data processor under the DPDP Act? Usually yes: it processes worker video on the factory's behalf, so put it under a written contract (section 8(2), Rule 6(1)(f)). The factory remains responsible regardless. Have your lawyer confirm this for your setup.
How do I check a vendor's accuracy claim? Run it on your own cameras for two weeks across all shifts, mark a ground-truth sample yourself, and compare the share of alerts that were real and the share of real events caught. Ask for the raw event list.
Should the RFP require edge processing? Not by default. Require bidders to state what leaves the plant, where it is stored and what happens when the link drops, then score the answer against your bandwidth and data-location needs.
Can I use the CCTV tender template for analytics? Only for the cameras. Hardware clauses do not test whether software produces correct results, protects data or lets you leave.