Vietnam’s Corporate Websites and the Consent Gap

What a scan of 500 major Vietnamese company sites reveals about cookies, beacons, and PDPL risk

TL;DR: We scanned the websites of the top 500 companies in Vietnam. Not every domain resolved, redirected properly, or returned analyzable results, so the final usable dataset came to 340 sites. Even with that limitation, the pattern is clear: 244 of 340 resolved sites were flagged high risk, 203 loaded third-party cookies, 273 loaded beacons, and only 63 had neither detected. The most common technologies were dominated by Google, Meta/Facebook, and YouTube. For Vietnamese businesses, the lesson is not subtle: many corporate websites still behave like marketing stacks first and compliance systems second.

Executive Summary

• Website tracking is now a board-level data-governance issue.
• 71.8% of resolved sites in the scan were flagged high risk.
• GTM, Google Analytics, DoubleClick, Meta, YouTube, and Google Maps dominate observed third-party calls.
• Under PDPL, Decree 356, Data Law, and Decree 165, companies need evidence, not just banners.
• The practical response is scan, classify, block, document, monitor, and audit.

“A cookie banner is not compliance if the browser has already called Google, Meta, or YouTube before the user had a real choice.”

Why this matters now

Website compliance is no longer a side issue. It is one of the most visible and technically provable forms of personal data processing a company carries out. A privacy notice can say one thing, but the browser shows what the site is actually doing.

That matters even more in Vietnam’s tightening legal environment. The Personal Data Protection Law and its implementing decree move the market further away from informal website practices and toward a more structured compliance model. This is not just about having a privacy policy or adding a banner. It is about whether a site is collecting identifiers, firing trackers, or connecting users to third-party services before valid legal conditions are met.

Methodology and scope

This analysis is based on a scan of 500 major company websites in Vietnam. Because not all domains resolved, loaded correctly, or returned usable data, the final analyzable set was 340 websites.

We are not naming individual companies in this article. Instead, we focus on the observed patterns across sectors such as:

• banking and financial services
• insurance
• aviation and travel
• telecom
• retail and e-commerce
• logistics
• manufacturing and industrials
• real estate
• consumer goods and food brands

This approach keeps the focus where it belongs: on systemic patterns, sector-level exposure, and the governance gap revealed by the scan. The point is not to single out one company. The point is to show that the underlying problem is systemic.

The headline findings

From the 340 resolved and analyzable sites, the scan produced the following top-line results:

• 244 sites were flagged high risk
• 29 sites were flagged medium risk
• 67 sites were flagged low risk
• 203 sites loaded third-party cookies
• 273 sites loaded beacons
• 199 sites loaded both third-party cookies and beacons
• Only 63 sites had neither detected

In percentage terms:

• 71.8% of resolved sites were flagged high risk
• 59.7% loaded third-party cookies
• 80.3% loaded beacons
• 58.5% loaded both
• Only 18.5% appeared comparatively “clean” from this specific scan perspective

The average resolved site loaded:

• 4.36 third-party cookies
• 6.76 beacons

The median site still showed:

• 2 third-party cookies
• 4 beacons

That is important. It means this is not just an outlier problem caused by a few heavily tagged websites. The issue is broad and recurring.

“In a consent-driven regime, a company is not judged by what its privacy policy claims. It is judged by what the browser actually loads.”

The top 10 beacons observed

The beacon results show a very concentrated ecosystem. The most common endpoints were overwhelmingly controlled by Google and Meta, with a smaller presence from YouTube and Google Maps.

What these beacons usually mean

The pattern is straightforward, but the compliance implication is often misunderstood.

Google Tag Manager is the dominant third-party loading layer. In this scan, www.googletagmanager.com appeared on 221 of 340 resolved websites, equal to 65% of the analyzable dataset.

GTM is often described as a “container,” but from a browser, privacy, and compliance perspective it is not neutral. Loading GTM means the visitor’s browser contacts Google-controlled infrastructure to retrieve the container script before any downstream tag logic is even considered. That initial call may already disclose technical identifiers and request metadata, such as IP address, browser/device information, timestamp, and referring page context, depending on the implementation and browser behavior.

So the compliance question is not only:

• what GTM fires,
• when those tags fire,
• and whether consent gating works.

It is also whether GTM itself should load before consent, whether the user was clearly informed that Google infrastructure is contacted, whether the processing has a valid legal basis, and whether any resulting third-party or cross-border processing has been assessed and documented under the PDPL and Decree 356.

“GTM is not just the box that fires the tags. The box itself is loaded from Google.”

The same pattern appears across the rest of the beacon ecosystem.

Google Analytics endpoints show widespread measurement behavior. Requests to region1.google-analytics.com, region1.analytics.google.com, and www.google-analytics.com indicate that many Vietnamese corporate websites are still built around behavioral measurement as a default layer. Analytics may be useful for business reporting, but it is still a processing activity. It requires purpose clarity, vendor disclosure, consent handling where required, and evidence that the site does not collect or transmit data before the user has made a valid choice.

DoubleClick and Google Ad Services endpoints point to advertising, conversion tracking, remarketing, and campaign attribution. These are higher-risk categories than basic site functionality because they are normally tied to marketing optimization, user profiling, ad measurement, or cross-site advertising ecosystems. When stats.g.doubleclick.net and www.googleadservices.com appear, the question is no longer only “does the website use analytics?” It becomes “is the site participating in advertising infrastructure before the user has meaningfully consented?”

Facebook endpoints point to Meta Pixel, social plug-ins, or related Meta infrastructure. In the scan, both www.facebook.com and connect.facebook.net appeared frequently. These technologies can support advertising audiences, event tracking, conversion measurement, and social integrations. They therefore need strict consent controls and clear disclosure. A website cannot treat Meta calls as harmless simply because they are common.

YouTube endpoints often mean embedded video, but embedded video is also a tracking surface. Many companies think of YouTube as content, not compliance infrastructure. That is a mistake. A YouTube embed can trigger third-party requests and cookies even when the user only visits a page to read corporate information, view a product page, or check company details. If the video is not strictly necessary, it should be treated as a non-essential third-party integration and controlled accordingly.

Google Maps endpoints may be more functional in character, especially for store locators, office maps, dealer networks, or branch information. But functional does not automatically mean risk-free. maps.googleapis.com still represents a third-party connection, and organizations still need to assess what is loaded, what data is transferred, whether the map is necessary for the requested service, and whether disclosure and consent handling are appropriate.

What stands out is that the modern corporate website in Vietnam is often not operating as a self-contained site. It is operating as a networked third-party data environment. The page may look like a company website, but under the surface it can connect the visitor’s browser to Google, Meta, YouTube, advertising systems, analytics infrastructure, maps, social plug-ins, and embedded content providers.

That is the real compliance issue. The website is no longer just publishing content. It is orchestrating third-party data flows.

“A corporate website may look first-party to the visitor, but the browser often reveals a much wider third-party data supply chain.”

The top 10 cookies observed

The cookie data tells the same story. The most frequent cookies were associated with Google Analytics, Meta/Facebook, and especially YouTube.

What these cookies usually indicate

• _ga is commonly associated with Google Analytics
• _fbp is commonly associated with the Meta/Facebook Pixel
• _gcl_au is typically related to Google Ads conversion tracking
• YSC, VISITOR_INFO1_LIVE, VISITOR_PRIVACY_METADATA, TESTCOOKIESENABLED, and related values are associated with YouTube embeds and Google/YouTube behavior

There are two very important lessons here.

1. Embedded content is a major blind spot

Many businesses still think only “ads” create privacy risk. That is wrong. A simple embedded YouTube video can create cookie and beacon activity that has nothing to do with what the user consciously came to do on the page.

A company may believe it is simply showing a product video or a corporate introduction. Technically, it may also be exposing the user’s browser to Google/YouTube identifiers, preferences, or event calls.

2. The presence of a cookie is not the only issue

The real issue is the processing operation behind it.

A cookie is simply evidence. The deeper compliance question is:

• what data is being collected,
• for what purpose,
• by whom,
• on what legal basis,
• whether the user was informed,
• whether consent was genuinely obtained where needed,
• whether the user can withdraw it easily,
• and whether the company can prove all of that later.

“A YouTube embed is not just a video player. In many cases, it is also a tracking surface.”

What the scan suggests about Vietnamese website practice

The broad picture is that many Vietnamese corporate websites are still running on a legacy digital-marketing model:

• deploy Google Tag Manager
• add Google Analytics
• add Meta Pixel
• embed YouTube
• sometimes add Google Ads or remarketing
• then try to “solve” compliance later with a banner

That order no longer works.

The website must be designed so that legal requirements govern technical execution, not the other way around.

If a site loads non-essential measurement, advertising, social, or embedded media technologies before the user has been properly informed and has given valid consent where consent is required, the compliance problem has already happened.

The PDPL implication: websites are personal-data processing environments

The legal and operational mistake many companies make is treating a corporate website as a brochure.

It is not.

A modern corporate website is a personal-data processing environment. It may look like a public information page, but technically it can collect, generate, transmit, or expose personal data and identifiers from the moment the page loads.

A website may process:

• IP addresses,
• device identifiers,
• cookie IDs,
• advertising IDs,
• session identifiers,
• browser and device metadata,
• referrer URLs,
• page-view behavior,
• click behavior,
• scroll or interaction events,
• language and location signals,
• form-entry data,
• embedded-media interactions,
• map or branch-location queries,
• campaign attribution data,
• and data passed to third-party vendors.

This is why website tracking matters under Vietnam’s Personal Data Protection Law. The PDPL is not limited to HR files, customer databases, CRM records, or back-office systems. It applies to personal-data processing more broadly. Official Government coverage of the legislative process also makes clear that the framework is intended to apply to organizations involved in personal-data processing, including foreign organizations directly processing, or related to the processing of, personal data of Vietnamese citizens.

That matters because many website data flows are not purely local and not purely first-party. When a site loads Google Tag Manager, Google Analytics, DoubleClick, Google Ads, Meta/Facebook, YouTube, maps, embedded media, chat widgets, or other third-party services, the website may create disclosures to external vendors before the company has made a clear legal assessment.

The key point is simple: the browser does not care what the privacy policy says. The browser executes the data flow.

If the browser calls a third-party endpoint, the company needs to understand what that call means.

It needs to know:

• what data is transmitted,
• whether identifiers are involved,
• whether the vendor receives personal data,
• whether the vendor acts as processor, controller, independent controller, or another role,
• whether the processing is necessary,
• whether consent is required,
• whether consent was actually obtained before the processing,
• whether data leaves Vietnam,
• whether the user was informed clearly,
• whether withdrawal stops the processing,
• and whether evidence exists to prove the company’s position.

For websites, the compliance question is therefore no longer:

“Do we have a privacy page?”

It is:

“Can we prove that every website data flow is lawful, disclosed, controlled, and documented?”

That is a very different standard.

A privacy page may describe intentions.
A website scan reveals behavior.
A consent record shows choice.
An audit trail proves control.

“A website is not only a communications channel. It is a live personal-data processing system.”

This has a direct implication for consent.

If analytics, advertising, remarketing, embedded video, social plug-ins, maps, chat widgets, or other non-essential technologies load before the user has made a valid choice, the issue is not merely a weak banner. It is a possible failure of processing control.

The company may have created a data flow before it had:

• informed the user,
• obtained consent where required,
• classified the purpose,
• documented the vendor,
• assessed cross-border transfer risk,
• or created evidence of lawful processing.

That is why the website must be treated as part of the company’s personal-data inventory. It should be mapped like any other processing activity.

At minimum, a website-processing record should include:

• website domain and page template,
• technology or tag involved,
• vendor receiving the data,
• purpose of processing,
• category of personal data,
• legal basis,
• consent requirement,
• storage or access mechanism,
• cross-border element,
• retention period where relevant,
• technical blocking logic,
• and evidence trail.

Without that inventory, the organization is effectively relying on hope: hope that agencies configured tags correctly, hope that plugins do not leak data, hope that embedded services behave as expected, and hope that the banner reflects the actual browser behavior.

That is not a compliance model.

Under the PDPL, the website should be governed as a personal-data processing environment from the start.

Why Decree 356 matters

The PDPL sets the direction. Decree 356/2025/NĐ-CP is the operational layer.

This matters because Decree 356 pushes organizations away from informal privacy statements and toward a documented compliance model. It is not enough to say that the company respects privacy. The organization needs records, governance, technical controls, and evidence.

For website and marketing operations, Decree 356 matters because it turns common digital practices into compliance questions.

Once a company uses third-party analytics, advertising tools, embedded media, tag managers, maps, chat tools, campaign pixels, offshore infrastructure, or agency-managed containers, the discussion quickly expands beyond “cookies” into:

• governance,
• accountability,
• vendor management,
• processing impact assessment,
• cross-border transfer impact assessment,
• technical controls,
• evidence records,
• incident readiness,
• and ongoing monitoring.

Official Government reporting on the PDPL framework highlights that organizations must prepare impact assessment files for personal-data processing and, where applicable, for cross-border transfer of personal data. It also notes that the cross-border mechanism is built around an impact assessment record and a post-check model.

For websites, that is important.

A website with Google, Meta, YouTube, advertising, analytics, maps, or other third-party services may create recurring personal-data flows. These flows may be small at the level of a single page view, but they can become significant at scale. Across thousands or millions of visits, the website can become a continuous data-export mechanism.

That is why Decree 356 should be read operationally.

It means companies need to ask:

• Do we have a documented processing activity for website tracking?
• Do we know which vendors receive data?
• Do we know whether those vendors are inside or outside Vietnam?
• Do we know what data categories are involved?
• Do we know whether identifiers or behavioral data are collected?
• Do we know whether the processing is necessary or optional?
• Do we know which tags are blocked before consent?
• Do we know which tags are allowed after consent?
• Do we keep evidence of consent and withdrawal?
• Do we have a cross-border transfer record where required?
• Do we update the assessment when marketing tools change?

This is the practical meaning of accountability.

A company cannot outsource this entirely to a marketing agency, web developer, plugin vendor, or analytics consultant. Those parties may help implement the system, but the organization remains responsible for understanding and governing the processing.

“Decree 356 turns website tracking from a marketing configuration into a documented compliance obligation.”

The decree also matters because website stacks change constantly.

Marketing teams add campaign tags.
Agencies add pixels.
Developers install plugins.
Social teams embed videos.
Sales teams add chat tools.
Retail teams add conversion tracking.
HR teams add recruitment analytics.
Branches add maps.
Product teams add forms.

Each change can create a new data flow.

That means compliance cannot be a one-time banner setup. Companies need a repeatable operating model:

1. Scan the website.
2. Identify all tags, cookies, beacons, embeds, and scripts.
3. Classify each by purpose and necessity.
4. Map each vendor and data category.
5. Assess consent and cross-border implications.
6. Block non-essential technologies before valid consent.
7. Record user choices.
8. Document the processing and transfer position.
9. Monitor changes.
10. Update the assessment when tools or vendors change.

In practical terms, Decree 356 means Vietnamese companies cannot afford to run websites as unmanaged marketing stacks. They need documented control.

A website should be able to answer five compliance questions at any time:

• What loads?
• Why does it load?
• Who receives data?
• What did the user agree to?
• Where is the evidence?

If the company cannot answer those questions, the website is not under proper governance.

The consequence is that cookie and beacon compliance must move into the same discipline as other regulated processing activities. It should connect to data mapping, vendor risk, consent management, DPIA/TIA records, audit trails, and management reporting.

That is the real importance of Decree 356 for website tracking.

It takes the issue out of the banner layer and places it where it belongs: inside the company’s compliance operating model.

The Data Law adds a second cross-border risk layer

The PDPL and Decree 356 are not the only legal instruments companies need to consider. Vietnam’s Law on Data, Law No. 60/2024/QH15, was issued on 30 November 2024 and took effect on 1 July 2025. It creates a broader data-governance framework that sits alongside the personal data protection regime.

This matters for website tracking because many third-party technologies do not only process personal data. They may also become part of a wider data-flow architecture involving analytics, marketing intelligence, customer behavior signals, platform integrations, operational data, and in some sectors, regulated or sensitive business data.

For most ordinary websites, the first legal question remains the PDPL question: is personal data being collected, disclosed, transferred, or processed lawfully?

But for certain sectors, especially where data volumes, sensitivity, infrastructure relevance, or regulated activities are involved, the second question becomes:

Could any of this data fall within the Data Law’s categories of important data or core data?

That distinction matters because cross-border transfer and processing of important data and core data is treated separately from ordinary personal data processing. Legal commentary on Vietnam’s Data Law framework notes that Data Law transfer-impact requirements are separate from PDPL transfer-impact requirements and apply specifically to cross-border transfers of data classified as important data or core data.

Decree 165/2025/NĐ-CP, which implements the Data Law, also addresses cross-border processing of important data and core data. It provides that where core or important data is transferred or processed across borders, the relevant Data Law and Decree 165 requirements apply, rather than simply treating the issue as a normal personal-data impact assessment matter.

This creates a more serious compliance issue for sectors such as:

• banking and financial services,
• insurance,
• telecom,
• aviation and logistics,
• healthcare,
• energy,
• infrastructure,
• large e-commerce platforms,
• and other organizations operating large-scale customer, transaction, behavioral, or operational datasets.

For these organizations, a third-party website tag should not be reviewed only as a “cookie issue.” It should be reviewed as part of the organization’s wider data-governance and cross-border transfer architecture.

A Google, Meta, YouTube, advertising, analytics, map, chat, or embedded-content integration may look small at page level. But at enterprise level, it can form part of a recurring outbound data flow to foreign-controlled infrastructure. That flow may need to be assessed under:

• the PDPL,
• Decree 356,
• the Data Law,
• Decree 165,
• sector-specific rules,
• vendor-risk controls,
• and cross-border transfer governance.

“For regulated sectors, website tracking is not only a consent problem. It can also become a cross-border data-governance problem.”

The practical implication is simple: companies should not assess website trackers in isolation. They should map each third-party technology against:

• the personal data involved,
• the purpose of processing,
• the vendor receiving the data,
• the country or infrastructure location involved,
• whether the vendor is acting independently or on instruction,
• whether the data could be important or core data,
• whether sector-specific rules apply,
• whether a PDPL transfer assessment is required,
• and whether a separate Data Law assessment is triggered.

This is especially important because Decree 165 allows competent authorities to require the suspension of cross-border transfer or processing of important or core data in cases involving national defence, security, national interests, public interests, rights and lawful interests of data subjects or data owners, non-compliance with the decree, or violations of data-protection rules.

For Vietnamese enterprises, this means cookie and beacon compliance cannot be reduced to a banner. The website must be part of a governed data-flow inventory. Every third-party call should be traceable, justified, classified, and documented.

The draft Data Exchange Decree shows where website data governance may go next

There is also an emerging layer that companies should watch closely: Vietnam’s draft Decree on Data Exchange Operations.

This instrument is not yet a promulgated decree, so it should not be presented as final law. However, it is important because it shows the direction of travel. The Ministry of Public Security has published the draft dossier for consultation, and the draft is framed as a decree regulating the operation of data exchanges.

The draft text is based on the Law on Data, the Personal Data Protection Law, the Law on Electronic Transactions, and the Cybersecurity Law. It covers the activities of data exchange service providers, testing of data on exchanges, conditions for participants and data products or services, pricing and valuation, transaction workflows, risk management, system safety, complaint handling, dispute resolution, and the responsibilities of sellers, buyers, and exchange operators.

This matters because website tracking data does not always remain “website analytics.”

In some business models, data collected through websites, apps, advertising systems, analytics tools, pixels, embedded content, and customer journeys may later be transformed into:

• audience segments,
• behavioral analytics,
• lead-scoring datasets,
• market intelligence,
• benchmark reports,
• advertising audiences,
• data products,
• or analytics and aggregation services.

Once data is packaged, exchanged, monetized, valued, listed, shared, or used as part of a data service, the compliance question changes. It is no longer only a cookie-consent issue. It becomes a question of data provenance, data product legality, source evidence, permitted use, buyer restrictions, security, valuation, and transaction governance.

The draft decree is especially relevant because it defines a data product or service originating from personal data as one whose source is personal data that has been de-identified. That is a critical point for companies that assume “de-identification” automatically removes all compliance risk. In practice, the organization still needs to prove the origin, method, lawfulness, quality, scope, and permitted use of the data product.

The draft also distinguishes between the National Data Exchange and other data exchanges. Other data exchanges would need to meet information-system security requirements from level 3 or higher and have the capability to connect and share data with the National Data Exchange.

For regulated sectors, this is particularly important.

Banks, insurers, telecoms, aviation companies, large retailers, platforms, logistics operators, and other high-data-volume businesses should not assess website tracking only at the page level. They should ask whether website-derived data is later used in a broader data economy model.

The practical compliance questions become:

• Was the original collection lawful?
• Was the user informed of the downstream purpose?
• Was consent obtained where required?
• Was the data de-identified, anonymized, aggregated, or merely pseudonymized?
• Can the company prove the data source?
• Is the data later used as a product, service, audience, model input, or benchmark?
• Is it shared with a vendor, platform, data exchange, or foreign infrastructure?
• Are there restrictions on buyer use or onward transfer?
• Is the data subject to PDPL, Data Law, cybersecurity, sector-specific, or cross-border controls?

“The next compliance question is not only whether the cookie was lawful. It is whether the data created from that interaction later becomes a product, service, audience, or exchangeable asset.”

This is where the Data Law and the draft Data Exchange Decree become strategically important. The draft decree would require a more formal operating model around data products and services, including transaction controls, security controls, public operating rules, payment and account structures, and operator responsibility. The draft also places responsibility on data exchange operators to manage participation, suspend or remove unlawful data products or services, monitor information security and data safety, maintain incident response and backup/recovery plans, and publish operating rules and service-price frameworks.

For ordinary corporate websites, this draft should be treated as an early warning signal rather than a direct conclusion. A company that merely runs a website with analytics is not automatically operating a data exchange.

But a company that turns website-derived behavioral data into monetized datasets, advertising audiences, market insights, AI training inputs, data products, or third-party data services should start preparing now.

The direction is clear: Vietnam is moving from privacy compliance toward broader data governance, data-market regulation, and accountable data commercialization.

For companies, that means cookie and beacon compliance should not stop at the banner. It should connect into a full data-flow inventory showing:

• where the data came from,
• what legal basis applied,
• which vendors received it,
• whether it crossed borders,
• whether it was transformed,
• whether it became a data product or service,
• and whether it entered any commercial, exchange, platform, or third-party data ecosystem.

“Website data is not always the end of the story. In the data economy, it may become the raw material for products, services, models, and transactions.”

The consent issue: what many sites still get wrong

The scan points to a recurring problem: many websites appear to treat consent as a banner issue, not as a technical control, legal record, and governance process.

That is where the risk begins.

A banner is only the visible layer. The real compliance question is what happens in the browser before, during, and after the user makes a choice. If third-party scripts, beacons, advertising pixels, analytics endpoints, video embeds, map services, or social plug-ins load before the user has been properly informed and before valid consent is captured where required, the compliance failure has already happened.

Under Vietnam’s PDPL and Decree 356, organizations need to be able to explain and evidence how personal data is processed, for what purpose, by whom, under what legal basis, and with what transfer or vendor controls. The law and decree both take effect from 1 January 2026, making this no longer a future theoretical issue for Vietnamese enterprises.

The most common failures tend to fall into six categories.

1. Trackers loading before the user makes a choice

This is the core technical failure.

Many websites display a consent banner while analytics, advertising, embedded content, or tag-management scripts have already loaded. In that case, the user interface suggests choice, but the browser has already created third-party connections.

This is especially problematic where the first call is to infrastructure such as Google Tag Manager, Google Analytics, DoubleClick, Meta/Facebook, YouTube, or Google Ads. The issue is not only what happens after consent. It is whether the website already disclosed personal data, device data, identifiers, request metadata, or behavioral context before consent was obtained.

“Consent cannot repair a third-party transfer that already happened before the user had a choice.”

2. Bundled consent and vague “accept all” flows

Many consent interfaces still group everything into one general acceptance layer.

That is weak compliance.

Analytics, advertising, embedded video, maps, social plug-ins, chat widgets, personalization, and strictly necessary functions are not the same purpose. They should not be collapsed into one vague statement such as “we use cookies to improve your experience.”

A valid consent model needs purpose clarity. The user should understand what they are agreeing to, which categories of technology are involved, and whether third parties receive data.

3. No real granularity between necessary, analytics, marketing, and embedded content

A common problem is that websites label too much as “necessary.”

A payment-session cookie, security cookie, or load-balancing cookie may be necessary. A Meta Pixel, YouTube embed, Google Ads conversion tag, or remarketing beacon is not necessary for the basic delivery of a corporate webpage.

Embedded content is often overlooked. A company may believe that a YouTube video, Google Map, or social plug-in is only a content feature. Technically, it may also create a third-party data flow. That means it needs to be assessed and controlled like any other non-essential integration.

4. No meaningful vendor disclosure

Many websites disclose categories such as “analytics partners” or “marketing partners” without naming the actual vendors or explaining what they do.

That is not enough for a serious compliance posture.

If a visitor’s browser connects to Google, Meta, YouTube, advertising networks, analytics vendors, maps providers, chat systems, or customer-data platforms, the organization should be able to disclose:

• who the vendor is,
• what purpose the vendor supports,
• what data may be processed,
• whether the vendor acts as processor, controller, or independent third party,
• whether data may leave Vietnam,
• and how the user can control the processing.

The scan shows that the most common observed ecosystem is not generic. It is heavily concentrated around specific global platforms. That makes vendor disclosure and transfer assessment even more important.

5. No evidence trail to prove what the user agreed to

A consent banner without an audit trail is not enough.

Companies should be able to prove:

• which banner version was shown,
• which language was shown,
• which vendors and purposes were disclosed at that time,
• what the user selected,
• when the selection was made,
• from which domain or service context,
• whether consent was later changed or withdrawn,
• and which tags were allowed or blocked as a result.

This matters because compliance is not only about having a banner. It is about being able to demonstrate that the technical behavior of the website matched the user’s actual choice.

“A banner asks for consent. An audit trail proves whether consent controlled the technology.”

6. Consent withdrawal that is harder than consent acceptance

A common dark-pattern problem is making “accept” easy and “reject” or “withdraw” difficult.

If a user can accept tracking in one click but must search through a privacy policy, footer link, account setting, or hidden preference center to withdraw, the consent model is structurally weak.

A proper model should make rejection and withdrawal accessible, understandable, and operationally effective. Withdrawal should not only update the interface. It should actually stop the non-essential processing and prevent future tag firing unless consent is restored.

What a better consent model looks like

A compliant model is not complicated in principle, but it must be implemented seriously.

A stronger website setup should include:

• pre-consent blocking of all non-essential third-party scripts and embeds,
• clear purpose categories for necessary, analytics, marketing, embedded media, maps, and social integrations,
• vendor-level disclosure for major third parties,
• granular choice rather than bundled consent,
• equal ease of accept, reject, and withdraw,
• technical enforcement so the tag layer follows the user’s choice,
• consent records that can be audited later,
• cross-border assessment where third-party infrastructure or foreign vendors receive personal data,
• and regular rescanning to detect new tags added by marketing teams, agencies, plugins, or embedded content.

That is the difference between a banner and compliance.

A banner is a UI component.
Compliance is a governed processing model.

Sector-level implications

Sector-level implications

Because individual companies are not named, the better question is how these patterns affect sectors.

The scan shows a market-wide issue: many Vietnamese corporate websites operate as third-party data environments. The page may look first-party to the visitor, but the browser often connects to Google, Meta, YouTube, advertising systems, analytics services, maps, embedded content providers, and other external infrastructure.

That creates different levels of risk depending on the sector.

Banking and financial services

For banks, securities firms, fintech providers, payment companies, and other financial institutions, the risk is especially serious.

These organizations already operate in high-trust environments. Their websites may include product journeys, branch locators, loan calculators, card applications, investor information, login links, campaign pages, customer-support flows, and lead-generation funnels. Even when the website does not process account data directly, the surrounding behavioral context can still be sensitive.

A visitor looking at mortgage products, credit cards, investment services, insurance-linked products, or business financing may reveal meaningful financial intent. If that behavior is shared with third-party advertising or analytics systems without strong consent and transfer controls, the issue is not merely “cookie compliance.” It becomes a trust, governance, and regulatory-risk issue.

Financial institutions should therefore treat website tracking as part of their broader data governance and vendor-risk framework. Tags should be reviewed like outsourced technology services, not like harmless marketing tools.

Insurance

Insurance websites often combine quote flows, lead-generation forms, campaign pages, product explainers, chat tools, and remarketing tags.

That creates a high risk of overcollection.

A user exploring life insurance, health insurance, travel insurance, motor insurance, or claims-related content may reveal personal circumstances, family context, risk appetite, health-related interest, financial planning behavior, or claims intent. Even when the website does not collect sensitive data directly, behavioral signals can still become revealing when combined with advertising identifiers and analytics profiles.

Insurance companies should be especially careful with Meta Pixel, Google Ads, remarketing audiences, call-tracking tools, and embedded third-party form systems. The commercial value of these tools is obvious, but so is the compliance risk.

Aviation and travel

Aviation and travel websites are often heavily instrumented because conversion, retargeting, route interest, and booking-intent analytics are commercially important.

But travel behavior can be sensitive in context.

A website visit may reveal destinations, timing, family travel, business travel, mobility patterns, or cross-border movement interest. If third-party technologies track those journeys before consent, the company may expose more than simple browsing behavior.

Travel and aviation companies should pay close attention to:

• analytics on booking flows,
• advertising tags on destination pages,
• retargeting pixels,
• embedded maps,
• loyalty-program landing pages,
• campaign microsites,
• and cross-border vendor infrastructure.

The more international the customer journey, the more important cross-border transfer governance becomes.

Retail and e-commerce

Retail and e-commerce sites are often the most aggressive users of marketing tags.

That is understandable from a growth perspective. These sites rely on conversion tracking, abandoned-cart journeys, product analytics, campaign measurement, lookalike audiences, and remarketing.

But business convenience does not cancel privacy obligations.

Retail browsing behavior can reveal income level, lifestyle, family status, health interests, children’s products, beauty concerns, religious or cultural preferences, and other personal patterns. When combined with persistent identifiers such as advertising cookies or pixels, that behavior can become highly valuable and highly intrusive.

Retailers should therefore separate:

• strictly necessary commerce functions,
• first-party analytics,
• advertising conversion tracking,
• remarketing,
• personalization,
• embedded content,
• and third-party audience tools.

Each should have a clear purpose, consent status, vendor disclosure, and retention logic.

Telecom

Telecom companies sit close to national digital infrastructure and handle large-scale user relationships.

Even a public-facing corporate or product website can reveal product interest, service availability checks, device preferences, broadband needs, enterprise connectivity interest, or customer-support behavior. Where telecom websites use third-party analytics, maps, chat, ad networks, or campaign tracking, those technologies should be assessed against a higher governance standard.

For telecoms, the issue is not only personal data. It may also intersect with broader Data Law, cybersecurity, infrastructure, and sector-specific expectations.

A telecom website should not be governed as a simple marketing site. It should be governed as part of a larger regulated data environment.

Manufacturing and industrial groups

Manufacturing and industrial companies sometimes assume that website privacy risk is mainly a consumer-brand problem.

The scan suggests otherwise.

Many industrial and B2B sites still load analytics, advertising tags, video embeds, maps, and third-party scripts. These may appear lower-risk than retail or banking tags, but they can still reveal business relationships, supplier interest, investor activity, procurement research, job-seeker behavior, or visits from sensitive commercial counterparties.

For industrial groups, the key risk is often unmanaged vendor sprawl. A website built over many years may include legacy plugins, old campaign tags, agency-installed scripts, embedded media, and forgotten analytics tools. Nobody owns the full inventory, but the company remains responsible for the data flow.

Logistics and transport

Logistics websites often include shipment tracking, quote requests, customer portals, branch maps, service-area tools, and B2B lead-generation flows.

That makes third-party tracking more sensitive than it may first appear.

A logistics user may reveal shipment interest, commercial routes, import/export activity, business relationships, operational timing, or supply-chain context. If those interactions are mixed with third-party analytics or advertising infrastructure, the company may unintentionally disclose commercially sensitive behavior as well as personal data.

Logistics companies should assess tracking tools not only through a privacy lens, but also through an operational confidentiality and data-governance lens.

Real estate

Real estate websites and campaign landing pages often rely heavily on advertising pixels, conversion tracking, embedded maps, virtual tours, forms, and retargeting.

The privacy risk is clear. A user’s browsing behavior can indicate income level, family planning, relocation intent, investment capacity, preferred location, and financial readiness.

For real estate companies, the main issue is usually campaign sprawl. Each new project or landing page may add new pixels, forms, scripts, or agency tools. Over time, the company loses control of what is loaded and who receives data.

The consent model must therefore cover not only the main corporate website, but also campaign pages, microsites, agent pages, and lead-generation funnels.

Consumer goods and food brands

Consumer brands often rely on social media integrations, embedded videos, campaign pages, contests, loyalty programs, and influencer-driven landing pages.

These environments can create significant third-party tracking exposure, especially when Meta, YouTube, Google Ads, TikTok-style campaign tools, or other marketing platforms are involved.

The risk increases where campaigns involve children, families, health-related products, beauty products, lifestyle segmentation, or loyalty programs. In those cases, website data can quickly become behavioral profiling data.

Consumer brands should treat marketing campaigns as privacy events, not only creative launches.

The common sector lesson

Across all sectors, the lesson is the same: the website cannot be treated as an isolated communications channel.

It is part of the organization’s data supply chain.

For low-risk sites, the immediate task may be basic cleanup: remove unused tags, block non-essential scripts, and add real consent controls.

For regulated or high-data-volume sectors, the task is broader. The organization needs a website data-flow inventory that connects to:

• PDPL compliance,
• Decree 356 documentation,
• Data Law classification,
• cross-border transfer governance,
• vendor-risk management,
• cybersecurity review,
• marketing operations,
• and audit evidence.

“The higher the sector risk, the less acceptable it is to treat website tags as a marketing detail.”

shows that many organizations need to move from website marketing management to website data governance.

Risk exposure and fine levels

This is where boards and management teams should pay attention.

Website tracking is easy to underestimate because it often enters the organization through marketing, web development, agencies, plugins, or campaign tools. But legally, the issue is not small. A website can create personal-data processing, third-party disclosure, vendor dependency, and cross-border transfer before anyone in management has reviewed the underlying data flow.

Vietnam’s Personal Data Protection Law and Decree 356 both take effect from 1 January 2026. Together, they move personal-data protection from a policy exercise into a much more formal compliance obligation. Organizations need to understand what personal data they process, why they process it, who receives it, whether it crosses borders, and what records exist to prove lawful handling.

Official Government coverage of the PDPL legislative process also makes clear that the sanctioning direction is intentionally strong. It describes potential administrative exposure including:

• up to 10 times the unlawful gains for buying or selling personal data,
• up to 5% of the previous year’s revenue for violations involving cross-border transfer of personal data,
• up to VND 3 billion for other violations,
• and fines for individuals at half the level applicable to organizations.

The detailed application of sanctions will depend on the applicable implementing and enforcement instruments. But the direction is already clear: Vietnam is moving toward meaningful financial consequences for unlawful personal-data handling, especially where data is commercialized, transferred, or processed without proper controls.

That matters because website tracking rarely stays as a simple “cookie issue.”

When a site connects visitors to Google, Meta, YouTube, DoubleClick, Google Ads, analytics platforms, maps, chat widgets, embedded media, or advertising systems, the risk chain can escalate quickly:

• from pre-consent loading,
• to unlawful or weak consent,
• to inadequate transparency,
• to undisclosed vendor processing,
• to uncontrolled third-party disclosure,
• to cross-border transfer exposure,
• to Data Law classification questions,
• to sector-specific governance risk,
• and potentially to data commercialization or data-product risk if the information is later transformed, monetized, exchanged, or reused.

“The risk is not the cookie alone. The risk is the unmanaged data flow behind it.”

This is why management teams should not ask only whether the company has a banner. They should ask whether the company can prove control.

Can the organization prove which third-party technologies loaded?
Can it prove which were blocked before consent?
Can it prove which vendors received data?
Can it prove whether any personal data or identifiers left Vietnam?
Can it prove which legal basis applied?
Can it prove what the user agreed to?
Can it prove that withdrawal stopped the processing?

If the answer is no, the exposure becomes broader than the cookie itself.

A weak website consent setup may create evidence of multiple failures at once:

• failure to inform,
• failure to obtain valid consent where required,
• failure to control processors or third parties,
• failure to document cross-border transfers,
• failure to maintain a reliable audit trail,
• failure to align marketing operations with privacy governance,
• and failure to demonstrate accountability when challenged.

For regulated sectors, the risk is even higher. Banks, insurers, telecoms, aviation companies, healthcare providers, large retailers, logistics operators, and infrastructure-related businesses need to treat website tags as part of their wider data-governance and vendor-risk environment. A third-party beacon on a public website may appear small, but at enterprise level it can become a recurring outbound data flow to foreign infrastructure.

That is the board-level issue.

The company may believe it is running a marketing website.
The browser may show it is operating a third-party data supply chain.

What companies in Vietnam should do now

The practical response is to bring the website under technical, legal, and operational control.

The immediate task is not to write a longer privacy policy. The immediate task is to bring the website under technical, legal, and operational control.

1. Scan every public-facing page template

Do not only scan the homepage.

Most website-tracking risk appears across templates and campaign pages, not only the front page. Companies should scan:

• homepage,
• product pages,
• service pages,
• campaign landing pages,
• lead-generation forms,
• recruitment pages,
• investor pages,
• embedded video pages,
• branch or store locator pages,
• maps,
• blog pages,
• checkout or booking flows,
• customer-support pages,
• and microsites managed by agencies or business units.

The goal is to identify what the visitor’s browser actually loads, not what the privacy policy claims.

2. Build a real tag and vendor inventory

Every cookie, beacon, pixel, SDK, script, iframe, embed, map, chat widget, analytics endpoint, and advertising tag should be listed.

For each technology, the company should record:

• vendor name,
• domain or endpoint,
• technology type,
• purpose,
• data categories,
• whether identifiers are involved,
• whether the vendor receives personal data,
• whether the vendor is local or foreign,
• whether data may leave Vietnam,
• whether the technology is strictly necessary,
• whether consent is required,
• which business owner requested it,
• and which contract or data-processing terms apply.

This inventory should not sit only with the marketing team. It should be visible to privacy, legal, IT security, compliance, and vendor-risk owners.

3. Block non-essential technologies before consent

This is the single most important technical control.

If a tag is used for analytics, advertising, remarketing, embedded media, social plug-ins, heatmaps, session recording, personalization, maps, or campaign attribution, it should not load before the user has made a valid choice, unless the company has a clearly documented legal basis that justifies the processing without consent.

This also applies to tag managers.

A website should not treat Google Tag Manager as automatically neutral merely because it is a container. If GTM itself loads from Google infrastructure, that initial third-party call should also be assessed and controlled.

“Consent must control the technology. The technology should not run first and ask permission later.”

4. Separate necessary, analytics, marketing, embedded media, and functional third-party services

A strong consent model needs real granularity.

The company should separate at least:

• strictly necessary technologies,
• security and fraud-prevention technologies,
• preference cookies,
• first-party analytics,
• third-party analytics,
• advertising and conversion tracking,
• remarketing,
• social media plug-ins,
• embedded video,
• maps,
• chat widgets,
• personalization,
• and campaign tools.

This matters because a user may accept necessary functions but reject advertising. They may accept embedded maps but reject Meta Pixel. They may allow analytics but reject remarketing. A bundled “accept all” model does not provide meaningful control.

5. Treat YouTube, maps, chat widgets, and social embeds as compliance components

These are not “just content.”

A YouTube video, Google Map, Meta plug-in, chat widget, booking widget, lead form, or embedded campaign tool can create third-party processing. It can also trigger cookies, beacons, device identifiers, request metadata, or cross-border infrastructure calls.

Each integration should be reviewed like a vendor processing activity.

The right question is not “does this make the page better?”
The right question is “what data flow does this create, and is it lawful before consent?”

6. Review cross-border implications

If the website routes personal data, identifiers, device data, behavioral signals, analytics events, form data, or request metadata to foreign vendors or foreign infrastructure, the company should assess whether cross-border obligations are triggered.

That assessment should cover:

• which data leaves Vietnam,
• which vendor receives it,
• which country or region is involved,
• whether the vendor acts as processor, controller, or independent third party,
• whether onward transfer is possible,
• whether the transfer is necessary,
• whether consent or another legal basis applies,
• whether PDPL transfer documentation is required,
• whether Data Law classification issues arise,
• and whether sector-specific rules apply.

This is especially important for organizations in banking, insurance, telecom, aviation, healthcare, logistics, e-commerce, and other high-data-volume sectors.

7. Connect website tracking to the Data Law inventory

For many companies, website data will remain ordinary personal-data processing. But for larger or regulated organizations, website-derived data may become part of broader datasets, analytics products, customer intelligence, advertising audiences, AI model inputs, or commercial data services.

That means the website inventory should connect to the organization’s broader data inventory.

Companies should ask:

• Does website-derived data become part of customer profiles?
• Is it combined with CRM, transaction, loyalty, or offline data?
• Is it used for segmentation, scoring, profiling, or model training?
• Is it shared with vendors or platforms?
• Is it monetized, exchanged, benchmarked, or packaged?
• Could it fall into important data, core data, or sector-regulated data categories?

This is where the Data Law and the emerging data-exchange framework become relevant. The more data is reused beyond the original website visit, the more important provenance, purpose limitation, classification, and downstream-use controls become.

8. Make rejection and withdrawal as easy as acceptance

Consent should not be designed as a trap.

If “accept all” is one click, rejection and withdrawal should also be easy. A proper model should include:

• clear reject options,
• no manipulative design,
• persistent access to preferences,
• easy withdrawal,
• immediate technical enforcement,
• and proof that withdrawal stopped the relevant processing.

Withdrawal should not only change a preference screen. It should change what the website loads.

9. Keep an audit trail

If the company is ever challenged, it must be able to show evidence.

That evidence should include:

• what loaded,
• when it loaded,
• which version of the consent banner was displayed,
• which language was displayed,
• which purposes and vendors were disclosed,
• what the user selected,
• whether any tags were blocked,
• whether any tags were allowed,
• when consent was changed or withdrawn,
• and which data flows were active at the time.

Without this evidence, the company may have a banner but no defensible compliance record.

10. Establish tag governance before agencies and teams add new tools

A common failure is that marketing teams, web agencies, media agencies, plugin vendors, and business units add tags without privacy review.

That must stop.

Companies should create a simple approval workflow:

• no new tag without owner,
• no new vendor without review,
• no new campaign pixel without consent classification,
• no embedded third-party tool without transfer assessment,
• no agency-managed container without internal visibility,
• and no production deployment without a scan.

This does not need to be bureaucratic. It just needs to be controlled.

11. Rescan regularly

Website compliance is not a one-time project.

Tags change. Agencies add pixels. Plugins update. Embedded media changes behavior. Campaign pages go live. Developers add scripts. Marketing tools introduce new endpoints.

Companies should rescan:

• after each major release,
• before major campaigns,
• after agency changes,
• after plugin or CMS updates,
• after consent-banner changes,
• and on a recurring compliance schedule.

The scan should become part of the organization’s monitoring and evidence program.

12. Move from banner thinking to governed website data flows

This is the most important step.

A banner is not the control system. It is only the user-facing layer of a much larger compliance architecture.

A governed model requires:

• scan,
• classify,
• block,
• disclose,
• obtain consent where required,
• enforce the choice technically,
• document the vendor and transfer position,
• record evidence,
• monitor change,
• and connect the website to the company’s broader data-governance program.

“A compliant website is not one that shows a banner. It is one where the data flows obey the user’s choice.”

For Vietnamese companies, this is the practical path forward. The website must be treated as a regulated data environment, not merely a marketing asset.

The bigger lesson

The most important finding from this scan is not that Google, Meta, YouTube, advertising tags, analytics endpoints, or embedded third-party services are common on Vietnamese websites. That was expected.

The important finding is that their prevalence remains so high across major corporate sites, and that many of these technologies appear to sit inside website stacks without the level of governance the new Vietnamese data-regulation environment now demands.

This is the gap.

Marketing teams often see tags as campaign infrastructure.
Developers often see them as scripts.
Agencies often see them as implementation details.
But under a modern privacy and data-governance regime, they are data flows.

A third-party beacon is not only a technical request. It can be a disclosure.
A cookie is not only a browser file. It can be an identifier.
A YouTube embed is not only a video player. It can be a tracking surface.
A tag manager is not only a container. It can be the first third-party call the browser makes.
A conversion pixel is not only marketing attribution. It can be evidence of behavioral monitoring.

That is why this issue matters.

The website may look first-party to the visitor, but the browser often reveals a much wider third-party data supply chain. Google, Meta, YouTube, advertising networks, analytics systems, maps, social plug-ins, embedded media, chat tools, and campaign platforms can all become part of the user’s data journey.

The companies that win in this environment will not be the ones with the prettiest banner. They will be the ones that can prove their website stack is under control.

They will be able to show:

• which technologies load,
• why they load,
• who receives data,
• which vendors are involved,
• which purposes apply,
• whether consent was required,
• whether consent was obtained,
• whether non-essential processing was blocked before consent,
• whether data crossed borders,
• whether Data Law classification issues were considered,
• whether sector-specific rules apply,
• and whether an audit trail exists.

This is not a niche issue. It cuts across sectors. It affects major brands. It is visible in the browser. It is easy to test. And it is increasingly difficult to defend if the organization cannot show proper control.

“The browser is now an audit surface. What loads on the page may matter as much as what is written in the privacy policy.”

The deeper lesson is that website compliance can no longer be separated from enterprise data governance.

A company cannot claim mature privacy compliance while its public website silently loads unmanaged third-party scripts. It cannot claim strong cross-border data controls while foreign vendor calls are embedded across campaign pages. It cannot claim meaningful consent if the tracking stack runs before the user has made a choice.

This is why the website must move from marketing ownership alone into shared governance between marketing, legal, compliance, IT, cybersecurity, procurement, and data protection leadership.

Website tracking is no longer just a digital marketing question.

It is a board-level data-governance question.

Conclusion

The scan of Vietnam’s top company websites shows a clear pattern.

Third-party tracking remains common.
Google and Meta dominate the observed ecosystem.
YouTube is a major hidden source of cookie and beacon activity.
Google Tag Manager is widely used as a third-party loading layer.
A large share of sites appear structurally exposed from a consent, transparency, vendor-governance, and cross-border data-flow perspective.

For Vietnamese businesses, the era of informal website privacy is ending.

The Personal Data Protection Law and Decree 356 create a stronger accountability environment for personal-data processing. The Data Law adds a wider governance layer for data classification, important data, core data, and cross-border handling. The emerging draft Data Exchange Decree shows where Vietnam may go next: toward more formal rules for data products, data services, provenance, transaction governance, and accountable data commercialization.

That means website data can no longer be treated as harmless exhaust from digital marketing.

It may become:

• personal data,
• behavioral data,
• advertising data,
• analytics data,
• customer intelligence,
• cross-border data,
• sector-regulated data,
• data used for profiling,
• data used for AI or segmentation,
• or data that later becomes part of a commercial data product or service.

The practical conclusion is simple.

Vietnamese companies need to audit the stack, control the stack, document the stack, and monitor the stack.

They need to know what loads before consent.
They need to know which vendors receive data.
They need to know where the data goes.
They need to know whether the user had a real choice.
They need to know whether withdrawal actually stops processing.
They need to know whether cross-border and Data Law obligations are triggered.
And they need evidence.

A website is no longer only a marketing asset.

It is a compliance surface, a data-flow environment, a vendor-risk gateway, a cross-border transfer point, and in some cases, the first layer of a wider data-commercialization chain.

The companies that understand this now will be better prepared for Vietnam’s next phase of privacy and data regulation.

The companies that ignore it may discover too late that the easiest part of their data environment to test was also the one they governed the least.

“Do not claim compliance from the privacy policy. Prove it from the browser.”

Ronni K. Gothard Christiansen
Technical Privacy Engineer & CEO, AesirX.io

Laws and instruments referenced

• Luật Bảo vệ dữ liệu cá nhân (PDPL): Vietnam Personal Data Protection Law, Law No. 91/2025/QH15, issued 26 June 2025, effective 1 January 2026.
• Nghị định 356/2025/NĐ-CP: Decree detailing and guiding implementation of the Personal Data Protection Law, issued 31 December 2025, effective 1 January 2026.
• Luật Dữ liệu: Vietnam Data Law, Law No. 60/2024/QH15, issued 30 November 2024, effective 1 July 2025.
• Nghị định 165/2025/NĐ-CP: Decree detailing and guiding implementation of the Data Law, issued 30 June 2025, effective 1 July 2025.
• Draft Decree on Data Exchange Operations: Draft decree on the operation of data exchanges / data trading platforms, published by the Ministry of Public Security for consultation from 3 April 2026 to 13 April 2026.
• Luật An ninh mạng: Vietnam Cybersecurity Law, referenced as part of the wider legal context for cybersecurity, cross-border digital services, and data governance.
• Luật Giao dịch điện tử: Vietnam Law on Electronic Transactions, referenced as part of the wider legal context for digital transactions, data systems, and trusted electronic records.
• Sector-specific rules and supervisory expectations: Relevant sector overlays may apply depending on the organization, including banking, insurance, telecom, aviation, healthcare, logistics, e-commerce, infrastructure, and other regulated or high-data-volume sectors.

Disclaimer

This article is for informational purposes only and does not constitute legal advice. It is based on a technical scan of resolved and analyzable website behavior and a compliance interpretation of the legal instruments referenced above. The scan results should not be treated as a final legal determination of any individual company’s compliance status.

Organizations should obtain qualified legal advice before making regulatory filings, cross-border transfer assessments, data-classification decisions, or enforcement-risk conclusions. AesirX ComplianceOne and Forseti can support compliance work, evidence management, regulatory mapping, and audit preparation, but they do not replace qualified legal counsel or human review and approval of compliance evidence, assessments, and filings.

FAQs