Who can open CCTV footage, and who opened it when?

Shop owners, building managers and DPOs get the same question sooner or later: who opened the footage from three o'clock yesterday afternoon? If you cannot answer, it means the system keeps the images but you do not know who has reached them.

The NCSA's CCTV security guideline of 29 September 2026 has two sections on this. Section 3.4 covers secure operation (accounts, permissions, viewing and exporting footage) and section 3.5 covers maintenance and monitoring (event logs). The companion guideline for AI-enabled CCTV adds section 3.5.7 on protecting logs.

These documents are guidance. Their foreword says they are only a preliminary recommendation with no binding force, so this article never says "the law requires" about their content. For data subject rights and disclosing footage to others under the PDPA, see CCTV at work under the PDPA.

What does the NCSA guideline ask about access to CCTV footage?

Section 3.4 opens with five questions the organisation should be able to answer at any time. They sum up the whole job in one sentence.

In English: who accesses what, through which channel, what can they do, what evidence is there, and is that access still needed? Our translation, not an official one. The five questions turn into five tasks: user accounts, channels, permissions, logs, and periodic review. If one is missing, the question "who opened it?" cannot be answered in full.

Section 3.4.5 explains why playback and export deserve this attention.

Roughly: playback, search, export and disclosure can affect security, privacy and whether the footage can later serve as evidence.

How should CCTV user accounts and permissions be divided?

Section 3.4.3 starts from least privilege: give people only what they need and separate rights by real duties. Someone who watches the live feed at a counter does not need to search old footage, and someone who searches footage does not need to change recorder settings.

The table in section 3.4.3 grades measures differently at levels B, E and H. These are levels of measures by system importance and risk, not a classification as critical information infrastructure (CII), as the document itself says in section 2.2.2.

• Separate viewer and administrator roles: "should be done" at all three levels
• Use accounts that identify the individual and avoid shared admin accounts: "should be done" at all three levels
• Disable guest, anonymous and unused accounts: "should be done" at all three levels
• Review permissions, and revoke when someone leaves a role or a contract ends: "should be done" at all three levels
• Separate rights to view, search, export and configure: "worth considering" at the small level (B), "should be done" at middle and high
• Control vendor and third-party rights specifically: "worth considering" at the small level, "should be done" at middle and high

On how often to review rights, the guideline refuses to set one interval for everyone.

In other words, review frequency should follow risk level, number of users, staff turnover, the nature of the rights and any applicable requirements, with no need for one cycle for every system. A shop with high staff turnover should therefore review more often than a small office with two administrators, and every departure should trigger an immediate review instead of waiting for the annual one.

For installers and outside technicians, section 3.4.1 suggests limiting access by time and purpose ("should be done" at middle and high levels) and logging administrator access and important activity. On passwords and remote access, see default passwords and remote access to cameras.

What should be recorded when footage is viewed, searched or exported?

Section 3.4.5 suggests recording five things about an export: who exported, when, which period of footage, the purpose, and the recipient. It is "worth considering" at the small level and "should be done" at middle and high levels, as is giving each export a reason and an approver.

Restricting playback rights by role and having a procedure for disclosure to outside parties are "should be done" at all three levels.

If footage is likely to become evidence, for example for police or in a dispute, the guideline asks you to keep chain of custody and to be able to say where a file came from.

That is: which system the data came from, which time span, who exported it and when, whether it was altered, and to whom it was handed over. The sequence below is the writer's suggestion for one export request, building on section 3.4.5; it is not guideline text.

1. 1 Receive
   Note who is asking, which period and camera, and whySection 3.4.5
2. 2 Check
   Decide whether there is enough reason and basis to disclose; if unsure, ask the DPO or legal counsel firstSection 3.4.5
3. 3 Approve
   A designated approver signs off, preferably not the same person who exports, if staffing allowsSection 3.4.5
4. 4 Export
   An authorised person exports; the system or logbook records exporter, time and period; the exported file is protectedSection 3.4.5
5. 5 Hand over
   Record the recipient and method; keep chain of custody if it is evidenceSection 3.4.5
6. 6 Review
   Check the monthly export list for anything unusualSection 3.5.2

Which events should a CCTV system log, and for how long?

Section 3.5.2 asks for logging as far as the system allows, and not everything equally. The reason for logging comes first.

Our reading: logging should support spotting anomalies, looking back and investigating incidents, and bulk logging with no purpose and no one responsible for using it should not be switched on. The section lists 13 kinds of event to consider, including logins and logouts, failed logins, changes to accounts and permissions, setting changes, enabling remote access, firmware updates, data exports, changes to retention, cameras or devices going offline, disk faults, changes to system time, tampering or blocking of a camera, and connections to unusual destinations.

Those most tied to who opened footage are logins, exports, permission changes and retention changes. A change of system time matters just as much: the guideline notes that it can affect the accuracy of evidence and later review.

Two other measures in section 3.5.2 are "should be done" at all three levels: set a log review cycle by risk, and set log retention according to law, requirements and purpose. Synchronising clocks, protecting logs from unauthorised edits or deletion, and alerting on important events are "worth considering" at the small level and "should be done" at middle and high.

On retention, the guideline gives no number and cautions against one default for all systems.

In short: do not set one retention period for all CCTV systems by default unless a law or applicable requirement sets one.

Does every CCTV system have to keep 90 days of logs under the Computer Crime Act?

Not on the wording of the Act, and the NCSA guideline warns about exactly this in section 2.2.2: do not conclude that every CCTV system has a duty to keep logs in the same form or for the same period. That sentence sits in a table in the document, so we summarise it rather than quote it as text.

Section 26 of the Computer-Related Crime Act B.E. 2550 (2007) concerns a "service provider" keeping "traffic data". Both terms are defined in section 3. Start with traffic data.

Our reading is that the pictures a camera records are image content, not data about a communication, while a log of a device's connections to a network or the internet could fall within the definition. That is the writer's interpretation, not a ruling; take legal advice on a real case. Section 26, first paragraph, says:

Who is a "service provider"? Section 3 gives two limbs: a person who provides others with access to the internet or the ability to communicate through a computer system, and a person who stores computer data for the benefit of others. A shop that runs cameras for its own premises does not automatically fit either. A company that stores camera footage on the cloud for customers might fit the second, depending on the facts of each case.

Section 26 also leaves the reach of the 90-day duty to the Minister.

We did not check that notification while writing, so we do not say which types are covered. What the text does show is that the 90-day duty attaches to a "service provider" and to "traffic data", not to every CCTV camera. A business that keeps logs for PDPA reasons must set its own retention period and be able to justify it, as section 3.5.2 says by pointing to law, purpose and risk. The clash between a log-retention duty and an erasure request is covered in a customer asks for erasure but the law says keep logs for 90 days.

Who should see and do what with footage? A role table

This table is the writer's suggestion building on sections 3.4.3, 3.4.5 and 3.5.2, to show what each role should be able to do and what evidence to keep. It is not a table from the guideline. Adjust it to your size.

What do the PDPA and the AI-CCTV guideline say about access and logs?

Under the PDPA, footage that identifies a person is personal data. Section 37 (1) of the Personal Data Protection Act B.E. 2562 (2019) requires the data controller to provide appropriate security measures against unauthorised access, use and disclosure. Limiting rights and keeping a trace of access are practical ways to do that.

The section does not say "you must keep logs" or "you must separate accounts". What is appropriate depends on the risk in each place. Sections 3.4 and 3.5 of the NCSA guideline work as a checklist that helps you explain what you considered, not as a legal line between right and wrong.

Logs are themselves data to look after, since they often hold account names, times and device addresses. The AI-CCTV companion guideline speaks to this directly in section 3.5.7.

In plain English: important logs should be protected from unauthorised access, editing or deletion and kept for a period that suits their purpose, requirements and risk; and logs that contain personal data or high-impact data should be protected to the level of that data. The text sits in the AI volume but works as a principle for ordinary cameras too. If your system analyses video with AI or uses biometrics, read that volume as well, because those logs may be more sensitive.

Mistakes to avoid with CCTV rights and logs

If you find that footage was opened or exported with no one accountable, assess whether it is a personal data breach. For that, see what to do when CCTV footage leaks.

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)