Privacy Policy

GitHands — githands.com

Version 1.0.2 · In force from 2026-08-02

This notice explains what we do with personal data when you use GitHands Cloud and the websites, applications and application programming interfaces we make available at githands.com (together, the "Service"). It tells you what we collect, why, who else sees it, how long we keep it, and what you can ask us to do about it.

We have written it to be read rather than to be defended. Where something is uncomfortable — data we hold that you never gave us, or data your employer decides to collect through our software — we say so plainly instead of burying it in a list.

What this notice covers

• The website at githands.com and the pages served from it.
• The GitHands Cloud web application, together with any desktop application, mobile application or browser extension we publish for it.
• The application programming interfaces and integrations we operate for it.
• The emails, notifications and support conversations that go with it.

A product-specific annex appears later in this notice. It adds detail for GitHands — what it actually collects, what is switched off by default, and which controls exist. It sits on top of this notice rather than instead of it, and where it is more specific about GitHands, the annex governs.

What this notice does not cover

Other companies' products. Other companies operate their own websites, products and services, and publish their own privacy notices. This notice covers only what is listed above. If a service is not on that list, this notice does not apply to it — whatever it looks like, and whoever links to it.

Software you run yourself. Some of our software is published as open source and can be installed on your own infrastructure. If you run your own deployment, you are the controller of the personal data in it — not us. You choose its hosting, its storage, its email provider and every other component. We have no access to that data, we do not process it, we are not your processor for it, and nothing in this notice describes it. Telling your own users what happens in your deployment is your job, not ours.

Sites we link to. The Service links out to third-party websites and services. Once you follow a link away from us, the operator of that site decides what happens to your data. We do not control those sites, we do not receive what you do on them, and we are not responsible for them. Read their notices, not this one.

Your organisation's own systems. Where your employer or another organisation uses the Service, it also runs systems of its own. This notice covers our part. Its notice covers its part.

Who we are

The controller of the personal data described in this notice is Ever Technologies LTD, a company registered in Bulgaria under company number 204599535, with its registered office at Mladost 2, bl. 211, ent. A, Sofia 1799, Bulgaria.

"Controller" is the legal term for the organisation that decides why personal data is used and how. Wherever this notice says we make that decision, Ever Technologies LTD is the organisation accountable to you — and to the Commission for Personal Data Protection (Комисия за защита на личните данни) (CPDP), which is our lead supervisory authority.

Ever Technologies LTD operates GitHands Cloud and is the company you contract with for it. There is no other operator behind us and no second company you have to chase to get an answer.

You can reach us about anything in this notice at [email protected], or by post at the registered office above.

There are parts of this notice where we are deliberately not the controller: where a customer puts personal data about its own people into the Service, that customer decides, and we act on its instructions. That split matters, so it has its own section below.

Other companies in our group

There is one other company in our group, and its role is narrow enough to state in a sentence.

Ever Co. LTD, a company registered in Israel under company number 515241842, with its registered office at HaAtsmaut 32/3, Ashdod 77452, Israel, owns the intellectual property in the software. Ever Technologies LTD operates the Service under licence from it.

That is the entire relationship. Its consequences are worth stating positively rather than leaving you to work them out:

• Ever Co. LTD does not access personal data held in the Service. No administration console, no production database, no support tooling, no backups, no error reports.
• It is not a controller of that data, not a processor of it, and not a sub-processor. It does not appear on our sub-processor list, because there is nothing for it to appear against.
• No personal data is transferred to it. No international transfer to Israel arises out of your use of the Service, because none happens.

Owning software is not the same as having access to the data that software holds, and we have kept the two apart on purpose.

If that ever changes — if Ever Co. LTD were to take on any role involving personal data from the Service — we would update this notice before it happened, name the role, disclose the transfer and the safeguard we relied on, and add it to our sub-processor list. Until you read that here, none of it is happening.

Data protection contact

We have not designated a Data Protection Officer. Article 13(1)(b) of the GDPR asks a controller to publish a Data Protection Officer's contact details where one has been designated. None has been designated at Ever Technologies LTD, so there are none to publish. We would rather tell you that outright than let a mailbox name imply otherwise. We keep the question under review, and if it changes we will publish the details here.

What we do publish is a contact route that is monitored and acted on. Privacy questions and requests to exercise your rights are handled through these addresses:

• [email protected] — use this for anything about this notice, about the personal data we hold, or to make a request under any of your rights.
• [email protected] — an alias that reaches the same people. It exists because procurement forms, security questionnaires and privacy tooling routinely expect an address in that form. It is a routing alias, not an office. Nothing about it means a Data Protection Officer has been designated.

You can also write to us by post at the registered office given above.

We will acknowledge your message, and we will answer a request to exercise your rights within one month — the deadline the GDPR sets. Where a request is genuinely complex, or where you have made several, we may extend that by up to two further months. If we do, we will tell you inside the first month and explain why.

Who decides what: controller and processor

Data protection law splits responsibility in two. The controller decides why personal data is used and how. The processor only acts on the controller's instructions. Which of the two we are is not a formality — it decides who you go to, who has to answer you, and who is accountable when something goes wrong.

Our position depends on whose data it is. There are three cases. We set them out here, in the privacy notice, rather than leaving them to a data processing agreement, because the person most affected by the second case is usually the person least likely to read a contract.

1. Our own relationship with you — we are the controller

Where we decide, we are accountable. We are the controller for:

• registration and account identity — the name, email address and credentials used to create and hold an account;
• billing, payments, invoices, tax records and collections;
• support conversations, including the tickets, emails, chats and attachments themselves;
• security, fraud prevention, abuse handling and audit logging;
• our own websites and their analytics, our newsletters, and our marketing to prospective customers; and
• running our business — accounting, insurance, professional advice, and defending claims.

Everything in this notice about purposes, legal bases, retention, transfers and your rights applies to this first case directly, and you exercise those rights against us.

2. Personal data a customer puts into the Service about its own people — the customer is the controller

When an organisation subscribes to the Service and uses it to run its business, the personal data it puts in is its data. It decides what to collect, which features to switch on, why, and for how long to keep it. We process that data only on that organisation's instructions. For it, the organisation is the controller and we are the processor.

This covers the ordinary contents of a workspace — employee and contractor records, contact details, projects, tasks, documents and messages. It also covers the parts that matter most, where a product provides them and the customer has enabled them:

• time-tracking data — timers, timesheets, time entries and the records behind them;
• activity data — how much keyboard and mouse activity occurred in a period, idle time, and which applications and websites were in use;
• screen and media capture — periodic screenshots and, where separately switched on, webcam stills, audio recordings and screen recordings.

We do not decide to collect any of this. The customer does. We build the features, we document what each one captures and what each control does, and we run them exactly as the customer configures them. We do not use that data for our own purposes, we do not use it to train models, and we do not look at it except where we must in order to run, secure or support the Service.

What GitHands can capture, what is off by default, and which controls exist is set out in the annex later in this notice.

3. Data a customer holds about its own clients and end users — the customer is the controller

Where a customer uses the Service to serve its own clients, members, applicants, patients or website visitors, that data sits in the same arrangement as case 2. The customer is the controller, we are the processor, and the customer owes those people the notice and the answers. If you have dealt with an organisation and want to know what it holds about you, ask that organisation.

If you are monitored at work, this part is for you

We would rather tell you directly than make you work it out from a contract you have never seen.

Your employer decides what is captured. We do not. Screenshots, activity rates, application and website usage, webcam stills, audio, screen recordings — each of these is a setting your employer switches on or leaves off, for the organisation and, where the product allows it, for individual people. We cannot switch them on for your employer, and we do not switch them on for ourselves.

Your employer is the controller of that data. That means your employer, not us:

• must have a lawful basis for monitoring you, under the GDPR and under its own national employment law, which differs sharply from country to country;
• must tell you, before it starts, what is captured, how often, why, and how long it is kept;
• must carry out a data protection impact assessment where one is required, and act on what it finds;
• must consult a works council, employee representatives or a trade union where its national law requires that; and
• must answer your requests about that data.

We make no claim that monitoring employees is lawful across the European Union, because it is not. Some countries restrict it tightly, some require consultation before it starts, and some prohibit particular forms of it outright. Whether your employer's use of these features is lawful where you work is your employer's responsibility. We require every customer to confirm to us that it has dealt with each of the points above before it uses these features.

How to exercise your rights over monitoring data. Send your request to your employer — it holds the data and it has to answer you. If you send it to us instead, we will not ignore it:

• we will forward it promptly to the customer whose workspace holds the data;
• we will tell you that we have done so, and to whom, so you are not left waiting on silence; and
• we will help that customer find, correct, export or delete the data, which is what our contract with it requires of us.

What we will not do is release one organisation's data to someone else on request. We cannot verify an employment relationship from the outside, and handing over a workspace's contents to a person the customer has not authorised would be a breach in its own right. That restraint protects you as much as it constrains you.

If you think your employer is monitoring you unlawfully, you can complain to the data protection authority in your own country, and to your national labour authority. You do not need our permission, and you do not need to come through us first.

Personal data we collect

We group this by where the data comes from, because that is what determines what we know about you and what we owe you.

Not every category applies to every product, plan or user. This section describes the shape of what we collect; the annex later in this notice lists what GitHands actually collects.

What you give us

• Account identity — your name, username, email address, password (held only as a hash), profile picture, job title, preferred language and time zone.
• Organisation details — the organisation you belong to, your team, your role and permissions within it, and who invited you.
• Contact details — email address, telephone number and postal address, where you provide them.
• Billing details — billing name and address, VAT or tax identification number, the plan you are on, invoices and payment history. We do not receive or hold your full card number — that goes straight to our payment processor.
• Support correspondence — the tickets, emails, chat messages, screenshots and files you send when you ask for help, and our replies.
• Content you submit — everything you or your organisation puts into the Service: documents, tasks, projects, records, messages and uploads. Where that content belongs to your organisation, we hold it as processor, not as controller.
• Anything else you volunteer — survey answers, feedback, event registrations, newsletter sign-ups, and whatever you choose to write to us.

What we collect automatically when you use the Service

• Device and browser data — device type, operating system, browser and version, screen size, language, and the version of our application you are running.
• Connection data — your IP address, and the approximate location it indicates. That is city-or-region level, derived from the IP address, and it is not satellite positioning. Where a specific feature collects precise location, it says so.
• Usage data — pages and screens viewed, features used, actions taken, navigation paths, timestamps and the page that referred you.
• Logs — server and application logs of requests, errors, response times, sign-ins, failed sign-ins and administrative actions, with the identifiers needed to tie an entry to an account.
• Diagnostics — crash reports, stack traces and performance traces. These can incidentally contain whatever was in the request that failed.
• Cookies and similar technologies — cookies, local storage, pixels, software development kit identifiers and comparable device storage. What each is for, and which ones need your consent, is in our Cookie Policy.

What we receive from other people

• Identity providers — if you sign in with a third-party account, we receive that account's identifier, your email address, your display name and usually your profile picture, plus confirmation that the sign-in succeeded. We never receive your password for it.
• Payment processors — whether a payment succeeded or failed, the payment method type, the last four digits and expiry of a card, the billing country, and any dispute or chargeback.
• Integrations you or your administrator connect — whatever the connected service returns within the permissions granted. That varies by integration and is shown to you when you authorise it.
• Your organisation — where an administrator creates your account, invites you, sets your role or imports records about you.
• Other sources, where a particular product uses them. Those are set out in the next section and in the annex.

What you have to give us

Some of it is unavoidable. Without account identity we cannot create an account for you; without billing details we cannot take payment for a paid plan; without certain records we cannot meet our own legal obligations. Where data is necessary in that sense, not providing it means we cannot provide that part of the Service — but nothing worse follows.

Everything else — an optional profile field, a newsletter subscription, an integration you could simply not connect — is genuinely optional, and declining it costs you nothing.

Data we do not collect

Shorter than the previous section, and just as binding. These are commitments about how the Service is built, not aspirations.

• We do not sell personal data. Not to data brokers, not to advertisers, not to anyone — and not under the broader definitions of "sell" or "share" used outside the European Union.
• We do not buy marketing lists. If we contact you about our products it is because you gave us your details, or because you are already a customer. We do not purchase your name from someone else in order to email you.
• We do not use your content to train machine-learning models — not for our own purposes, and not for the benefit of other customers. Where a product has an AI feature, it processes your content to produce your result, and that is the end of it. If we ever want that to change, it will be an opt-in you actively choose, described before you choose it.
• We do not run advertising inside the Service. No third-party advertising, no behavioural ad targeting, no cross-site advertising identifiers in the product.
• We do not record what you type. Where a product measures keyboard and mouse activity, it counts events over a period. There is no keylogger in our software. The content of your keystrokes is never captured, stored or transmitted.
• We do not ask for special-category data — health, racial or ethnic origin, religious or philosophical beliefs, political opinions, trade union membership, sex life or sexual orientation, genetic or biometric data. There are no fields for it, we do not infer it, and we do not want it. The one honest caveat is about what can end up inside a screenshot, and it has its own section below.
• We do not store full card numbers or card security codes. Those are entered on our payment processor's systems and never reach ours.
• We do not collect precise location by default. Where a product uses location at all, it is because a specific feature needs it, and that feature says so.

If you find any of this to be untrue of something we ship, tell us at [email protected]. We will treat it as a defect in the product, not as a disagreement about wording.

Where data comes from when it does not come from you

Not all of the personal data we hold came from you. Article 14 of the GDPR requires us to tell you where it came from, and this section does that.

• Your employer, or the administrator of your workspace. Where an organisation subscribes to the Service, an administrator creates accounts, invites people, sets roles and imports records. That supplies your name, work email address, job title, team, role and permissions, and whatever else the organisation chooses to hold about you in its workspace. For that data the organisation is the controller, as set out above.
• Identity providers. If you sign in with a third-party account, that provider supplies the account identifier, your email address, your display name and usually a profile picture, and confirms the sign-in succeeded. It supplies nothing else, and never a password.
• Integrations you or your administrator connect. A connected service supplies whatever the permissions you granted allow — for example issues and repositories from a code host, messages and channel names from a chat tool, calendar entries, contacts, or records from another business system. The scope is shown when the connection is authorised, and it can be revoked in the same place.
• Payment processors and resellers. They supply the outcome of a payment, the payment method type, the last four digits and expiry of a card, the billing country, and any dispute or chargeback. They do not pass us the card itself.
• Publicly available sources, where a product builds profiles from them. Some products work with information people have published themselves — a public code-hosting profile, a public company page, a public professional listing. Where a product does this, the annex names the categories taken and the sources they came from, explains the basis we rely on, and says how to object. If we hold a profile about you that you never gave us, you can object to it and we will act on that.
• Service providers acting for us. Fraud and abuse signals, delivery and bounce information from the systems that send our email, and security intelligence about addresses and networks.

Where we are the controller of personal data that did not come from you, we will tell you within a reasonable period and at the latest within one month of obtaining it — or, if we use it to contact you, at that first contact. Where informing every individual separately would take disproportionate effort, this notice and its annex are the public information we provide instead, which is what Article 14(5)(b) allows.

Why we use personal data, and on what legal basis

Article 6 of the GDPR requires a lawful basis for each purpose. So this is one row per purpose, rather than a general list of all six bases — you can check us against each line.

Purpose	Personal data used	Lawful basis
Providing GitHands Cloud: creating and running your account, signing you in, delivering the features you use, and keeping your data available to you	Account identity, organisation and role, credentials, content you submit, device and connection data	Contract — Art 6(1)(b). Necessary to perform our agreement with you
Taking payment: invoicing, collecting fees, applying refunds, chasing non-payment	Billing details, plan and subscription data, invoices, payment outcomes	Contract — Art 6(1)(b)
Keeping accounting, tax and invoicing records	Invoices, payment records, billing identity	Legal obligation — Art 6(1)(c), under tax and accounting law
Support: answering your questions, investigating faults and reproducing problems you report	Support correspondence, account identity, logs and diagnostics, and whatever you point us at	Contract — Art 6(1)(b) where you are a customer. Legitimate interests — Art 6(1)(f) where you are not, so that we can answer anyone who writes to us
Security and abuse prevention: authentication, rate limiting, bot and fraud detection, investigating misuse, protecting accounts and infrastructure	Account identity, IP address, device data, request logs, sign-in and failed sign-in records	Legitimate interests — Art 6(1)(f) in keeping the Service and the people who use it safe
Keeping the Service running: monitoring, error tracking, debugging, capacity planning and backups	Logs, diagnostics, usage data, account identifiers	Legitimate interests — Art 6(1)(f) in operating a reliable service
Understanding how the Service is used, so we can improve it	Usage events, feature interactions, device and browser data, aggregated statistics	Legitimate interests — Art 6(1)(f). Consent — Art 6(1)(a) wherever cookies or similar device storage are involved, as set out in our Cookie Policy
Marketing to people who are not yet customers: newsletters, product announcements and events	Contact details, marketing preferences, whether you opened or clicked a message	Consent — Art 6(1)(a), which you can withdraw at any time
Marketing our own similar products to an existing customer who gave us their address during a sale, with an opt-out in every message	Contact details, the products you already have	Legitimate interests — Art 6(1)(f), relying on the narrow existing-customer exception in the ePrivacy rules
Meeting legal obligations: responding to lawful requests from authorities, sanctions and export-control checks, statutory record-keeping, and our own data protection duties	Whatever the specific obligation requires, and no more	Legal obligation — Art 6(1)(c)
Establishing, exercising or defending legal claims, and handling complaints, disputes, audits, insurance and corporate transactions	Account and billing records, correspondence, and the logs relevant to the matter	Legitimate interests — Art 6(1)(f) in protecting our legal position

Two things this table deliberately does not cover.

Where we act as processor, the lawful basis is not ours to pick. The customer that put the data into the Service decides the purpose and must have its own basis for it. See the controller and processor section above.

Where we rely on your consent, you can withdraw it at any time, and withdrawing it is as easy as giving it. Withdrawing consent does not make earlier processing unlawful — it stops the processing from that point on.

The legitimate interests we rely on

Where the table above says "legitimate interests", the law requires us to tell you what that interest actually is — not simply to name the basis and move on. For each one we have asked three questions: what is the interest, is the processing genuinely necessary for it, and is it fair to you. That last question is the balancing test, and we keep a written record of it.

Keeping the Service and its users secure

• The interest: preventing unauthorised access, account takeover, fraud, spam, denial-of-service and abuse of the Service.
• Why the processing is necessary: you cannot see an attack without looking at the traffic. Sign-in records, IP addresses, device data and request logs are what make an intrusion visible at all.
• Why it does not override your rights: the data is limited to what security work needs, it is kept for a bounded period, and the benefit goes to the same accounts and the same people whose data is used. Nobody reasonably expects a service to be run without security logging.

Keeping the Service running

• The interest: operating a reliable service — monitoring, error tracking, debugging, capacity planning and backups.
• Why the processing is necessary: faults surface in logs, and a crash report is only useful if it records what was happening when the crash occurred.
• Why it does not override your rights: it is operational data, kept for short periods, used to fix software rather than to form views about people, and reachable only by the staff who need it.

Understanding how the Service is used

• The interest: knowing which features are used, where people get stuck, and what to build or fix next.
• Why the processing is necessary: the alternative is guessing. Aggregate usage data is the only practical way to see this without interrogating every user.
• Why it does not override your rights: we analyse it in aggregate rather than to make decisions about you individually, and wherever cookies or similar device storage are involved we ask for your consent instead of relying on this interest at all.

Answering people who write to us without an account

• The interest: replying to a question from someone who is not a customer.
• Why the processing is necessary: we cannot answer you without keeping your message and your address.
• Why it does not override your rights: you chose to contact us, we use it only to answer, and we keep it no longer than the matter and any follow-up require.

Telling existing customers about our own similar products

• The interest: letting people who already buy from us know about the products next to the one they bought.
• Why the processing is necessary: it uses the address they gave us during that sale, and there is no less intrusive way to reach them.
• Why it does not override your rights: it is confined to our own similar products, every message carries a one-click opt-out, and an opt-out is acted on immediately and permanently.

Running and protecting our business

• The interest: accounting, audit, insurance, professional advice, complaints, disputes, enforcing our terms, and evaluating or completing a corporate transaction.
• Why the processing is necessary: these are ordinary obligations of operating a company, and each one needs the records that relate to it.
• Why it does not override your rights: the data is confined to the matter in hand, access is narrow, and a great deal of it we are required to keep in any event.

Your right to object

You can object to any processing we base on legitimate interests, at any time, by writing to [email protected]. Tell us which processing, and where you can, why — your particular situation is part of the balance. We will stop unless we can show compelling legitimate grounds that override your interests, rights and freedoms, or unless we need the data to establish, exercise or defend legal claims.

If you object to direct marketing there is no balancing at all. We stop. That right is absolute.

You can also ask us for a summary of the balancing test behind any interest listed above, and we will give you one.

Special categories of data

Some personal data carries extra protection under Article 9 of the GDPR: data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs or trade union membership, and genetic data, biometric data used to identify someone, data concerning health, and data about a person's sex life or sexual orientation. Data about criminal convictions and offences is restricted separately, under Article 10.

We do not seek any of it. We do not ask for it at sign-up, in billing or in support. There are no fields for it, we do not infer it, and we do not enrich profiles with it. Please do not send it to us in a support ticket either — if you need to show us something sensitive to get help, redact it first.

The honest caveat: incidental capture

Where a customer switches on screen capture, webcam capture or audio capture, what gets captured is whatever is there. A screenshot taken while someone has a hospital appointment email open captures health data. A webcam still can show a religious head covering. An audio recording can pick up a background conversation that has nothing to do with work.

That is not a theoretical risk and we will not present it as one. It is a direct consequence of capturing a screen or a room on a timer, and it is true of every product that does it, ours included.

Whose responsibility it is

The customer that switches these features on is the controller of what they capture, including anything special-category that comes with it. So the customer, not us:

• decides whether to enable capture at all, and has to judge whether the benefit justifies the intrusion;
• must carry out a data protection impact assessment before starting, and act on what it finds — capture of this kind will normally require one;
• must have a lawful basis, and where special-category data is realistically in scope must also satisfy Article 9(2), which an employee's consent rarely does on its own, because of the imbalance between employer and employee;
• must configure the product to reduce that risk rather than accept it; and
• must deal with what has been captured, including deleting a capture that should never have been taken.

We are the processor for it. We do not decide to capture anything, we do not review captures for our own purposes, and we act on the customer's configuration and instructions.

The levers, and using them

Where a product offers screen or media capture, it also offers controls that materially reduce this risk. Depending on the product, those include:

• switching capture off entirely, for the whole organisation or for an individual person;
• switching off the more intrusive capture types — webcam stills, audio and screen recording — while keeping the rest;
• reducing how often captures are taken;
• blurring captured images;
• shortening how long captures are kept, and deleting them automatically at the end of that period;
• letting people see what has been captured about them; and
• deleting an individual capture.

If you are a customer, these are yours to set, and the defaults are not a recommendation. Choose the least intrusive configuration that meets the purpose you actually have, and write down why you chose it. That record is what a supervisory authority will ask for.

If you are being monitored and something sensitive has been captured, ask your employer to delete it. Your employer can do that in the product. If you tell us instead, we will forward your request and help your employer act on it, as described in the controller and processor section above.

Which of these controls GitHands provides, and what its defaults are, is set out in the annex later in this notice.

GitHands: the people in this Service who never signed up

This annex is unlike every other product annex we publish, and the reason is worth putting in the first line rather than the fifteenth. Most of the personal data in GitHands Cloud is about developers who have never used it. They did not create an account, they did not agree to anything, and nothing they did was addressed to us. We collected their data from public sources, we added inferences of our own to it, and some of them are then sent a message.

If you are reading this because you received an email you did not ask for, or because you found your own name on a GitHands page, this section is written for you and not for our customers. It is the notice Article 14 of the GDPR requires us to give you when we hold data about you that did not come from you, and everything you need in order to make us stop is in it. Nothing below is behind an account.

What the Service does

A customer names a public code repository, or writes a brief describing the kind of developer it wants to reach. The Service then:

• enumerates the people publicly associated with that repository — the accounts that starred it or forked it, its contributors, the people who commented on its issues, reviewed its pull requests or joined its discussions, and the followers of the organisation that owns it. For a curated "awesome list" it does the same for the repositories the list points at;
• finds a contact address for each person, by the routes set out below;
• builds a profile of that person from their public activity, and adds scores and inferences we generate ourselves;
• drafts a message with a language model, personalised to that person, and sends it — as one message or as a sequence spread over time; and
• records what happened to it — whether it was delivered, opened, clicked, replied to, bounced or unsubscribed from.

For all of that, Ever Technologies LTD is the controller. We are not acting on a customer's instructions when we decide to build this database, what to infer from it or how long to keep it — we decide that. So the rights in this policy run against us directly, and you do not have to find out which of our customers holds your record before anyone will answer you.

Where your data came from

Everything we hold about a person who is not a user came from one of these, and from nothing else:

• the public GitHub REST, GraphQL, Search and Events APIs, and the equivalent public GitLab endpoints;
• public repository pages — stargazer lists, fork lists, contributor lists, issue and pull-request participants, discussion participants, and organisation follower lists;
• public commit metadata — the author and committer name, email address and date recorded in a public commit;
• public profile fields — username, display name, avatar, biography, company, location, personal site, linked social handle, follower and repository counts, and the "available for hire" flag if you have set it; and
• public dependency manifests in your public repositories, read to work out which technologies you use.

Every record carries a provenance flag saying which of those it came from. If you ask us where we got your data, we can tell you which route it arrived by rather than gesturing at "public sources".

We plan to add professional networking platforms as a further source. We will not do so without updating this annex first, and the notice you receive at first contact will name the actual source your record came from, not a general list.

Your email address, and how we got it

This is the part of the processing most people find surprising, so it gets its own section rather than a bullet. We look for a contactable address in four places, in this order, and stop at the first that works:

1. the email address published on your profile, where you have chosen to publish one;
2. the author or committer address recorded in the commits of the repository being searched, where you have committed to it;
3. the author or committer address in commits across your own most recently updated public repositories; and
4. the address carried in the public push-event stream for your account.

We discard the anonymised noreply addresses that GitHub issues, because contacting one is pointless. We do not guess addresses, we do not generate permutations of a name against a company domain, and we do not buy address lists.

An address you put in a commit was published so that your work could be attributed to you, not so that somebody could sell to you. We know that, and we are not going to pretend otherwise. Routes 2, 3 and 4 above take an identifier published for one purpose and use it for another, and that is the single hardest part of this processing to justify. We treat it accordingly: those records carry the provenance flag that says so, we hold them to the same objection and deletion routes as everything else, and if you tell us to stop we do not ask you why.

What we work out about you

Alongside what we collected, we generate our own assessments. These are ours, not yours, and none of them is verified:

• an engagement score from 0 to 100 and a label for it — Champion, Hot, Warm or Cold;
• an intent tier, estimating how likely you are to be looking for a tool of the kind being marketed;
• an influence score, a network rank and a cluster, derived from a graph of relationships between accounts;
• a contributor class and a contribution-depth score;
• an activity trend, and any technology migrations we think we can see in your history;
• a technology fingerprint, parsed from the dependency manifests in your public repositories;
• a numeric embedding of your profile, which is what makes "find developers similar to this one" possible;
• an approximate time zone, a confidence figure for it, and your likely working hours, inferred from the timestamps on your public commits; and
• an employment life stage — job hunting, recently hired, exploring, building or settled — with a confidence figure.

Two of those deserve to be named rather than buried in a list. Inferring your working hours from commit timestamps is an inference about your daily routine and roughly where in the world you are. And inferring that you may be job hunting is an inference about your employment situation, drawn from public activity that you did not publish in order to say anything of the kind.

All of these are opinions produced by software from partial signals, and any of them can simply be wrong. Our terms forbid a customer from treating them as facts about you, and forbid using them to decide anything about your employment, credit, insurance, housing or access to a service. The Acceptable Use Policy puts that in binding terms.

Why we think we are allowed to do this

The lawful basis for building and using this database is our legitimate interests, Article 6(1)(f). The law requires us to weigh that interest against your rights, and to be able to show our working. Here it is in summary; ask [email protected] and we will send you the full assessment.

• The interest. Reaching the specific developers most likely to want a developer tool, instead of advertising it to everybody.
• Why the processing is necessary for it. The signal that a person cares about a particular technology is their public activity around it. There is no less intrusive route to the same result — untargeted advertising is not a lesser interference with you, it is a larger interference with everyone else, and it does not work.
• Where the balance is thinnest, stated honestly. Publishing code under your own name does not mean you expected to be marketed to, and a data protection authority has said as much about a comparable service. Our interest does not automatically win. What makes the balance defensible is the mitigations, not the purpose — which is why we treat them as commitments rather than as good intentions.
• The mitigations we rely on. Business-context data only. Nothing from a private repository or a private profile. A provenance flag on every record so we can always tell you where it came from. A permanent, one-click, no-questions objection. Suppression that covers every customer and never expires. Retention limits that expire rather than renew. No special-category data, sought or inferred. No sale of the database to anybody.
• Our conclusion. The interest is legitimate and the processing is proportionate so long as the mitigations above actually work. If one of them stops working, the balance fails — so treat any failure of one as something to report to us at [email protected], and we will treat it as a defect.

Where a customer imports its own contact list or connects its own CRM, the basis for that data is the customer's to establish, not ours. See the three flows at the end of this annex.

Article 14: how you are told, and where we rely on the exception

Article 14 requires us to tell you that we hold your data, where it came from and what we do with it. There are two situations and we handle them differently.

If we contact you, you are told individually, in that first message. Every first outbound message carries, in the message itself and not behind a link:

• who the controller is — Ever Technologies LTD, Mladost 2, bl. 211, ent. A, Sofia 1799, Bulgaria, company number 204599535 — and how to reach us;
• the specific source your record came from, in plain words: your public profile, the commits of a named repository, your own public repositories, or the public event stream;
• what we hold, what we have inferred, and what the message is for;
• that the basis is legitimate interests, and that you may object;
• who receives the data and how long we keep it;
• your rights, and your right to complain to a supervisory authority; and
• a one-click objection link that does not expire.

That is Article 14(3)(b) — notice at the latest at the first communication. Because we are contacting you anyway, it costs us nothing, so there is no argument for doing less.

If we hold your record and nobody ever contacts you, this annex is the notice. Here we rely on the exception in Article 14(5)(b) for disproportionate effort, and we want the reasoning on the record rather than asserted:

• notifying a person we hold data about and do not intend to contact would mean initiating contact for the sole purpose of telling them we exist — which is the intrusion the notice is meant to protect them from, delivered to people we were otherwise going to leave alone;
• so we do what Article 14(5)(b) requires instead: we make the information public, in this annex, at a stable address, in the same document as the removal route, with no account and no token needed to read it; and
• we do not claim this exception for anyone we actually email. Their notice is individual, in the message, as above. The exception covers only the records that sit still.

If you think that reasoning is wrong in your case, say so at [email protected]. You can also put it to a supervisory authority, and you do not need to come through us first.

How to make us stop, and how to be removed

Objecting to direct marketing is absolute under Article 21(2). There is no balancing test, no condition, no time limit and nothing for us to weigh. You do not have to give a reason, be a customer, hold an account, or explain how you found us.

You were added to this database without doing anything at all, so removing yourself takes one action and no account. Any of these works:

• the objection link in any message you received from us. It never expires. A link that stops working after a few days is not an opt-out, and ours does not;
• the removal page at https://githands.com/remove, which needs no token, no sign-in and no prior message from us. Give us the email address or the profile you want removed; or
• an email to [email protected], which a person reads.

What happens then:

• we act within 24 hours in the ordinary case, and within one month at the outside. Sending stops immediately;
• the suppression is platform-wide and permanent. It is not per-customer and it does not expire. No customer of ours can reach you afterwards through this Service, whatever project or account they use;
• your profile, your inferences, your scores and your engagement history are deleted, and you are removed from any public page described below;
• we keep one thing, and only one: a one-way hash of your address and the date. We cannot read your address back out of it, and its only function is to recognise you if the extraction pipeline encounters you again so that you are never re-added. Keeping it is what makes the objection stick, which is why the law lets us; and
• we tell the customers who already hold your record to delete or suppress it, and our contract with them requires them to do it within five business days.

One limit, stated plainly because you should not discover it later. If a customer had already exported your details into its own CRM or mailing tool before you objected, that copy is in a system we do not control, and that customer is the controller of it. We will tell you which customers we notified, so you can go to them directly. Ask at [email protected] and we will name them.

What we publish about you

The Service has public pages for a repository's community, showing named individuals — username, avatar and the engagement score we generated for them — without a sign-in and open to search engines.

That is a different purpose from outreach, and we treat it as needing its own justification rather than riding on the one above. Publishing an unverified judgement about a named professional is the part of this product we are least comfortable with, and the rights below exist because of that discomfort:

• you can have your entry taken down through any of the three routes in the previous section, and removal from the public page is immediate rather than queued;
• when we take an entry down we also ask the major search engines to drop the cached copy, and we tell you when we have done so; and
• objecting to the public page does not require you to object to anything else, and objecting to outreach removes you from the public page as well.

The tracking inside our messages

Messages sent through the Service carry:

• an open-tracking image, a single transparent pixel loaded from our servers, which tells us that the message was opened, when, and how many times; and
• click-tracking links, which pass through our servers before going where they say they go.

Loading either one discloses your IP address, your user agent and the time to us. That is how the technique works — there is no version of it that watches without seeing you.

This is access to information on your own device, so it is regulated separately from data protection, and consent is the rule in the European Economic Area and the United Kingdom. You did not give it. So:

• open tracking is off by default for a recipient whose profile location or inferred time zone places them in the EEA or the United Kingdom, and a customer cannot switch it on for them;
• your mail client's "do not load remote images" setting defeats the pixel entirely, and we would rather tell you that than not; and
• the Cookie Policy annex covers the rest of what our own pages load.

Who else sees your data

Our sub-processors are listed in full at https://githands.com/subprocessors, with what each one does and where it is. Three of them deserve to be named here rather than left to the table, because they are the ones a person in your position is least likely to guess.

• The language-model provider. Drafting a personalised message means sending your name, your username, your email address, your repositories and what we have inferred about you to a model provider, and it is forwarded on to the model that actually runs. Classifying your reply means sending the text of your reply.
• The AI observability service. Every one of those prompts, and the completion it produced, is stored as a readable trace so we can debug quality and cost. Your data sits there in plain text.
• The email delivery provider, which necessarily receives your address, the message and everything the tracking above records.

None of them is allowed to use your data for its own purposes, or to train models on it. Most of them are established outside the European Economic Area, and the transfers section of this policy sets out the mechanism we rely on for each.

How long we keep it

What we hold	How long we keep it
A profile of a person who has never been contacted	12 months from when we last verified it against the source. Not renewed by re-finding you: if nothing new happens, it expires
A profile of a person who has been contacted and did not respond	24 months from the last message
Inferences, scores, technology fingerprints and embeddings	Deleted as soon as the signals behind them are stale, and in any event with the profile
Message, delivery, open and click records	24 months from the send
The text of a reply you sent us, and its classification	24 months from receipt, or until you ask us to delete it, whichever is first
An entry on a public community page	For as long as the profile behind it exists, and removed immediately on objection
A suppression record after you object	Permanently, as a one-way hash of your address plus the date, and nothing else

We do not restart a retention period because your circumstances changed. Changing employer, starring something new or pushing a commit does not renew our clock. Only re-verification of a record we are entitled to hold does, and only within the limits above.

Decisions about you

Nothing in this Service makes a decision that produces a legal effect for you, or that similarly significantly affects you, by automated means alone. What it produces is a score, a label and a drafted message, all of which reach a human being at one of our customers before anything happens.

They are still profiling, which is why they are set out in full above rather than summarised. And they are fenced: our Acceptable Use Policy prohibits any customer from using this Service, or anything it outputs, to decide employment, credit, insurance, housing, benefits or eligibility for a service. We are not a recruitment database, we are not a background-check service, and a customer that uses us as one is in breach.

What we do not do

• We do not touch private repositories, private profiles or anything behind a permission. Only the official public APIs of the source platforms, and only what they serve to anybody.
• We do not scrape. No unofficial endpoints, no headless-browser harvesting of pages the API does not serve, no circumvention of rate limits or technical protections.
• We do not seek or infer special-category data. No health, beliefs, politics, union membership, ethnicity, sex life or sexual orientation. There are no fields for it and we do not want it.
• We do not sell the database. Not to advertisers, not to data brokers, not to recruiters. A customer can export the records its own project produced, under contractual duties to honour objections and delete on notice; we do not licence the database as a product.
• We do not use it for consumer marketing. This is business-context outreach to a person in their professional capacity, and customers are contractually restricted to that.

The source platforms' own rules

GitHub's Acceptable Use Policies restrict what information gathered from GitHub may be used for, including sending unsolicited mail to its users and passing personal information to recruiters. GitLab has its own equivalents. Those rules bind the account that does the reading.

So the reading is done under the customer's own account, which the customer connects in its own name and warrants that it is entitled to use for this purpose. Our Terms of Service annex sets out that obligation and the indemnity behind it. We also reserve the right to retire a source, or a method of finding an address, at any time — including because a platform asks us to — and we will do that without waiting to be compelled.

If you are a customer: three flows, three roles

Which of us answers for what depends on where the data came from. There are three cases and they do not overlap.

• Data the Service extracts, enriches and scores from public sources. We are the controller. We decide to collect it, we run the enrichment and the scoring, and we answer the objections. Your Data Processing Addendum does not cover it, and you cannot instruct us to re-add a person who has objected.
• Contacts you import by file, records you sync from your own CRM, and campaign content you write. You are the controller and we are your processor. The Data Processing Addendum annex sets out what you warrant about that data before you bring it in.
• Records you export, and messages you send. You become an independent controller the moment data leaves the Service into your systems, and you are the sender of record for every message. Your own Article 13 and Article 14 notices, your own lawful basis, and your own obligation to honour objections all attach to you at that point.

If you run GitHands yourself

The software is open source and can be run on your own infrastructure. In your installation we process nothing, we hold no data and we are not your processor — you choose the database, the sending provider, the model provider and the source credentials, and the obligations to the people in your database are yours alone.

One thing does reach us, and we would rather you heard it here than found it in a configuration file.

• An installation sends us an anonymous heartbeat roughly every 24 hours. It contains an installation identifier, the version, the billing mode, the operating system, architecture, runtime and database versions, counts of organisations, users, campaigns, sends and AI calls, counts of errors by a fixed error class, which features are switched on, and optionally an operator contact address if you have set one.
• It contains no recipient data, no message content, no repository or organisation names, no model prompts or completions, no credentials and no raw IP addresses.
• You can switch it off, and switching it off is a supported configuration rather than a hack.
• Check the administrator alert address before you go live. It defaults to an address at our domain, so until you change it, alerts about your campaign failures reach us. Set it to your own address.

Cookies and similar technologies

Cookies, local storage, pixels, software development kits and similar technologies get their own document, because they need more detail than a summary can carry. What each one is, what it does, how long it lasts, who operates it and how to refuse it is set out in our Cookie Policy.

In short, we sort them into four categories:

• Strictly necessary — needed to deliver what you asked for: signing you in, holding your session, routing traffic, remembering your cookie choice itself, and protecting forms and sign-in against automated abuse. These are not optional, and we do not ask for consent to them.
• Preferences — remember choices you have made, such as language, region and interface settings.
• Analytics — help us understand how the Service is used so we can improve it.
• Marketing — measure our campaigns and help us understand which organisations take an interest in us.

Nothing in the preferences, analytics or marketing categories is placed or read on your device until you agree to it. You can accept everything, refuse everything, or choose category by category, and refusing takes exactly as few clicks as accepting.

Changing your mind

Your choices are not permanent. A Cookie preferences link sits in the footer of every page on githands.com and reopens the same panel you saw the first time. Change a category there and it takes effect immediately, for the future. Withdrawing is as easy as agreeing, and nothing about the Service is withheld from you for refusing.

One analytics tool runs without consent, because it is configured so that it stores and reads nothing on your device and never builds a persistent identifier for you. That is a conditional position, not a permanent one: the Cookie Policy names the tool, describes the exact configuration we rely on, and says what happens if any part of that configuration ever changes.

Who receives your personal data

We disclose personal data only to the categories of recipient below, and only as much as each one needs to do the job it is there for.

• Service providers acting as our processors — hosting and infrastructure, storage, content delivery, email delivery, error monitoring, product analytics, customer support tooling and similar. They act on our documented instructions under a written contract that meets Article 28 GDPR, they are bound to confidentiality and appropriate security, and they may not use your data for their own purposes.
• Payment processors — to take payment, issue invoices and handle refunds and disputes. For their own regulated obligations — fraud prevention, anti-money-laundering, card-scheme rules — they act as controllers in their own right, and their own privacy notice governs that part.
• Professional advisers — lawyers, accountants, auditors and insurers, bound by professional confidentiality, where we need advice or have to evidence that we have complied with something.
• Public authorities, courts and regulators — where the law requires us to disclose, or where we need to establish, exercise or defend a legal claim. We check that a request has a proper legal basis and is no wider than it needs to be, we push back where it is not, and we tell you about it unless we are legally prohibited from doing so.
• An acquirer or successor — if we are reorganised, merged or sold, or if part of the business changes hands, personal data may pass to the acquirer as part of that transaction. The acquirer is bound by this policy or by a notice at least as protective, and we will tell you before anything about the handling of your data changes.

The sub-processors we engage for the hosted Service

These providers are engaged for the hosted Service as it is delivered to everyone. They are the ones your data is most likely to reach.

Sub-processor	Purpose	Location	Transfer mechanism	Personal data
Cloudflare, Inc.	Authoritative DNS, reverse proxy, TLS termination and the tunnel that is the only public route into our infrastructure. Every request to any GitHands hostname passes through it.	United States, with edge termination worldwide	Standard Contractual Clauses (EU 2021/914)	IP address, connection and TLS metadata, full request URLs and headers, cookies in transit
GitHub, Inc. (a Microsoft Corporation company)	Three distinct roles. It hosts our source code, our container images and our build pipeline. It is the identity provider when a customer signs in with GitHub. And its public API is the primary source from which the developer database is built — profiles, stargazer and forker lists, contributor and participant lists, public commit metadata and public event streams.	United States	Standard Contractual Clauses (EU 2021/914)	the queries we make against its public API, the OAuth grant and access token a customer gives us, our own account and organisation identity
Resend, Inc.	Delivery of outbound email — account and invitation mail, and the campaign messages a customer sends through the Service's default sending path — together with the delivery, open, click, bounce, complaint and reply events that come back.	United States	Standard Contractual Clauses (EU 2021/914)	recipient email address and name, personalised subject line and message body, delivery, open, click, bounce and unsubscribe events, recipient IP address and user agent captured by open and click tracking, the content of a reply
OpenRouter, Inc.	Routing of every AI request the Service makes to the model provider selected for it. This is the only AI provider configured in the hosted Service. OpenRouter forwards the prompt on to the upstream model provider it routes to, and that provider receives the same content.	United States, and onward to the selected model provider	To be confirmed — we do not yet evidence a mechanism	developer names, usernames, email addresses, biographies and repository lists embedded in prompts, drafted outreach messages and the inbound replies being classified, customer chat messages with the in-product assistant
Langfuse GmbH	Observability for AI requests — the full prompt and the full completion for each call are recorded as a trace so we can debug quality and cost. That means the same personal data that goes to the model provider is also stored here, in readable form.	Germany	None needed — established in the EEA	complete prompts and completions, developer names, email addresses and repository data contained in them, session and user identifiers attached to a trace
Functional Software, Inc. d/b/a Sentry	Application error monitoring and performance tracing. Browser reports are sent to a path on our own domain and forwarded on, so that an extension blocking third-party requests does not silently hide our errors from us. Server-side logging is enabled, so console output can travel with a report.	United States	Standard Contractual Clauses (EU 2021/914)	IP address and user agent, user identifier and email address attached as error context, URL and route, stack traces and breadcrumbs, console output, which can carry fragments of whatever request failed
PostHog, Inc.	Product analytics — which pages and features are used, where people abandon a flow, and what fails. Captured both in the browser and on our servers. Consent-gated in the browser.	United States	Standard Contractual Clauses (EU 2021/914)	IP address and the approximate location derived from it, device and browser characteristics, pageviews and in-product events, distinct identifier and referrer
Jitsu Labs, Inc.	A second product-analytics event pipeline. Events are collected through an endpoint on the githands.com domain rather than a vendor hostname, which is worth saying plainly: an endpoint on our own domain that forwards to somebody else should never be a surprise. Consent-gated.	United States	Standard Contractual Clauses (EU 2021/914)	IP address and user agent, in-product events and their properties, user identifier
Trigger.dev Ltd.	The managed runtime that executes background work — extraction runs, enrichment, scoring, sequence steps and scheduled jobs. Job payloads and run logs are held there, and the runtime holds the credentials it needs to reach our database.	United Kingdom	None — we run this ourselves in the EU	job payloads, which contain developer profiles and campaign content, run logs and error output, database connection credentials, and therefore indirect reach into application data
ui-avatars.com	Generated placeholder avatars, used where a person has no avatar of their own. The person's name or GitHub username is placed in the image URL, so it is disclosed to this provider every time the image is rendered in a customer's browser.	Not published by the provider	To be confirmed — we do not yet evidence a mechanism	the developer's name or GitHub username, in the request URL, the viewing user's IP address and user agent
Cloudflare, Inc. (R2 object storage)	Holds the encrypted off-site copy of our backups - Postgres WAL and dumps, Velero, etcd, Proxmox configuration and MinIO mirrors - as the third tier of the backup chain (node8 NVMe, then Ceph RGW, then Cloudflare R2). Encrypted by us before it leaves our network.	United States	Standard Contractual Clauses (EU 2021/914)	client-side encrypted backup archives only - no plaintext is ever readable by the provider, the archives themselves derive from every category of data the products hold
Google Ireland Limited (Google Workspace)	Hosts the corporate mailboxes that receive every support, privacy and rights request our own documents tell data subjects to write to, plus the recruitment mailbox that holds candidate CVs.	Ireland (contracting) / United States and global (Google LLC)	Standard Contractual Clauses (EU 2021/914)	all inbound and outbound company email, support, DSAR and privacy correspondence with data subjects, candidate CVs and application correspondence (ever-tech careers), customer and supplier correspondence and attachments
Cloudflare, Inc. (Turnstile)	Checks that the person completing registration, onboarding or an anonymous flow is not a bot; on ever-works the API refuses the anonymous flow when no CAPTCHA provider is configured, which is why it is unconditional there.	United States	Standard Contractual Clauses (EU 2021/914)	IP address, user agent and device signals, mouse, touch and timing interaction signals, Turnstile challenge cookie
Clerk, Inc.	Holds the account identity for the hosted cloc platform - name, email address, avatar, password or federated identity, sessions and multi-factor settings - so that our own database does not, and brokers the short-lived source-control credential used when the Service acts in a user's name.	United States	Standard Contractual Clauses (EU 2021/914)	name, email address and avatar, password hash or federated identity, session, device and sign-in records, organisation membership and role, social-connection claims where a user signs in that way, the short-lived source-control credential brokered for a single request and not stored
Tavily	The default provider for public web search and page extraction, used by agents researching a topic and by the automated research that runs when an account is created, where the queries are built from the new account holder's name and email domain.	United States	To be confirmed — we do not yet evidence a mechanism	search queries, including a person's name and their employer's email domain, the addresses of pages retrieved and the extracted page content, our API key and request metadata
Prospect One sp. z o.o. (jsDelivr)	Serves the Lottie animation runtime hard-coded into the ever-works login and register pages, so every person who opens the login page hands their IP to it before authenticating.	Poland (operator); delivery worldwide	Standard Contractual Clauses (EU 2021/914)	IP address, user agent, referring page URL
UNKNOWN - community-run npm CDN; no obtainable DPA counterparty identified	Second permitted origin for the Lottie animation runtime on the ever-works login and register pages.	United States (unverified)	To be confirmed — we do not yet evidence a mechanism	IP address, user agent, referring page URL
Google Ireland Limited (reCAPTCHA)	Scores whether the person submitting a signup, login or contact form is human, loading on the form page before any consent choice is made.	Ireland (contracting entity); processing in Ireland (contracting) / United States (onward processing by Google LLC)	Standard Contractual Clauses (EU 2021/914)	IP address, user agent and device characteristics, mouse, touch and timing signals from the form page, cookies set on google.com
Chargebee, Inc. - VERIFY; Chargebee Europe BV (Netherlands) is the EEA entity if it is the one contracting.	Handles subscription billing and invoicing for the hosted Gauzy service.	United States / Netherlands	To be confirmed — we do not yet evidence a mechanism	billing identity and address, plan, invoice and payment history
Shopify International Limited	Runs the storefront and order pipeline for the shop product, holding customer, order and payment-status records.	Ireland (contracting) / Canada and United States (Shopify group)	Standard Contractual Clauses (EU 2021/914)	customer name, email address and shipping address, order and payment status, browsing and cart events on the storefront, cookies set by the storefront

The full and current list, including everything below, is published at https://githands.com/subprocessors, together with the notice period and objection procedure that apply when we add or replace one.

Three tiers, and why the difference matters

A single flat list of every vendor that appears anywhere in our software would be both inaccurate and misleading, so the sub-processor page is split into three tiers. They mean genuinely different things.

• Always engaged. The providers above. If you use the hosted Service, these are in the path.
• Engaged only if you turn something on. Optional integrations, connectors and features. A provider in this tier is engaged only when you or your workspace administrator enables the specific feature or connects the specific account it belongs to. Enable nothing and it is never involved. The list says which feature or setting activates each one.
• Self-hosted deployments only. Several of our products are published as open source and can be run on your own infrastructure. In that case you choose the database, object storage, email relay, AI provider and everything else, using your own credentials. Those providers appear in the list so you can see what the software can be pointed at — but they are your providers, not ours. We process nothing in a deployment you run, we are not your processor for it, and the commitments in this policy do not describe it.

We do not sell your personal data

We do not sell personal data, and we do not share it for cross-context behavioural advertising. We do not supply it to data brokers, we do not trade it for services, and we do not permit any provider we engage to use it to build advertising or interest profiles, on our sites or anywhere else.

Sending personal data outside the EEA

Most of the personal data we hold stays inside the European Economic Area, on infrastructure we operate ourselves. Some of it does not: a number of the providers we engage are established outside the EEA — principally in the United States — and some of them route, cache or store data on servers outside it.

Where that happens, the transfer needs a lawful mechanism under Chapter V GDPR. We use one of the following for every transfer, and the sub-processor page names the destination country and the mechanism provider by provider.

Adequacy

Where the European Commission has decided that a country provides an adequate level of protection, the transfer relies on that decision and needs nothing further. Adequacy decisions are kept under review by the Commission and can be amended, suspended or repealed, so we monitor them rather than treat them as permanent.

Providers in the United States

For a US provider we rely on one of two things.

• The EU–US Data Privacy Framework, but only where that provider is actively self-certified under it for the type of data concerned. We check the official Data Privacy Framework list when we engage a provider and re-check it periodically. We do not claim the Framework for a provider that has not certified, or whose certification has lapsed.
• Standard Contractual Clauses — the clauses approved by the European Commission in Implementing Decision (EU) 2021/914, with the modules that match the relationship, together with a transfer impact assessment and supplementary measures: encryption in transit and at rest, minimising what is sent in the first place, contractual limits on onward disclosure, and a commitment from the provider to notify and where possible challenge a government access request.

We keep Standard Contractual Clauses in place as the standing mechanism, including for providers that are also certified under the Framework. That is deliberate, and here is the honest reason.

The Commission's adequacy decision for the Framework, adopted on 10 July 2023, is currently valid. It was challenged, and on 3 September 2025 the General Court of the European Union dismissed that challenge in Latombe (Case T-553/23). That is not the end of it — an appeal is pending before the Court of Justice as Case C-703/25 P, and the two arrangements that preceded this one were each struck down by the same court. So we treat the Framework as a mechanism under review rather than a settled answer, and we keep a second mechanism standing behind it so that a change in the law is a paperwork event for us and not an interruption for you.

Other countries

For a transfer to any other country without an adequacy decision, we use Standard Contractual Clauses with the same assessment and supplementary measures. Where a transfer is to the United Kingdom or Switzerland, the corresponding UK and Swiss additions are applied to those clauses.

We rely on an Article 49 derogation — for example, a transfer that is strictly necessary to perform a contract you have asked us to perform — only in a specific, occasional case where no other mechanism fits. It is not a routine mechanism for us, and we do not use it to run a regular data flow.

Getting a copy of the safeguards

You are entitled to see the safeguards we rely on. Write to [email protected] naming the provider or the transfer you are asking about, and we will send you a copy of the relevant clauses and tell you which modules apply. We may redact commercial terms such as pricing and service levels; we do not redact the data protection terms, which are the part that concerns you.

How long we keep personal data

"As long as necessary" is not an answer, so here are the actual periods. Each one runs from the event in the middle column, and at the end of it we delete the data or irreversibly anonymise it.

What we hold	How long we keep it	Why that period
Account and profile data — name, email address, workspace membership, settings	For as long as the account is open, then deleted within 30 days of closure	We need it to give you the account; after that we do not
Content and files you put into the Service	For as long as the account is open; after it ends, available for export for 30 days, then deleted	You decide what is in it — see below
Invoices, payment records and the tax data attached to them	10 years from the end of the accounting year in which the transaction fell	Accounting and tax law in Bulgaria requires it, and we cannot shorten it at your request
Record that you accepted our terms — version, date, method	5 years after the agreement ends	The general limitation period for a claim under the contract
Support correspondence and tickets	24 months from the last message in the thread	Long enough to handle a recurring problem and a follow-up; not longer
Security, access and audit logs	12 months	Investigating unauthorised access, and evidencing that we did
Application and error logs, crash reports, diagnostics	90 days	Fixing what broke; they lose value quickly
Marketing contact records and the evidence of your consent	Until you object or withdraw. We then remove you from the lists and keep only a suppression record — your email address and the date — so that we do not contact you again	An unsubscribe that forgets you is not an unsubscribe
Cookie and consent choices	As stated in the Cookie Policy, which gives the lifetime of each entry	It belongs with the technology it describes
Backups	Each backup ages out on its own rolling cycle, within 30 days	Recovering from failure and ransomware, without becoming a second archive
Anything we are required to preserve for a legal claim, investigation or regulatory request	Until the claim, investigation or request ends, including any appeal period	We are not allowed to delete evidence, and neither are you

Data that belongs to one of our customers

For personal data held inside a customer's workspace — including anything the Service captures about that customer's own personnel — the customer sets the retention period, not us. We are their processor for it. The defaults and the limits of what they can configure are described in the product annex to this policy.

We delete that data when the customer instructs us to, or at the end of the export window after their agreement ends, whichever comes first. If you are one of their people and you want their data about you deleted sooner, ask them — see the section on your rights, which explains how we route that.

What "delete" means here

Deletion is applied to live systems straight away. Backup copies are not individually edited — doing so would defeat what a backup is for — so a deleted record persists in backups until that backup ages out on the cycle above, at most 30 days. During that window the data is not used for anything, and we do not restore a backup to bring back data someone asked us to delete; a backup is restored only to recover a whole system after a failure.

Where we can keep something useful without keeping you identifiable, we anonymise instead of deleting — aggregate usage counts, for example. Once anonymised the data is no longer personal data, and it is not possible for us to re-identify you from it.

How we protect personal data

We take the measures Article 32 GDPR requires: technical and organisational safeguards appropriate to the risk, reviewed as the risk changes. In practice that means the following.

• Encryption in transit. Traffic to and from the Service travels over TLS. HTTPS is enforced, and plain HTTP requests are redirected rather than served.
• Encryption at rest. The storage holding customer content, databases and backups is encrypted at rest, and particularly sensitive values — credentials, tokens and keys — are additionally encrypted at the application layer rather than stored in readable form.
• Access control and least privilege. Access to production systems is limited to the people whose job needs it, granted by named individual accounts rather than shared logins, protected by multi-factor authentication, scoped to the narrowest role that works, and reviewed and revoked when a role changes or someone leaves.
• Network segmentation. Databases, storage and internal services sit on segmented internal networks and are not exposed to the public internet. Administrative interfaces are not publicly reachable.
• Logging. Administrative and security-relevant events are logged, retained for the period in the retention section, and monitored so that unusual activity raises an alert rather than sitting unread.
• Backups. Data is backed up regularly, held on separate infrastructure from the live systems, and restores are tested — an untested backup is a guess, not a control.
• Vulnerability management. Dependencies are scanned, code is analysed automatically before it ships, security patches are applied on a defined schedule with a faster path for serious issues, and we operate a responsible disclosure route so that anyone who finds a problem can tell us.
• Personnel. Everyone with access is bound by written confidentiality obligations that outlast their engagement, works on a need-to-know basis, and has access removed when it is no longer needed.
• Providers. We assess a provider before we engage it, contract with it under Article 28 GDPR, and hold it to security obligations at least as strict as our own.

Our Security page sets out the detail, including which measure applies to which part of the Service, our incident response process, and the shared responsibility split between what we secure and what you secure.

What we do not claim

We do not hold a SOC 2 report and we are not certified to ISO/IEC 27001, and we do not claim either. If anything you read or are told suggests otherwise, it is wrong, and we would like to know where it came from. Where we describe a practice on this page or on the Security page, we describe something we actually do; where we adopt a framework as a reference without being audited against it, we say so plainly rather than implying a certification.

No system is perfectly secure

No service, ours included, can be made completely secure, and anyone who tells you otherwise is selling something. What we can honestly promise is that we take the measures above seriously, that we keep them under review, and that if a personal data breach affects you we will act on it: we notify the CPDP where the law requires it, within the deadline it sets, and we tell affected people directly without undue delay where the breach is likely to result in a high risk to them.

Your part matters too. Use a strong and unique password, turn on multi-factor authentication where it is offered, keep your devices patched, and do not share credentials or access tokens. If you think an account has been compromised, tell us at [email protected] immediately.

Your rights over your personal data

Where we are the controller, the GDPR gives you the rights below. They are yours to use, you do not have to explain why you are using them, and using one costs you nothing.

• Access — ask whether we hold personal data about you and, if we do, get a copy of it together with the information in this policy about how it is used. (Article 15)
• Rectification — have inaccurate data corrected and incomplete data completed. Much of this you can do yourself in your account settings, which is faster than asking us. (Article 16)
• Erasure — have data deleted where we no longer need it for the purpose we collected it for, where you withdraw the consent it rested on, or where we have processed it unlawfully. (Article 17)
• Restriction — have us pause processing while a dispute is sorted out: while we check an accuracy challenge, for example, or while we consider an objection. We keep the data but stop using it. (Article 18)
• Portability — receive the data you gave us, in a structured, commonly used, machine-readable format, and have it sent to another provider where that is technically feasible. This applies to data processed by automated means on the basis of your consent or a contract with you. (Article 20)
• Objection — object to processing we base on our legitimate interests. We then stop unless we can demonstrate compelling legitimate grounds that override your interests, rights and freedoms, or unless we need the data for a legal claim. (Article 21(1))
• Objection to direct marketing — absolute, and there is nothing to weigh. If you tell us to stop using your data for direct marketing, including any profiling connected to it, we stop. No balancing test, no grace period, no exceptions. (Article 21(2))

You also have the right to withdraw consent where consent is what we rely on, which has its own section below, and the right to complain to a supervisory authority, which has the section after that.

Some of these rights have limits written into the law itself. Erasure does not override an obligation to keep invoices for the statutory accounting period, and portability does not extend to data we inferred or generated rather than received from you. Where we cannot do all of what you ask, we will tell you which part we cannot do and why, rather than declining as a whole.

How to make a request

Write to [email protected]. Tell us which right you are using and enough about yourself for us to find the right records — the email address on the account is usually enough. You can also write to us by post at the address at the end of this policy.

• It is free. We charge nothing for a request. If a request is manifestly unfounded or excessive, particularly because it repeats one we have already answered, the law lets us charge a reasonable fee based on our administrative cost or refuse it. If we ever do either, we will explain why and tell you how to challenge that decision.
• We answer within one month of receiving the request. Where a request is complex, or where you have made several, we may extend that by up to two further months — and if we do, we will tell you within the first month, and tell you why.
• We check who you are before we hand over personal data, because the alternative is handing your data to someone who claims to be you. We ask for the least that makes us confident, usually a reply from the email address already on the account. We ask for an identity document only where nothing lighter works, and anything you send us for verification is used for that and nothing else, then deleted.

If your data sits in a customer's workspace

This is the most important paragraph on this page for many of the people who read it.

A large part of the personal data in the Service was put there by one of our customers — your employer, the organisation whose workspace you belong to, or the operator of a site built on our platform. Where the Service captures data about how an organisation's own personnel work, that data belongs to that organisation's workspace.

For that data the customer is the controller and we are only their processor. We process it on their documented instructions and for no purpose of our own, so the law directs your request to them, not to us. Practically:

• Send your request to that organisation. They decide it, and they are the ones who have to answer you within the deadline.
• If you send it to us instead, we will not ignore it. We will forward it to the relevant customer promptly, tell you that we have done so, and assist them in answering it as our Data Processing Addendum requires.
• We will not decide the request ourselves, and we will not delete, correct or hand over data from a customer's workspace without their instruction — unless a law that applies to us requires it. That is not us being unhelpful: acting on a workspace's data without the controller's instruction is precisely what a processor is not allowed to do.

If you are not sure which of the two situations you are in, ask us at [email protected] and we will tell you, and point you to the right organisation if it is not us.

Withdrawing your consent

Where we rely on your consent for something, you can withdraw it at any time, and withdrawing is as easy as giving it. You do not have to give a reason, and we do not ask you to justify it.

Withdrawing consent stops the processing from that point onwards. It does not make what we did before unlawful — processing carried out while your consent was in force stays lawful, and withdrawal does not undo it. What it does mean is that we stop, and that we do not start again unless you tell us to.

How to withdraw, purpose by purpose

• Cookies and similar technologies — open the Cookie preferences link in the footer of any page on githands.com, turn off the categories you no longer want, and save. The change takes effect immediately. Details are in our Cookie Policy.
• Marketing emails — use the unsubscribe link at the bottom of any message we send you, or write to [email protected] and ask us to stop. Either route works, and the unsubscribe link does not require you to sign in or find your password first.
• Optional features and integrations you switched on — turn the feature off, or disconnect the connected account, in your settings. If you cannot find the switch, ask us at [email protected] and we will turn it off for you.

If you have consented to something not listed here, write to [email protected] naming it, and we will act on it the same way.

What happens next

We stop the processing, and we remove you from the relevant list or turn the relevant feature off. We keep the minimum record needed to show that you consented and that you withdrew, because being able to evidence consent is itself a legal requirement — for how long, see the retention section.

We will not quietly move the same processing onto a different legal basis to keep it running. If some part of what you asked us to stop genuinely rests on another basis as well — an invoice we are required to keep, for example — we will tell you which part and why, rather than leaving you to discover it.

Most of what we do is not based on consent at all. It rests on performing our contract with you, on legal obligations, or on legitimate interests. Withdrawing consent therefore does not close your account or switch off the Service — it affects only the things you consented to.

Complaining to a supervisory authority

If you think we have handled your personal data badly or unlawfully, you have the right to complain to a data protection supervisory authority. That right is yours regardless of anything else in this policy.

We would like the chance to put it right first. Write to [email protected], tell us what went wrong, and we will look into it and come back to you. In most cases that is the quickest way to get the outcome you actually want. You are not required to do this, and it is not a condition of complaining — you can go straight to an authority, and you can do it at any point, including while we are still dealing with your complaint.

Our lead supervisory authority

We are established in Bulgaria, so our lead authority is the Commission for Personal Data Protection (Комисия за защита на личните данни) — the CPDP. Its website, including its complaint form and current contact details, is at https://www.cpdp.bg/.

You can also complain closer to home

Under Article 77 GDPR you may lodge your complaint with the supervisory authority in the EU or EEA country:

• where you live;
• where you work; or
• where the thing you are complaining about took place.

You do not have to use ours, and you do not need our agreement to use another one. If you complain to your local authority, it will co-operate with ours through the mechanism the GDPR sets up for exactly this situation, so nothing is lost by choosing whichever is easiest for you.

You also have the right to an effective judicial remedy — against a supervisory authority's decision, and against us directly — in the courts of the country where you live or where we are established. Complaining to an authority does not use up that right.

Automated decision-making and profiling

We do not make decisions about you that produce legal effects concerning you, or that similarly significantly affect you, based solely on automated processing. No algorithm of ours decides whether you are hired, paid, promoted, disciplined, dismissed, given credit, or charged a different price. Where a decision of that kind is made about you by an organisation using the Service, a person at that organisation makes it.

We do use automated rules to detect fraud, spam, abuse and attacks against the Service — rate limits, anomaly detection, and similar. Those rules can block a request or temporarily restrict an account. If one of them affects you, write to [email protected] and a person will review it.

Where a customer turns on AI features, be aware of this

This is the part worth reading carefully, because it is easy to misunderstand.

Some of our products capture activity data on behalf of a customer — an employer, typically — and some of them offer optional AI features on top of it. Where a customer enables those features, the Service can generate automated assessments of the activity it captures. The clearest example: classifying whether the content of a captured screen appears to be work-related. Other examples include scoring or summarising captured activity and grouping it into categories.

Four things follow, and we would rather state them plainly than let them be discovered later.

• The output goes to the customer, not to us. It is presented to the organisation whose workspace the data belongs to. That organisation is the controller of it, and we are only its processor.
• The customer decides what, if anything, to do with it. We do not act on these assessments, we do not use them for any purpose of our own, and we do not share them with anyone else.
• These outputs are not decisions, and must not be used as if they were. An automated assessment is an input to a human judgement. Our terms require the customer not to treat an output of the Service as an automated decision about a person, and to apply meaningful human review before acting on one. Whether any particular use is lawful where that customer operates — including the lawful basis for it, the notices it has to give, any impact assessment it has to carry out, and any consultation with employee representatives it has to run — is that customer's responsibility to determine, not ours.
• They can be wrong. A classifier reading a screen has no idea what your job is. It can label genuine work as unrelated, and it can miss the opposite. Anyone relying on one of these outputs should treat it as a rough signal, and we say so to our customers as well as to you.

If an assessment about you has been generated

Ask the organisation whose workspace holds the data — normally your employer. You can ask them for human involvement, for an explanation of how the assessment was reached, to express your point of view, and to contest the result. They are the controller, so they are the ones who have to answer.

If you send that request to us, we will forward it to them promptly, tell you we have done so, and assist them in answering it. See the routing paragraph in the section on your rights, which explains why we cannot decide it ourselves.

Children

The Service is not directed at children, and we do not knowingly collect personal data from them. It is a business product, bought by organisations and used by the people who work in them. We do not design it for children, we do not market it to them, and we do not offer accounts to them.

Where consent is the basis for an online service offered directly to a child, the GDPR sets the age at which the child can consent alone. In Bulgaria that age is 14. Other EU and EEA countries set it anywhere between 13 and 16, and the age in the country where the child lives is the one that applies. Below that age, consent has to come from — or be authorised by — a holder of parental responsibility. Because we do not offer the Service to children, we do not operate a parental consent mechanism, and a child under the applicable age should not create an account or submit personal data to us.

If a child's data has reached us

Tell us. Write to [email protected] with enough detail for us to find the record — an email address, an account name, or the page where the data was submitted. You do not need to prove anything first, and you do not need to be the child's parent to report it.

We will check, and where we confirm that we hold personal data collected from a child without proper authorisation, we will delete it without undue delay, keeping only what a law that applies to us requires us to keep.

If the data sits inside one of our customers' workspaces rather than in our own records, the customer is the controller of it. Tell them as well, and tell us — we will forward your report to them and press for it to be dealt with, as the routing paragraph in the section on your rights describes.

Links and content from other sites

Our websites and the Service link to services we do not run, and some pages embed content that other people host — videos, maps, code repositories, documentation and similar.

Following a link takes you somewhere this policy does not reach. Loading embedded content means the provider hosting it receives data directly from your browser, typically your IP address, your device and browser details, and the page you were on, and it may set its own cookies.

We do not control those services, and this policy does not apply to them. What they collect and what they do with it is governed by their own privacy notice, which is the one to read before you use them. Where embedded content is not strictly necessary to deliver a page, we load it only once you have agreed to the relevant cookie category — see our Cookie Policy.

A link is not an endorsement. If a link from our site takes you somewhere that mishandles your data, we would like to know at [email protected] so we can reconsider carrying it.

Changes to this policy

This policy changes when the Service changes, when we engage or replace a provider, or when the law moves. We would rather update it than let it drift out of date and quietly stop being true.

Every version carries a version number and the date it takes effect, shown at the top of the page. This is version 1.0.2, in force from 2026-08-02.

How we tell you

• Minor changes — clarifying wording, correcting a mistake, adding a provider of a kind already described — are published with a new version number and a new effective date. We do not send a separate notice for these.
• Material changes — a new purpose, a new category of personal data, a new category of recipient, a longer retention period, a change to how you exercise your rights, or a change to the legal basis we rely on — are notified at least 30 days before they take effect, by email to account holders and by a notice on the site. That gives you time to read them and to act before they apply.
• Changes that need your consent are not made by publishing a new version. We ask you, and we treat silence as a no.

This policy is a notice, not a contract. We do not ask you to accept it, and continuing to use the Service is not us collecting your agreement to it. Where we genuinely need your agreement to something, we ask for it separately and record it.

Previous versions stay available

We do not overwrite the past. Every version of this policy that we have published remains available, with the dates it was in force, from the version history linked at the foot of https://githands.com/privacy. If you want to know what we said about your data on a particular date, that is where to look — and if you cannot find it, ask us at [email protected] and we will send it to you.

How to contact us

The controller for the personal data described in this policy is Ever Technologies LTD, registered in Bulgaria under company number 204599535, with its registered office at Mladost 2, bl. 211, ent. A, Sofia 1799, Bulgaria.

• Privacy questions, and any request about your personal data — [email protected]
• Data protection correspondence — [email protected]

Both addresses are monitored by the same people, and either will reach us. By post, write to the registered office above and mark the letter for the attention of the privacy team. We correspond in English.

We have not designated a Data Protection Officer under Article 37 GDPR. The [email protected] address is a contact channel, not a designation, and we will not describe it as one. If that position changes, this policy will say so and will give the designated office's contact details.

If your question is about personal data held inside one of our customers' workspaces, that customer is the controller and the request goes to them — see the routing paragraph in the section on your rights. Write to us anyway if you are unsure, and we will tell you who to ask.

This document is version 1.0.2 of the Privacy Policy for githands.com, in force from 2026-08-02. Earlier versions, with the dates they applied, are at https://githands.com/privacy.