Remove "we may" or "possible" from your privacy policy. EU regulators call for plain language.

Open the privacy policy on your own site and search it for the words "we may".

I ran that search across 336 published policies in August 2026. 69% of them came back with a hit, and most had more than one: among the policies that hedge using language like "we may", "might", "some", "possible" etc., the median is three and the highest was 55. If yours is in that group, every hit is a sentence about what your company does with other people's data, written so that nobody can tell whether you do it or not.

That's a problem and the work to fix it, is to settle those sentences against your own systems, one at a time. Do it sooner than later, because the next person to read the document closely may not be you. It could be an enterprise prospect's counsel holding your Privacy Policy up against your DPA, or a customer asking which sub-processors hold their data, and neither question can be answered out of a sentence that says "we may".

What is wrong with "we may"?

"We may share your personal data with third-party service providers" is either true or false about your product today, and the sentence is built so the reader cannot find out which.

The EU's data protection authorities have written this down explicitly. Before the GDPR applied, those authorities sat together as the Article 29 Working Party, and their Guidelines on transparency say that language qualifiers such as "may", "might", "some", "often" and "possible" should be avoided 1. A company that keeps indefinite language has to be able to "demonstrate why the use of such language could not be avoided and how it does not undermine the fairness of processing". That's very hard to do in practice. The guidelines ask for information that is "concrete and definitive", not "phrased in abstract or ambivalent terms", and the poor-practice examples they give read like generator output: "We may use your personal data to develop new services", "We may use your personal data for research purposes".

That is guidance rather than a prohibition, but it sits on top of two provisions that are not. Article 12(1) of the GDPR requires the information in Articles 13 and 14 to reach people "in a concise, transparent, intelligible and easily accessible form, using clear and plain language", and Article 5(1)(a) makes transparency one of the principles the whole regulation rests on 2.

They are also not a period piece from 2018. The European Data Protection Board, the body that replaced the Working Party and seats the head of each country's data protection authority, adopted these guidelines as its own on its first day 3 and was still citing them for detailed transparency guidance in September 2025 4.

What did 336 published policies say?

As I stated above, I actually went and checked how frequently unclear wording like "we may" etc. was used in the privacy policies of sites that launched their product on Product Hunt. The answer: Mostly that they hedge. 231 of the 336 (69%) use "we may" or "we might" about their own processing, and the same pass turned up two smaller patterns worth knowing about.

See this earlier post on legal bases and transfers for the full methodology of the scan. I should note here that since these are Product Hunt launches, most of these companies are American, though Article 3(2) reaches any that offers its product to people in the Union 2.

The middle row is the one I did not expect to matter. 41 policies instruct the reader to keep checking the document for changes: "You are advised to review this Privacy Policy periodically for any changes", or "We encourage you to review this policy periodically". The transparency guidelines address that exact habit. They warn that telling the users to regularly check the notice for updates are "considered not only insufficient but also unfair in the context of Article 5.1(a)" 1. What the guidelines ask for instead is that material changes get pushed to people through a channel devoted to the change, such as an email or a notice in the product, rather than left on a page for them to find. Two of the 41 do promise exactly that alongside the line, which is the compliant version of it; the other 39 offer the reader nothing but the invitation to keep looking.

Then there is what those 41 sentences have in common with each other. 25 of them appear word for word, capitalisation included, in at least one other company's policy. "You are advised to review this Privacy Policy periodically for any changes" turns up in six different companies' documents; three more share "We encourage you to review this Privacy Policy periodically". A sentence that appears identically in six unrelated companies' privacy policies is not a statement about any of their products.

How do you turn "we may" into a sentence you can defend?

Go through the points below one at a time. For each one, exactly one of four things is true:

1. You do it. Delete the hedge. "We share", "We use", "We transfer".
2. You do not do it. Delete the sentence.
3. You do it under a condition. Plenty of real hedges are covering a genuine "sometimes": you use a payment processor for paying customers only, or one optional integration is the only thing that sends data abroad. Name the condition rather than the possibility. "When you subscribe, we share your billing details with Stripe" is a fact; "we may share your data with payment providers" is not. This is also the one case where keeping the hedge is defensible, and the guidelines say what that costs you: you have to be able to show why the vague wording could not be avoided 1.
4. You cannot tell. Ask whoever owns that system, which is usually one question to one engineer. If nobody at the company knows either, stop looking for it in the document: that is not a wording problem but something the company does not know about itself, and it belongs on the second list at the end of this post.

Where to look depends on the sentence, and none of these are legal questions:

• "We may share your data with third-party service providers." Article 13(1)(e) lets you publish either the recipients or the categories of recipients 2, so this is about the internal list you write the sentence from, not about naming every vendor on the page. The real list is spread across your cloud console, your billing page and the browser's network tab on your own marketing site. Every vendor that receives personal data belongs on it, including the ones nobody thinks of as vendors, like your error tracker and your email sender.
• "We may transfer your data outside the EEA." Take the list you just made and find out which region each vendor runs in. This is a settings page per vendor, not a research project.
• "We may retain your data for as long as necessary." Article 13(2)(a) wants the storage period, or the criteria used to determine it 2. "As long as necessary" is that field left blank. Go and find what your system deletes and when. If the honest answer is that nothing has ever been deleted, write that down as the retention position and then decide whether you want to publish it.
• "We may use cookies." Open your own site in a private window and read the cookie jar.

While you are in the document, delete the line inviting readers to check the policy periodically, and put in its place what you will actually do: email people when something material changes. If you would not send that email, do not publish the sentence.

Each of those takes minutes and produces a fact. The document then follows from the facts, which is the opposite order to the one the generator worked in.

Which problems does a search box miss?

A search box misses two things. The first is silence: the disclosure that should be there and simply is not, which no search for hedged wording can find, because there is no sentence to find.

That gap is bigger than the vague one. In the same scan, of the 233 products that publish a policy and load a third-party service in the visitor's browser, 139 say nothing whatsoever about international transfers. Of the 397 policies, 217 name no legal basis at all. Reading your own document more carefully will never surface a missing section, so this one is checked the other way round: start from the list in Article 13, the twelve things a privacy notice has to tell people, which I walked through in an earlier post, and ask which of them your policy answers.

The second gap is time. Your policy was accurate the day it was published, and then you shipped. Adding one analytics vendor makes the recipients sentence wrong. Adding a call to a model API makes the recipients sentence and the transfers sentence wrong together. Both are changes the transparency guidelines say should reach your users before they take effect 1, which is hard to manage if nobody wrote down the day it happened. Re-reading the document will never surface any of this, because the change happened in the product rather than in the text.

What do you do with the list?

Open the policy, search for "we may", and for each hit write down what you would have to open to settle it: a console, an invoice, a table, a cookie jar. You will end up with two lists, sentences you can fix in an afternoon and facts that nobody at the company currently knows. That second list is the useful output of the exercise, and it does not shrink by rewording the document.

It is also what my co-founder and I built Lawcel for. Lawcel is a tool that keeps a structured record of the facts your legal documents stand on: the vendors that receive personal data, the regions they run in, what you store and for how long. It writes your documents from that record instead of from a questionnaire, and when a required fact is missing it asks you and then declines to draft until it has an answer, because filling that space with "we may" is the problem itself rather than a way past it. From then on it reads the pull requests in your repository and opens a case, a flagged item naming which document a change contradicts, so the day you add that model API is the day you hear about it.

So start the second list, whatever you keep it in. If you would rather not keep it by hand, that is what we are here for: give Lawcel the facts you dug up today and it will tell you which ones are still missing before it writes you anything.