CCTV in the cloud and on apps: questions to ask first

Footage kept in the cloud, or viewed through a mobile app, is convenient because nobody has to walk to the recorder. The price is that part of the footage, and part of the control over who can open it, now sits outside the network the organisation runs itself. The NCSA guideline v1.0.0 (29 September 2026) does not forbid this, and it does not claim the cloud beats an on-site recorder. It asks you to ask the whole set of questions: where is the footage, who can reach it, who is responsible for what, and how do you get it back if you stop using the service.

This article reads clause 3.3.3.4 (P2P and external services) and clause 5.1 (apps, mobile devices, cloud and external services) of the general guideline, and sets them beside the National Cybersecurity Committee's cloud standard notification of 2024 and section 28 of the Personal Data Protection Act. The NCSA guideline is a recommendation with no binding force. The Committee's notification is an actual notification with a defined scope. Keep the two apart.

The PDPA side of the camera itself, such as signage, lawful basis, retention and who may view footage, is in our article on CCTV in offices, shops and condominiums. This one is about footage that leaves your own equipment.

How do P2P cameras, mobile apps and vendor clouds differ from a recorder in the office?

They differ in who the middleman is. A recorder in your office (an NVR or DVR) is in your hands. A P2P or vendor-cloud service routes the app's connection through servers run by the manufacturer or a provider. We split storage into four setups to make decisions easier: in the camera, on an on-site NVR, in the manufacturer's cloud, and in a cloud you chose yourself. The guideline does not divide things this way itself.

This is an excerpt of clause 3.3.3.4 in the Thai original; the guideline has no English translation yet. In short: P2P or the manufacturer's cloud can make outside access easy, but it should be governed the way any other remote access route is. The same clause adds that P2P or cloud should not be called safe or unsafe by the name of the technology alone, but judged on architecture, controls and actual risk.

The eight questions clause 3.3.3.4 asks before you switch it on

1. Connection route: through which system or service does it connect?
2. Data sent out: what data or metadata leaves the organisation?
3. Location: where are the servers, according to what the provider discloses?
4. Who has access: who can support or administer the system?
5. Authentication: is MFA supported?
6. Control: can the service be switched off or restricted?
7. Logging: are there enough event logs?
8. Exit: how can you move away or end the service?

Note the wording "according to what the provider discloses" in the third question. A server location is the provider's own statement, so ask for it in writing in the service documents or the contract rather than relying on a sales web page.

How should a mobile app that views the cameras be controlled?

Like any other route into the system from outside, not as a toy on a phone. Clause 5.1.1 asks you to consider the account, the app, the phone and the data that may be left on it, all at once.

The Thai excerpt says that viewing CCTV through a phone, tablet or app adds convenience for monitoring and response, but should be controlled in the same way as other remote access. The measures clause 5.1.1 recommends, in our words:

• Use named accounts and avoid shared ones
• Use MFA for high-privilege accounts or outside access when the service supports it
• Limit who can play back, export and administer, by duty
• Do not switch on public or unauthenticated sharing of footage or links without a reason and suitable controls
• Phones should have a screen lock, run a supported operating system and not be modified in ways that weaken security
• If a phone is lost, it must be possible to revoke the sessions, tokens or accounts concerned
• Do not save CCTV footage to personal storage on the device unless necessary
• Keep the app on a supported version and turn on sign-in alerts where available

For high-risk systems the guideline says mobile device management (MDM) or an equivalent measure may be considered.

Should footage be kept on an NVR or in the cloud, and what should you ask first?

No storage setup is right every time, and chapter 5 of the guideline warns in both directions. An in-house system that is never updated, has shared accounts, no event logs and uncontrolled remote access may be riskier than a managed and audited cloud service. Conversely, a cloud service where nobody can say where the data is, who can access it or who holds the keys may be unsuitable for a high-impact system.

The Thai excerpt above is a single sentence stating exactly that: an internal system that is not updated, has shared accounts, no event logs and uncontrolled remote access can carry higher risk than a systematically managed cloud service, while a cloud service where the organisation cannot tell where data is stored, who can access it, who controls the keys or how data is deleted at exit may be unsuitable for a high-impact system.

The guideline sums up the principle this way: judge by the risk and the controls that actually exist, not by the name of the service model.

What must a cloud provider answer before footage goes there?

Clause 5.1.3 lists eight things an organisation should be able to answer. The table below is our own condensed version, with the reason for each question.

The guideline adds that if a law, sector rule, organisational policy, procurement requirement or contract says certain data must be stored or processed in Thailand, that condition should be stated clearly and be verifiable.

Who is responsible for what must be written down

Clause 5.1.4 asks you to agree clearly who manages accounts and MFA, encryption and keys, logs, patches, backup and recovery, incident handling, the data life cycle and exit, and to record this in the contract, the service documents or a responsibility matrix. The advantage of a matrix is that when an incident happens, nobody argues about whose job it was.

If the provider can access or process personal data for you, clause 5.1.5 asks you to define the data scope, purpose, the controller's instructions, confidentiality, security measures, subprocessors, breach notice, help with data subject requests, return and deletion, and audit rights. That is the same list the PDPA side requires in a processor agreement; the full list is in our article on processor agreements. If a provider is the only one touching footage, also list it in your record of processing activities (RoPA), which AIPDPA provides; see the demo account.

Does the National Cybersecurity Committee's 2024 cloud standard apply to our cameras?

It depends on whether your organisation is an "agency" as the notification defines the word. The notification was issued under the Cybersecurity Act B.E. 2562 (2019), and clause 3 gives the definition.

Clause 4 attaches the duty to agencies that use a public cloud service.

Clause 5 adds that where the data is personal data, the confidentiality impact level is to be set at medium or above, under the 2023 notification on determining cybersecurity characteristics. So for a state agency, regulator or critical information infrastructure operator that keeps camera images showing faces on a public cloud, the footage is personal data and clause 5 can apply. A private business outside the clause 3 definition is not bound directly by the notification, though its provider or a contract with such an agency may bring the standard to it. The standard as a whole is explained in our article on the 2024 cloud standard.

Clause 5.1.2 of the CCTV guideline says briefly that organisations within the notification's scope should consider its requirements when using cloud for CCTV, and that the guideline does not replace the notification, so both should be followed. For high-impact systems the notification adds provider qualification and certification requirements, such as ISO/IEC 27017 or CSA STAR Level 2 under stated conditions, but the guideline warns against applying them to every CCTV system alike.

Footage on a foreign server: does PDPA section 28 apply?

Section 28 concerns a data controller that sends or transfers personal data to another country. The destination must have adequate data protection standards, unless one of the listed exceptions applies.

Whether using a manufacturer's cloud located outside Thailand amounts to "sending or transferring" must be decided on the facts case by case, and our article on section 28 works through it in detail. What carries over to cameras is the set of four facts you need before you can decide, and the questions in clauses 5.1.3 and 3.3.3.4 already collect the same information.

1. In which country are the primary and backup servers?
2. From which countries can the provider's staff view footage or the system?
3. Who are the subprocessors, and where are they?
4. Does the provider or its group use the footage for any other purpose of its own?

Keeping data in Thailand does not end the question either. Clause 5.1.3 cautions:

In our own reading, for cameras a server in Thailand reduces the section 28 question, but if the administering team or the keys are abroad the question continues. That is our interpretation, not a statement in the guideline.

What happens to our footage when the provider reports an incident, moves its storage or ends the service?

Write the answer into the contract in advance. Clause 5.1.7 suggests requiring the provider to notify incidents and changes that affect security, privacy or continuity: security incidents, personal data breaches, service interruptions, lost or altered keys, moving the storage or processing location, changing subprocessors, changing key controls, and ending a feature or API you rely on.

On timing, the guideline says not to use one 24, 48 or 72 hour frame for every kind of event; set it from the law, the seriousness of the event, the response you need and your own risk. For the PDPA deadline when data leaks at a processor, see our article on processor breaches.

Is the footage really gone after deletion?

Clause 5.1.6 asks where data sits: primary storage, backups, replicas, cache, exported files and logs or metadata. Then decide which of these deletion must cover, and ask for evidence of deletion in proportion to risk.

The Thai excerpt says do not set a deletion period, for example "within 30 days", as a single value for every service without a reason; if no law or requirement sets one, agree a suitable period in the contract or service terms according to risk and technical capability. So a buyer should not accept a vague promise to delete "within a reasonable time" without asking further, nor copy one contract's number onto all services.

An exit plan from day one

Clause 5.1.8 asks you to plan for ending or switching the service before you start, so you are not locked in. The plan should say how and in what format you get data and settings back, which accounts, rights, sessions, tokens, keys and certificates must be revoked, how long backups are kept and when they are deleted, whether you can get proof of deletion, and what you do if the service stops before the move is done.

1. Before switching on P2P or a vendor cloud
   Answer the eight questions, then decide whether to disable, restrict or keep using the service.Clause 3.3.3.4
2. When choosing and contracting
   Ask about location, access, keys, backups, subprocessors and responsibilities; sign a processor agreement.Clauses 5.1.3 to 5.1.5
3. Setting up and granting rights
   Named accounts, MFA, no public sharing, and a way to revoke sessions when a phone is lost.Clause 5.1.1
4. During use
   Review the provider when it notifies you of changed storage, subprocessors or key measures.Clause 5.1.7
5. When leaving or changing provider
   Export footage and settings, revoke rights and keys, delete copies and backups, and ask for proof of deletion.Clauses 5.1.6, 5.1.8

A hypothetical: six shops with cameras viewed through the brand's app

Suppose an owner has fitted one brand of camera in six shops. Branch managers and the owner watch through the brand's app, footage is stored in the brand's cloud, and nobody has read the service terms. Where should the checking start?

1. Get the service documents from the brand and answer the eight questions of clause 3.3.3.4; for any you cannot answer, ask the seller in writing
2. Find out whether the connection through the brand's service can be switched off; if not, and the server location is unknown, consider which cameras to move to on-site storage first
3. Replace shared logins with named accounts, remove the generic account the installer set up, and turn on MFA if supported
4. List who at the brand or its subprocessors can view footage; if anyone can, put a section 40 agreement in place, and look at section 28 if servers or support are outside Thailand
5. Write down how to leave: export footage, delete data, revoke rights, before a seventh shop is added

If the business is an ordinary private business outside the notification's definition of agency, it need not file the report under clause 6 of that notification. The list above is still worth asking, because footage of customers' and staff faces is personal data under the PDPA.

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)