How to assess GDPR compliance? Key website compliance self-check points explained at a glance

What should you look at first to determine whether a website basically complies with GDPR requirements?

　　The easiest mistake to make when assessing GDPR compliance is to focus only on the cookie pop-up and privacy policy page. For quality control or security management personnel, what really matters is not “whether it has been written down,” but “whether the data is collected lawfully, clearly disclosed, properly transferred, and capable of being evidenced.”

　　If a website targets users in the EU or actually processes personal data from the EU, it is advisable to start with four points during a self-assessment: what personal data is collected, what the legal basis for collection is, who the data is sent to, and whether users can withdraw consent or submit deletion requests. This order is practical because many websites appear to have complete copy on the surface, while the actual problems lie in forms, analytics code, and third-party plugins. This order is practical because many websites appear to have complete copy on the surface, while the actual problems lie in forms, analytics code, and third-party plugins.

　　Simply put, whether a website can be considered “basically compliant” does not depend on how attractive the pages look, but on whether you can trace a piece of data from the moment it enters the website through its storage, use, sharing, and deletion.

Does placing only a privacy policy on the website count as compliance?

　　No. A privacy policy is only part of the obligation to provide information; it is not compliance itself.

　　A usable privacy policy should at least address several core questions: who processes the data, what data is processed, for what purpose, what the legal basis is, how long the data is retained, whether it is transferred to third parties or overseas, and how users can exercise their rights of access, rectification, erasure, and objection.

　　However, the problem with many websites is not that “nothing has been written,” but that “what has been written does not match actual practices.” For example, a page may state that data is “used only to respond to inquiries,” while the backend synchronizes form data with a CRM, email marketing platform, and advertising remarketing tool. Alternatively, it may state that data is “not shared with third parties,” while actually loading external chat plugins, maps, videos, and analytics scripts. Such inconsistencies between documentation and actual practices are themselves high-risk issues.

Why might a website still fail to comply with GDPR even after a cookie pop-up appears?

　　Because the key issue is not “whether a pop-up appears,” but “what the default behavior is.” If non-essential cookies are already written to the device before the user gives consent, the pop-up remains problematic no matter how complete it is.

　　During an actual review, it is advisable to examine cookies in two categories:

• Essential cookies: such as login sessions, shopping cart maintenance, and basic security protection. These can generally be set based on the operational needs of the website.
• Non-essential cookies: such as analytics, advertising tracking, social media sharing, and heatmap recording. These generally require valid consent in advance.

　　Three details also require attention: whether the reject button is clearly visible, whether consent by category can be selected, and whether users can change their choices afterward. Providing only an “Accept” option without a “Reject” option, or hiding the rejection option deeply within the interface, are common problems.

Are forms the part of a website most likely to cause problems?

　　Usually, yes. Forms directly collect names, email addresses, telephone numbers, company names, and job titles, and sometimes also collect budgets, purchasing requirements, regions, and attached files. Once this information can identify an individual, it falls within the scope of GDPR concerns.

　　To determine whether a form is compliant, you can review it according to the following logic:

1. Are the fields necessary? If a mobile phone number is not needed, it should not be required by default.
2. Is the purpose clearly stated before submission? For example, whether the information is used for quotations, after-sales contact, or marketing subscriptions.
3. Is marketing subscription consent selected separately? An inquiry request cannot be bundled with marketing consent.
4. Is the transmission encrypted? Both the form page and the submission interface should use HTTPS.
5. Does the backend have access controls and a data retention period in place?

　　Many teams make their frontend notices very comprehensive, but automatic forwarding from backend email accounts, form export files accumulating for long periods, and shared use of test accounts are all weaknesses in terms of security and compliance.

To what extent should third-party tools be checked?

　　At a minimum, they should be “visible, explainable, and disableable.” Common third-party tools on websites include analytics, advertising pixels, online customer service, email subscriptions, CDNs, video players, map plugins, and social media components. They are not necessarily unlawful; the problem is that many companies have no idea what data these tools actually take away.

　　During a self-assessment, do not look only at what is written in the page source code. You should also examine actual network requests, script loading times, and where the data goes. Security management personnel are usually concerned with the following information in this table:

What is the most common misjudgment for marketing websites targeting the European market?

　　A common misjudgment is assuming that GDPR has little to do with the company because the website server is not located in Europe. In reality, the focus is not only on where the server is located, but also on whether the company offers products or services to EU users or monitors their behavior.

　　For example, supporting EU languages, running advertising campaigns targeting Europe, accepting payments in euros, collecting inquiries from European visitors, and conducting remarketing tracking may all cause GDPR to apply. For websites focused on overseas customer acquisition, the more complete the marketing chain, the less compliance should be understood as merely “adding something to the legal page.” Website development, SEO, advertising, and data analytics are inherently part of one chain. It is best to review frontend collection methods, backend retention rules, and third-party interface permissions together. This is also something that many integrated website and marketing service projects need to address before launch.

When conducting an internal review, should quality control or security management personnel check the documents or the system first?

　　Create a checklist first, then cross-check the documents and the system. Looking only at the documents may overlook technical implementation, while looking only at the system makes it difficult to determine whether the legal basis for processing is complete.

　　A practical approach is to first prepare a list of data processing activities, including page entry points, field names, collection purposes, receiving systems, storage locations, retention periods, deletion methods, and relevant third parties. Then use this list to compare the privacy policy, cookie settings, permission configurations, log records, and supplier agreements.

　　Some teams prepare detailed policy documents, but their systems still contain historical form databases that no one cleans up, accounts belonging to former employees that have not been revoked, and real customer data copied into test environments. For security personnel, these issues are often more deserving of priority than the wording on the page.

What evidence is best retained in advance during a GDPR compliance self-assessment?

　　Not every issue can be resolved through verbal explanations, so anything that can be documented should be documented where possible. Key materials include cookie consent records, privacy policy version records, third-party tool lists, records of processing activities, procedures for handling user requests, account permission assignments, and records of deletion or anonymization activities.

　　Here is a practical observation: website redesigns, the addition of new plugins, and changes to form fields can quietly undermine compliance. If change records are kept too generally, investigating problems later can be very time-consuming. Even for marketing pages, privacy copy, tracking strategies, and interface changes should be included in the launch checklist.

　　Incidentally, if internal training materials or knowledge content involve policies or processes, attention should also be paid to whether the way they are linked and the context are appropriate. Content such as Research on Financial Management of Hospital Infrastructure Projects under the Background of the New Accounting System may not itself constitute a high risk if it is merely displayed on an information page. What really matters is whether the page contains forms, tracking scripts, download-based lead collection, or external link redirection.

If non-compliance is discovered, should a function be taken offline first or should the documents be supplemented first?

　　It depends on the risk level, but the principle is clear: where ongoing unlawful collection or data processing triggered without consent is involved, control the risk first and supplement the documentation afterward.

　　Several scenarios requiring priority handling include:

• Advertising or analytics scripts begin tracking before the user has given consent.
• The form collects sensitive information unrelated to the business.
• Data is transmitted in plain text by email or through an interface.
• The source of a third-party plugin is unknown, and it continuously sends visitor data externally.

　　These issues cannot be appropriately addressed merely by modifying the privacy policy as a “remedy.” The correct sequence is to first pause the relevant scripts, disable the fields, restrict access, and cut off synchronization, and then complete the disclosures, authorizations, and records.

Can you remain confident in long-term compliance after completing one review?

　　No. A website’s GDPR compliance is not a one-time status, but rather the result of continuous maintenance. Marketing websites in particular are frequently redesigned, use many plugins, have numerous landing pages, and involve long advertising chains. Compliance today does not mean that the situation will remain the same next month.

　　A more reliable approach is to incorporate the review schedule into daily processes: conduct a review before launching a new page, when adding a new third-party tool, when changing form fields, and perform a comprehensive review once every quarter. For security management personnel, the most valuable thing is not memorizing the provisions, but establishing a review mechanism that can identify deviations, track responsibility, and make timely corrections.

　　Ultimately, the most practical conclusion is this: when determining whether a website complies with GDPR, do not first ask “Is the page wording complete enough?” Instead, ask “Where did this piece of personal data come from, where did it go, why can it be processed, and who can prove it?” Once these four questions are clarified, you will basically have a clear understanding of the website’s compliance status.