GDPR-compliant project management: five questions for any vendor
Every vendor claims GDPR compliance. Five questions that test whether it holds – on data location, the processing agreement, sub-processors, export and what the tool measures about you.
The short version
- GDPR compliance isn't a feature a vendor owns – it comes out of where the data sits, what the contract says, and what actually gets processed.
- Five questions give you a first read: where is the data, who is the processor, who are the sub-processors, how do you get out, and what does the tool measure about you.
- A data centre in Frankfurt does not rule out the US CLOUD Act if the parent company is American. Location alone is not enough.
- A vendor who dodges these questions has already answered them.
The moment usually arrives late. You've been using a tool for two years. It holds client projects, bug reports and contact details including phone numbers. Then a new client – a clinic, a law firm, a local authority – asks for your data processing agreement and a list of sub-processors. You email the vendor. Back comes a PDF pointing at an Irish subsidiary, plus a link to a page listing forty service providers.
Now it's awkward. Not because you did anything wrong, but because the check is happening two years too late – and because switching now means carrying two years of project history with you. The cheapest moment for these five questions is before you sign up.
Why „GDPR-compliant“ isn't a product feature
On vendor sites the phrase reads like a property: GDPR-compliant, in the same breath as „responsive“ or „dark mode included“. It isn't. The regulation addresses you first – you are the controller under Art. 4, because you decide which data goes into which tool. The vendor is a processor and has to give you the means to meet your obligations.
That has a practical consequence: a tool can make the work easy or hard, but it cannot do it for you. „We are GDPR-compliant“ with no contract, no sub-processor list and no statement on location is therefore not a claim – it's a slogan.
Five questions a vendor should be able to answer
These five are enough for a first assessment. They're phrased so that an evasive answer stands out:
- Where exactly does the data sit – which country, and does the operator belong to a group headquartered outside the EU?
- Do I get a data processing agreement under Art. 28, and can I read it before signing?
- Which sub-processors are involved, and will I be told when that list changes?
- How do I get out: is there a complete export in a format that's readable without your product?
- What does the tool measure about us – tracking, analytics, or evaluating our content for product improvement or AI training?
Few people ask the last one, and it's often the most revealing. A tool that mines your project data to improve a model is also processing the client data you put in there.
Location alone isn't the answer
„Data centre in Frankfurt“ sounds settled but isn't. The US CLOUD Act obliges US companies to hand over data they control, regardless of which country the servers stand in. A European subsidiary of an American group falls under it. Location is therefore necessary but not sufficient; what matters alongside it is who controls the operator.
That's why the question about corporate structure sits in the same line as the one about the country. Asked separately, you get two accurate answers that together paint a false picture.
The agreement belongs before the signature
Art. 28 requires a contract between controller and processor before processing starts. In practice it gets sent afterwards – and by then nobody reads it, because the tool is already in production. Ask for it up front and read the two parts that actually matter: the sub-processor list, and what happens to your data when the contract ends.
How IssuePilot answers these five
A checklist is worth little if the vendor publishing it ducks out, so here are the answers for IssuePilot – including the points that are still open.
- Location: servers in Germany, operated by a German company with no foreign parent group. The second half of that sentence is the important one.
- Processing agreement: available on request via the contact page. It isn't a self-service download yet – that's an open point, not a secret.
- Sub-processors: named on request. Publicly named so far is Stripe for payments; Stripe processes card data, IssuePilot stores none.
- Export: you can export your data at any time, and we action deletion on request.
- Self-measurement: there is no third-party tracking inside the application. On this marketing website, analytics and marketing services load only after you actively consent.

On transport and storage: traffic between browser and IssuePilot is encrypted over HTTPS/TLS. Credentials in the password vault are encrypted with AES-256-GCM, with an access log recording who saw what and when. Your data is backed up regularly.
And what we deliberately do not claim: there is no ISO 27001 or BSI C5 certification, we name no specific data centre, and details on backup intervals, encryption at rest and TLS versions are provided on request rather than sharpened up here for marketing. A vendor who instantly quotes a neat figure on those points without being able to evidence it isn't more diligent – just bolder.

More detail is on the security page. If you'd rather work through it as a checklist, there's a free GDPR check that asks the same kind of questions about your own setup.
Where this checklist stops
Five questions are a shortlist, not legal advice – and this article isn't either. Whether a given processing activity needs a data protection impact assessment, what your record of processing activities must contain, and what counts as a special category of personal data in your case all depend on your business and belong in a conversation with someone who carries liability for the answer.
What the checklist does is filter early. Vendors who dodge questions one and three don't need further examination. That saves your time for the cases where a closer look pays off.
Common mistakes
- Checking only when a client asks: by then the project history is already in the tool and switching costs a multiple.
- Confusing data location with data sovereignty: the country answers the access question only together with the corporate structure.
- Filing the processing agreement unread: the two parts that matter – sub-processors and deletion – are rarely on page one.
- Putting everything you know into the tool: data minimisation is not a vendor property. Health data or national insurance numbers belong in no task field.
- Treating certification logos as proof: a seal says nothing about which scope was certified – or whether your processing falls inside it.
In short
The question isn't whether a vendor writes „GDPR-compliant“ on their homepage. It's whether they give five concrete answers without dodging: country and corporate structure, contract before signature, sub-processors with change notifications, complete export, and what they measure about you.
For teams handling data from healthcare, public administration or professional services, this has stopped being a box-ticking exercise. You'll have to pass those answers on to your own clients – and you can only pass on what you were given. How IssuePilot sits next to the larger tools is in the Jira alternative comparison.
Security & data protection at IssuePilot
Take a lookYannick Schneider
Founder of IssuePilot
Yannick builds websites and software for clients at Schneider & Liska Webservice. IssuePilot grew out of that everyday work – out of wanting to stop hunting for feedback, bugs and tasks across five different channels.
More about us