Expertise · GDPR compliance and Law 195/2024

We bring a system that talks to clients in a state in which it can be shown to an inspector, and we verify that from code, not from a questionnaire.

Law No. 195/2024 applies in the Republic of Moldova from 23 August 2026 and transposes GDPR. We do the engineering part: we inventory what the system actually collects, verify the real behaviour of the page, write the processing activities register and implement retention, consent and deletion as functions that run. We do not provide legal advice.

Discuss a project

Already builtTwo in-house implementations, plus the work done on ourselves. First: `gdpr-scan-md`, a deterministic scanner, with no artificial intelligence component, public at `ongdpr.md` (checked with curl on 06.09.2026: 308 redirect to `/ro`, then 200 with 95,131 bytes). It has seven modules, weights and thresholds written in a single file as the single source of truth, and 488 `it()`/`test()` cases in the engine’s test directory. Second: the full text of Law 195/2024 modelled in machine format — 90 articles, 384 paragraphs, 408 letters, 9 chapters, 16 sections — with the MD5 of the source PDF and the extraction method recorded in the file, so that a citation can be checked down to the page. The third proof, the one that says the most: the art. 30 register of this site, written for us, with the declared limitations of the work itself and eight points still open. Mandatory reserve: we are not a law firm and we do not issue legal opinions. A technical tool does not replace a lawyer, and we say that in the product as well, not only here.

Law no. 195/2024 on the protection of personal data was adopted on 25 July 2024, published in the Official Gazette no. 367-369 of 23 August 2024 and entered into force on 23 August 2026. It transposes Regulation (EU) 2016/679. For a company in Moldova, this means that the obligations that were previously spoken of as something “European” are now local obligations, with a local authority and with fines that are calculated in lei or as a percentage of turnover, whichever is greater.

The part we deal with is engineering. A system that talks to clients — a site with a form, a chat assistant, an agent that answers the phone, a CRM — collects data in places that nobody remembers after the second year. The published policy says one thing, the code does another, and the divergence is not seen until someone asks. The work therefore starts from the code and from the real behaviour of the page, not from a questionnaire completed by someone who remembers what it was like last year.

We say plainly what we do not do: we do not provide legal advice, we do not issue opinions, we do not draft defences, and we do not take the place of a lawyer or data protection officer. We are builders. We produce the verified inventory, the technical evidence, the register and the implementation — the material a lawyer can work with instead of starting from statements. Where the question becomes legal, we mark it as such and pass it on.

The result is measured differently from what is customary. Not by the number of documents produced, but by how many public statements remained standing after verification. On our own website, that exercise has meant, above all, deletions: an annual independent penetration test, a 180-day audit log, encryption across all databases, daily off-site backups, fourteen sub-processors and two hosting locations — none could be supported with evidence, so none remained on the page.

GDPR compliance and Law no. 195/2024 — the engineering part · video in Romanian, with subtitles and a transcript in English

Full transcription

Let’s get straight to the point. Welcome to a new analysis, today we’re tackling a huge challenge for everything that means the business environment, especially in the context of the new regulations in the Republic of Moldova. Our absolute focus today: how do we check compliance directly from the code, and not from endless stacks of paper. Very often, when it comes to confidentiality, everyone looks at the legal documents uploaded on the site, but, surprise, the documents almost never reflect the technical reality of the system, so today we’re exploring exactly how we can extract the pure truth directly from the infrastructure. Section 1. The illusion of declarative compliance. Or, in other words, what we officially declare on paper versus what we actually do in practice.

Just think for a moment what a site actually does behind the scenes when nobody is looking at it. A virtual assistant or an online shop spills data through all sorts of corners that, let’s be honest, the technical team probably completely forgot about two years after launch. Dozens of third-party tools, analytics scripts, marketing code, all of these run silently in the background, without a technical eye looking under the bonnet, it is simply impossible to know exactly who is extracting what data or where they are sending it. And here’s the trap. On the one hand we have the theory, that static privacy policy, unchanged for years and, most often, based on a template. And on the other hand?

Well, on the other hand there is reality. The code is alive, extremely dynamic, constantly updated and sucking data in the background. This gap between theory and practice is invisible, until a hard audit or, much worse, a security breach, when no one can ignore the elephant in the room any more. Let’s move on to section 2, MISA, namely Law 195/2024, with direct and quite harsh impact starting on 23 August 2026. We’re basically talking about European obligations brought here, in the form of local, strict rules, in the Republic of Moldova, and the maximum ceiling for fines? 2 million lei. Yes, you heard that right. 2 million. These sanctions are designed specifically to discourage ignorance. A miserable cookie banner that doesn’t work properly technically is no longer a simple design error.

It is a huge legal and financial vulnerability. The law is very clear and does not really forgive. It always applies the higher value between the fixed amount and the percentage of turnover. For basic obligations, sanctions reach 1 million lei or 1% of turnover. But attention, the essential elements, meaning everything related to consent, people’s rights and data transfers, automatically move into the higher band, maximum 2 million lei or 2%. The key idea to remember here: any technical error on the consent side is charged without concessions at the maximum level. Which brings us to section 3, checking from the code or, as I like to call it, extracting the absolute technical truth. Given those huge fines, we simply can no longer rely on people’s memory or on questionnaires ticked in a hurry.

The solution lies in engineering, and the process has three ironclad steps. Step 1. We read the source. We query the server to see clearly what reaches memory. Step 2. Extremely important. We press the reject button for cookies and listen to the network traffic for about 3 seconds. If the tools in the background keep sucking data, it’s clear, there is a problem. And step 3. We draft the famous Record of Processing Activities based strictly on these incontestable technical доказательства. In this way the document becomes anchored in reality. To standardise this whole story, technical tools such as the GDP Scan MD scanner use a fixed mathematical score, with a maximum of 1. But there is a golden rule here, a very hard one.

A single critical element failing instantly caps the final score at 0,49. Bam, non-compliant. That means you can have the most beautiful and well-written privacy policy in the world, but if a tracker starts before the visitor gives consent, you’ve failed the test. Documents simply cannot save badly written code. We move on to section 4. The real case on a proprietary platform. A technical audit of radical transparency. To prove it works, the team behind the methodology decided to test their own tool directly on their own site. And what do you know? Over the years, on their public page, all sorts of fantastic corporate claims had piled up. A 180-day audit log, encryption on absolutely all databases, some 14 sub-processors.

It sounded extremely professional, didn’t it? Only those claims had appeared there by inertia. They had simply been copied from one internal document to another, without anyone checking from the primary code whether those things were still valid. So they applied the technical rule with absolute rigour. No primary document extracted directly from the code for a statement? It gets removed! They did a massive general clean-up. A heap of pompous phrases about old tests or irrelevant backups disappeared completely. The reason? Simple. It is much, much safer to have a shorter, honest compliance page, anchored 100% in real facts, than a dossier full of promises you cannot prove in the event of an inspection. Ah, and besides this clean-up, the self-audit brought to light something fascinating about AI-based intelligent chatbots.

They bring three major risks with them. 1. At hand, they retain all sorts of sensitive data that visitors throw in there completely unsolicited. 2. The inevitable transfer of those texts to a third-party model provider, usually in another country. And 3. The most critical aspect, listen here. Writing to the browser memory on the simple opening of the page, before the person clicks anything. The only solution? To go into the code and block the model from loading until the visitor actually decides to press the conversation start button. We also get to section 5, the technical and legal limits. How far engineering goes and where we have to let the legal professionals do their job. It is absolutely clear that the methodology in the code is vital, but let’s not kid ourselves, it does not solve absolutely everything on its own.

The technical tool deals with tangible things. It inventories the infrastructure, looks into the code and brings out clear evidence about how the system behaves. However, mind you, it does not amount to a legal opinion. A technical tool cannot decide the legal grounds in a contract and does not interpret laws. That part is the exclusive territory of lawyers. In short, technology lays a super-solid foundation of concrete, of evidence, and the lawyers come and build legality on top of it. This boundary brings to light something extraordinary about the famous article 30, the Register of Processing Activities. I’ll tell you a secret, a live register genuinely generated from code will never look immaculate at the first scan. Those rows marked as unverified, which require a human, legal decision, those very rows show the real transparency of an organisation.

Any register that looks perfect from day one, complete and with no open errors, is in almost all cases a cheap illusion, a simple card filled in from a template that completely ignores the real complexity of a piece of software. So, drawing a line under everything we’ve talked about, seeing this colossal difference between what is written on paper and what the machinery actually executes, in your organisation what does the verification process look like? Does compliance rely on some dusty documents, forgotten somewhere in the website basement, or on indisputable certainties extracted directly from the live code? Moving to a technical check is not just a box to tick on paper in order to get around Law 195/2024. It is the ultimate guarantee that you truly respect people’s data. A shift in perspective that simply transforms the way we think about security.

What it covers

The work, by component

The inventory is made from code and from the live server, not from a questionnaire

The first stage means reading the source and interrogating production: what fields are actually written, where they go, what is placed in the browser memory and when, which third-party services load the page, what the server log retains and for how long. One concrete example from our own inventory: the chat assistant on the site loaded on every page view and wrote the session identifier and history into the browser’s local memory **before** the visitor asked for anything. No questionnaire would have revealed that, because nobody knew it.

Behavioural verification: we press the refuse button and listen to the network

The presence of a consent banner proves nothing. Our scanner finds the banner, actually presses the refuse control, and then listens to network traffic for three seconds. A tracking tool counts as a breach only if it was already pulling before any consent and continues to pull after refusal, without a refused-consent signal. A site that properly runs implicit refusal is not punished for its cookie-free pings — the rule was added explicitly so as not to contradict the check that rewards exactly that behaviour.

The register of processing activities, written as a live document

Article 30 requires a record of processing activities with purposes, categories of data subjects and data, recipients, transfers, erasure periods and a description of security measures. We write it line by line from the verified inventory, and what could not be verified remains marked „unverified”, not filled in from a template. The maintenance rule is written into the document: if a code change alters what is collected, where it goes or how long it is kept, the register and the published policy are changed **in the same commit**. Divergence between code and policy is exactly the problem that generates the document.

A score that can be reconstructed, not a tick box

The seven categories have fixed weights: cookies 0.25, consent mechanism 0.20, policy 0.20, transport 0.15, forms 0.08, jurisdiction 0.07, controller identity 0.05 — exact sum 1.0, verified by a test. A failed finding reduces its category proportionally to severity: critical 1.0, high 0.6, medium 0.3, low 0.15; a warning costs half. Above 80 is compliant, above 50 is risk, below — non-compliant. All numbers are kept in a single file, as a single source of truth, so that anyone can reproduce the calculation.

The hard rule for breaches that are happening right now

A single failed critical finding forces the verdict „non-compliant” and caps the score at 49, regardless of what the weighted formula would say. The reason is simple: tracking tools that pull before consent, or a refuse button that stops nothing, affect every visitor at this moment. An impeccable privacy policy is not allowed to raise the average above that.

Retention as an automated task that leaves a trace, not as a promise in the policy

„We keep data for 24 months” is a statement that can only be checked one way: by running deletion. At our site, the lead request log reads its period from configuration (`LEAD_RETENTION_DAYS`, default 730 days) and cleans up on every write. In a larger platform, the cleanup is a scheduled task that runs **after** the backup and only if it succeeded — a deletion without a fresh backup is the only form of deletion from which there is no return — and writes a row into an execution table. That row is the compliance proof required by Art. 5(2). Before the first real activation, the task runs empty for at least a week and the log is read.

Transfers: where the obligation stops and where it begins

Art. 44(2) says that the entire chapter on transfers **does not apply** to transfers to EEA states, where no special authorisations are required. That completely changes the analysis: hosting in the European Union is not an aesthetic preference, it is the difference between „nothing to justify” and „a file of safeguards”. For the rest, we check concretely: which provider receives what, on what basis, and whether the invoked derogation fits. An example from our own register: notification via Telegram is a transfer to a third country, and we wrote in the register that the invoked derogation is designed for occasional transfers, while ours is systematic. It is a recognised limitation, with the technical alternative written alongside it.

Banner detection that does not pretend to see everything

Eighteen well-known consent platform selectors, each with a cited source, plus a heuristic for hand-written banners — very common at small firms in Moldova — that reads computed styles from the live page, not the static HTML. The walk enters open shadow DOM and iframes, because some banners live entirely there. Closed shadow roots remain invisible by construction: we say that openly and have a test that holds the claim in place.

Removing claims we cannot support

The least pleasant and most useful part. A compliance page that lists non-existent certifications, audits and practices is a bigger risk than a short one, because every line becomes a verifiable statement before the authority. The rule we apply: a public claim has one line in an evidence register, with the primary document — not the internal document that repeats it. Claims without a primary document are removed until the document appears.

What it looks like

The path, step by step.

We scan from the outside and read from the inside, in parallel

Automated scanning gives the public state in a few seconds: transport, cookies before consent, the banner’s real behaviour, policy content elements, forms, jurisdiction, the controller’s identity. In parallel, the code is read. We deliver the report with findings, evidence and the reference to the corresponding article in Law 195/2024 — and the list of divergences between what the published policy says and what the system does.

We write the register and mark what could not be verified

The record of processing activities, one activity per line, with purpose, legal basis, categories, recipients, transfers, location, term, measures and the reference to the file in the code where it is implemented. We also deliver the list of open points, with the name of the person who must decide. A register with no open points on the first pass is usually a register filled in from a template.

We fix in code what is fixed in code

Implicit consent refused, third-party components loaded only after acceptance, minimisation applied at write time, retention as an automated task with a log, status checkpoints, rights over files. Each fix goes in together with the change to the document that describes it, in the same pass. We deliver the code and the result of the rescan, so the difference is measurable, not declared.

We hand over the file and the procedure that keeps it alive

The register, the breach notification procedure, the impact assessment where required, the list of sub-processors with what each receives, and the evidence register for public claims. Plus the rule that keeps them up to date: policy and code change together. Anything that requires legal interpretation goes to the lawyer, with the technical material prepared.

The path of a compliance task: external scanning and code reading in parallel, then the list of divergences between the published policy and the real behaviour, then the register of what was checked and what remained open, then the fixes in code — with a rescan at the end, so the difference is measured, not declared.

The data

What we touch, where it lives, and how long it stays

The questions anyone with a data protection officer would ask — asked here before they do.

What automated scanning actually sees: Only the public surface of the analysed website: response headers, written cookies, network requests triggered by the page, policy text, form fields, third-party domains called. It does not log in, does not fill in forms with real data and does not touch password-protected areas. Scanning a public site is exactly what any visitor does, with the clock running.
How our robot behaves: 45-second budget per scan. Own user agent, which identifies itself and links to the page that explains what the scan does and how to opt out. The target site’s `robots.txt` is respected by default, with a separate read capped at 8 seconds, so a slow `robots.txt` does not eat into the audit budget. Before any request, a guard blocks internal addresses, the local network and the cloud infrastructure metadata endpoint.
What we touch in a compliance job on the client’s system: The database schema, configuration, code and logs — not the content of personal data. When a check still requires a real example (for instance, what actually ends up in a notification), it is done on a test case created for that purpose, not on a live client. Access is granted for the duration of the job and revoked at the end, and the revocation is checked.
Where our data sits and why it matters: This site runs on OVHcloud, Bucharest, Romania — the European Economic Area. The assistant platform runs on Microsoft Azure, Poland Central, confirmed by querying the virtual machine metadata service, not from the vendor documentation. Server logs rotate daily with 14 retained copies, with restricted read access. These three lines replaced a much longer list of locations we could not confirm.
Minimisation, applied to us as well: The visitor IP address is not written in full: it is truncated before storage to the network prefix — /24 for IPv4, /48 for IPv6 — because the published policy says IPs are anonymised, and the statement must be true in code. The request log is kept with 0600 permissions in a 0700 directory. The form state check point returns only booleans, never the token, chat identifier or bot name.

A case

What remained of a compliance page after the primary document was requested for every line

The situation

The work was done on ourselves, not on a client. The firm’s public compliance page had been written by accumulation: statements appearing in one internal document, repeated in a second, carried into a third and reaching the site without anyone ever asking for the original. They all sounded equally certain.

What we built

We applied a single rule: every public statement gets one line in an evidence register, with the primary document — not the document that repeats it. In parallel, the real behaviour was checked: which cookies are written before consent, with browser memory cleared; what the page loads on open; what retention term actually exists in code; where the servers sit, by querying the machine metadata service, not the vendor documentation.

What came out

Among other things, the annual independent penetration test fell away, as did the 180-day audit log, the declared encryption on all databases, two-factor authentication on all admin accounts, the encrypted off-site daily backup, a number of sub-processors three times higher than the real one and two non-existent hosting locations. Two locations remained, both confirmed in the European Economic Area. Separately, a real problem no one knew about was found and fixed: the chat assistant loaded on every page view and wrote the session and history into browser memory before the visitor asked for anything. It now loads on button press.

What the case does not say

The resulting register is not clean and it should not be: it has eight open points, marked with the name of the role that must decide, and an explicitly acknowledged limitation about a systematic transfer covered by a derogation intended for occasional transfers. A register with no open points, written in the first pass, is almost always a register filled in from a template. The value of the document lies in the lines that say "unverified".

Questions

What people ask us before they call

Are you giving legal advice?

No, and it is important to be clear from the start. We are not a law firm, we do not issue legal opinions and we do not replace a data protection officer. We handle the technical part: the verified inventory from the code, proof of the system’s real behaviour, the art. 30 register and implementation. This is the material a lawyer can work with. Our public tool says the same thing about itself — it is a technical analysis, not a legal assessment.

From what date does the law apply and what concrete risk is there?

Law No. 195/2024 entered into force on 23 August 2026. The fines have two thresholds, and the text says the higher value of the amount and the percentage is taken: up to 1,000,000 lei or 1% of the total turnover from the previous year for the obligations of the controller and the processor; up to 2,000,000 lei or 2% for the basic principles of processing and the conditions for consent, for the rights of data subjects and for transfers to other states. Consent and people’s rights are in the upper band — which is why a banner that does not work matters more than it seems.

We host in the European Union. Do we still have transfer obligations?

For transfers to states in the European Economic Area, no. Article 44(2) says explicitly that the entire chapter on transfers does not apply to these transfers and that no special authorisations are needed. That makes the hosting choice a compliance decision, not only one of latency. Obligations remain, however, for any provider outside the EEA — including small services that no one puts on the list: messaging notifications, traffic statistics, a transactional email service.

Do we need to appoint a data protection officer?

The law requires it in three situations: public authority or body; core activities that involve regular and systematic large-scale monitoring of data subjects; or large-scale processing of special categories of data or data relating to criminal convictions. If you do not fall within this, appointment remains optional — but beware of the trap we found in our own case: if you publicly state that an officer has been appointed, the notification obligation that accompanies the appointment appears. The published position and the internal assessment must not contradict each other. Whether you fall within it or not is a legal question; we flag it, we do not decide it.

How long do we have if a breach happens?

Notification to the Centre is made without undue delay and, where possible, within 72 hours from the moment of becoming aware; after this deadline, the notification must be accompanied by a reasoned explanation of the delay. The authorised person notifies the controller without undue delay. The hard part is not the deadline, but what the notification must contain: the nature of the breach, the categories and approximate number of persons and records affected. Without a proper record of what data is held where, the 72 hours are spent searching. That is why the register is written before the incident.

Does an AI assistant that talks to clients complicate things?

Yes, in three concrete points. First: the conversation contains what the client writes, and clients write anything, including sensitive data you never asked for — this calls for an explicit instruction for staff and a retention period. Second: the assistant sends text to a model provider, so a sub-processor appears and, usually, a transfer. Third, the one most often overlooked: the component is often loaded when the page opens and writes to the browser memory before the visitor has asked for anything. That is exactly what we found on our own site and fixed by loading only when the button is pressed.

Does a score of 100 mean we are legally in the clear?

No. The score measures what can be measured automatically from the public surface: transport, cookies, banner behaviour, policy content elements, forms, jurisdiction, the controller’s identity. It does not see the real legal basis for the processing behind it, the contracts with sub-processors, the consent records in the database, actual retention, or how you respond to a request for access. A good score says the surface is clean. The rest is checked from the inside, and the interpretation remains legal.

Can you scan our site without breaking anything?

The scan is a visit, not a penetration test: the public page is loaded, the banner refusal control is pressed, and traffic is listened to, with a total budget of 45 seconds. The robot identifies itself with its own user-agent and respects the site's `robots.txt` by default. It does not log in, does not fill in forms with real data, and does not touch protected areas. If you prefer not to be scanned, blocking via `robots.txt` works and is respected.

Why did you remove claims from your own compliance page instead of adding more?

Because every public claim is a verifiable statement. Our page listed an annual independent penetration test, a 180-day audit log, encryption across all databases, two-factor authentication on all admin accounts, encrypted daily off-site backups, fourteen sub-processors and multiple hosting locations. None could be supported with a primary document. We removed them and left what can be shown. A short and truthful file stands up to scrutiny; a long and decorative one does not.

What the statements above rest on (25 sources)

ongdpr.md responds with 308 to /ro, then 200 with 95,131 byteshttps://ongdpr.md · 2026-09-06

24 of them are code and files from our repositories. We don't publish their name or line: together, on a single page, they would describe too precisely how systems that aren't only ours are built. We go through them with you, in the repository, on request — verification stays possible, it just happens in a conversation.

How we work All services

What would you want to work better?

Tell us about your process. Together we decide what is worth building, what we can connect, and how we check the result.

Let's talk