Data Processing Addendum

This Data Processing Addendum ("Addendum") governs our processing of personal data on your behalf when you use Ever Works Cloud. It is agreed between you and 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.

It forms part of our Terms of Service, it applies automatically from the moment you put personal data about other people into the Service, and it needs no separate signature. If your procurement process requires a countersigned copy, write to [email protected] and we will provide one on these same terms.

Definitions

Words defined in the Terms of Service — including Customer Data, End User, Service, Subscription and Workspace — carry the same meaning here. The following words have the meaning given below.

• Addendum — this document, its Schedules, and the product annex to it.
• Terms — the Terms of Service between you and us for the Service, together with any Order under them.
• Data Protection Law — every law that applies to the processing carried out under this Addendum, including the GDPR, the UK GDPR, the Swiss FADP, and any national law implementing or supplementing them, in each case as amended, extended or replaced.
• GDPR — Regulation (EU) 2016/679, the General Data Protection Regulation.
• UK GDPR — the GDPR as it forms part of the law of the United Kingdom by virtue of section 3 of the European Union (Withdrawal) Act 2018, read with the Data Protection Act 2018.
• Swiss FADP — the Swiss Federal Act on Data Protection of 25 September 2020, with its implementing ordinance.
• Controller, Processor, Data Subject, Personal Data, Personal Data Breach, Processing and Supervisory Authority — the meanings given in Article 4 GDPR. Where another Data Protection Law governs a particular operation, that law's equivalent term applies to it.
• Special Category Data — the categories of personal data listed in Article 9(1) GDPR, and personal data relating to criminal convictions and offences under Article 10 GDPR.
• Customer Personal Data — the personal data contained in Customer Data that we process on your behalf under the Terms. It does not include the personal data we process in our own right as controller — your account and administrator details, billing and tax records, support correspondence, security and audit logs, and website analytics — which our Privacy Policy governs instead.
• Monitoring Data — the part of Customer Personal Data that the Service captures about how individuals work, where you have enabled the features that capture it. Depending on the product and your configuration this can include periodic screenshots and their thumbnails, screen recordings, webcam stills, audio recordings, the names of applications and windows in use, visited website addresses and their metadata, keyboard and mouse activity rates and event counts (never keystroke content), idle time, time entries, and location where that feature is switched on. The product annex lists exactly what Ever Works can capture and what each control does.
• Monitored Individual — an employee, worker, contractor or other person whose Monitoring Data is captured through your Workspace.
• Documented Instructions — your instructions to us on how Customer Personal Data is to be processed. They consist of the Terms, this Addendum, the settings and configuration you and your administrators apply in the Service, the features you switch on or leave off, your use of the Service's documented functionality, and any further written instruction we accept.
• Sub-processor — a third party we engage to process Customer Personal Data on your behalf so that we can deliver the Service.
• Sub-processor List — the list published at https://ever.works/subprocessors, as it stands from time to time.
• Security Measures — the technical and organisational measures set out in Schedule 2 and on our Security page.
• Restricted Transfer — a transfer of Customer Personal Data to a country outside the European Economic Area, the United Kingdom or Switzerland (as applicable) that requires a safeguard under Chapter V GDPR or its equivalent.
• SCCs — the standard contractual clauses for the transfer of personal data to third countries approved by the European Commission in Implementing Decision (EU) 2021/914 of 4 June 2021, in the modules and with the options identified in the section on international transfers and in Schedule 3, which calls them the Clauses.
• UK Addendum — the International Data Transfer Addendum to the EU standard contractual clauses issued by the Information Commissioner under section 119A of the Data Protection Act 2018, version B1.0.
• Schedules — Schedule 1 (description of the processing), Schedule 2 (security measures), Schedule 3 (transfer mechanism), Schedule 4 (jurisdiction-specific terms) and Schedule 5 (sub-processors), each of which forms part of this Addendum.

How to read this Addendum

• Headings are for navigation and do not affect meaning.
• "Including", "such as" and "for example" introduce examples and never narrow the words before them.
• A reference to an Article is a reference to an Article of the GDPR, and to the corresponding provision of any other Data Protection Law that applies.
• A reference to a law includes that law as amended, extended or replaced, and any guidance a Supervisory Authority issues under it.
• "In writing" includes email.
• The English version of this Addendum is the authoritative one. A translation is a convenience; where it differs, the English text applies.

Scope, term and which document wins

When this Addendum applies

This Addendum applies whenever we process Customer Personal Data on your behalf in connection with the Service. That happens as soon as you or an End User puts personal data about another person into the Service — a colleague, an employee, a contractor, a client, a candidate, a contact — which for almost every customer is on the first day.

You do not have to ask for it, sign it, or trigger it. It is part of the Terms and it binds both of us from the moment the Terms take effect.

What it does not cover

Three things sit outside it, and each is governed elsewhere.

• Our own controller processing. Your account and administrator details, billing and tax records, support correspondence, security and audit logs, and our website analytics are processed by us as controller, for our own purposes. Our Privacy Policy governs that, not this Addendum, and a data subject exercises rights over it against us directly.
• Software you run yourself. Several of our products are published as open source and can be deployed on your own infrastructure. In a deployment you operate, we process nothing. We are not your processor for it, the Sub-processor List does not describe it, the Security Measures do not apply to it, and this Addendum gives you nothing in respect of it. The open-source carve-out in the Terms explains why.
• Third-party services you connect. Where you connect an integration, a marketplace app or your own AI provider, that provider processes data under its own arrangement with you. We are not its processor and it is not our Sub-processor, unless the Sub-processor List says otherwise.

The description of the processing

The subject matter, duration, nature and purpose of the processing, the types of personal data and the categories of data subject are set out in Schedule 1, as Article 28(3) requires. The product annex to this Addendum records what is specific to Ever Works — including, where the product captures Monitoring Data, exactly what each feature captures, at what frequency, and which controls you hold.

How long it lasts

This Addendum takes effect when the Terms do and continues for as long as we process Customer Personal Data on your behalf. It survives termination of the Terms until deletion or return is complete under the section on deletion and return, and the sections on confidentiality, security, breach notification, international transfers, deletion and return, audits and liability survive for as long as they are capable of applying.

Which document wins

Conflicts between documents are inevitable, so here is the order. Where two of them genuinely contradict each other on a question about the processing of personal data, the higher one applies:

1. the SCCs, the UK Addendum and any other transfer mechanism incorporated by this Addendum;
2. this Addendum, including its Schedules;
3. an order form or other agreement we have both signed that expressly varies this Addendum;
4. the Terms; and
5. our Privacy Policy, Cookie Policy and any other policy incorporated by reference.

The product annex forms part of this Addendum. Where it says something more specific about Ever Works, that specific statement applies to Ever Works. A term that adds something is not a conflict — both documents apply, and only a term that cannot be true at the same time as another engages this order.

If the law changes

Data protection law moves, and a mechanism this Addendum relies on can be amended, replaced or invalidated. If that happens — a new set of standard contractual clauses, a repealed adequacy decision, a superseding regulation — we will adopt the replacement mechanism or make the amendment that the change requires, and that amendment takes effect without either of us having to sign anything further. We will not use this paragraph to reduce the protection you have, and any change we make under it must leave you at least as well protected as you were.

Who is the controller, who is the processor

Data protection law splits responsibility in two. The controller decides why personal data is processed and how. The processor acts only on the controller's instructions. This is not paperwork: it decides who owes the notices, who has to answer a data subject, and who is accountable to a Supervisory Authority.

The split

You are the controller of Customer Personal Data. We are your processor. You decide what goes into the Service, which features are switched on, why, and for how long the data is kept. We process it on your Documented Instructions and for no purpose of our own.

Where you are yourself a processor — because the data belongs to one of your own clients, and that client is the controller — you appoint us as your sub-processor on these same terms. In that case you confirm that your own controller has authorised our appointment, and the transfer sections apply Module 3 of the SCCs rather than Module 2.

We are an independent controller for the limited processing described in the scope section: your account and administrator details, billing and tax records, support correspondence, security and audit logs, and our website analytics. We do not become the controller of Customer Personal Data by processing it, and nothing in this Addendum makes us a joint controller with you.

We never process Customer Personal Data for our own purposes. We do not sell it, we do not use it to build profiles, we do not use it to train machine-learning models for our own benefit or for other customers unless you have expressly opted in, and we do not look at it except where we must in order to provide, secure or support the Service for you.

No company in our group other than Ever Technologies LTD processes Customer Personal Data, and no group company appears on the Sub-processor List.

Monitoring: the split matters most here

Where Ever Works captures Monitoring Data, you are the controller of it and we are your processor. We build the features, we document what each one captures and what each control does, and we run them exactly as you configure them. We do not decide to capture anything about your people, and we cannot switch a capture feature on for you.

We make no claim that monitoring employees is lawful across the European Union, because it is not. National employment law under Article 88 GDPR diverges sharply. Some countries require consultation before monitoring starts, some make it subject to a binding co-determination right, and at least one prohibits remote surveillance for the purpose of supervising performance almost outright. Whether your use of these features is lawful where your people work is your assessment to make, and this Addendum is drafted on the basis that you have made it.

What you represent and warrant to us

These are representations and warranties, not a general promise to obey the law, and we rely on them. Each time Monitoring Data is captured through your Workspace, you represent and warrant that:

• (i) You are the controller and you have identified a valid lawful basis under Article 6 GDPR — and, where Special Category Data is involved, a condition under Article 9 — for every purpose for which you monitor. You acknowledge that consent is generally not a valid basis for monitoring in an employment context, because the imbalance of power between employer and worker means the consent is rarely freely given. If you are relying on legitimate interests, you have carried out and documented a balancing test that addresses the intrusiveness of what you have enabled.

• (ii) You have given each Monitored Individual the information Article 13 requires — in full, in plain language, and before any capture of their data begins. That includes your identity as controller, what is captured, how often, why, on what lawful basis, how long it is kept, who receives it, and how to object or complain. Telling people afterwards does not satisfy this, and neither does burying it in a handbook nobody has been shown.

• (iii) You have carried out a data protection impact assessment under Article 35 wherever one is required, before the processing started, and you have acted on what it found. Where the residual risk remained high, you have consulted your Supervisory Authority under Article 36 before beginning.

• (iv) You have completed every works-council, trade-union or employee-representative process your local law requires, before enabling any capture feature — and you will not enable one while that process is outstanding. This obligation is real and specific in a number of jurisdictions, and we name them so that nobody can say they were not told:

  • Germany — the works council's co-determination right over technical devices suitable for monitoring behaviour or performance, under section 87(1) no. 6 of the Works Constitution Act (BetrVG);
  • Austria — works-council consent for monitoring measures and technical systems affecting human dignity, under section 96(1) no. 3 of the Labour Constitution Act (ArbVG);
  • the Netherlands — the works council's prior consent for any system for monitoring employee behaviour or performance, under Article 27(1)(l) of the Works Councils Act (WOR);
  • Italy — prior agreement with the trade unions or, failing that, authorisation from the labour inspectorate, under Article 4 of the Workers' Statute (Law 300/1970); and
  • Finland — co-operation negotiations with employee representatives on the purposes and methods of technical monitoring before it is introduced, under the Co-operation Act.

  This list is illustrative of the strictest regimes we know of. It is not a complete list of your obligations, and the fact that your country is absent from it is not our assurance that nothing is required of you there.

The remaining representations — about jurisdictions where capture is prohibited, and about covert monitoring — are in the next section, because they are restrictions on what you may instruct us to do.

We do not verify any of this

We are not in a position to check whether you have a lawful basis, whether your people were told, whether your impact assessment was done, or whether your works council agreed. We do not audit your compliance, we do not approve your configuration, and the fact that the Service allows a setting is never our advice that switching it on is lawful for you. Providing a feature is not a legal opinion about it.

Your indemnity

You will defend us, and pay the damages, fines and costs finally awarded or agreed in settlement, against any claim, investigation or enforcement action arising from a breach of the representations and warranties in this section or in the next one — including a claim by a Monitored Individual, a works council, a trade union, a labour authority or a Supervisory Authority.

This indemnity runs on the same conditions as the mutual indemnities in the Terms: we will tell you promptly, let you control the defence, and co-operate at your expense. In line with the Terms, your obligations under this indemnity are not subject to the cap on liability. If you are dealing with us as a consumer rather than for purposes related to your trade, business, craft or profession, the consumer carve-out in the Terms applies and this indemnity does not bind you.

Processing only on your instructions

The rule

We process Customer Personal Data only on your Documented Instructions, including in relation to transfers of that data to a third country, unless a law of the European Union or of a Member State to which we are subject requires us to process it otherwise. Where such a law applies, we will tell you what it requires before we process — unless that same law prohibits us from telling you, on important grounds of public interest.

What counts as an instruction

Your instructions are not limited to letters you write us. They are:

• the Terms and this Addendum, including the Schedules and the product annex;
• the configuration you apply — every setting, feature switch, capture frequency, retention period, permission and integration that you or your administrators choose, and every one you leave at its default;
• your use of the Service's documented functionality, including exports, deletions and API calls; and
• any further instruction you give us in writing and we accept.

Your configuration is your instruction. When you enable screen capture, set a capture interval, turn on webcam stills or audio recording, extend a retention period or add a Monitored Individual, you are instructing us to process personal data in that way, as surely as if you had written us a letter saying so. Leaving a capture feature switched off is equally an instruction, and we will honour it.

Instructions outside the Service's ordinary functionality

An instruction that goes beyond what the Service does as documented — a bespoke export, a targeted retrieval, a processing step we do not offer — must be given in writing to [email protected]. We will tell you whether we can carry it out and, if it requires work outside the scope of your Subscription, what it will cost, before we do anything. We will not carry out such an instruction without agreeing it with you first.

What you must not instruct us to do

These are restrictions on your instructions, and they are also representations you give us. You represent and warrant that:

• (v) You will not enable, and will not instruct us to operate, screen capture, webcam capture, audio recording or screen recording where the law of the place a Monitored Individual works prohibits it. We name Portugal expressly. The Portuguese Labour Code prohibits an employer from using remote surveillance means to supervise a worker's professional performance, and the narrow exception is for the protection of persons and property and for particular safety or operational needs. In practice that makes productivity-purpose screen, webcam or audio capture effectively unavailable in Portugal, and no configuration we offer changes that. Portugal is the clearest case, not the only one — comparable restrictions exist elsewhere and you are responsible for knowing which apply to your people.
• (vi) You will not use the Service for covert or secret monitoring. Every Monitored Individual must know that capture is happening, what is captured and when it is running. You will not disable, suppress, circumvent or conceal any indicator, notice or notification the Service provides for that purpose, and you will not represent the software to your people as something other than what it is. We do not provide a stealth mode and we will not build one, at any price, for any customer. In some countries covert monitoring of workers carries criminal exposure as well as a regulatory one.
• Every instruction you give us complies with Data Protection Law, and you have the right to give it.
• You will not send us Special Category Data, or personal data relating to criminal convictions and offences, through any feature that is not designed to hold it. Where such data is incidentally caught — a health portal visible in a screenshot, for example — you remain the controller of it, and you will use the exclusion, masking, blur and pause controls the Service provides to reduce that risk.
• You will not use the Service to process personal data of children where the product is not offered for that purpose.

The remaining representations — about your controller status, lawful basis, Article 13 notices, impact assessments and employee-representative processes — are in the previous section. The indemnity in that section covers a breach of the representations in this section too.

When we think an instruction is unlawful

If we consider that an instruction infringes the GDPR or another Data Protection Law, we will tell you. We will say which provision concerns us and why, in writing, and we will give you the chance to withdraw or amend the instruction.

While the point is unresolved we may suspend the affected processing, and if you confirm an instruction we reasonably believe would put us in breach, we may decline to carry it out. Declining or suspending on that ground is not a breach of the Terms by us and does not entitle you to a refund — but we will not use it as a pretext, and we will explain our reasoning rather than simply stopping.

This works the other way as well. We do not sit in judgement on your processing generally. Our duty is to raise the point when it is apparent to us from what we can see, not to review your compliance programme — and our silence on an instruction is never our approval of it.

Confidentiality of the people who handle your data

Article 28(3)(b) requires us to ensure that everyone we authorise to process Customer Personal Data is bound to keep it confidential. Here is how we do that.

• Written confidentiality obligations. Every employee and every contractor who can reach Customer Personal Data is bound by a written confidentiality undertaking, or by an equivalent statutory obligation of confidence. Those obligations survive the end of their employment or engagement, and they are not limited to the period in which the person had access.
• Need to know, not seniority. Access is granted on the basis of what a person's role actually requires. Being senior is not a reason to have access; needing it to do a specific job is. Access is granted through named individual accounts, never shared logins, and it is protected by multi-factor authentication.
• Least privilege, and it is reviewed. Permissions are scoped to the narrowest role that works. They are reviewed periodically, and they are revoked when someone changes role or leaves — as part of the process, not as a favour to be remembered later.
• Training. People with access are trained on data protection and on secure handling before they get it, and again as the rules change.

Access to Monitoring Data specifically

Monitoring Data is the most intrusive category of Customer Personal Data the Service holds, and we treat it accordingly.

• Nobody at our end browses it. Access by our personnel is limited to what is strictly necessary to operate, secure, restore or support the Service, and to what you ask us to do.
• Where we need to access it to resolve a support request, we do so on your request or with your agreement, and we limit the access to what the request requires.
• Privileged access is logged. Administrative access to Customer Personal Data is recorded, and those records are retained and monitored. Where you ask us, as controller, what our people accessed in your Workspace and when, we will tell you.
• The Service's own controls over who inside your organisation can see Monitoring Data are yours to configure. The product annex describes them.

Sub-processors and confidentiality

Every Sub-processor we engage is bound by confidentiality obligations at least as protective as those in this section, flowed down by contract before any Customer Personal Data reaches it. The sub-processing section says what else we require of them.

Your Confidential Information

Customer Personal Data is your Confidential Information under the Terms. Nothing in this section reduces the confidentiality obligations we owe you there, and nothing in the Terms reduces this section.

Security measures

What we commit to

We implement and maintain appropriate technical and organisational measures to protect Customer Personal Data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure and unauthorised access, as Article 32 requires. The measures take account of the state of the art, the cost of implementation, the nature, scope, context and purposes of the processing, and the risk to the people whose data it is.

The measures we actually operate are set out in Schedule 2, and our Security page describes them in more detail, including which measure applies to which part of the Service. They are contractual commitments, not marketing copy: encryption in transit and at rest, access control and least privilege, network segmentation, logging and alerting, tested backups, vulnerability management, secure development, and personnel and vendor controls.

Measures change, protection does not go backwards

Security is not static, and a schedule frozen in 2026 protects nobody in 2029. We may update the Security Measures as technology and threats change. What we will not do is reduce them: any change must leave the level of protection for Customer Personal Data at least equivalent to the level described in Schedule 2 at the time you subscribed. Where a change is material, we will update Schedule 2 and the Security page.

Assistance with your own Article 32 obligation

Article 28(3)(f) obliges us to assist you in meeting your own security obligation, taking into account the nature of the processing and the information available to us. In practice that means:

• the information in Schedule 2, the Security page and the DPIA support pack, which you may rely on in your own assessment;
• answers to a security questionnaire, on the terms in the audits section;
• where we have commissioned independent security testing, a summary of the results, under confidentiality — Schedule 2 states plainly whether such a report exists, and today it does not; and
• prompt engagement where you tell us of a risk you have identified.

What we do not claim

We do not hold a SOC 2 report and we are not certified to ISO/IEC 27001. We describe practices we actually run, and we do not imply a certification we do not hold. If a document, a salesperson or a comparison table has told you otherwise, it is wrong and we would like to know where it came from.

No system can be made completely secure. What we can honestly commit to is the measures in Schedule 2, kept under review, and the breach obligations in the next section when something goes wrong.

Your side of the line

Some of the controls that protect Customer Personal Data are yours, not ours, and no measure we take can compensate for them being left open. You are responsible for:

• who you invite into your Workspace, what role you give them, and removing them when they leave;
• requiring strong authentication for your own users, including multi-factor authentication where the Service offers it;
• keeping administrator credentials, API keys and integration tokens secret, and rotating them when a person with access leaves;
• the security of the devices your people use, including the devices on which any desktop agent runs; and
• the capture, retention, blur, masking, exclusion and pause settings you choose — a screenshot never taken is the strongest security measure available for it, and that switch is on your side.

Our Security page sets out this shared responsibility split in full.

If there is a personal data breach

We tell you, and we tell you quickly

If we become aware of a Personal Data Breach affecting Customer Personal Data, we will notify you without undue delay, and in any event within seventy-two (72) hours of becoming aware of it. That is a floor, not a target: where we have confirmed that a breach affects your Workspace, we aim to make first contact within twenty-four (24) hours.

"Becoming aware" means the point at which we have a reasonable degree of certainty that a security incident has led to Personal Data being compromised — not the moment a monitoring alert fires. We do not delay a notification while we finish investigating, and we will not wait to be certain of the full picture before telling you there is one.

What the notification contains

We will give you the information you need in order to meet your own duties under Articles 33 and 34, so far as it is available to us at the time:

• what happened, when it happened, and when we became aware of it;
• the categories of Customer Personal Data affected, and the approximate number of records and data subjects, where we can establish them;
• whether Monitoring Data was affected, which is the category most likely to make a breach high-risk to the people concerned;
• the likely consequences;
• the measures we have taken or propose to take, including anything you can do to mitigate the effects; and
• a contact point at our end who can answer follow-up questions.

The first notification will usually be incomplete, and we would rather send it incomplete than send it late. We will follow it with further information in phases as the investigation develops, without you having to chase us, and we will tell you when the investigation has closed.

Who notifies whom

You are the controller, so the decision to notify a Supervisory Authority under Article 33, and affected individuals under Article 34, is yours. We will not make that notification on your behalf and we will not contact your data subjects directly about it, unless you instruct us to in writing or the law requires us to act.

We will give you reasonable assistance with both — including the information above, our timeline of events, and answers to questions your Supervisory Authority puts to you about our part of the processing.

Where the breach also affects personal data for which we are the controller, we will make our own notifications in our own right, to the CPDP and to the people concerned, as the law requires.

Investigation and containment

We will investigate, contain, and take reasonable steps to mitigate the effects of the breach and to prevent it recurring, and we will document what happened and what we did. That record is available to you on request under the audits section.

A notification is not an admission

Telling you about an incident is not an acknowledgement of fault or of liability on our part, and we would rather that were written down than have it become a reason to hesitate before picking up the phone. Fault is worked out afterwards, on the facts.

Keep your security contact current

Notifications go to the administrator contacts on your account and to any dedicated security contact you have given us. Keeping those addresses accurate and monitored is your responsibility — a notification sent within the hour to a mailbox nobody reads has done neither of us any good. You can update the contact at any time by writing to [email protected].

If you need to report a security problem to us, write to [email protected] and treat it as urgent. Our Security page sets out the responsible disclosure route.

Sub-processors

Your general authorisation

You give us a general written authorisation to engage Sub-processors, under Article 28(2). That authorisation is not open-ended: it is subject to the conditions in this section, which give you a published list, advance notice of every change, and a right to object with a real consequence attached.

The Sub-processors engaged today are published at https://ever.works/subprocessors and summarised in Schedule 5. The published list is the operative one; the Schedule is a snapshot of it.

What the list tells you, and why it has three tiers

A flat list of every third party that appears anywhere in our software would be both inaccurate and misleading, so the published list is split into three tiers that mean genuinely different things:

• Always engaged. Engaged for the hosted Service as delivered to everyone. If you use the Service, these are in the path. This tier is the Article 28 sub-processor list.
• Engaged only if you turn something on. Optional integrations, connectors and features. A provider in this tier is engaged only once you or your administrator enables the specific feature or connects the specific account. Enable nothing and it is never involved. The list says which setting activates each one, and enabling that setting is your instruction to engage it.
• Self-hosted deployments only. Providers you would configure yourself if you ran our open-source software on your own infrastructure. They are your providers, not ours. We process nothing in a deployment you run, and nothing in this Addendum applies to it.

For each entry the list gives the provider, what it does, the categories of personal data involved, the country in which it processes, and the transfer mechanism where one is needed.

What we require of every Sub-processor

Before any Customer Personal Data reaches a Sub-processor, we:

• assess it — its security posture, its location, and what it actually needs access to;
• put a written contract in place imposing data protection obligations at least as protective as those in this Addendum, including confidentiality, security, breach notification, deletion and audit rights, as Article 28(4) requires; and
• restrict it to the minimum data and the minimum purpose the job requires.

We remain fully liable to you for a Sub-processor's performance of its data protection obligations. If it fails, that is our failure, and you take it up with us and not with them.

Notice before we add or replace one

We will give you at least thirty (30) days' notice before a new Sub-processor starts processing Customer Personal Data, or before we replace an existing one.

Notice is given by updating the published list and by emailing the address you have registered for the purpose. You can register or change that address by writing to [email protected]. If you have not registered one, notice goes to your account's administrator contacts and the published list stands as notice in any event — so subscribing to the notification is worth two minutes of your time.

One exception, and we would rather state it than rely on a general reservation of rights. Where a Sub-processor must be replaced urgently — it has failed, been compromised, or ceased to provide the service — we may engage a replacement on shorter notice, or without prior notice if the alternative is an interruption or a security risk to you. In that case we will tell you as soon as we reasonably can afterwards, explain why, and your objection right below applies from the moment we tell you exactly as it would have applied before.

Your right to object, and what happens if you use it

You may object to a new or replacement Sub-processor on reasonable data protection grounds, in writing to [email protected], within thirty (30) days of the notice.

An objection is not a formality that we note and ignore. When you object:

1. We will work with you in good faith for thirty (30) days to find a resolution — a different provider, a configuration that keeps your data out of that provider's path, an additional safeguard, or a restriction on what the provider can reach.
2. If we cannot resolve it, you may terminate the affected part of the Service, or the whole Subscription if the Sub-processor cannot be separated from it, by written notice within thirty (30) days of the end of that period. We will refund the fees you have prepaid for the terminated part for the remainder of the term, calculated pro rata.
3. Termination on this ground is not a breach by you, carries no early-termination charge, and does not affect the data export window in the Terms.

We will not begin processing with the objected-to Sub-processor for your Customer Personal Data while the 30-day discussion period is running, unless doing so is necessary to keep the Service running or to keep it secure — and if it is, we will tell you so at the time.

No group companies on the list

No company in our group other than Ever Technologies LTD processes Customer Personal Data, so none appears on the Sub-processor List. If that ever changes, it is a change to the list and every notice and objection right in this section applies to it in the ordinary way.

Helping you answer data subjects

Whose job it is

The requests are yours to answer. Where an individual asks about Customer Personal Data — access, rectification, erasure, restriction, portability, objection, or a decision taken about them by automated means — you are the controller and Article 12 puts the reply and the one-month deadline on you.

Our obligation under Article 28(3)(e) is to assist you, by appropriate technical and organisational measures, so that you can meet it. We take that seriously, because a processor that cannot produce the data turns your one-month deadline into a fiction.

The tools come first

Most requests should never need us at all. The Service provides the functionality to search, view, correct, export and delete Customer Personal Data inside your Workspace, including Monitoring Data. Where Ever Works offers a specific export or erasure route, the product annex says where it is.

Use those tools first. They are faster than asking us, they work at any hour, and they do not depend on anybody's queue.

When you need us

Where the tools do not reach, write to [email protected] describing what you need. We will:

• acknowledge within three (3) business days;
• provide the assistance within ten (10) business days, or sooner where your own deadline requires it and you tell us the date you are working to; and
• tell you promptly if a request is genuinely not technically possible, and what the nearest alternative is, rather than letting the clock run out in silence.

Assistance of this kind is included in your Subscription. Where a request requires substantial manual engineering work — reconstructing historical data from backups, for example — we will tell you before we start what it will involve and what it will cost, and we will not begin until you agree. We will never charge you for a routine request, and we will not use cost as a reason to be slow.

Requests that come to us instead of you

Individuals do not always know who holds their data, and a monitored worker very often writes to the vendor whose name is on the software.

If a data subject contacts us about Customer Personal Data, we will not answer the substance of it. We have no lawful basis to disclose one organisation's data to a person that organisation has not authorised, and we cannot verify an employment relationship from the outside. Instead we will:

• forward the request to you promptly, using your registered privacy contact;
• tell the individual that we have forwarded it and to whom, so that they are not left waiting on silence; and
• help you deal with it, as described above.

The only exceptions are where the individual is exercising a right against us as controller — over their own account, billing or support data — or where the law requires us to respond directly.

Monitored individuals in particular

Requests from Monitored Individuals are the ones most likely to arrive, and the ones where the answer matters most to the person asking.

• They go to you. You are the controller of Monitoring Data and you hold the employment relationship.
• We will help you find, produce, correct, restrict or delete it, on the terms above.
• Where Ever Works lets a Monitored Individual see, and in some configurations delete, their own captured data, we will not disable that capability at your request in order to keep it from them. Which of those controls exist is described in the product annex.
• We will not take an instruction from you to withhold from an individual data they are entitled to under Article 15. Whether an exemption applies is your call as controller — but we will not help you conceal the existence of the processing itself.

Complaints and supervisory authorities

If a Supervisory Authority contacts us about your processing, we will tell you without undue delay unless the law prohibits it, and we will co-operate with the authority as Article 31 requires. Our own lead authority is the Commission for Personal Data Protection (Комисия за защита на личните данни), the CPDP, at https://www.cpdp.bg/.

Impact assessments and prior consultation

Whose obligation this is

A data protection impact assessment is your obligation, not ours. Article 35 puts it on the controller, and for Customer Personal Data — above all for Monitoring Data — the controller is you.

Article 28(3)(f) puts a different obligation on us: to assist you with Articles 35 and 36, taking into account the nature of the processing and the information available to us. We commit to that assistance here, and we back it with something the market does not currently provide.

You will very probably need one

We are not your legal adviser and this is not advice. But it would be dishonest to sell a monitoring feature and stay quiet about the assessment it triggers, so:

If you enable screen, activity, application, website, webcam or audio capture, assume an impact assessment is required before you switch it on. The nine criteria in the European guidance on high-risk processing are the operative test, and two of them are the working threshold. Continuous or interval capture of workers typically meets four or five:

• evaluation or scoring — activity percentages, productivity figures, manager dashboards;
• systematic monitoring — capture at an interval, over a working day, without a specific trigger;
• data about vulnerable data subjects — the guidance names employees expressly, because of the imbalance of power between worker and employer;
• innovative use of technology — including any automated classification or scoring layered on top; and
• matching or combining datasets — screenshots plus application and website logs plus activity rates plus time entries plus, where enabled, location.

Several Member States have also filed national lists under Article 35(4) that catch systematic workplace monitoring, whether or not they name it in those words. And in the Netherlands, where the residual risk stays high after mitigation, Article 36 prior consultation with the supervisory authority is required before monitoring starts, not after. In Germany, processing that is subject to an impact assessment obliges the employer to appoint a data protection officer under section 38 BDSG regardless of headcount.

You will reach your own conclusion. We would rather you reached it before deployment than during an investigation.

What we will do

• Provide the DPIA support pack below, published, current, and free.
• Answer an impact-assessment questionnaire about our part of the processing, within ten (10) business days of receiving it, once per twelve months for each product you subscribe to — and more often where a Supervisory Authority, a works council or a material change to the Service makes it reasonable.
• Support an Article 36 prior consultation. Where you have to consult a Supervisory Authority before starting, we will supply the information about our processing that the authority asks for, and we will answer questions put to us through you within the authority's timescale.
• Tell you when something changes that would affect an assessment you have already done — a new data category, a new capture feature, a change to a default, a new Sub-processor, a change of storage region or a change to a retention ceiling.

The DPIA support pack

We publish a DPIA support pack for Ever Works and we keep it current. It is written to be pasted into your own assessment and put in front of your works council, your data protection officer and your auditors. It contains:

• The data categories captured, feature by feature — what each capture feature records, precisely, and what it does not. Including the explicit negatives, because a negative commitment is worth more in an assessment than a positive claim: no keystroke content, no email content, no capture outside the periods you configure.
• Capture frequency ranges — the minimum, maximum and default interval for every capture feature, and what the interval means in records per person per day.
• Retention windows, as actual numbers. Our ceilings, our defaults, the range you can configure inside them, and when the automatic purge runs.
• Storage regions — where each category of Customer Personal Data is stored and processed, and where backups are held.
• The Sub-processor list for the product, in the three tiers described in the sub-processing section, with the categories of data each one receives.
• The transfer mechanism relied on for each Restricted Transfer, and the assessment behind it.
• The security measures in Schedule 2, mapped to the risks they address.
• A lever-to-risk map — every privacy control the product offers (default off, per-user and per-team disable, capture interval, on-device blur, excluded applications and sites, masking, per-user pause, retention ceiling, data-access parity for the monitored person, and the audit log of privileged access), set against the specific risk each one mitigates and the residual risk it leaves.

It is free, it is public, and it does not require a sales conversation to obtain. Ask at [email protected] if you cannot find the current version, or want it in a form your own template can absorb.

What we will not do

We will not write your impact assessment, sign it off, or tell you that your processing is lawful. That assessment depends on your purposes, your workforce, your country's employment law and your own balancing of interests — none of which we can see, and all of which are yours to decide. Anyone offering to do it for you from the vendor's side of the relationship is selling you a document, not a defence.

Information and audits

Article 28(3)(h) entitles you to the information you need to demonstrate that we meet our obligations, and to audits and inspections. This section says how that right is exercised. It satisfies the right; it does not water it down — but it is deliberately staged, because an open-ended right for every customer to walk into a shared production environment would degrade security for all of them, including you.

Stage one: the documentation, which is already published

Most audit questions are answered before they are asked. Available to you at any time, at no cost:

• Schedule 2 and our Security page — the technical and organisational measures we operate;
• Schedule 1 — the description of the processing, and Schedule 3 — the transfer mechanism;
• the Sub-processor List at https://ever.works/subprocessors, with categories of data, country and mechanism per provider;
• the DPIA support pack for Ever Works;
• a summary of the results of any independent security testing we have commissioned, provided under confidentiality on request — Schedule 2 says plainly whether such a report exists, rather than letting you assume one does; and
• the records we keep under Article 30(2) of the processing carried out on your behalf, so far as they relate to you.

Stage two: a written questionnaire

If the published material does not answer your question, send us a questionnaire.

• Once in any twelve (12) month period, per subscribing entity.
• We respond within thirty (30) days of receiving it.
• Reasonable in scope: limited to the processing of your Customer Personal Data and to our obligations under this Addendum.
• Included in your Subscription at no extra charge. Where a questionnaire is exceptionally long or requires bespoke evidence to be assembled, we will tell you before we start what it will involve and what it will cost, and we will not begin until you agree.

Industry-standard questionnaires are welcome and are usually the fastest route for both of us.

Stage three: an on-site inspection

An on-site audit is available where a Supervisory Authority requires one, and where a confirmed Personal Data Breach has affected your Customer Personal Data. It is also available where the answers at stages one and two do not, on a reasonable view, allow you to satisfy your own obligations — but we will ask you to say which question remains unanswered, because that is the point of the staging.

An inspection is subject to all of the following:

• thirty (30) days' written notice, unless a Supervisory Authority requires it sooner;
• not more than once in any twelve (12) month period, unless a Supervisory Authority requires more or a breach affecting your data has occurred;
• conducted during business hours, in a manner that does not interfere with the operation of the Service for you or anyone else;
• limited in scope to the processing of your Customer Personal Data and our compliance with this Addendum, and to a duration agreed in advance;
• conducted by you or by an independent auditor you appoint, provided the auditor is not a competitor of ours, and provided you and the auditor are bound by confidentiality obligations at least as protective as those in the Terms;
• carried out at your cost, including our reasonable costs of supporting it at our then-current professional services rates; and
• covering the scope of a Sub-processor's processing through us — we will obtain the information you need from the Sub-processor rather than sending an auditor to it directly.

What an audit will not include, at any stage. Access to another customer's data, or to any system in a way that would expose it. Direct access to our multi-tenant production environment, credentials or live databases. Penetration testing, vulnerability scanning or any other active test against our production systems without our prior written agreement and an agreed scope. Access to our own confidential commercial information that is not relevant to the processing of your data.

Costs where something is found

The cost rule above has one exception, and it should. If an audit reveals a material breach by us of this Addendum, we bear our own costs and we will reimburse the reasonable costs of the audit — and we will remedy the finding at our expense, on a plan and a timetable agreed with you.

Findings are confidential

Audit reports, questionnaire responses, testing summaries and everything you learn in the course of an audit are our Confidential Information under the Terms. You may share them with your own auditors, advisers and a Supervisory Authority where they are bound by confidentiality or by law; otherwise they stay with you.

Where a Supervisory Authority is the one asking

Nothing in this section limits a Supervisory Authority's own powers of investigation and inspection, or your ability to comply with an order from one. If an authority requires access to us in connection with your processing, tell us and we will co-operate directly.

International transfers

Where your data sits

Customer Personal Data is stored on infrastructure we operate inside the European Economic Area. Schedule 3 names the regions, and the product annex records anything specific to Ever Works.

We are established in the EEA. Ever Technologies LTD is a Bulgaria company, so the processing we carry out for you does not itself involve a transfer out of the EEA and needs no Chapter V safeguard between you and us.

We do not transfer Customer Personal Data to any company in our group outside the EEA. No group company processes it and none appears on the Sub-processor List.

Restricted Transfers therefore arise in three narrower places, and Schedule 3 deals with each:

• onward, to the Sub-processors on the published list that are established or process outside the EEA — principally in the United States. This is the main one, and the Sub-processor List names the country and the mechanism for each provider;
• back to you, where you or your users are established outside the EEA and data leaves it to reach you; and
• where your own regime treats the flow as restricted — the United Kingdom and Switzerland, dealt with in Schedule 4.

The standard contractual clauses

The SCCs are incorporated into this Addendum by reference, and they apply to every Restricted Transfer of Customer Personal Data. Where they conflict with anything else in this Addendum, the SCCs win.

Module selection. Which module governs a transfer depends on the role each of us holds in it:

• Module Two — controller to processor — where you are the controller of the Customer Personal Data transferred and we process it for you. Where clauses have to be concluded with an importing Sub-processor for data you control, we enter into them for that transfer acting on your behalf, and you authorise us to do so by this Addendum.
• Module Three — processor to processor — where we are the exporter in our capacity as your processor, and where you are yourself a processor and we act as your sub-processor.
• Module Four — processor to controller — where you are a controller established outside the EEA and data returns to you from us.

Module One does not apply: this Addendum governs processing we carry out for you. Schedule 3 maps every module against the flow it covers, and where more than one is true at once each applies to the flow it describes.

The options and variables we have selected, so that nobody has to guess:

• Clause 7 (docking clause) — included, so that a further party may accede.
• Clause 9(a) — Option 2, general written authorisation, with a minimum notice period of thirty (30) days for the addition or replacement of a sub-processor. That is the same notice and objection regime as the sub-processing section, and neither reduces the other.
• Clause 11(a) — the optional independent dispute-resolution body language is not adopted. Data subjects keep every other redress route in the clauses, including a complaint to a Supervisory Authority and a remedy before the courts.
• Clause 13 and Annex I.C — the competent Supervisory Authority is the one identified in Schedule 1. It follows from where you are established, not from where we are.
• Clause 17 — Option 1, the laws of the Republic of Bulgaria.
• Clause 18(b) — the competent courts of Sofia, Bulgaria. This does not affect a data subject's right under Clause 18(c) to bring proceedings in their own member state.
• The Appendices — Annex I.A and I.B are completed by Schedule 1; Annex I.C by Schedule 1; Annex II by Schedule 2; Annex III by Schedule 5 and the published Sub-processor List.

Accepting this Addendum is your signature on the SCCs, and our acceptance of your Subscription is ours. There is no separate signing ceremony. If your compliance process needs a countersigned copy, write to [email protected] naming the entity and the modules you need.

The United Kingdom and Switzerland

Both regimes recognise the EEA as adequate, so sending your data to us is not normally a restricted transfer under either. The mechanisms below stand behind that recognition rather than instead of it.

• United Kingdom. Where a transfer is restricted by the UK GDPR — principally our onward transfer to a provider outside the United Kingdom — the UK Addendum applies to the SCCs. References to the GDPR are read as references to the UK GDPR and the competent authority is the Information Commissioner. Schedule 4 completes each of the Addendum's four tables, including our selection that neither party may end it when the Approved Addendum changes.
• Switzerland. Where a transfer is restricted by the Swiss FADP, the SCCs apply with the adaptations the Federal Data Protection and Information Commissioner recognises: the FDPIC as competent authority for FADP-governed transfers, references to the GDPR read as references to the FADP, "member state" not read so as to stop a data subject resident in Switzerland bringing proceedings where they live, and — for as long as Swiss law protects it — data about legal entities treated as personal data.

Schedule 4 sets both out in full, together with our position on representatives under Article 27 in each regime.

The EU–US Data Privacy Framework

Where a US Sub-processor is actively self-certified under the Framework for the type of data concerned, that certification is an additional basis for the transfer. We check the official list when we engage a provider and re-check it periodically, and we do not claim the Framework for a provider that has not certified or whose certification has lapsed.

We keep the SCCs in place as the standing mechanism regardless, including for certified providers. The Framework's adequacy decision is valid today — the General Court dismissed the challenge to it in Latombe (Case T-553/23) on 3 September 2025 — but 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 annulled by that court. Keeping a second mechanism standing makes a change in the law a paperwork event for us rather than an interruption for you.

Assessment and supplementary measures

Before a Restricted Transfer begins we carry out a transfer impact assessment covering the destination country's law and practice, the nature of the data and the safeguards available, and we keep it under review. Alongside the clauses we apply: encryption in transit and at rest, minimising what is sent in the first place, contractual restrictions on onward disclosure, and access controls at the importer.

Government access requests

Where a Sub-processor receives a legally binding request from a public authority for Customer Personal Data, our contracts require it to notify us — and we will notify you — unless it is legally prohibited from doing so, to challenge a request that is unlawful or overbroad, and to disclose no more than the minimum the request actually compels. We do not grant any government direct, unfettered or back-door access to Customer Personal Data, and we would not. If we receive such a request ourselves, the same commitments apply and we will tell you unless we are prohibited from doing so.

Onward transfers

A Sub-processor may not transfer Customer Personal Data onwards to a further recipient in a third country unless it does so under a mechanism valid under Chapter V, imposes obligations at least as protective as those in this Addendum, and is permitted to do so under its contract with us. The Sub-processor List records where that arises.

If a mechanism falls away

If a transfer mechanism this Addendum relies on is invalidated, amended or replaced, we will adopt the replacement mechanism, or take the additional measures the change requires, without undue delay and at our cost. Where no lawful mechanism remains available for a particular transfer, we will stop making that transfer and we will tell you what it means for the Service. You may obtain a copy of the safeguards relied on for any transfer by writing to [email protected]; we may redact commercial terms such as pricing, but never the data protection terms.

Deletion and return at the end

Article 28(3)(g) gives you the choice: at the end of the provision of services, we either delete Customer Personal Data or return it to you, and we delete the existing copies unless a law requires us to keep them. Here is how that choice is exercised and what the dates actually are.

Your choice, and the default

When your Subscription ends you have thirty (30) days to export your data. That window, and how to use it, is set out in the Terms.

• To have the data returned, export it yourself during the window using the product's export functionality or the API, or ask us at [email protected] and we will produce it for you. Exports are delivered in a structured, commonly used, machine-readable format, with uploaded files in the format we hold them. A request made inside the window is honoured even if the export is delivered after the window has closed.
• If you make no election, we delete. Deletion is the default, because holding data nobody asked us to keep is the worse of the two failure modes.

The deletion timetable

• Live systems: deletion begins when the 30-day export window closes, and completes within a further thirty (30) days.
• Sub-processors: we instruct every Sub-processor holding Customer Personal Data to delete it on the same timetable, and their contracts require them to.
• Deletion is permanent and we cannot reverse it. Once it has run, an export is no longer possible.

Backups, stated honestly

We do not surgically remove one customer's records from a backup set that already exists, because doing so would compromise the integrity of the backup and defeat what a backup is for.

Customer Personal Data therefore persists in backups until those backups age out in the ordinary rotation — at most thirty (30) days. While they exist, backups are encrypted, access-controlled, and restored only as a whole in a disaster-recovery event. We do not restore a backup in order to bring back data someone asked us to delete, and data in a backup awaiting rotation is not processed for any other purpose. The retention section of our Privacy Policy states the cycle.

Deletion during the term

You do not have to wait for the end of the Subscription.

• Delete a record, a file, a screenshot or a user's captured data from inside the Service at any time, and we will act on it as an instruction.
• Retention settings are an instruction too. Where Ever Works lets you set a retention period for Monitoring Data or other categories, data is deleted automatically when that period expires. The product annex gives the ceilings, the defaults and the range you can configure.
• Where you need a deletion the product's functionality does not reach — a specific data subject's data across a whole Workspace, for example — write to [email protected] and the data subject request section applies.

Where we have to keep something

We may retain Customer Personal Data where a law of the European Union or of a Member State to which we are subject requires us to. If that happens:

• we keep only what that law requires, and only for as long as it requires;
• we tell you what we are keeping and why, unless the law prohibits us from telling you;
• the data is isolated, and our processing of it is restricted to storage — we do not use it for anything else; and
• the confidentiality, security and transfer obligations in this Addendum continue to apply to it for as long as we hold it.

The Terms also allow us to retain records needed to establish, exercise or defend a legal claim, and billing and tax records for the period accounting law requires. Those retentions are ours as controller and they are described in our Privacy Policy, not here.

Certificate of deletion

On written request to [email protected], we will confirm in writing that deletion has been completed, stating what was deleted, when, and anything retained under the paragraph above with the reason for it. There is no charge for this and you do not need to explain why you want it.

Where we suspended or terminated for cause

If we terminated for unpaid fees or for a breach of the Acceptable Use Policy, the Terms allow us to withhold an export until the matter is resolved. That never affects an individual's rights under data protection law. A data subject's right to obtain a copy of their own personal data does not depend on your account being in good standing, and the deletion timetable above runs regardless.

Liability

One cap, not two

Our liability under this Addendum is governed by the limitation of liability section of the Terms. This Addendum does not create a second liability regime, and it does not sit outside the cap.

Specifically:

• the exclusions and the cap in the Terms apply to any claim arising out of or in connection with this Addendum, however the claim is framed — contract, tort including negligence, breach of statutory duty, or otherwise; and
• the cap is a single aggregate cap across the Terms and this Addendum taken together. Claims under both do not give you two caps to draw on, and a claim brought under this Addendum reduces what remains available under the Terms in the same amount.

What the cap does not touch

Nothing in this section or in the Terms excludes or limits either party's liability for:

• death or personal injury caused by negligence;
• fraud or fraudulent misrepresentation;
• gross negligence or wilful misconduct; or
• anything else that cannot lawfully be excluded or limited.

Your indemnity in the roles section is not subject to the cap, consistent with the indemnification section of the Terms. Our indemnities are subject to it, except where the law does not permit that.

If you are dealing with us as a consumer rather than for purposes related to your trade, business, craft or profession, the consumer carve-out in the Terms applies here in the same way: your mandatory statutory rights are unaffected, and a limitation that would be unfair or unenforceable against you does not apply to you.

Claims by data subjects, and Article 82

Nothing in this Addendum limits or excludes a data subject's rights, including the right to compensation under Article 82 GDPR, or either party's liability to a data subject or to a Supervisory Authority. Neither of us can contract that away and neither of us is trying to.

Where one of us pays compensation to a data subject for damage caused by processing under this Addendum, that party may claim back from the other the part of the compensation corresponding to the other's share of responsibility, as Article 82(5) provides. The cap above applies to that claim between us as it applies to any other. Nothing in this paragraph delays payment to the data subject — the apportionment between us is worked out afterwards, on the facts, and never in front of the person owed the money.

Administrative fines

Each of us bears the administrative fines imposed on it in its own right. We do not indemnify you against a fine imposed on you for your own processing — including a fine arising from monitoring you configured, a lawful basis you did not have, a notice you did not give, an impact assessment you did not carry out, or a consultation you did not hold. Those are the matters you have represented to us in the roles and instructions sections, and your indemnity there runs the other way.

No double recovery

Neither of us may recover twice for the same loss under different sections of the Terms and this Addendum.

Annex: Ever Works — sites we provision for you

Where we provision and host a directory site for you there are two distinct processing relationships, and confusing them is the commonest mistake in this arrangement.

1. The platform — you are the controller, we are the processor

Your account, your content, your team's data and the directory entries you publish. The ordinary allocation applies.

2. Your site's visitors — you are the controller, we are the processor

People who visit the site we host for you are your data subjects. You decide what it collects from them, why, and for how long. We host it and process on your instructions.

That means:

• the privacy notice on that site is yours to write and publish, not ours to supply — the site carries your brand and a visitor's relationship is with you;
• any consent banner on it is yours to configure, and you are responsible for whether it actually gates what it claims to gate;
• any analytics, forms, payments or comment tooling you add is yours — you choose those providers, contract with them, and disclose them in your own notice.

On request we will tell you exactly which parts of the stack we operate. What we cannot do is publish a notice on your behalf or make your consent choices for you.

Directory entries about identifiable people

A directory entry can describe an individual — a founder, a maintainer, a named contact — who has signed up to nothing. Where you publish such an entry:

• you are the controller for it and you are responsible for having a basis to publish it;
• the individual may object, or ask for correction or removal, and those requests are yours to answer;
• where such a request reaches us we will forward it to you and assist, but we will not decide it for you.

Termination

When provisioning ends we return or delete the site's data on the schedule in the core Addendum. We do not retain a copy to operate the site independently, and we do not transfer it to another customer.

Schedule 1 — Description of the processing

This schedule describes the processing we carry out for you. It is the description Article 28(3) GDPR requires a processor's contract to contain, and where the Standard Contractual Clauses apply, it is also Annex I to those Clauses: Part A below is the list of parties, Parts B to G are the description of the transfer, and Part I is the competent supervisory authority.

It describes the hosted Service as we deliver it generally. Two things narrow it:

• The product. Ever Works offers some of the features described below and not others. Where a feature does not exist in the product, the data it would produce is never created. The annex to this document describes Ever Works specifically.
• Your configuration. Several categories below only arise because you switched something on. We do not decide to collect them and we cannot switch them on for you.

If you have agreed a narrower or more specific description with us — in an order form, or in your own data processing agreement that we have signed — that description governs and this one fills the gaps.

A. The parties and their roles

In the language the Clauses use, you are the data exporter and we are the data importer.

You.

• Identity: the organisation named on the account or order form for the Service.
• Contact: the administrative contact registered on your account, and the notice address in the Terms.
• Activities relevant to the data: using Ever Works Cloud to run your own business — creating a workspace, inviting your people, entering and generating content, and switching product features on and off.
• Role: controller. If you are yourself processing on someone else's behalf — an employer whose workforce administration you run, a client whose recruitment or projects you handle — then your role is processor and ours is sub-processor. Nothing in this schedule changes; only the module in Schedule 3 changes, and you must have that other organisation's authority to appoint us.

Us.

• Identity: Ever Technologies LTD, registered in Bulgaria under company number 204599535, registered office Mladost 2, bl. 211, ent. A, Sofia 1799, Bulgaria.
• Contact: [email protected].
• Activities relevant to the data: operating, hosting, securing, backing up and supporting the hosted Service, and providing the features you enable within it.
• Role: processor. We act only on your documented instructions. We are not a joint controller with you for anything in this schedule.

Signature and date. Accepting this document counts as signing it, and as signing the Clauses where they apply. How that works, and how to get a countersigned copy, is in Schedule 3.

B. Categories of data subject

The people whose personal data we process for you are, depending on the product and what you use it for:

• your employees — permanent, part-time, fixed-term and probationary;
• your contractors, freelancers, consultants, agency workers and temporary staff, whether engaged directly or through an intermediary;
• your administrators and other users of your workspace, including people you have invited but who have not yet accepted;
• job applicants and candidates, including people who applied to you directly and people whose details you imported or were sent by a recruiter;
• your own clients, customers, members and the individuals who work for them — contacts, leads, correspondents, invoice recipients and the people named inside the work you do for them;
• your suppliers, vendors and partners, and the individuals who work for them;
• visitors and end users of a site, directory or workspace you operate through the Service, where the product provides one;
• people who appear incidentally in captured or uploaded material — someone who walks past a webcam, a colleague on a shared screen, a name in a document, a voice in the background of a recording. These people are usually not your users and have no relationship with us at all. They are still data subjects and the law still protects them; and
• anyone else your users choose to write about, upload or import into your workspace.

C. Categories of personal data

D. Special categories of personal data, and criminal-offence data

We do not ask for special category data and there are no fields designed to hold it. We do not infer it, we do not enrich records with it, and we do not want it in a support ticket.

It can still arrive, in two ways, and pretending otherwise would be dishonest:

• You may put it there deliberately. Workforce and recruitment records can legitimately contain health and absence information, trade union membership, or data revealing racial or ethnic origin.
• Capture picks up whatever is on the screen or in the room. A screenshot taken while a medical appointment email is open captures health data. A webcam still can reveal a religious head covering. This is a direct consequence of capturing on a timer, not a remote possibility.

The same is true of criminal-offence data under Article 10 — a background check result or a disclosure in a document.

Restrictions and safeguards applied. We treat this data with the measures in Schedule 2 applied to all customer content: encryption in transit and at rest, access restricted to the small number of our people whose work requires it and logged when used, no use for any purpose of ours, and deletion on your instruction — including deletion of an individual capture.

You remain responsible for the condition that makes it lawful. Where Article 9 or Article 10 data is realistically in scope, you must satisfy Article 9(2) or Article 10 yourself, configure the product to reduce the risk rather than accept it, and deal with what has been captured. An employee's consent rarely carries that weight on its own, because of the imbalance between an employer and an employee.

E. Nature and purpose of the processing

Nature. Collection, recording, structuring, storage, retrieval, indexing and search, display, transmission, duplication for redundancy and backup, computation and the generation of derived records such as reports and activity scores, delivery of notifications and emails you have configured, restriction, erasure and destruction.

Purpose. One purpose only: to provide, secure, maintain, support and improve the hosted Service for you, in accordance with the Terms and your documented instructions, together with anything we are required to do by law.

We do not process your data for our own purposes. We do not use it to train machine-learning models, for ourselves or for other customers, unless you have expressly opted in. We do not sell it, we do not share it for advertising, and we do not look at it except where running, securing or supporting the Service requires it.

F. Frequency of the processing

Continuous, for as long as your agreement is in force. Within that:

• most processing happens whenever your users use the Service, and whenever a feature you have enabled runs on its own schedule — a capture interval, a notification, a report;
• backups, retention jobs and integrity checks run on a fixed automated schedule;
• export, correction and deletion happen when you instruct them; and
• access by our personnel is occasional and happens only where support, security or operating the Service requires it.

G. Duration of the processing

We process your data for the term of your agreement, and then:

• for the export window after termination stated in the Terms, so that you can retrieve your data;
• for the further period it takes routine backups to age out on their own cycle, after which no copy remains; and
• for as long as we are legally required to keep something specific — an invoice, or material we have been ordered to preserve for a claim or an investigation.

During the term, you set the retention periods for the data in your workspace, within the ranges the product supports. The defaults and the configurable ranges for Ever Works are in the annex to this document. Our own retention for the records we hold as controller is in our Privacy Policy.

H. Transfers to sub-processors

• Subject matter and nature: hosting and infrastructure, storage and content delivery, email delivery, error and performance monitoring, product analytics, support tooling, and payment and billing — each processing only the data its function needs.
• Which providers, where they are, and on what transfer mechanism: the published list, which is the Annex III to the Clauses. See Schedule 5.
• Duration: for as long as the provider is engaged for the Service, and no longer than the retention periods in Part G.

I. Competent supervisory authority

Where the Clauses apply, the competent supervisory authority is determined by where you are established, not where we are:

• if you are established in an EEA member state, it is the supervisory authority of that state;
• if you are not established in the EEA but the GDPR applies to you under Article 3(2) and you have appointed a representative under Article 27, it is the supervisory authority of the member state where that representative is established; and
• if you are not established in the EEA, the GDPR applies to you under Article 3(2), and you have no Article 27 representative, it is the supervisory authority of a member state in which the data subjects concerned are located.

Our own supervisory authority is the Commission for Personal Data Protection (Комисия за защита на личните данни) (CPDP) — https://www.cpdp.bg/ — because our only establishment is in Bulgaria. It is the authority that supervises us, and the one to which we notify a personal data breach on our own account.

Nothing here stops a data subject complaining to the authority in their own country. They do not need your permission or ours.

Schedule 2 — Technical and organisational security measures

This schedule sets out the measures we have in place to protect personal data we process for you. It is the description Article 32 GDPR requires, and where the Standard Contractual Clauses apply, it is Annex II to those Clauses.

Two commitments about the schedule itself:

• Everything below describes something we actually do. Where a control is partial, or where we do not have something a reader might expect, this schedule says so rather than staying silent. A security annex that describes an aspiration is a misrepresentation, and it is the kind that surfaces at the worst possible moment.
• We may change these measures, but not downwards. Security practice moves, and a frozen list would stop us improving. Any change must maintain a level of protection at least equivalent to what is described here.

Our Security overview carries the longer version of the same material, including the shared-responsibility split. Where the two differ, this schedule governs your contract with us.

1. Where the Service runs

The Service runs primarily on hardware we own and operate ourselves, not on rented capacity in a public cloud. That shapes several of the measures below: the database, object storage, cache, secret store and build system are software we run on our own machines, so the companies that write that software never receive your data and are not sub-processors.

Physical access to that hardware is restricted to authorised personnel. Where part of the Service depends on an external provider — content delivery and edge protection, email delivery, monitoring — that provider's own physical and environmental controls apply, and our contract with it requires them. Which providers those are, and where they are, is in the published sub-processor list.

2. Encryption and pseudonymisation

• In transit. Traffic between you and the Service travels over TLS. HTTPS is enforced and plain HTTP requests are redirected rather than served. Traffic between components inside our infrastructure runs on internal networks that are not reachable from the public internet, and connections that leave that boundary — to a sub-processor, to a backup destination — are encrypted.
• At rest. Databases, the object storage that holds uploaded files and captured media, and backup copies are encrypted at rest.
• At the application layer. Passwords are stored as salted one-way hashes and are never recoverable in readable form, including by us. Credentials, API tokens and integration keys are additionally encrypted before storage rather than held in plain text.
• Secrets management. Credentials for infrastructure and services are held in a dedicated secret store and injected into running systems at start-up. They are never committed to source control. Access to the secret store is separate from access to the systems that consume the secrets.
• Pseudonymisation. Where a record does not need to identify a person to serve its purpose, it does not — usage statistics are aggregated, and where we log an IP address for a security or acceptance record we store it hashed rather than raw. This is a technique we apply where it works, not a blanket claim: most of what you put into the Service has to stay identifiable to be useful to you.

3. Confidentiality — who can reach your data

• Individual named accounts. Every person with access to production systems has their own account. There are no shared logins and no shared administrative credentials.
• Multi-factor authentication is required for access to production systems and to the code and configuration repositories that control them.
• Least privilege. Access is granted at the narrowest scope that allows the work, is reviewed when a role changes, and is removed when someone leaves or no longer needs it.
• Administrative interfaces are not publicly reachable. Databases, storage back-ends, internal services and management consoles sit on segmented internal networks behind authentication, not on the open internet.
• Access to customer content is exceptional. Our people do not browse your workspace. Access happens where it is needed to investigate a fault you have reported, to respond to a security incident, or to carry out an instruction you have given us — and it is logged.
• Tenant separation. Each customer's data is logically separated, and the application enforces that separation on every request rather than relying on a query being written correctly. Some products go further and give each customer its own database; the annex says which.
• Confidentiality obligations. Everyone with access is bound by written confidentiality obligations that continue after their engagement ends. This is stated as a commitment in the confidentiality section of this document, and it is a condition of having access at all.

4. Integrity — controlling what changes

This is the area where our practice is stronger than a small operator's usually is, so it is worth being specific.

• Infrastructure and application configuration live in version control. Changes are made by committing to a repository, not by typing commands at a live system.
• An automated deployment system applies those changes and then keeps applying them. It continuously compares the running state against the repository and reverts anything that has drifted, which means an undocumented manual change to production does not survive. Every change therefore has an author, a timestamp, a reviewable diff and a route back.
• Code review and automated analysis. Changes to application code are reviewed before they ship. Automated static analysis, dependency vulnerability scanning and secret scanning run in the build pipeline, and builds run on infrastructure we control.
• Change records. Changes to production infrastructure are recorded in a written change log, including what changed, how it was verified, and how to reverse it.

5. Availability and resilience

• Components that can run on more than one machine do run on more than one machine, so the loss of a single machine does not take the Service down.
• Storage is replicated across several machines, and the database runs as a cluster with automated failover to a standby.
• Infrastructure and application health, capacity and error rates are monitored continuously, with alerts routed to a monitored channel.
• Availability monitoring includes a dead man's switch, so a failure of the monitoring itself raises an alarm instead of producing reassuring silence.

6. Restoring availability — backups

• Backups run automatically on a schedule, and databases additionally archive their transaction logs continuously, so a recovery point is measured in minutes rather than in a day.
• Backup copies are held on infrastructure separate from the live systems, and a further copy is held at an off-site destination, so that a single failure — including a failure of a whole site — does not take the live data and the backups together.
• Restores are tested. An untested backup is a guess.
• Backups age out on the rolling cycle described in the retention section of our Privacy Policy. They are not a second archive and they are not used to bring back data that someone asked us to delete.

7. Logging, detection and incident response

• Administrative actions, authentication events and other security-relevant events are logged, and the logs are retained for the period stated in our Privacy Policy.
• Alerts are raised on anomalous conditions rather than logs being left to be read later.
• We operate a documented incident response process: contain, assess, fix, notify, then record what happened and what changed as a result.
• If a personal data breach affects data we process for you, we tell you — without undue delay after becoming aware of it, on the terms in the personal data breach section of this document. That section governs the timing and the content of the notification; this schedule does not change it.
• We operate a responsible disclosure route so that anyone who finds a weakness can report it to us. It is described on our Security overview.

8. Data minimisation, accuracy, retention and deletion

• The Service collects what a feature needs to work. Features that capture more — screen, camera, audio, location — are separate settings that you switch on deliberately, and each can be switched off independently.
• You can correct or delete records directly in the product, which is normally faster than asking us.
• Retention periods for data in your workspace are configurable within the ranges the product supports, and expired data is deleted by an automated job rather than accumulating until someone remembers.
• Deletion is applied to live systems immediately. Backup copies are not individually edited — that would defeat the purpose of a backup — so a deleted record persists in backups until that backup ages out, and during that window it is not used for anything.

9. Portability and getting your data out

You can export your data in structured, commonly used, machine-readable formats through the product and its interfaces, at any time during the term and during the export window after it ends. You do not need our help or our permission to do it, and there is no charge for a standard export.

10. Our people

We are a small team, and the honest description of our personnel security is that it depends on a short access list rather than on a large compliance apparatus.

• Access to production is limited to the people whose work requires it, and the list is short enough to be reviewed by name.
• Everyone with access is bound by written confidentiality obligations that outlast their engagement, and is briefed on the obligations in this document before being given access.
• Operating rules for production work are written down, and a change that is not recorded is treated as a fault in its own right.
• Access is revoked when a role changes or an engagement ends.

11. Providers we engage

• We assess a provider's security and data protection position before engaging it.
• We contract with it under Article 28 GDPR, on obligations at least as protective as the ones we owe you.
• We put a transfer mechanism in place where it is established outside the EEA — see Schedule 3.
• We publish who they are, what they do and where they are, and we distinguish providers that are always engaged from ones that only exist because you switched a feature on — see Schedule 5.

12. Your side of the line

Some of the controls that protect your data are ours to operate and some are yours. We cannot operate these for you:

• choosing who to invite to your workspace, what role to give them, and removing them promptly when they leave;
• enforcing multi-factor authentication on your users, and keeping your own credentials and API tokens secret;
• deciding which capture and monitoring features to enable, at what frequency, and for how long the results are kept;
• deciding what to put into the Service in the first place, including whether it needs to contain special-category data at all; and
• keeping the devices your people use patched and under your control.

13. What we do not claim

We do not hold a SOC 2 report, we are not certified to ISO/IEC 27001, and we do not claim either. We do not publish a third-party audit report or an independent penetration test report, because we do not currently have one. If anything you have been told or shown suggests otherwise, it is wrong, and we would like to know where it came from.

Where we adopt a recognised framework as a reference for how we work, we say that we use it as a reference. We never describe that as a certification. If we obtain one, this schedule will say so, and it will name the auditor and the scope rather than displaying a logo.

No system is perfectly secure, ours included. What is written above is what we do about it.

Schedule 3 — Transfer mechanism

This schedule explains when personal data crosses a border, what legal mechanism covers it, and — where the Standard Contractual Clauses apply — exactly which module and which options we have chosen. Vendors usually leave this to be guessed at. Guessing is what makes a transfer unlawful.

"The Clauses" means the standard contractual clauses approved by the European Commission in Implementing Decision (EU) 2021/914 of 4 June 2021, in their approved form.

1. Start here: most of this involves no transfer at all

We are established in Bulgaria, inside the European Union. Customer personal data is stored on infrastructure we operate ourselves, inside the European Economic Area, and processed there. Sending your data to us is therefore not normally a restricted transfer, and no transfer mechanism is needed for it.

Where a provider we have engaged stores, routes or caches data somewhere else, the destination country is named against that provider on the published sub-processor list, together with the mechanism relied on. Anything specific to Ever Works — a storage location, a regional endpoint, a feature that sends data somewhere the rest of the Service does not — is recorded in the annex to this document.

The transfer question arises in three narrower places, and those are what the rest of this schedule is about:

• Onward to a provider outside the EEA. Some of the providers we engage are established outside the EEA, principally in the United States, or route or store data outside it. Here we are the exporter.
• Back to you, where you are established outside the EEA. When your users open their workspace from a country outside the EEA, or you export your data there, personal data leaves the EEA to reach you.
• Where your own law treats the flow as restricted — the United Kingdom and Switzerland have their own regimes, dealt with in Schedule 4.

2. Mechanisms, in the order we rely on them

• Adequacy first. Where the European Commission has decided that the destination country provides an adequate level of protection, the transfer relies on that decision. Adequacy is kept under review by the Commission and can be amended, suspended or repealed, so we monitor decisions rather than treat them as permanent, and we keep a second mechanism standing behind them.
• The Clauses as the standing mechanism. For any destination without an adequacy decision, and as a fallback behind every adequacy decision we rely on, the Clauses apply. They are incorporated into this document and take effect automatically to the extent a transfer is restricted, with no separate document to sign and nothing for you to request.
• The EU–US Data Privacy Framework, only where it is real. We rely on the Framework for a United States provider only where that provider is actively self-certified for the type of data concerned, and we keep the Clauses in place alongside it rather than instead of it. The reasoning, and the state of the litigation behind it, is in the international transfers section of this document.
• Derogations, rarely. We rely on an Article 49 derogation only for a specific, occasional transfer where no other mechanism fits. It is not how we run a regular data flow.

3. Which module applies

Module One does not apply. This document governs processing we carry out for you; where we act as a controller in our own right, our Privacy Policy governs and the transfers are described there.

Where more than one row is true at once — you are a processor for a client and you are outside the EEA — each applies to the flow it describes.

4. How we have completed the optional parts of the Clauses

The Clauses leave several choices to the parties. Ours are fixed here so that no one has to negotiate them or, worse, assume them.

5. Where the annexes to the Clauses live

The Clauses require three annexes. Rather than repeat their content in a fourth place where it can drift, they map onto this document:

6. Signature

Accepting this document is your signature on the Clauses, and our acceptance of your subscription is ours. There is no separate signing ceremony and you do not have to ask for one.

If your own compliance process needs a countersigned copy on paper or as a signed file, write to [email protected] naming the entity and the modules you need, and we will provide one. We will not condition that on a fee, an NDA, or a minimum contract value. A transfer mechanism you cannot evidence is not much use to you.

7. Transfer impact assessment, and what happens if a government asks

The assessment and the supplementary measures are described in the international transfers section of this document, which governs. What belongs in the transfer annex is the operative part — what actually happens when an authority asks.

We require every provider outside the EEA, and we commit to you ourselves, that on receiving a legally binding request from a public authority for personal data processed under this document:

• we tell you, unless we are legally prohibited from doing so — in which case we use reasonable efforts to obtain a waiver of the prohibition, and we record what we did;
• we challenge the request where there are reasonable grounds to consider it unlawful under the law of the requesting country or under international law, and we pursue available appeals; and
• we disclose the minimum the request actually compels, and never more because it was easier.

We do not give any authority direct, unsupervised or blanket access to systems holding your data, and we have not built a mechanism for one.

8. Data subjects can enforce this

Under the Clauses, the individuals whose data is transferred are third-party beneficiaries. They can enforce the relevant clauses against us directly, and they do not need your permission or ours to do it. That is a feature of the mechanism, not an oversight, and we are not going to describe it as a formality.

9. If this schedule conflicts with something else

To the extent the Clauses conflict with this document, the Terms, or any other agreement between us, the Clauses prevail for the transfer they cover. Nothing we agree with you reduces the protection the Clauses give a data subject.

Country-specific additions — the United Kingdom and Switzerland — are in Schedule 4, and they modify the Clauses only for the transfers those regimes govern.

Schedule 4 — Jurisdiction-specific terms

Data protection law is not one law. The rest of this document is written to the GDPR, which is the frame that fits most of our customers. This schedule adds the terms that apply where a different or additional regime governs your processing.

How to read it. Each part below applies only where, and only to the extent that, the law it names applies to the processing we carry out for you. The parts add to the rest of this document; they do not replace it. Where two parts are relevant at once — you are a UK company with Swiss staff — each applies to the flow it governs.

A. European Economic Area — the GDPR

This is the default frame for the whole document, so this part records only what is specific.

Meanings. Words defined in the GDPR — controller, processor, personal data, processing, personal data breach, supervisory authority — carry their GDPR meanings throughout this document.

Our establishment and our authority. Our only establishment is in Bulgaria, inside the European Union. Our supervisory authority is the Commission for Personal Data Protection (Комисия за защита на личните данни) (CPDP) — https://www.cpdp.bg/. Because we are established inside the Union, we do not need and have not appointed a representative under Article 27 GDPR, and we will not present a contact address as one.

Records of processing. We maintain the record of processing activities Article 30(2) requires, covering the categories of processing we carry out for our customers. We will make the parts relevant to you available on request under the audit and information section of this document.

Instructions required by law. If Union or member state law requires us to process your data in a way your instructions do not cover, we will tell you what the requirement is before we act on it — unless that same law prohibits us from telling you on important grounds of public interest.

A2. National employment law inside the EEA — your obligation, not ours

Where you use the Service to record, measure or capture what your workers do, the GDPR is only half the question. Article 88 GDPR leaves employment-context processing to national law, and national law diverges sharply. We make no claim that workplace monitoring is lawful across the European Union, because it is not.

You are the controller for that processing, and complying with the law of each country where your monitored people work is your responsibility. The obligations that most often catch employers are:

• Co-determination and works council consent. In Germany, a works council has a binding co-determination right over any technical system capable of monitoring behaviour or performance, whatever the stated purpose, and a deployment without an agreement is legally void. In Austria, monitoring measures that touch human dignity require works council consent that cannot be substituted by a court or an arbitration board; where there is no works council, each affected employee must agree individually. In the Netherlands, the works council has prior consent rights over systems for monitoring behaviour or performance.
• Prior agreement with unions or an authority. In Italy, equipment from which remote monitoring of workers may derive requires a prior union agreement or authorisation from the labour inspectorate before installation.
• Co-operation procedures. In Finland, the purposes and methods of technical monitoring must go through co-operation negotiations with employee representatives before introduction, and the employer is limited to information directly relevant to the employment relationship.
• Express prior notice. In Spain, monitoring must be notified expressly, clearly and in advance, and must respect a minimum standard of privacy.
• Outright restriction. In Portugal, the Labour Code forbids an employer from using remote surveillance to supervise a worker's professional performance, with only a narrow carve-out for protecting people and property. Productivity-purpose screen capture should be treated as unavailable there. In France, the supervisory authority has held keylogging software on employees' machines unlawful absent a very strong specific justification, and rules out permanent screen sharing and periodic photographs of the worker.
• Prior consultation. Where a data protection impact assessment leaves a high residual risk, several authorities require prior consultation with them before monitoring starts, not after.

This list is illustrative, it is not advice, and it will go out of date. It is here because a customer switching on screen capture across several countries needs to know that one configuration is not lawful everywhere. The representations you give us about monitoring are in the Terms and in the product annex; this part explains what stands behind them.

B. United Kingdom

Where it applies. This part applies where your processing is governed by the UK GDPR and the Data Protection Act 2018.

Meanings. References in this document to the GDPR are read as references to the UK GDPR, references to a supervisory authority are read as references to the Information Commissioner, and references to member state law are read as references to the law of the United Kingdom.

Sending data to us is not normally a restricted transfer. The United Kingdom recognises the EEA as providing an adequate level of protection, so your data reaching our infrastructure inside the EEA does not need a transfer mechanism. That recognition is kept under review, which is why the mechanism below stands behind it rather than instead of it.

Restricted transfers out of the United Kingdom. Where a transfer under this document is restricted by the UK GDPR — principally our onward transfer to a provider outside the United Kingdom — the Clauses apply as varied by the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses (version B.1.0) issued by the Information Commissioner, which is incorporated into this document and completed as follows:

Where you require the International Data Transfer Agreement rather than the Addendum, write to [email protected] and we will enter into it instead for the transfers it covers.

A UK representative. We have not appointed a representative under Article 27 UK GDPR. Where we handle personal data about people in the United Kingdom, we do it as your processor, in the course of providing a service to you — not by offering services to those individuals ourselves and not by monitoring their behaviour for our own purposes. That is our assessment, and we keep it under review. If it changes we will appoint a representative and say so here, rather than leaving the position to be inferred.

C. Switzerland

Where it applies. This part applies where your processing is governed by the Swiss Federal Act on Data Protection.

Meanings. References in this document to the GDPR are read as references to the Federal Act on Data Protection where that Act governs, and references to a supervisory authority are read as references to the Federal Data Protection and Information Commissioner.

Sending data to us is not normally a restricted transfer. Switzerland recognises the EEA as providing adequate protection, so your data reaching our infrastructure inside the EEA does not need a transfer mechanism.

Where a transfer is restricted, the Clauses apply with the adaptations the Federal Data Protection and Information Commissioner recognises:

• the competent supervisory authority for a transfer governed by the Federal Act on Data Protection is the Federal Data Protection and Information Commissioner;
• references to a member state must not be read so as to stop a data subject resident in Switzerland bringing proceedings at their place of residence; and
• for as long as Swiss law protects the data of legal entities as well as individuals, "personal data" in the Clauses and in this document includes data about legal entities where Swiss law governs.

A Swiss representative. We have not appointed a representative in Switzerland. Our assessment, and our commitment to keep it under review, is the same as for the United Kingdom above.

D. If you are somewhere else

We have written this document to the three regimes above because they are the ones our customers are actually subject to. Nothing in it says that your own country's law does not apply to you — if it does, it does, and this document does not displace it.

Two practical consequences:

• Local requirements are yours to identify. Notice rules for electronic monitoring, sector rules, data localisation, and anything else your regulator imposes on you as controller.
• We will meet you part of the way. If your law requires specific contractual terms of a processor, write to [email protected] with the requirement and we will tell you plainly whether we can agree to it. Where we can, we will put it in a country addendum. Where we cannot, we will say so and explain why, rather than signing something we cannot actually perform.

Schedule 5 — Sub-processors

The list of sub-processors we engage for the hosted Service is published and maintained in one place:

https://ever.works/subprocessors

That page is incorporated into this document by reference, and where the Standard Contractual Clauses apply it is Annex III to those Clauses.

Why this schedule points at the list instead of copying it

Because a copy would be wrong. A list frozen into a versioned legal document is out of date the first time a provider changes, and then there are two versions of the truth with no way for you to tell which one governs. The stale copy is the one that ends up quoted in a dispute.

Incorporating by reference is not a way of avoiding the commitment. It comes with three things that a printed annex does not give you, all of them below: advance notice before the list changes, an archived and checksummed history so you can prove what it said on any past date, and a single page that is always current.

What the published list tells you, provider by provider

• the provider's legal name and the country it is established in;
• what it does for us — the service, not a vague category;
• the processing it carries out and the categories of personal data involved;
• where the data is stored or routed;
• the transfer mechanism, where the provider is outside the EEA, and whether we are relying on an adequacy decision or on the Clauses; and
• which tier it sits in.

The three tiers, and why the difference is not cosmetic

• Always engaged. The providers in the delivery path of the hosted Service for every customer. These are the sub-processors in the Article 28 sense, and they are what this schedule is really about.
• Engaged only if you turn something on. Optional integrations, connectors and features. A provider in this tier is engaged the moment you or your administrator enables the specific feature or connects the specific account, and never before. The list says which setting activates each one, so you can check what your own configuration has switched on.
• Self-hosted deployments only. Several of our products are published as open source and can be run on your own infrastructure. If you do that, you choose the database, object storage, email relay, AI provider and everything else, with your own credentials and your own contracts. Those providers appear on the list so you can see what the software can be pointed at — they are yours, not ours. We process nothing in a deployment you run, we are not your processor for it, and nothing in this document describes it.

Collapsing these into one list would be simultaneously inaccurate and self-incriminating, which is why we do not.

Your authorisation

You give us a general written authorisation to engage sub-processors, under Article 28(2) GDPR and Option 2 of Clause 9 of the Clauses. We may engage the providers on the published list, and add or replace one on the notice terms below.

We stay responsible for them. Where a sub-processor fails to meet its data protection obligations, we remain fully liable to you for the performance of those obligations. Engaging a provider does not move the obligation off us and onto them, and this schedule does not let us point at a supplier when something goes wrong.

Every sub-processor is engaged under a written contract imposing data protection obligations at least as protective as the ones we owe you, with the transfer mechanism in Schedule 3 where it is established outside the EEA.

Notice before the list changes

We give you at least 30 days' notice before a new or replacement sub-processor starts processing your data. The full procedure — how notice is given, how to object, on what grounds, and what happens if we cannot resolve your objection — is in the sub-processing section of this document, and it governs. This schedule adds only the practical part:

• To be told directly, subscribe. Email [email protected] asking to be added to the sub-processor change notifications, with the address you want them sent to. Watching the page is not a substitute and we are not going to pretend it is.
• The page carries a dated change log, so a change is visible there as well as in your inbox.

Proving what the list said on a given date

Every published version of the list is archived with its date and a checksum of its contents. That means you can establish which providers were engaged on any past date — the question that actually gets asked during an audit, a breach investigation or a due diligence exercise, and the one a live page on its own cannot answer.

If you need a dated extract, signed by us and attached to your copy of this document, write to [email protected] and ask. There is no charge.

What is deliberately not on the list

• Software we run ourselves. Our database, object storage, cache, secret store, content management and build systems are open-source software running on our own hardware. The organisations that publish that software never receive your data, so they are not sub-processors and listing them would be padding that obscures the providers who do matter.
• Companies in our own group. No company in our group is engaged as a sub-processor for the hosted Service. The group section of the published list is empty because that is true, not because it was left out. If that ever changes, the entry appears on the list with the same 30 days' notice as any other, and it will name the entity, the country and the transfer mechanism.
• Your own integrations. Where you connect the Service to a system you have chosen — your own storage, your own email relay, your own AI provider, a third-party application through its API — that provider is acting for you, not for us. We tell you what leaves and where it goes; we do not become its controller or its processor by passing data along the connection you configured.

How to contact us about this addendum

This Data Processing Addendum is with Ever Technologies LTD, registered in Bulgaria under company number 204599535, with its registered office at Mladost 2, bl. 211, ent. A, Sofia 1799, Bulgaria.

• Data protection questions, data subject requests, sub-processor change notifications, and anything about how we handle personal data — [email protected]
• Signed or countersigned copies of this addendum and the Standard Contractual Clauses, audit requests, country addenda, and formal notices under this addendum — [email protected]
• Security incidents and anything you think has been compromised — tell us immediately — [email protected]

By post, write to the registered office above. We correspond in English.

The address we will use to reach you

If a personal data breach affects data we process for you, we notify the administrative contact on your account. Keep that address current, and make sure it goes somewhere a person reads promptly rather than to an individual who has left. If you would rather we used a dedicated security or privacy address, tell us at [email protected] and we will record it against your account.

We have not designated a Data Protection Officer

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

We would rather tell you that plainly than let a mailbox name imply an appointment that does not exist — including in a procurement questionnaire, where the honest answer is the one above.

If we do not resolve something

Come to us first: [email protected], and if that does not work, [email protected]. We would rather fix a problem than read about it from a regulator.

If we still have not resolved it, you can complain to the supervisory authority for the country where you are established. Our own authority is the Commission for Personal Data Protection (Комисия за защита на личните данни) (CPDP) — https://www.cpdp.bg/. A data subject can complain to the authority in their own country as well, and neither of us can require them to come through us first.

This document is version 1.0.0 of the Data Processing Addendum for ever.works, in force from 2026-08-02. Earlier versions, with the dates they applied, are at https://ever.works/dpa.