Privacy Policy

Ever Demand — everdemand.co

Version 1.0.2 · In force from 2026-08-02

This notice explains what we do with personal data when you use Ever Demand and the websites, applications and application programming interfaces we make available at everdemand.co (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 everdemand.co and the pages served from it.
• The Ever Demand 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 Ever Demand — 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 Ever Demand, 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 Ever Demand 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 Ever Demand 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 Ever Demand 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 Ever Demand: 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 Ever Demand provides, and what its defaults are, is set out in the annex later in this notice.

Annex: Ever Demand

This annex describes what the Ever Demand software actually holds and what we actually do with it. It is written from the code, not from the product page, and where the software falls short of what a privacy notice would like to promise, it says so.

Which of three situations you are in

Everything else in this annex depends on this, and getting it wrong in either direction would be the single worst mistake in the document. There is no hosted Ever Demand platform today. What we operate under this name is a website, a documentation site and the content management system behind them.

1. Somebody runs the software themselves — the ordinary case. The business that deployed it is the controller. It chose the hosting, the database, the payment account, the mapping key and every other component. No personal data from that deployment reaches us. We are not its processor, we have no access to it, and nothing in this notice describes it. If you are a shopper, a courier or a merchant on a deployment somebody else runs, the business behind it is the organisation that owes you answers, and it is the one to ask.

2. We host an instance for you. Under the free-hosting offer in our Terms of Service, or under an Enterprise engagement. Then you are the controller of the shopper, courier, merchant and order data, and we are your processor for it. We are separately the controller of the narrow set of records described in the controller-and-processor section above — your administrator contacts, our correspondence with you, and our own security and audit logs.

3. You are visiting everdemand.co or the documentation site. We are the controller. Contact form submissions, the pricing-notification form, newsletter sign-ups, the support chat, bot protection on those forms, and — after you consent — analytics. What is set on your device is in our Cookie Policy.

The people the platform holds data about

Named individually rather than swept into "users", because their positions are genuinely different:

• shoppers — people with an account who order;
• prospective shoppers who have no account — someone who submitted an invite request and is waiting for a store to approve it;
• couriers — enrolled by an administrator, never by self-registration;
• merchant and warehouse staff — likewise enrolled by an administrator;
• platform administrators — who can see every shopper, courier, merchant and order, and the live map;
• delivery recipients who did not place the order — the person at the address, where a shopper has ordered to somebody else's home.

What the platform holds

Category	What is in it
Identity	First and last name, and a profile or logo image address
Contact	Email address and telephone number, for shoppers, couriers and merchant contacts, including a merchant's separate orders mailbox and orders telephone number
Credentials	A hashed password, session and access tokens
Social identity	The account identifier returned by Google or Facebook, where the operator has enabled social sign-in
Delivery location	Country, city, street, house, apartment, postcode, a free-text notes field, and a precise geographic point held for map and proximity searching
Courier position	The courier's current device position while on duty — see the next section, which is the important one
Courier work data	Online or offline status, lifetime deliveries, deliveries today, distance travelled today, orders skipped, and an administrator-controlled flag that switches an account off
Orders	Basket contents, prices, order number, whether it is delivery or collection, and the full timestamp chain from placement through to completion, plus which courier and which warehouse handled it
The order snapshot	A copy of the ordering shopper written into the order itself — see the limitations section below
Payment identifiers	The payment provider's customer and charge identifiers, and card metadata such as brand, last four digits and expiry. Full card numbers go to the payment provider and are not held by the platform
Devices	Device identifier, platform, language, and the push notification channel identifier
Merchant gateway credentials	The payment keys a merchant configures for its own store, held in the platform database — see the limitations section
Logs	Application and service logs, which contain identifiers and can contain fragments of a request

The free-text delivery notes field deserves a separate mention: it is unstructured and unvalidated, and people write whatever helps a courier find them. Some of what ends up there is far more personal than the address itself.

Courier location — exactly what happens

Vagueness here reads as concealment, so this is precise.

• While the courier's own status is set to Online, the courier application reads the device's position approximately every three seconds and sends it to the server.
• While the courier's status is Offline, nothing is read. The application does not sample position, and there is no background collection when the courier is off duty. That gate is in the courier's own hands and it is the strongest design fact in this product.
• The stored value is the current position, overwritten by the next reading. The platform does not build a location history table.
• The position is shown to platform administrators, to the merchant, and to the shopper who placed the order, inside the shopping application, while the delivery is running.

That last point is the one that matters most and the one operators most often fail to disclose. A courier's live position being visible to a member of the public is a materially different thing from a dispatcher watching a fleet map, and a courier is entitled to be told about it before it starts, not after.

Where we host an instance, we do not decide any of this. The operator decides whether to run the courier application at all, who may see the map, and whether the ordering shopper sees the courier. Our Data Processing Addendum treats courier position and courier work data as monitoring data and puts the corresponding obligations on the operator in binding terms.

Courier work data

Alongside position, the platform accumulates counters about the person doing the work: lifetime deliveries, deliveries completed today, distance travelled today, orders skipped, and the record of going online and offline. There is also an administrator-controlled flag that switches a courier's account off entirely.

These are performance measures. They are not a by-product of dispatch — an employer can read them as a productivity score, and some will.

Our position on them is deliberate rather than accidental. Where we host an instance, we compute and store these counters on the operator's instruction and for no purpose of our own. We do not benchmark couriers, we do not compare them across operators, we do not build or sell an industry dataset from them, and we do not use them to train anything. If we ever derived anything from them for a purpose of our own, we would become a controller of that, and we would say so here before we did it.

If you are a courier

You will not have signed up for this, so it is worth reading.

• Your position is read only while you have set your status to Online. Setting it to Offline stops it. Nothing is read from your device when you are off duty.
• While you are on a delivery, the customer waiting for it can see where you are, as well as your dispatcher and the store.
• The application also counts your deliveries, the distance you have covered today and the orders you have skipped, and the business that gave you the account can see all of it.
• The business that gave you the account decides all of this, and holds the data. Ask them what they collect, why, how long they keep it, and who sees it. If we host their instance, we will help them answer you — the section on your rights above explains how we route a request that comes to us instead.

People who never signed up

Three groups end up in the platform without ever agreeing to anything, and the obligation to tell them sits with the operator of the deployment, not with us:

• Invite requesters. A person with no account submits a street address, house, apartment, postcode and a device identifier, and that record waits in a store's console for approval. That is a residential address held about somebody with no account and no relationship with anyone but the store.
• Couriers and merchant staff. The account is created by an administrator before the worker's first contact with the software.
• Delivery recipients who did not order. A shopper can send an order to somebody else's home, and the address, apartment number and delivery notes are then visible to the store, the courier and the administrators.

Where we host an instance, our Data Processing Addendum requires the operator to give those people the notice the law requires. We cannot give it for them: we do not know who these people are, and in most cases we have no way to reach them.

Three limitations we are not going to hide

Overstating what our software can do would be its own misrepresentation, so here is what it cannot.

• Records are marked deleted, not erased. Every record carries a deleted flag, and there is no hard erasure path anywhere in the service layer. Marking something deleted removes it from the application; it does not remove it from the database.
• Every order carries a copy of the shopper. When an order is created, the shopper's name, email address, image, delivery location and apartment are copied into the order document — and in the published code, so is the stored password hash. Deleting or changing the shopper's own record does not reach those copies. Anyone running a deployment should treat the order snapshot as containing authentication material and remove it.
• Payment material reaches the logs, and merchant keys sit in the database. The payment-method handler writes the payment provider's token and card object into the application log at information level, and the payment keys a merchant configures for its own store — including the secret one — are held in the platform database and are readable from the administration console.

We will not host an instance for anyone until the credential copy and the payment logging are fixed in the code we would be running. For a deployment you run, all three are yours to deal with, and the Security page sets out what to do about them.

How long data is kept

The platform ships no automatic retention or deletion routine. Records persist until somebody removes them. There is one genuine exception, and it works in your favour: courier position is a single current value that the next reading overwrites, so no position history accumulates.

In a deployment you run, retention is something you have to implement and describe — it is not something the software does for you, and saying otherwise in your own privacy notice would be inaccurate. Where we host an instance, you set the periods, we apply them, and we will tell you honestly which records our tooling can reach and which it cannot.

The retention section above covers what we hold as controller for our own website and our own correspondence, which is a different and much smaller set of data.

Automated decisions inside the platform

Three mechanisms are worth naming: orders are allocated to couriers, a courier can skip an order and that is recorded, and a store owner approves or refuses an invite request. All three are the operator's configuration and the operator's decision-making, not ours. We do not rank or score couriers, and we do not operate any allocation logic of our own.

If an operator uses the work counters to make a decision about a courier that produces legal effects or similarly significantly affects them, that is the operator's processing to justify, and the courier's rights in relation to it run against the operator.

If a deployment shows you a privacy page

The software bundles its own privacy and terms pages, which a deployment serves to its own users. Those pages describe that deployment, and the business running it is responsible for their content. If a page served by a deployment we do not run names any Ever company as the controller of that deployment, it is wrong — the controller is the business that deployed the software, and that is who you should contact.

Our website

On everdemand.co and the documentation site we hold what you send us through the contact form, the pricing-notification form, the newsletter sign-up and the support chat — a name, an email address, an organisation and whatever you write — together with the ordinary connection and usage data described above. We are the controller for all of it. What is stored on your device, what waits for your consent, and who the providers are is in our Cookie Policy.

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 everdemand.co 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	Personal data
Cloudflare, Inc.	Authoritative DNS, TLS termination, reverse proxy and bot filtering in front of everdemand.co, docs.everdemand.co and the content management system behind the website, and the tunnel that carries requests to our own servers.	United States, with the connection terminated at the edge location nearest to the visitor	IP address, request URL, headers and TLS metadata, cookies in transit
Functional Software, Inc. d/b/a Sentry	Error and performance monitoring for the website, the documentation site and the content management system, so that a failure is visible to us with enough context to fix it.	United States	IP address, browser and device, page or route being viewed, request context and breadcrumbs, which can contain fragments of what was submitted
iubenda s.r.l.	Cookie banner and consent record on everdemand.co — it displays the choice, applies it, and stores the proof of what you chose.	Italy	IP address, consent choices and the record of them, timestamp and user agent
Google LLC (reCAPTCHA)	Bot protection on the public forms — contact, pricing notification and newsletter sign-up. It loads only on a page carrying a protected form.	United States	IP address, browser and device signals, mouse and interaction telemetry
GitHub, Inc.	Source hosting, build pipeline and container registry for the website, the documentation site and the published source code. This is how the site is built and shipped, not where visitor data lives.	United States	contributor account names and public profile data, developer identity in build logs

The full and current list, including everything below, is published at https://everdemand.co/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 everdemand.co, 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://everdemand.co/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 everdemand.co, in force from 2026-08-02. Earlier versions, with the dates they applied, are at https://everdemand.co/privacy.