You have published a new privacy policy, the cookie banner works, and the notices have been updated. GDPR compliance is now taken care of — or at least that is what the post-implementation report suggests. But then someone opens your online store in a clean browser session and discovers that one tool described in the policy does not exist on the website, while three others are operating even though they are not mentioned in either the policy or the record of processing activities.
This is not a hypothetical situation. It is a pattern that regularly emerges several weeks after a GDPR implementation has been completed. The management board believes that the documentation is complete. Meanwhile, the website takes on a life of its own — marketing installs new plugins, the provider updates integrations, and no one informs the person responsible for data protection.
This article explains what a post-implementation website audit is, why a privacy policy alone is not enough to demonstrate GDPR compliance, and how to check in a few steps whether the declarations in your documents match what actually runs on your website. You will also learn about the risks arising from discrepancies between your documentation and the actual state of affairs — and what to do about them before the President of the Polish Data Protection Authority does it for you.
Key concepts you need to know
Before we move on to the assessment method, it is worth clarifying a few terms. This is not about theory — it is about making sure you know exactly what you are checking and why.
| Concept | What it means in the context of your website |
|---|---|
| Post-implementation audit | A technical and documentation review conducted several weeks after GDPR recommendations have been implemented — it checks whether the changes are actually working and whether any new discrepancies have emerged |
| Record of processing activities (Article 30 GDPR) | A document in which the controller describes every operation involving personal data: its purpose, legal basis, categories of data, and recipients. The obligation applies to every controller, regardless of company size |
| Consent mode | The technical configuration of analytics and advertising tools that determines whether scripts run before the user gives consent or only after consent has been given |
| Consent management mechanism (cookie banner) | The interface through which users give or refuse consent to cookies — it must comply with the requirements of Article 7(3) GDPR and Article 399 of the Electronic Communications Law |
| Information obligation (Article 13 GDPR) | The information that the controller must provide to a person when collecting their data: the controller’s identity, the purpose of processing, the legal basis, the retention period, and the person’s rights |
| Data processing agreement (Article 28 GDPR) | An agreement between the controller and a provider (e.g. the website provider) that processes data on the controller’s behalf — it governs the scope, purpose, and conditions of processing |
Why implementing GDPR does not put the matter to rest
Implementing a privacy policy, launching a cookie banner, and updating notices is the starting point — not the end point. The accountability principle under Article 5(2) GDPR requires you to be able to demonstrate compliance at all times, not only on the day the documents are published.
The problem is that a website changes faster than its documentation. Marketing adds a tracking pixel. Accounting integrates a new invoicing tool. The website provider updates a review collection plugin that enables automatic purchase review invitations by default. Each of these changes is a new processing activity — with its own purpose, legal basis, and potentially an obligation to obtain consent for electronic communications (Article 398 of the Electronic Communications Law).
Discrepancies can go both ways
This is the most important observation from post-implementation reviews. Discrepancies between the documentation and reality are not one-directional:
| Direction of the discrepancy | What it involves | Provisions breached |
|---|---|---|
| A tool described in the policy but not operating on the website | The company declares processing that it does not carry out — misleading users about the scope of operations performed on their data | Article 5(1)(a) GDPR (fairness), Article 12(1) GDPR (transparency) |
| A tool operating on the website but not included in the policy or the record | Processing takes place without a documented legal basis — the controller is unable to demonstrate it | Article 6 GDPR (no legal basis), Article 13 GDPR (no information), Article 30 GDPR (no entry in the record), Article 24 GDPR (lack of accountability) |
An audit conducted solely “on paper” — that is, one limited to reading the policy — will not detect either type of discrepancy. To identify them, you need to open the website and compare what happens there with what the documentation says.
Three common sources of discrepancies
- Plugins with features enabled by default. A post-purchase review collection plugin may automatically send emails inviting customers to leave a review — and it may do so from the moment it is installed, before anyone consciously decides to activate the feature. This is a separate processing activity and, if invitations are sent by email, it is also subject to Article 398 of the Electronic Communications Law.
- Integrations added by other departments. An accounting and invoicing integration, a new analytics tool, or a marketing pixel — each processes personal data and must be entered in the record of processing activities, described in the policy, and checked to determine whether a data processing agreement is in place with the provider.
- The consent management provider omitted from the documentation. The paradox is that the very tool intended to ensure GDPR compliance is itself omitted from the record of processing activities and the privacy policy. The consent management provider is the one most often forgotten — because it is “the compliance tool”.
Contact us if you would like to check whether your website has any such discrepancies.
How to conduct a post-implementation website audit step by step
A post-implementation review does not require specialist software. It requires a method. Below is the recommended sequence of steps — from opening your browser to analysing the policy’s content.
Step 1: use a clean session and observe what happens before consent
- Open your browser in private mode or clear the website data (cookies, cache, and local data).
- Visit the website — do not click anything on the cookie banner.
- Open the developer tools (F12 in most browsers).
- Go to Application → Storage → Cookies and list all cookies stored before you interact with the banner.
- Go to the Network tab and check which network requests have been sent — look for analytics, advertising, and third-party domains.
- Classify every cookie and request: is it technical (essential for the website to function), or does it require consent?
If you see analytics or advertising cookies, or requests to advertising providers’ domains before giving consent, that is a warning sign. It does not automatically mean there has been a breach, but it requires clarification: what is the legal basis for storing the data, and has the user been informed about it?
Step 2: check the consent mode configuration
Check the values of the consent mode parameters in the website code:
| Parameter | Correct default value (before consent) |
|---|---|
analytics_storage |
denied |
ad_storage |
denied |
ad_user_data |
denied |
ad_personalization |
denied |
If any of these parameters has a default value of granted, analytics or advertising tools run before the user gives consent.
Step 3: assess the first layer of the banner
Open the cookie banner and check which options the user sees on the first screen:
| Element | Correct state | Incorrect state |
|---|---|---|
| “Allow all” button | Present | — |
| “Reject all” button | Present and visually equivalent to “allow” | Missing or hidden in the second layer |
| “Customise” / “settings” button | Optional | Does not by itself replace “reject” |
A “customise / allow all” layout without an equivalent reject button is a pattern identified as unlawful in EDPB Guidelines 03/2022. Article 7(3) GDPR requires withdrawing consent to be as easy as giving it. The CJEU judgment in C-673/17 Planet49 confirmed that consent requires active, specific action, while the judgment in C-61/19 Orange România held that consent is not freely given when the user must actively object to processing (Decisions of the President of the Polish Data Protection Authority – list).
This is a change the website provider can implement at the configuration level — it does not require a new project or an additional budget.
Step 4: cross-check the policy against the website
This is where you combine the technical findings with the documentation. Prepare two lists:
- Tools described in the policy but not found on the website — each such tool represents a declaration of processing that the company does not carry out.
- Tools found on the website but not included in the policy or the record of processing activities — each such tool represents processing without a documented legal basis.
A systems register that includes only positive entries (“we have this, it works”) will not detect the first type of discrepancy. It is therefore worth deliberately adding negative entries marked “not found” — this allows the register to account for the documentation rather than merely list the current state.
Step 5: verify privacy notices
Go through all forms on the website (contact, newsletter, and registration forms) and check the notices displayed below them:
- Have the controller’s details been completed, or is there still a placeholder such as “(personal data controller’s details…)”?
- Does the notice contain the complete set of information required under Article 13 GDPR: the controller’s identity, the purpose of processing, the legal basis, the retention period, and the person’s rights?
- Does the newsletter form separate the two layers of consent: consent to the electronic communication channel (Article 398 of the Electronic Communications Law) and the legal basis for processing personal data under the GDPR?
An incomplete placeholder can survive several consecutive reviews — because no one reads a notice they inserted themselves.
Step 6: analyse the content of the privacy policy
Analyse the policy’s content last — so that you compare it with the established facts, not the other way around. Check:
- Whether the policy is labelled “draft” — if so, it is binding on data subjects while describing itself as unfinished.
- Whether the publication date has been completed.
- Whether it refers to Article 173 of the Telecommunications Law (repealed) instead of Article 399 of the Electronic Communications Law — a reference to a repealed provision is an immediate sign that the document is outdated.
- Whether it refers to documents that no one has prepared: a Transfer Impact Assessment (TIA), a risk assessment, or a Data Protection Impact Assessment (DPIA). A TIA and a DPIA are two separate documents — a TIA examines the effectiveness of transfer safeguards in the context of the third country’s laws, while a DPIA assesses the effects of processing under Article 35 GDPR. A policy that refers to both must have both in place.
The most common shortcomings identified in post-implementation reviews
Experience from reviewing e-commerce websites reveals a recurring pattern. The table below groups shortcomings by priority — from those requiring immediate action to those that require the facts to be established.
| Priority | Shortcoming | Who fixes it | Effort required |
|---|---|---|---|
| Urgent | No equivalent reject button on the first layer of the banner | Website provider | Configuration change |
| Urgent | Incomplete placeholder for the controller’s details in the notice below a form | Website provider | Content completion |
| Urgent | Policy labelled “draft” without a publication date | Website provider / company | Remove the label and add the date |
| Urgent | Reference to Article 173 of the Telecommunications Law instead of Article 399 of the Electronic Communications Law | Legal adviser | Update the policy’s content |
| Urgent | The policy refers to a TIA, risk assessment, or DPIA that does not exist | Company + legal adviser | Prepare the documents or remove the references |
| Medium | Tools are operating but not included in the policy or the record | Company + legal adviser | Add an entry to the record and update the policy |
| Medium | A tool is described in the policy but not found on the website | Company + legal adviser | Remove it from the policy or implement it |
| To be determined | Review plugin with automatic invitations — feature status unknown | Company (internal verification) | Check the configuration |
| To be determined | Encryption of data at rest, backup testing, access rights review | Company (IT) | Confirm implementation |
Note the entries marked “to be determined”. An external review cannot tell you anything about encryption of data at rest or backup testing — these elements require confirmation from the IT team. It is better to state this explicitly than to let anyone believe that the report covers everything.
One conclusion recurs in every review: most urgent shortcomings can be fixed through simple changes by the website provider. They require no effort from the company other than issuing an instruction. A list of shortcomings does not necessarily mean a new project and a new budget.
The systems register — a tool that brings order to the entire process
The review itself is a one-off assessment. To ensure that the results are not lost and that the next review has a point of reference, you need a register of systems and tools operating on the website.
The register should contain at least four columns:
| Tool / component (provider, country of establishment) | Function on the website | Provider’s legal role and categories of data | Status and comments |
|---|---|---|---|
| Consent management mechanism (provider X, Germany) | Collecting and managing cookie consent | Processor; data: cookie identifiers, IP address, user choices | Compliant — requires a data processing agreement |
| Analytics tool (provider Y, USA) | Website traffic analysis | Independent controller or joint controller; data: identifiers, activity data | Compliant — transfer based on Decision (EU) 2023/1795, provided that the importer is certified |
| Marketing pixel (provider Z, USA) | Remarketing and conversions | Independent controller; data: identifiers, activity data | Not found on the website — negative entry |
| Accounting and invoicing integration (provider W, Poland) | Invoice generation, customer data synchronisation | Processor; data: first name, surname, address, tax identification number, transaction data | Operating but not included in the policy — requires an entry in the record of processing activities and an update to the policy |
Negative entries (a tool described in the policy but not found on the website) are a deliberate documentation decision. They allow the register to account for the documentation rather than merely list the current state. An item assessed as compliant should also include a maintenance recommendation — otherwise, after a year, no one will remember that it was checked and found to be satisfactory.
Data transfers outside the EEA
For every tool whose provider is established outside the European Economic Area, check the basis for the transfer. As of the publication date of this article, Commission Implementing Decision (EU) 2023/1795 establishing an adequate level of protection under the EU-US Data Privacy Framework remains formally in force (Decision (EU) 2023/1795 – Polish text on EUR-Lex). It covers only US organisations certified under the DPF. Proceedings challenging the decision are pending before the EU courts (Proceedings document C_202506610), but as of the publication date, no final judgment annulling it has been issued.
Contingency plan: Standard Contractual Clauses (SCCs) under Article 46 GDPR, combined with an assessment of the laws and practices of the recipient country (Transfer Impact Assessment — TIA) and supplementary technical measures (encryption, pseudonymisation). The SCCs may not be modified, but they may be incorporated into a broader agreement containing additional clauses, provided that those clauses do not conflict with them.
Your relationship with the website provider — what to include in the agreement
The website provider (hosting, maintenance, development) acts as a processor under Article 28 GDPR. It installs plugins, updates integrations, and configures the consent management mechanism. If it does so without your knowledge, you, as the controller, lose control over the processing.
Article 28(3) GDPR gives you the necessary tools, but you must actively use them in the data processing agreement:
| Right / obligation | Legal basis | What to include in the agreement |
|---|---|---|
| Acting only on documented instructions | Article 28(3)(a) GDPR | A prohibition on installing tools, plugins, and integrations without notifying the controller in writing and obtaining approval |
| Right to audits and inspections | Article 28(3)(h) GDPR | The right to conduct a review at least once per calendar year, subject to notification of its scope, timing, and authorised participants |
| Engaging subprocessors with consent | Article 28(2) GDPR | The obligation to obtain prior written consent for each subprocessor |
| Remedying shortcomings within a specified period | Article 5(2) GDPR (accountability) | A deadline for implementing changes after an audit (e.g. 5 working days for urgent shortcomings and 10 for the others) |
| Assistance with compliance obligations | Article 28(3)(e)–(f) GDPR | The obligation to assist with data subject rights requests and breach notifications |
A contractual penalty for failing to meet these obligations must be regulated separately — the GDPR does not impose one automatically.
How often to repeat the review
The GDPR does not specify a fixed review frequency. Article 24(1) requires measures to be implemented and reviewed and updated “where necessary”. Article 32(1)(d) requires regular testing and assessment of the effectiveness of measures. Processors should be audited at least once a year (Guidelines 05/2020 on consent – Polish Data Protection Authority).
For a website, the following schedule works well:
| Type of review | When | Scope |
|---|---|---|
| Post-implementation | Several weeks after implementing the recommendations | Verification that the changes have been implemented correctly and that no new discrepancies have emerged |
| Annual | Every 12 months | Full cross-check, update of the systems register, verification of provider agreements, review of transfers |
| Ad hoc | After every change to the website (new plugin, integration, or change of provider) | Verification of the new element and update of the documentation |
A “to be determined” status from a review should be temporary. Assign an owner to each such item (the person responsible for resolving it), a response deadline (based on the level of risk), and an escalation path if no response is received. No response does not mean acceptance of the risk — it means a lack of accountability.
We can help you with this
A post-implementation review does not have to be complicated — but it must be thorough. It requires combining a technical analysis of the website with an assessment of the documentation and knowledge of the current legal framework. This is exactly what we do as part of our annual data protection programme.
Our support is available at three levels, tailored to your company’s needs:
- Operational minimum — a one-off website review with a list of urgent shortcomings, a policy–website cross-check, and recommendations assigned to responsible parties and prioritised.
- Solid foundation — a review plus a register of systems and tools, and updates to the privacy policy and privacy notices.
- Comprehensive protection — an annual programme including monitoring of legal developments, registers of transfers and subprocessors, regular reviews, and an outsourced Data Protection Officer provided by our law firm.
We work with e-commerce, SaaS, and IT companies that treat data protection as part of organisational management — not as a one-off project to be completed and forgotten.
GDPR compliance is a process, not a document
A privacy policy is a document. GDPR compliance is a state that requires continuous verification. Every new plugin, every integration, and every change introduced by the website provider may create a new processing activity — with its own purpose, legal basis, and information obligation.
A post-implementation website audit is a method for detecting discrepancies before the supervisory authority does. Most urgent shortcomings are simple configuration changes that the website provider can implement on your instructions. The real expense arises from documents that no one has prepared and processes that no one monitors.
If your company has completed a GDPR implementation and you want to check whether the matter is genuinely settled — contact us.
Frequently asked questions
We paid for GDPR implementation six months ago — why do we need another review of the same website?
An implementation establishes the position as at the date the documents are published. From that point on, the website changes: marketing adds tools, the provider updates plugins, and new integrations are introduced. A post-implementation review checks whether the declarations in the policy still match what is actually happening on the website. Without it, you cannot be sure that the documentation is up to date — and the accountability principle under Article 5(2) GDPR requires compliance to be demonstrated at all times, not only on the implementation date.
How much IT work does this involve? Does a list of shortcomings mean a new project?
Most urgent shortcomings identified during reviews are configuration changes made by the website provider — adding a reject button to the banner, completing a placeholder in a notice, or removing the “draft” label from the policy. They require no effort from the company other than issuing an instruction. Costs arise only where documents that no one has prepared are required (TIA, DPIA, risk assessment), or where organisational and technical work is needed from IT (encryption, backup testing).
How can we check in five minutes whether our cookie banner is configured correctly?
Open the website in a clean browser session (private mode or with the website data cleared). Do not click anything on the banner. Check two things: whether the first layer of the banner displays a visually equivalent “reject all” button alongside “allow all”, and whether any analytics or advertising cookies appear in the Application → Cookies tab of the developer tools before you interact with the banner. If the reject button is missing or cookies are stored before consent, this is a warning sign that requires investigation.
Do automated post-purchase emails requesting a review require separate consent?
Automatically sending invitations to leave a review is a separate processing activity with its own purpose and legal basis. When sent by email, it is also subject to Article 398 of the Electronic Communications Law, which requires consent to send unsolicited commercial communications electronically. This feature is sometimes enabled by default when a review collection plugin is installed — check the configuration and determine whether your company consciously activated it.
Is a privacy policy published as a “draft” without a date binding?
Yes — a policy published on the website is binding on data subjects regardless of how you have labelled it. A “draft” label with an empty publication date works against you: in the event of a dispute or inspection, it supports the argument that the controller itself considered the document unfinished but nevertheless published it as binding. Remove the “draft” label and add the publication date.
Can I ask the website provider to carry out such a review, or must it be done by someone external?
The website provider acts as a processor — it should not assess its own compliance. A post-implementation review should be conducted by someone independent of the provider: an internal DPO, an external adviser, or a law firm. The website provider is, however, the recipient of the recommendations — it is responsible for implementing the resulting configuration and technical changes.
