Buying CCTV for an organisation is the process of writing testable requirements into the tender and contract, then accepting the real system before it goes live, as chapter 4 of the NCSA guideline v1.0.0 suggests. The guideline is a recommendation, not law. This article suits buyers, IT and legal teams, and gives a requirement-and-evidence table, an acceptance checklist and the processor-agreement point.
- The NCSA guideline v1.0.0 (29 Sep 2026) is a recommendation without binding force, but a sound basis for tender criteria and acceptance tests.
- Clause 4.1 says avoid vague wording such as "highly secure" or a bare megapixel figure; pair every requirement with a check and a pass criterion.
- Clause 4.2.5: before go-live, remove installer and test accounts, temporary passwords and the installer's remote support channels.
- If a supplier or provider can reach footage for you, PDPA section 40 paragraph 3 requires an agreement with the processor.
A CCTV system whose picture appears on the monitor is not necessarily a finished delivery. A factory-default password may still be in place, the installer's account may still be open, and the vendor's app may be sending footage to a server nobody asked about. That is why the general NCSA guideline devotes an entire chapter, chapter 4, to buying and accepting a system.
This article reads clause 4.1 (security requirements in procurement) and clause 4.2 (secure delivery and acceptance) and turns them into something a buyer can use: a requirement-and-evidence table, an acceptance-day checklist, and the points to write into a contract when a supplier or service provider will touch your footage. The data protection side of the camera itself (signage, lawful basis, retention) is covered in our article on CCTV in offices, shops and condominiums and is not repeated here.
Is the NCSA guideline law, and who is it for?
It is not law. The guideline says of itself, in its preface, that it is only a preliminary recommendation without binding force, and that it cannot replace any law, notification, rule, contract or other requirement that is in force. In this article, "should" always means "the guideline recommends", never "the law requires".
ทั้งนี้ แนวปฏิบัติทั้งสองฉบับนี้เป็นเพียงข้อเสนอแนะเบื้องต้นให้กับผู้ที่เกี่ยวข้อง ไม่มีสภาพบังคับใช้ ไม่สามารถใช้แทนกฎหมาย ประกาศ หลักเกณฑ์ สัญญา หรือข้อกำหนดอื่นที่มีผลใช้บังคับThere is no official English translation of this guideline yet, so the quotation above is in the original Thai. In short: the two NCSA CCTV guidelines are preliminary suggestions to the people concerned, they have no binding force, and they cannot replace laws, notifications, rules, contracts or other binding requirements.
The document is version 1.0.0, the final issued version, dated 29 September 2569 (2026). Clause 4.1 splits the roles. The system owner or buyer sets the requirements and criteria in the terms of reference (TOR); bidders, installers and integrators must show capability and evidence that match them. If the TOR is vague, the supplier has nothing to prove.
The guideline also grades systems into levels B, E and H by importance and impact, and says the strictness of purchasing requirements should follow that level. Those letters are a way of applying this guideline. The text states they are not a legal classification of organisations and not a designation of critical information infrastructure, so do not use them to claim that you are, or are not, CII.
What is the difference between a TOR that can be tested and one that cannot?
A testable TOR says what will be examined, how, and what result counts as a pass. Clause 4.1.1.15 explains why this matters: without it, the buyer cannot say on acceptance day which property passed or failed, or on what evidence.
ข้อกำหนดที่กำหนดไว้ควรสามารถตรวจสอบได้ในขั้นตอนพิจารณาข้อเสนอ การทดสอบ หรือการตรวจรับ ไม่ควรใช้ถ้อยคำกว้าง เช่น “ระบบต้องมีความมั่นคงปลอดภัยสูง” โดยไม่มีเกณฑ์หรือหลักฐานที่สามารถตรวจสอบได้| What people often write | Problem | A testable version |
|---|---|---|
| "The system must be highly secure" | No criteria; the supplier says "yes" and the matter ends | Separate rights to view, search, export and administer by role; the bidder shows documents or a demonstration; it can be tested before acceptance |
| "Cameras of at least 8 megapixels" | Pixel count does not show what the image can be used for | State that the main entrance must give an image at the recognition or identification level set in the point requirements; the bidder shows calculations; test in real conditions before acceptance |
| "ONVIF supported" | Devices may support different profiles or different functions | State the use cases that must connect, and test them against the real equipment |
| "The vendor must notify EoL/EoS" | Unclear what is notified, when, and with what help to migrate | Require status, effective date, the scope of support ending, and the upgrade or replacement path |
The guideline's own example of a poor TOR is one that states only camera resolution. It calls that unsuitable because it cannot confirm that the picture at each location serves its purpose.
ตัวอย่างการกำหนด TOR ที่ไม่เหมาะสม คือ “กล้องต้องมีความละเอียดไม่น้อยกว่า 8 Megapixel”เพียงอย่างเดียว เนื่องจากไม่สามารถยืนยันได้ว่าภาพจะตอบวัตถุประสงค์ของแต่ละจุดหรือไม่Start from the point requirement, not from the camera spec
Clause 4.1.1.7 asks the buyer to write first what the image from each point must be used for: detecting that someone passed, observing behaviour, recognising a known person, or identifying an individual. Only then are specifications and provable acceptance criteria set.
It names the things that can make a high-resolution camera useless: mounting position, distance, field of view, lens, lighting, movement and compression. So ask for tests by day and by night, at the times the system will actually be used, not only in good light.
What should you ask suppliers for, and which evidence goes with each item?
The table below condenses clauses 4.1.1.1 to 4.1.1.13 into a list you can paste into a TOR. We wrote it ourselves rather than copying the guideline's tables, and the last column draws on the sample checks in clause 4.1.1.15. For a small system, use what fits the risk; the guideline itself says to apply it proportionately.
| Topic (clause) | Requirement to write | Evidence to request | Check on acceptance day |
|---|---|---|---|
| Accounts and rights (4.1.1.1) | Default credentials can be changed before use and are not shared across a batch; named accounts; separate rights to view, search, export and administer; MFA where risk calls for it; time-limited accounts for outside providers | Administrator guide or a demonstration of the permissions screen | Create test accounts for several roles and confirm each can do only what its role allows |
| Ports, services and outside access (4.1.1.1 to 4.1.1.2) | Unneeded ports and services can be closed; cameras and admin interfaces need not face the internet directly; admin access can be limited by source; remote access can be limited or disabled | Hardening guide and network diagram | Review settings and try connecting; no unapproved path should exist |
| P2P and vendor cloud (4.1.1.2) | Use can be identified, disabled or controlled clearly | Document showing what data leaves and where the servers are | Compare against the approved scope |
| Event logging (4.1.1.3) | Log successful and failed sign-ins, account and rights changes, configuration changes, remote access, exports, updates, and camera or storage faults | Sample log file | Trigger a test event, such as a wrong password, and retrieve the record |
| Vulnerabilities and firmware (4.1.1.4 to 4.1.1.5) | A reporting channel, security advisories, a support period for fixes, and a way to verify the source and integrity of firmware before installing | Vulnerability disclosure policy, sample advisory, description of the update process | Ask for a demonstration of an update from a trusted source and its verification |
| Encryption and keys (4.1.1.6) | Protect the admin channel with TLS or equivalent; say who controls keys and certificates; protect exported files | Security architecture document | Inspect certificate settings and the export method |
| Image quality (4.1.1.7) | Point requirements, DORI level, pixel density, day and night images, compression that does not make the picture unusable | The bidder's calculations or design | Record test footage at the real distance and lighting |
| Retention and capacity (4.1.1.7, 4.1.1.11) | Hold footage for the period the organisation sets; size storage from camera count, data rate and recording mode | Capacity calculation | Check settings and play back old footage |
| Privacy features (4.1.1.11) | Limit the field of view, mask areas, delete or overwrite on expiry, restrict and protect exports | Manual and settings screens | Try a mask and an export under accounts with different rights |
| Interoperability and exit (4.1.1.8) | State the use cases that must connect; export video and settings in a reusable form; replace cameras or storage without replacing everything | Interoperability test results | Connect to the specified equipment and run the use case |
| Supply chain (4.1.1.9) | The manufacturer can say which models a component flaw affects, assess it, fix it and tell users, without publishing every component | Evidence of the vendor's process | Ask for an example of a past vulnerability case |
| Product lifecycle (4.1.1.10, 4.1.1.13) | Warranty, security patch period, firmware period, spare parts, EoL and EoS dates, advance notice | Product lifecycle policy | Check the manufacturer's documents for support periods and an advisory channel |
| Cloud and outside services (4.1.1.12) | State data and processing location, jurisdiction, who has admin access, subprocessors, key control, backup and recovery, incident notice, return and deletion, and an exit plan | Service documents and contract | Confirm the live environment matches the TOR and contract (see our article on cloud and apps) |
If you want retention periods that match policy, with a record of deletions as evidence, the retention rules and disposal logs in AIPDPA support this; see the demo account.
Evidence comes in levels, and it need not always be a certificate
Clause 4.1.1.14 says to decide at the outset what evidence a bidder must show. The range runs from product specifications, hardening guides, manufacturer policies and security advisories, through demonstrations, test reports, independent assessments and certificates, to documents shown only to assessors under a confidentiality agreement. The level should follow the risk.
A certificate is not the whole answer. Clause 4.1.2 asks what scope it covers, whether it matches the model and version you are buying, whether it is still valid, who issued it, and whether it was self-assessed or done by a third party. Holding a certificate does not mean the product is secure enough in every context, the guideline says, and lacking one should not by itself be the reason for calling a product unsuitable.
The guideline adds that foreign labels or certification schemes are useful supporting evidence, but another country's legal requirements or mandatory criteria should not be adopted automatically as binding rules for a CCTV system in Thailand.
What should the contract say about product lifetime and the day support ends?
CCTV systems are usually used for years, while firmware, software and related services may be supported for a shorter time. Clause 4.1.1.13 therefore asks buyers to look across the whole service life, not only at how long the hardware warranty runs.
TOR หรือสัญญาควรกำหนดว่า ผู้ผลิตหรือผู้ให้บริการจะสนับสนุนผลิตภัณฑ์ในด้านใดและนานเพียงใด เพื่อให้องค์กรสามารถประเมินต้นทุนและความเสี่ยงตลอดอายุการใช้งาน ไม่ใช่พิจารณาเฉพาะระยะรับประกันอุปกรณ์| Topic | Question that needs a written answer | If the seller cannot answer |
|---|---|---|
| Warranty period | What is covered, for how long, and does it include hardware, software or services? | Have the scope written into the contract rather than assumed |
| Fixing vulnerabilities | Until when will the manufacturer issue security updates for this model? | Record it as residual risk and plan to replace the model early |
| Advisory channel | Where will the organisation receive security advisories? | Name the recipient and channel in the contract |
| Spare parts | For how long are spares and replacement devices available? | Consider buying spares or choosing a model that is easy to replace |
| EoL and EoS | When does the product stop being sold, and when does support end in part or in full (patches, firmware, spares, helpdesk)? | Treat the lifetime as uncertain and add compensating controls, such as network isolation |
| Advance notice | How long before EoL or EoS will the manufacturer tell you? | Put a minimum notice period in the contract as a number |
| Transition | How will data and settings move to a new system? | Specify the export format and who pays |
The guideline also warns against a one-line clause such as "the seller must notify EoL/EoS". It asks for a requirement that spells out the end-of-life and end-of-support status, the effective date, the scope of support that stops, and the upgrade or replacement path.
If a supplier or installer manages the system or stores footage for us, do we need a data processing agreement?
If a seller, installer or cloud provider accesses or processes footage that is personal data on your behalf, it can be a data processor, and section 40 of the Personal Data Protection Act requires the controller to have an agreement with it.
In carrying out the activities in accordance with the Data Processor's obligations as assigned by the Data Controller under paragraph one, the Data Controller shall prepare an agreement between the parties to control the activities carried out by the Data Processor to be in accordance with the Data Processor's obligations for compliance with this Act.
The NCSA guideline says the same thing in procurement language. Clause 4.1.1.11 asks the buyer to define roles, duties, security measures, incident handling, return or deletion of data and the use of sub-processors in the contract.
Clause 4.1.1.11 warns that privacy functions in a product, such as masking part of the image, are only tools that help compliance and do not make the use of the system lawful automatically.
| Situation | Likely status | What to do |
|---|---|---|
| Sells cameras and a recorder, hands over, keeps no access | Seller of goods; does not process our footage | The security requirements and acceptance tests in this article are enough |
| The installer keeps an account or remote channel for maintenance and could see footage | May be a processor for the part that reaches footage | Make a section 40 agreement; use named accounts with scope, duration and activity logs under clause 4.2.5 |
| A provider stores footage in the cloud or lets us view it through an app | Usually a processor | Sign an agreement covering the clauses discussed in our article on processor agreements and run the checks in our article on vendor checks |
| The manufacturer uses footage for its own purposes | If it acts outside instructions, section 40 paragraph 2 treats it as controller for that use | Prohibit it expressly and check that sharing is switched off in the app or cloud |
If the provider or its servers are abroad, section 28 on transfers outside Thailand also comes into play. The sequence of checks is in our article on section 28, and the CCTV-specific questions are in our article on cloud and P2P.
What should be checked on handover day before anyone signs?
Clause 4.2 sets the goal wider than seeing a picture. A complete handover lets the owner manage, operate, maintain, audit, recover and upgrade the system without depending on the installer more than necessary.
การส่งมอบระบบ CCTV ไม่ควรถือว่าเสร็จสมบูรณ์เพียงเมื่อกล้องสามารถแสดงและบันทึกภาพได้ แต่ควรยืนยันว่า ระบบที่ติดตั้งจริงตรงตามแบบและข้อกำหนดที่ได้รับอนุมัติ- Before the tender document is issuedWrite point-by-point operational requirements, pick the B/E/H level, and attach an acceptance test to each key requirement.Clause 4.1.1.15
- While bids are evaluatedAsk for the evidence you specified (documents, demonstrations, test reports) and check that any certificate matches the model and scope.Clauses 4.1.1.14, 4.1.2
- Before the contract is signedPut in product lifecycle dates, a processor agreement, cloud conditions and an exit plan.Clauses 4.1.1.10, 4.1.1.12
- During installationWhat is installed must match the approved design; if it differs materially, assess and approve before acceptance.Clause 4.2.1
- Acceptance dayCheck the image, recording, security settings and the documents handed over.Clauses 4.2.2 to 4.2.4
- Before go-liveRemove installer accounts, temporary passwords, remote support channels and temporary firewall rules, then save the result as a baseline.Clauses 4.2.3, 4.2.5
- After acceptanceTrack open issues until closed, or have someone with authority formally accept the remaining risk.Clauses 4.2.8, 4.2.9
Checklist 1: is what was installed what was bought? (clause 4.2.1)
- Cameras: number, model, serial numbers and positions match the approved list
- Recorders and video management software: model, version and licences
- Storage: type, capacity and settings
- Network equipment: models, connections and segmentation
- Installed firmware and software versions, and the system configuration
- Cloud services, remote access and links to other systems match the approved scope
If the installed system differs materially from the TOR, design or bid, the guideline asks for an impact assessment and approval before acceptance, rather than accepting first and discussing later.
Checklist 2: do the image and recording work in practice? (clause 4.2.2)
- Test in real or near-real conditions, using the point requirements as the baseline
- Check coverage, DORI level, day and night use, light handling and motion blur
- Test continuous recording, playback, export, retention, capacity and the alert when storage runs low
- For important systems, test continuity and recovery as specified
The clause closes by saying image quality should not be accepted on resolution or the camera datasheet alone.
Checklist 3: security state before go-live (clause 4.2.3)
- Default passwords and credentials changed, removed or managed
- Accounts created for real users and roles; installation, test and guest accounts removed, disabled or restricted
- Only approved ports and services open; admin interfaces reachable only from set networks and by set rights
- Remote access only by approved channels; MFA working as specified
- Firmware at the approved, still-supported version
- Logging, device clocks, retention, backup and restore, encryption and certificates, and any P2P or cloud service match what was approved
The guideline asks that these results be kept as an approved configuration baseline, to compare against whenever settings change later. Without a baseline there is nothing to compare, so nobody can say who changed what.
Checklist 4: documents to receive (clause 4.2.4)
The documents should let the owner run and recover the system without relying on one installer's memory. A new document is not needed for every item if the information already exists in a system or manual the owner can reach and check.
- Equipment register, and the software and firmware versions actually installed
- Camera layout, network diagram, as-built design, and network data (IP addresses, VLANs, ports and services)
- Role and rights structure, retention settings and the storage calculation
- Backup and restore procedure with test results, maintenance plan, firmware update procedure
- Hardening guide, advisory and vulnerability-reporting channels, support period and EoL/EoS information
- Test and acceptance results, including open items, exceptions and residual risk
Checklist 5: close the back doors used during installation (clause 4.2.5)
Before go-live, remove access and settings used only during installation, testing or handover. The guideline lists eight:
- Installation accounts
- Test accounts
- Temporary user accounts
- Temporary passwords
- Remote support channels
- Temporary authentication tokens or keys
- Temporary firewall rules
- Ports or network services opened for installation or testing
ผู้ติดตั้งหรือผู้ให้บริการไม่ควรคงสิทธิการเข้าถึงระบบของลูกค้าไว้โดยไม่จำเป็น หากจำเป็นต้องคงสิทธิเพื่อการบำรุงรักษาหรือการให้บริการ ควรกำหนดให้ใช้บัญชีที่สามารถระบุตัวบุคคลได้ พร้อมกำหนดวัตถุประสงค์ ขอบเขตสิทธิ วิธีการอนุมัติ ระยะเวลา การพิสูจน์ตัวตน การบันทึกกิจกรรม การเพิกถอนสิทธิและการตรวจสอบการใช้งานตามความเหมาะสมกับระดับความเสี่ยงIf a technician really does need continuing access for maintenance, record it as an agreement: a named person, purpose, scope, approval method, duration and an audit trail, held with the contract rather than agreed orally.
If the contract requires certificates, test reports or third-party assessments (clauses 4.2.6 and 4.2.7)
Do not stop at confirming that a document exists. Check that the evidence is genuine, still valid, in scope, matched to the model and version, and traceable to what was delivered. Clause 4.2.6 says evidence for a different model or covering only some components should not be treated as covering the whole system. For cloud-based systems, clause 4.2.7 asks you to confirm that data location, processing location, subprocessors, admin access, keys, backup, incident notice, return and deletion match the TOR and contract.
What if defects remain at acceptance: can we accept with conditions?
Yes, but in a way that can be tracked. Clause 4.2.8 says not to record merely "will be fixed later", and clause 4.2.9 asks the acceptance reviewer to state the result with reasons, assessed against the criteria set.
หากยังมีข้อบกพร่องหรือข้อกำหนดบางรายการที่ยังไม่แล้วเสร็จ ไม่ควรบันทึกเพียงว่า “แก้ไขภายหลัง” แต่ควรกำหนดให้สามารถติดตามและตัดสินใจด้านความเสี่ยงได้อย่างชัดเจน- The issue: the defect or gap found
- Its impact on data, systems or mission, and the risk level
- An interim measure while it is open
- What must be fixed, who is responsible, and by when
- Status: open, in progress or closed
The guideline gives three sample outcomes, which can be used as a form as they stand.
The key requirements have been verified and nothing makes go-live inadvisable.
Issues remain but there are risk-reducing measures, an owner and a deadline; follow up until fixed or formally risk-assessed, and do not leave them open-ended.
A defect or risk remains above the level the organisation accepts.
A frequent mistake is to assume that signing for the work also accepts the risk. The guideline says this should not be assumed.
Significant residual risk should be considered and accepted in writing by someone with authority in the organisation's risk management process, not signed off by the installer or a technical committee on its behalf.
A sequence for the buyer
- Write the point requirements first and say what each location's image must be used for
- Put testable requirements in the TOR, with the check method and pass criterion for each
- Ask for evidence in proportion to risk, and check the scope, model and version of every certificate
- Get answers on security updates, EoL and EoS in writing before signing
- If anyone can reach footage on your behalf, make a processor agreement under section 40 paragraph 3
- On handover day run the five checklists and save the result as an approved baseline
- Close temporary accounts and channels before go-live, then sign for acceptance
- If you accept with conditions, record an owner and a due date in writing
Frequently asked questions
Does the NCSA guideline require these items in a TOR?
No. The document says it is a preliminary recommendation with no binding force, and it cannot replace laws, notifications or contracts that apply. If a law, rule or contract sets requirements, follow those as well. The guideline is a sound basis for writing criteria.
Does a small shop buying a few cameras need all of this?
The guideline says to apply it in proportion to purpose, context and risk, and it includes a section for small system users. A worthwhile minimum: have the seller change default passwords, close the installer's accounts and remote channels before handover, ask about security updates, and save the settings on acceptance day.
Can a manufacturer's certificate replace an acceptance test?
No. Clause 4.1.1.14 says one certificate should not stand in for all evidence, and clause 4.1.2 asks you to check scope, model, version, status and issuer each time. Equally, a missing certificate should not by itself be a reason to call a product unsuitable.
The installer wants to keep an admin account for maintenance. Should we agree?
Clause 4.2.5 says access should not be kept without need. If it is needed, use a named account with a stated purpose, scope, approval method, duration and activity log. If the installer can see footage, a section 40 processor agreement is also advisable.
We are buying a cloud viewing service from a foreign manufacturer. What else goes in the contract?
Add data and processing location, admin access, subprocessors, key control, incident notice, return and deletion under clause 4.1.1.12. If data goes outside Thailand, section 28 of the PDPA applies too. Details are in our article on cloud and P2P services.
Law and sources
- NCSA Thailand CCTV Security Guidelines (TCSG) v1.0.0, 2026 (guidance, not law) — 4.2
- Personal Data Protection Act B.E. 2562 (2019) — Section 40
Text in the "The text" boxes is copied word for word from AIPDPA's legal knowledge base, transcribed from the Royal Gazette and official documents; every edit is checked by the system against that base, character by character. English wording is an unofficial translation; the Thai text prevails. This article is general information, not legal advice for a particular case.
Do it in the system
Who stands behind this guide?
Written by the AIPDPA legal team · Content owner: Phuwara Krobtaku, Attorney-at-law · Thai Barrister-at-Law · technology & intellectual property counsel
Lawyer's licence no. 477/2558 · Thai Barrister-at-Law · LL.M. in Intellectual Property & IT Law (Gold Medal)