Laos Regulates Digital Platforms: Certification, Standards, and Open Questions

On October 2, 2025, the Lao Official Gazette published the Decision on Digital Platforms No. 3648 (ຂໍ້ຕົກລົງ ວ່າດ້ວຍ ຖານລະບົບດີຈີຕອນ), issued by the Ministry of Technology and Communications (MTC).

The Decision has two key highlights:

First, it requires a wide range of local digital platform operators (i.e., operators established and registered in Laos) to comply with a comprehensive set of technical standards, including online marketplaces, digital banking and payment applications, ride-hailing and delivery platforms, booking platforms, online games, and social media networks, among others, but also vending machines. Compliance is verified through a digital platform certification process administered by the MTC. Platforms that successfully complete the process receive a certificate and are entitled to display the MTC certification mark.

Second, unlike local platforms that must undergo the full certification process, offshore-based service providers that have no legal presence in Laos but earn income from Lao-based users face a separate registration obligation, without the full technical standard assessment that certification requires. They must register with the MTC and are subject to annual reporting and monitoring obligations.

Scope of the Decision

The Decision regulates the digital platform itself, not the activity behind it. Operators remain subject to sector-specific licensing requirements from the relevant authorities in addition to the digital platform certificate. The two are separate obligations.

Room for Clarification

The Decision presents some interpretive challenges, not unusual in emerging regulatory frameworks. In particular, which platforms are actually subject to the certification is not always clear. These ambiguities should not be used as a reason to delay implementation. Many platforms are clearly identified in the fee schedule and should proceed with certification without waiting for further clarification, while clarifications would be welcome in subsequent regulations or a revised version of the Decision.

This article provides an overview of the Decision, highlights some of those interpretive challenges, and offers a practical perspective on which operators are subject to the certification and what technical standards they must meet. Offshore-based providers are addressed in Part III.

Readers primarily interested in understanding who the Decision applies to and what technical standards it imposes can jump directly to Part II. For those who want the full picture, including the interpretive challenges, Part I provides that context.

I. Definitions, Scope, and Ambiguities

This part examines the key definitions that determine who the Decision applies to, the ambiguities that emerge from a close reading of those definitions, and recommendations for addressing them.

A. Key Terms

The Decision provides definitions early on (Articles 2-3) to understand its reach. Not all definitions require detailed discussion. The Decision alone is not enough and it must be read in the light of the Law on Electronic Transactions (2022), where important definitions that the Decision builds on are found.

1. Digital Platform

The Decision defines “digital platform” (ຖານລະບົບດີຈີຕອນ) as follows (Article 2):

A digital platform is a form of digital infrastructure that serves as an intermediary service to support the conduct of electronic transactions, manages data and creates an environment that enables connections between service providers and service users so that they can use services and conduct electronic transactions together through the use of digital technology and internet networks.

2. Electronic Transaction

Electronic transactions (ທຸລະກຳທາງເອເລັກໂຕຣນິກ) are a key element of the definition of digital platform. The definition is found in the Law on Electronic Transactions (Article 2):

An electronic transaction is the conclusion of contracts, the supply of goods, and the provision of services electronically, through the use of electronic instruments in whole or in part, such as buying and selling, exchanging, making payments, and granting authorizations through online systems.

3. What is a Digital Platform

The definition reveals the core structure: a digital environment serving as an intermediary to connect service users and service providers with a transactional aim, to support the conduct of electronic transactions online. For instance, a banking mobile app through which bank customers can make payments, or merchant websites selling goods (e.g., food) or services (e.g., transport).

A Platform Built Around Transactions

The examples provided in the definition to illustrate “electronic transactions” (e.g., “buying and selling, exchanging, making payments”) are introduced by the Lao term “ເຊັ່ນ,” “for example,” which confirms that the list is illustrative rather than exhaustive. That said, the interpretative weight of a list of examples is rarely neutral in legal interpretation, as it orients the reader toward the intended scope of the definition, which here points toward transactions involving money or the exchange of value. The inclusion of “granting authorizations” could suggest a broader scope beyond purely financial transactions, but it remains contextually colored by the surrounding examples.

B. Some Gaps in the Text: Interpretative Challenges

Ambiguities emerge on a closer read.

1. A Scope Wider Than Expected

The Decision defines its scope of application as follows (Article 4):

This Decision applies to individuals, legal entities, or organizations, both domestic and foreign, that conduct activities related to the provision of electronic transaction system services in the Lao PDR.

Surprisingly, the provision defining the scope of the Decision does not mention “digital platforms.” The focus is made on the expression “electronic transaction system services” (ການບໍລິການລະບົບທຸລະກຳທາງເອເລັກໂຕຣນິກ), which is not defined. The Law on Electronic Transaction provides the closest available expressions (Article 25-26). That said, the expressions are not identical. The connection is useful but does not fully resolve the scope.

Two observations follow:

1. The scope does not specifically cover digital platforms, but activities related to the provision of electronic transaction system services. Whether a platform falls within scope depends on whether it is associated with such activities.
2. The scope is probably broader than the name of the regulation suggests, since “electronic transaction system services,” read in light of the Law (Articles 25-26), can cover a wider category of operators. One constant remains though: the Law points toward activities involving the movement or exchange of value (e.g., money transfer, e-marketplace).

But for some reason, exact expression “electronic transaction system services” is entirely abandoned in the rest of the Decision, though related expressions such as “electronic transaction system” appear occasionally elsewhere. This raises questions as to whether the Decision’s scope should be assessed in the light of this expression, given that the regulator never returns to it explicitly.

2. Who Must Obtain the Digital Platform Certificate?

The Decision limits certification to “digital platforms that operate electronic transaction services” (Article 21), suggesting not all digital platforms are concerned. Article 4 and the fee schedule point in the same direction, implying a defined category rather than a universal obligation.

The problem is twofold. First, the expression “that operate electronic transaction services” is never defined, leaving operators uncertain about whether they fall within it. Second, the definition of digital platform already implies a strong transactional dimension, which makes the expression largely redundant: under the current definition, virtually any digital platform would already qualify.

The fee schedule provides the most practical guidance for now. It lists specific platform types subject to certification, and the relevant fees to be paid, though it raises its own questions, as some platform types with no obvious transactional feature appear on the list while others do not. Platforms not explicitly listed are left to assess their own situation.

What Appears to Matter Most

Based on the overall reading of the Decision, what appears to matter most is whether a platform includes an electronic transaction feature, but this is never explicitly stated. The inclusion of platform types such as education and public health platforms, whose definitions in the Decision contain no reference to payments or any exchange of value, suggests that the trigger may be broader or simply inconsistent.

3. Technical Standard and the 9 types in Question

Technical Standard Confirmation: A Misleading Appearance

Article 5 introduces “digital platforms that must undergo technical standard confirmation” and classifies them under 9 types. Read in isolation, this suggests that “technical standard confirmation” is a standalone procedure, in parallel with the certification, applying to a specific category of platforms that may differ from those in Article 21, as discussed in Section 2.

The expression “technical standard confirmation” is defined (Article 3(1)), but no independent procedure for obtaining it is described anywhere in the Decision, and no certificate or formal document is associated with it.

The answer only emerges much later in the Decision. Article 22 reveals that technical standard confirmation is not a standalone procedure at all but simply one of the conditions that must be met within the digital platform certification process. It has no independent legal existence.

The 9 types in Article 5 are most likely just a classification of the platforms that operate electronic transaction services, not a distinct category subject to a separate process. The mention of technical standard confirmation alongside the 9 types serves no apparent regulatory purpose and creates a false impression of a standalone procedure. The regulatory relevance of the 9 types themselves is also questionable, as discussed below.

The 9 Types in Question

The 9 types are as follows (Article 5):

The 9 types are as follows (Article 5):

1. Commerce platforms;
2. Financial platforms;
3. Transportation and logistics platforms;
4. Education platforms;
5. Public health service platforms;
6. Tourism service platforms;
7. Digital content service platforms;
8. Social media network platforms;
9. Other digital platforms.

Each type has its own description (Articles 6-14). For some types, the connection to the transactional nature of the definition of digital platform is not immediately obvious, education and public health platforms being clear examples.

A Catch-All Within a Catch-All

While the provision indicates 9 types, the 9th type “other digital platforms” (Article 14) is defined so broadly that it can be read as encompassing virtually any digital platform:

Other digital platforms are digital platforms that facilitate the conduct of transactions, directly or indirectly, which provide services as follows:

1. Online search engines;
2. Online intermediation services;
3. Virtual assistants;
4. Digital assets;
5. Subscription service system;
6. Online games (Esports); and
7. Other platforms.

9 Types, or All Types?

The expression “digital platforms that facilitate transactions, directly or indirectly” extends the reach of the 9 types to the point of including virtually any digital platform. Search engines, for instance, are broadly associated with facilitating transactions. Online games may include a transactional feature, though not always. For Esports specifically, the connection is even less obvious, and the Decision provides no guidance on where the line is drawn. All in all, this sub-list reads as a broad catch-all within an already broad catch-all category, which raises the question of whether the 9 specific types serve any meaningful regulatory purpose.

C. Recommendations

The ambiguities identified above point to areas where targeted revisions would significantly improve clarity and ease of the implementation of the Decision.

1. Clarifying the Digital Platforms Subject to Certification

• The definition and the certification trigger do not work together. Revising the definition to soften its transactional dimension, reflecting the broader understanding of digital platforms as environments facilitating interactions that may also include transactions, would give the expression “that operate electronic transaction services” a clear and useful role.
• In any case, the expression “digital platforms that operate electronic transaction services” must be explicitly defined in the Decision, ideally in the article setting out key terms (Article 3). As it stands, this expression is crucial as it triggers the certification obligation but is never defined, leaving operators uncertain about whether their platform meets those criteria.

2. Reconsidering the Reference to the 9 Types

• The 9 types have no evident regulatory purpose and should be deleted. What should matter is whether a digital platform falls within the criteria of the definition of digital platform that “operate electronic transaction services”; whether it is related to a financial, hospitality, or a transport activity should not be relevant. Some elements of the 9 types could be used as simple illustrative examples of the intended scope of the digital platforms subject to the certification.
• The 9 types could still be relevant in relation to the fee schedule, where digital platforms subject to certification would pay different fees (which is already the case) depending on various factors or risks they may pose to users (e.g., volume of transactions, sensitivity of transaction data).

3. Clarifying the Scope of the Decision

• Article 4 does not mention digital platforms. Article 4, which defines the scope of the Decision, explains that the Decision applies to entities “that conduct activities related to the provision of electronic transaction system services,” an expression that is undefined in the Decision and never used explicitly as such again after Article 4. This creates immediate uncertainty about who is subject to the Decision, before the reader has even reached the substantive provisions. Article 4 should refer to digital platforms explicitly and use expressions defined in the Decision about the regulated subject.

4. Using Terminology Consistently

• The Decision uses multiple expressions to refer to digital platforms and their function. Some examples: “digital platform” (the Title); “digital platforms that operate electronic transaction services” (Articles 1, 21); “service to support the conduct of electronic transactions” (Article 2); “activities related to the provision of electronic transaction system services” (Article 4); “digital platforms that must undergo technical standard confirmation” (Article 5); “digital platform that facilitates…” followed by a specific activity (Articles 6-13); “digital platform that facilitates the conduct of transactions, directly or indirectly” (Article 14).
• This inconsistency creates uncertainty about whether these expressions carry distinct legal meanings. Addressing the recommendations above, in particular clarifying the definition of digital platform and the scope of the certification, would naturally resolve most of these inconsistencies.

5. Clarifying the Relationship with Sector Regulators

• The Decision does not address how it interacts with sector-specific licensing requirements. Since the Decision regulates the platform while sector regulators license the activity behind it, the two are complementary rather than duplicative. That said, operators currently have no guidance on how the two sets of obligations interact in practice, which takes precedence in case of conflict, or whether compliance with one satisfies any requirements of the other. A coordination mechanism between the MTC and relevant sector regulators would provide that clarity.

II. Digital Platform Certification: Who Must Comply and How

The interpretative challenges discussed in Part I should not obscure what the Decision clearly does. A large number of digital platforms are unambiguously subject to certification, and the technical standards they must meet are detailed below. Operators that successfully complete the certification are entitled to display the digital platform certification mark.

A. Digital Platform Certification: Who is Concerned?

The digital platform certification is a process administered by the MTC through which local digital platform operators confirm that they meet, among other things, the technical standard requirements set out in the Decision.

1. Platforms Subject to Certification

The Decision provides that digital platforms “that operate electronic transaction services” must undergo the certification (Article 21). That said, given that the expression “that operate electronic transaction services” is not defined in the Decision, it is the fee schedule (Article 31) that provides the clearest indication of which digital platforms are subject to certification. The list is as follows:

1.      Commercial platforms

◼️ Electronic marketplace

◼️ Electronic shop

◼️ Product sales programs and vending machines

2.      Financial platforms

◼️ Digital bank

◼️ Payment services

◼️ Electronic wallet

◼️ Financial institution services

◼️ Sub-payment intermediary services

◼️ ATM/Cash deposit-withdrawal machine programs

3.      Transport and logistic platforms

◼️ Goods, materials, and items transport–delivery services

◼️ Passenger transport/online taxi

◼️ Logistics

4.      Education, public health service, tourism service, or social media network platforms

5.      Digital content service platforms

6.      Digital asset service platforms

7.      Online game (Esports) service platforms

8.      Other digital platforms

To trigger the certification process, an application must be submitted to the MTC with supporting documents (e.g., Enterprise Registration Certificate, security audit report). Financial platforms and digital asset platforms must additionally provide a penetration testing report and have a Know-Your-Customer mechanism and measures to prevent money laundering and the financing of terrorism (Articles 22-23).

Fees for the certification vary depending on the platform (from LAK 1million to LAK 15 million). The certificate is issued within 30 days, is valid for one year, and must be renewed annually. On-site inspection is possible (Article 24).

2. What the List Reveals

A List that Raises Questions

The list is directly inspired by the 9 types of digital platforms referenced in the Decision (Articles 5-14). The list goes beyond what the expression “that operate electronic transaction services” would suggest. Several platform types, including education and public health platforms, have no electronic transaction features in their descriptions (Articles 9, 10). Yet they appear on the list and are subject to certification.

Conversely, some platform types referenced in the 9 types are absent from the fee schedule entirely. Search engines, for instance, appear in the description of “other digital platforms” (Article 14) but do not feature in the fee schedule. It is unclear whether this reflects a deliberate choice to exclude them from the certification requirement, an assumption that they fall within the “other digital platforms” catch-all in the fee schedule, or simply an omission.

A Broader Scope Than Expected

The list also extends to less obvious entries. Product sales programs and vending machines, as well as ATM/cash deposit-withdrawal machine programs, appear respectively under commercial and financial platforms. Their inclusion signals that the Decision’s reach extends beyond conventional digital platforms to encompass physical machines with embedded software, a broader scope than the name of the regulation might suggest.

What This Means for Operators

For most operators, the practical takeaway is straightforward: if your platform appears on the list, certification likely applies. Where a platform includes a payment or electronic transaction feature, the obligation is clear regardless of the category it falls under.

For platform types listed in a generic way, such as education, public health, tourism, and social media platforms, which appear as a single line without sub-examples, the position is less certain. These platforms are on the list, which suggests the certification obligation applies. That said, operators of such platforms that do not include any payment or electronic transaction feature may want to seek confirmation from the MTC before assuming the obligation applies to them.

B. Technical Standard Requirements: An Overview

The MTC has consolidated minimum standards that digital platforms must comply with, a first for the industry. Some of these standards, as detailed below, are broadly framed and will benefit from further refinement over time, which is common in any emerging regulatory framework. The observations further below flag areas where greater precision or alignment with recognized international standards could strengthen both compliance and enforcement.

1. The Standards

System development process (Article 15)

This standard sets out the baseline requirements for how digital platforms must be developed, including alignment with international software development standards, support for the Lao language, and the inclusion of features to protect younger users from inappropriate content.

The Decision sets out the following requirements:

• Consistent with the international technical standard for software development ISO/IEC 29110
• Support Lao language characters
• Specify development tools and programming languages
• The system must be efficient, available, and easy to use
• The system must be accurate and reliable
• Have an alert system for content that may affect children or young people

System Management (Article 16)

Once a platform is live, how it is managed day to day is equally important. This standard covers the controls that must be in place to protect access to the system, including password requirements, access restrictions, usage logging, and documented management procedures.

The Decision sets out the following system management requirements:

• Have an access control system to restrict data access to authorized users only
• Passwords must meet minimum conditions, including at least 8 characters
• Encrypt password data or use equivalent methods
• Maintain a system usage history log
• Document in writing the methods for system management, access, and user control

General Data Storage (Article 17)

Platforms collect and store significant volumes of data. This standard addresses where that data must be kept, how long it must be retained, and what security standards must be met, including rules on third-party storage and cross-border data transfers.

The Decision sets out the following data storage requirements:

• Specify the database used by the system
• Store data in the Lao PDR, either directly or through reliable third parties; where data is stored abroad, timely access must be guaranteed
• Data storage must be consistent with ISO/IEC 27001 international data security standard
• Guarantee data completeness and integrity
• Have an accessible data backup and recovery system
• Retain system usage history for at least 90 days; financial platforms must comply with relevant laws and regulations for financial data storage

Storage of Personal Data (Article 18)

Personal data deserves a higher level of care. This standard goes beyond general data storage to set specific rules on what personal data platforms may collect, how it must be used, and what commitments platforms must make to their users about how that data is handled.

The Decision sets out the following requirements:

• Collect only data necessary and relevant to the service
• Define the scope of personal data storage and clearly inform users of the purpose
• Formally commit to and use stored data only for the purposes disclosed to users
• Be responsible for all data it collects, stores, and uses

Security Protection (Article 19)

This is the most technically detailed of the six standards. It covers the full range of security measures platforms must have in place, from network protection and data encryption to independent security audits, penetration testing for financial platforms.

The Decision sets out the following requirements:

• Have a network protection system
• Have data confidentiality measures (e.g., digital signatures, data encryption, confidentiality rules)
• Have basic security systems with efficient, stable servers in secure locations with dedicated security staff
• Have technical and electronic data security measures, including cyberattack risk management
• Conduct independent technical security audits at least once per year or upon system modification, with a written audit report
• Financial platforms must conduct penetration testing (Pentest) upon creation or system modification
• Guarantee 24/7 customer service with an experienced team capable of resolving issues promptly
• Have a data encryption system ensuring only authorized users can access and decrypt data
• Have a system to filter and verify electronic data integrity before recording, including protection against SQL injection and cross-site scripting
• Have antivirus and anti-malware protection systems
• Network connections and devices must comply with standards under clearly designed architecture for basic network components and ensure interoperability

Access to Digital Platforms (Article 20)

This standard defines the features that platforms must provide to users when they access the platform, including authentication systems, session management, and the display of privacy policies and terms and conditions before registration. Some of these requirements may represent a meaningful change for platforms that have not previously implemented formal identity verification for their users.

The Decision sets out the following requirements:

• Have a digital identity authentication system for data access
• Have a logout system
• Have a user registration (Sign in) and profile editing system (User profile)
• Have a forgotten password management system
• Have an automatic session timeout system when the platform is inactive
• Use reCAPTCHA or image codes to prevent automated login attempts
• Display privacy policy and terms and conditions before user registration

2. Observations and Recommendations

The technical standards are a welcome development, giving operators clear guidelines to work with. That said, some standards would benefit from greater precision.

Vague ISO Alignment

Vague standard: “consistent with ISO.” The technical standards refer to ISO 29110, and ISO27001 (Articles 15, 17). However, the Decision does not require platforms to comply with or obtain ISO certification, but merely to “be consistent” with it. This formulation is vague and leaves both operators and regulators without a clear benchmark. It is unclear what consistency with the standard is required in practice, and how the MTC will assess it during the certification process.

The MTC may be reluctant to require certification for a good reason: These certifications are costly and may represent a real obstacle for new platforms that are yet to generate revenue, especially SMEs and startups. Still, all platforms should aim for ISO full compliance.

Recommendations: Requiring compliance with or certification against recognized international standards, such as ISO/IEC 27001, would give both operators and the MTC a clearer and more enforceable benchmark.

On the cost concern, a tiered approach could address this: ISO compliance may apply immediately for certain companies (e.g., in terms of revenue, sector), with possibly a grace period of, say, 24 months for newly formed companies to comply with ISO requirements. The MTC may request from these platforms to include a clear path to security compliance in their development roadmap and steadily achieve alignment with international standards within a given timeframe.

Other Missing Benchmarks

Several requirements under Article 19 share a common limitation. Expectations are set in broad terms without specifying a benchmark against which compliance can be assessed. Digital platforms are required to have a “network protection system”, “basic security systems […] security staff”, “antivirus and anti-malware systems”, and network connections that comply with “standards”. No standard is specified (e.g., method, software, or staffing qualifications).

Recommendations: Clarifying the benchmarks against which the standards will be assessed. This applies to both software and hardware requirements. Similarly, the requirement for security staff should specify the expected level of experience and qualifications.

Password Requirements (Article 16)

These fall short of current international benchmarks. The NIST SP 800-63-4 Digital Identity Guidelines recommend a minimum of 15 characters when a password is the sole authentication factor, that is when no additional verification is required, and 8 characters only when combined with multi-factor authentication (MFA), that is when the user must pass at least two verification steps, such as a password plus a one-time code sent to a phone. The Decision’s 8-character minimum does not distinguish between these two scenarios. From a plain reading, the 8-character password is fine even when being the sole authentication factor.

Recommendations: Aligning with international standards and referencing the latest version of NIST or ISO standards directly, rather than setting fixed numerical thresholds, would also anticipate upgrades of the requirements as international benchmarks evolve.

Clarification Required: Digital Identity Authentication System

Authentication Levels: An Open Question. The Decision requires digital platforms to have a “digital identity authentication system” but does not specify what level of authentication is required. The Law on Electronic Transactions establishes three levels: a single-layer password, a two-layer password, and more than two layers (Article 40), the latter two are commonly referred to as multi-factor authentication (MFA). Neither the Law nor the Decision specifies which level applies to which type of platform.

What about identity proofing? The Decision and the Law do not address whether the “system” includes identity proofing. The Law includes provisions about identity proofing (Articles 33-36): Level 1 takes the information provided at face value with no verification. Level 2 allows the service provider to request identity documents (e.g., a copy of a national ID card). Level 3 requires in-person identity verification (Article 36). The Law does not explicitly make identity proofing a binding obligation on digital platforms, and the Decision does not address it.

Recommendations: Clarifying what authentication level is required, and whether identity proofing is also part of the digital identity authentication system, and if so, providing a clear guideline on what level of identity proofing is also expected from digital platforms. Requirements could vary depending on the type of platform. For instance, a digital banking service platform may be expected to have a higher level while lower-risk platforms, such as tourism or content platforms, may require less stringent verification.

Renewal and Ongoing Compliance

Ongoing compliance: an open question. The annual renewal process (Article 26) does not require a comprehensive re-assessment of compliance with the technical standards, only the most recent security test. It is also unclear how ongoing compliance is monitored between renewals, which is crucial to ensure standards are maintained over time.

Recommendations: Requesting only the most recent security test results at renewal seems insufficient. A more robust process should be considered, drawing inspiration from ISO certification practice: operators would produce annual security reports verifying ongoing compliance, while a more comprehensive inspection would be carried out every three years before recertification. Any issues identified during annual reporting would need to be resolved before that three-year review. Local IT security service providers could conduct these inspections and report directly to the MTC, reducing reliance on operator self-reporting.

This could be taken a step further for the ISO-related standards specifically. If the MTC were to require full ISO/IEC 27001 certification, as recommended above, rather than mere consistency with it, the audit and monitoring of those standards could be left to accredited auditors. The MTC would then simply rely on their reports rather than conducting its own assessments.

C. Digital Platform Certification Mark

The Decision establishes a digital platform certification mark that signals that the platform has successfully completed the digital platform certification process and meets the MTC’s technical standard requirements. The mark can be displayed on the digital platform or be used for advertisement purposes as well (Article 30).

The Decision does not provide the logo of the actual mark and only indicates that the design of the mark is under the responsibility of the MTC.

III. Digital Platform Services of Providers Based Abroad

The Decision also targets “providers from abroad,” defined as any individual, legal entity, or organization that does not have domicile and is not registered in Laos but earns income from providing digital goods and services to users in Laos (Article 3). In short, a foreign entity generating income from Lao-based users must register with the MTC, regardless of whether it has a presence in the country.

Registration requires supporting documents including proof of enterprise establishment and a security testing certificate, without further indication of applicable testing standards (Article 33). Fees amount to USD 1,000 annually plus a one-time USD 300 research service fee at submission (Article 34). Registered platforms must report annually on their business operations and are subject to MTC monitoring once a year.

About Registration

The provisions are primarily aimed at collecting information and monitoring activities (Article 32). That said, the safety dimension is not entirely absent, as registration documents must include evidence of security testing and measures to protect data security and the confidentiality of personal data (Article 33).

Key Observations

Coordination with the Ministry of Finance. The Decision does not reference Instruction No. 0588 issued by the Ministry of Finance in 2024, which requires offshore platforms earning income from Lao-based users to register with the Ministry of Finance and declare VAT. Offshore providers therefore face dual registration obligations with no guidance on how they interact.

Reporting content. Annual reporting is required but its content is not defined. It is also unclear whether the application form is available online or whether local counsel is required.

Management and other changes. Finally, the obligation to notify “management changes” or “other changes” within thirty days is vague. Neither “management” nor “other changes” is defined. For large providers with complex corporate structures and frequent global changes, this could prove disproportionate and practically unworkable.

Recommendations

Offshore providers that fall within the scope of the Decision should seek clarification from the MTC on the practical implementation of their obligations, in particular on the content of the annual reporting and the scope of changes that must be notified.

The registration scheme for offshore providers would benefit from greater clarity. The reporting content should be defined, and the scope of “management” and “other changes” narrowed. The Decision should also acknowledge the Ministry of Finance’s Instruction No. 0588 and provide guidance on how the two registration regimes articulate, so that offshore providers can navigate their obligations under both instruments without unnecessary confusion.

Conclusion

There are interpretative challenges that will need to be addressed, but they should not overshadow the meaningful steps taken towards a comprehensive framework to raise and harmonize technical standard requirements across all types of digital platforms, for the benefit of users and consumers based in Laos. Legitimate questions remain on the applicability of the Decision and the digital platform certification process for some platforms, especially those not explicitly listed in the fee schedule and not integrating any payment features within their platform. That said, many platforms are clearly identified and should comply with the Decision as soon as possible, if they have not already done so.

The Decision also provides a set of sanctions for non-compliance, ranging from the suspension and revocation of the digital platform certificate (Articles 28-29, 46) and fines (Article 45) to the blocking of access to the digital platform itself (Article 46). The latter measure could have significant practical consequences for offshore service providers whose platforms are accessible to users in Laos. European operators should also note that the broad obligation to cooperate and provide information to “relevant State authorities” (Article 45(7)) may create tension with their GDPR obligations. While the word ‘relevant’ could imply some degree of selectivity, the absence of any procedural framework makes it difficult to assess what safeguards apply in practice. This could be clarified in a future revision of the Decision.

Disclaimer

This article is for general informational purposes only and does not constitute legal advice. For legal assistance or advice regarding law matters in Laos, readers must contact a qualified Lao lawyer.

Translation Note

This article is based on an independent reading of the official Lao text. This is not an official translation. While every effort has been made to ensure accurate and contextually appropriate terminology, some terms may be subject to refinement as legal usage and official interpretations evolve. For instance, the Lao word “ການຢັ້ງຢືນ” can be translated as either “confirmation” or “certification.” In this article, it was translated as “confirmation” in the expression “technical standard confirmation,” and as “certification” in the expression “digital platform certification,” to reflect that the latter involves the issuance of an actual certificate while the former does not.

If readers have a more accurate translation supported by reliable sources, comments are welcome, either in discussion or by private message.