Security overview

This page describes how we protect the Ever website and the data you keep in it. It is written to be checked rather than admired: every measure below is something we actually run, and where we do not do something that a page like this usually claims, we say so instead of leaving a gap you have to guess at.

The short version:

• We run the Service on hardware we own and operate ourselves, not as a tenant in someone else's cloud. The database, the object storage and the secrets store are ours. That is why the list of providers with access to your data is short.
• Traffic is encrypted in transit, storage is encrypted at rest, and off-site backup copies are encrypted before they leave our network, so the provider holding them holds ciphertext.
• Production changes go through version control and review. Hand edits on live systems are the exception, not the routine.
• We hold no security certification, and we do not claim one. The next section says exactly what we do instead.

What this page covers

It covers the hosted Service we operate at ever.co — the application, its interfaces, and the infrastructure underneath them.

It does not cover two things that are easy to confuse with it:

• A copy of the software you run yourself. Where our software is published as open source and you deploy it on your own infrastructure, you are the operator. You choose its hosting, its storage and every other component, we have no access to it, and nothing on this page describes it.
• Your own systems and your own configuration. Which of your people have access, how you configure the product, what you connect it to and how you secure the devices your team uses are yours. The shared responsibility section near the end of this page sets out that split in detail, because most real incidents happen on one side of that line rather than in the middle of it.

What this page is, legally

This is a factual description of the measures in place at the version and date shown at the end. It is not a warranty, and it does not create a service level commitment. Our contractual security obligations are in our Data Processing Addendum and in the Terms of Service, and those are the documents that bind us.

We change these measures as the systems and the threats change. We will not make a change that materially reduces the protection described here, and when the description changes we republish this page with a new version and date.

One thing we will not tell you

No system is perfectly secure, and a vendor who tells you otherwise is selling something. Everything below reduces risk; none of it eliminates it. What we can commit to is that we take these measures seriously, that we test the ones that can be tested, and that when something goes wrong we tell you rather than manage the news.

Certifications — what we hold, and what we do not

We do not hold a SOC 2 report of any type. We are not certified to ISO/IEC 27001. We hold no other security certification or attestation, and we do not claim one.

We are stating that first, in plain words, because a security page that leaves the question open is doing so on purpose. If a proposal, a sales conversation, a questionnaire response, a directory listing or a third-party summary has told you that we are SOC 2 or ISO 27001 certified, it is wrong — please send it to [email protected] so we can get it corrected at the source.

What we do instead

We use two published control sets as a working checklist rather than as a badge:

• The control areas of ISO/IEC 27001 Annex A — access control, cryptography, operations security, supplier relationships, incident management, continuity — as the structure for reviewing our own practices. This page is organised broadly along those lines.
• Article 32 GDPR, which is not optional for us and is the standard our customers can actually hold us to: technical and organisational measures appropriate to the risk, kept under review as the risk changes.

No external auditor has examined either. These are self-assessments, and you should read them as such. An unaudited framework alignment and a certification are different things, and we will not blur the two by writing "aligned with" in a way that reads like "certified to".

What you can have instead of a certificate

A certificate is a proxy for evidence. Where we cannot give you the proxy, we will give you the evidence:

• This page, which is specific enough to be checked against what we actually do.
• The security measures schedule in our Data Processing Addendum, which is contractual rather than descriptive — if a measure matters to you, that is where to pin it down.
• A completed security questionnaire. Send yours to [email protected]. We answer them, we answer them honestly, and where the honest answer is "no" you will get "no" rather than a paragraph that avoids the question.
• Evidence on request for specific points — a description of the architecture, the outcome of our most recent restore test, the current sub-processor list, the transfer mechanism for a named provider.
• A right to audit, on the terms set out in the Data Processing Addendum.

If that changes

If we obtain a certification or an independent report, this page will say which one, who issued it, what its scope covers and what it excludes — because the scope is the part that matters and the part most often left out. Until that day, the sentence at the top of this section is the whole answer.

Encryption

In transit

All traffic between you and the Service travels over TLS. HTTPS is enforced and plain HTTP requests are redirected rather than served, so a request that arrives unencrypted never reaches the application with its contents intact. We keep the accepted protocol versions and cipher suites current and retire weak ones as the ecosystem does.

Traffic between our own sites, and between our infrastructure and the edge network in front of it, runs over encrypted connections. Traffic to the providers we engage runs over TLS to their published endpoints.

At rest

• Storage holding customer content, databases and backups is encrypted at rest. That protects against the loss, theft or improper disposal of physical media — it does not protect against a compromise of a running system that already has the data decrypted, and we would rather you knew which threat it answers.
• Off-site backup copies are encrypted before they leave our network, with keys we hold and manage ourselves. The provider storing those copies holds ciphertext and nothing else: it cannot read them, and neither can anyone who obtains them from it.

At the application layer

Some values are too sensitive to rely on storage-level encryption alone, so they are encrypted again inside the application before they are written:

• Credentials, access tokens and API keys — including tokens you grant us for a third-party integration.
• Secrets used to operate the Service — held in a secrets manager we run ourselves, injected into workloads at runtime, and never committed to source control.

Passwords are never stored in a form we can read. They are put through a modern one-way hashing function with a per-password salt. We cannot recover your password, tell you what it is, or send it back to you — a reset is the only route, and any service that offers you the alternative is storing it wrongly.

Where a specific product stores a particular credential differently from the description above, its annex to this page says so and says why. We would rather publish an awkward exception than a tidy sentence that is not true everywhere.

Keys

Encryption keys are held in our self-hosted secrets manager, separately from the data they protect, and are accessible only to the systems and people that need them. Keys are rotated when a person with access leaves, when we have reason to think a key has been exposed, and on a periodic schedule. The keys for off-site backups are held independently of the infrastructure they protect, so that losing a site does not also lose the ability to decrypt its backups.

Access control

Your access to your own data

Access inside your workspace is yours to configure. The Service gives you named user accounts, roles and permissions, workspace administrators who can invite and remove people, and session controls. Where a product supports single sign-on, multi-factor authentication or IP restrictions, its annex says so and its documentation says how to switch them on.

Turning those controls on, and reviewing who still needs access, is your job — see the shared responsibility section. The most common way an account is compromised is not a flaw in our systems; it is a shared password, a former employee who was never removed, or an integration token that outlived its purpose.

Our access to production systems

• Named individual accounts, never shared logins. Every action in production is attributable to a person.
• Multi-factor authentication on the systems and administrative accounts that support it.
• Least privilege. Access is scoped to the narrowest role that lets the work happen, and elevated access is granted for a purpose rather than held permanently by default.
• Changes go through Git. The configuration of the live environment is held in version control and applied automatically, so a change is reviewable, attributable and reversible. Direct hands-on changes to a running system are an exception for incidents and hands-on maintenance, not the daily routine — and the automation reverts undeclared edits rather than leaving them in place.
• Removal on departure or role change. Access is revoked when someone leaves or no longer needs it, and credentials they held are rotated. Access is reviewed periodically as well, because revocation lists rot.

Access to your content

We access the content in your workspace only where it is necessary to operate, secure or support the Service — for example to investigate a fault you have reported, or to respond to a security incident. We do not browse customer content, and we do not use it to build products, train models or produce insights for anyone else.

Support access is granted for the task in hand and logged. Where a product offers a mechanism for you to grant or revoke support access yourself, its annex describes it.

Being honest about the limits

We are a small team, and several of us hold administrative access because operating this infrastructure requires it. A large organisation would separate the person who approves a change from the person who makes it; at our size that separation is partial, and we are not going to describe it as complete. What we do instead is make every change visible: production state comes from version control, actions are attributable to named accounts, and administrative events are logged and monitored.

Infrastructure and hosting

We run our own infrastructure

The Service does not run in a rented public cloud account. It runs on physical servers we own, in facilities we control, inside the European Union, on a virtualisation and container platform we operate ourselves. The database, the object storage, the message and cache layers, the secrets store and the deployment system are all components we run — not managed services bought from a third party.

That is an unusual answer in this market, and it has a direct consequence you can verify: the list of providers with access to your data is short. Most of what would otherwise be a sub-processor is simply a service we operate.

In outline, and deliberately without the detail that would help someone attack it:

• Hardware and virtualisation we own, clustered so that losing a machine does not lose a service.
• A container orchestration platform running the applications, with the control plane replicated across multiple machines.
• PostgreSQL, run by an operator that handles replication, failover and continuous archiving of the write-ahead log.
• S3-compatible object storage we host, for files and media, with data replicated across nodes.
• A secrets manager we host, from which credentials are injected into workloads at runtime.
• Declarative configuration held in Git and applied automatically, so the live environment matches a reviewed commit rather than an accumulation of manual changes.

A content delivery and security network sits in front of all of it, and our source code, build pipeline and container registry are hosted with a third-party provider. Those are genuine third parties even though the infrastructure behind them is ours, and they are named on our sub-processor page.

Redundancy and failure domains

Services that can run on more than one machine run on more than one machine. Databases are replicated, object storage is replicated across nodes, and the systems that hold backups run on a physically separate cluster from the systems they protect — so a failure that takes out the live environment does not take its backups with it.

This is not the same as multi-region redundancy, and we will not describe it as such. We can lose machines without losing data or availability. A whole-site failure means recovering from off-site copies, which is a matter of hours rather than seconds. The continuity section is specific about what that means.

Separation between customers

Isolation between customers is logical, not physical, unless you have separately contracted for a dedicated deployment. Depending on the product that means a separate database per customer, a separate namespace and deployment per customer site, or tenant scoping enforced in the application and the data model. Your product's annex states which model applies to you — it is a question worth asking of any vendor, and worth a straight answer.

Separation between environments

Development, staging and production are separate environments with separate credentials and separate data stores. Production credentials are not available in development or staging, and we do not copy production data into a development environment. Test data is synthetic or anonymised.

Third-party managed services, where they are used

A small number of products use a third-party managed database, managed storage or hosted platform for a specific function rather than our own. Where that is the case it is named in that product's annex and it appears in the always-engaged tier of the sub-processor list. We do not describe the estate as fully self-hosted where a product's data actually sits somewhere else.

Network security

At the edge

Every request to the Service passes through a content delivery and security network before it reaches us. That layer terminates TLS, absorbs volumetric denial-of-service traffic, applies a web application firewall and filters automated abuse. It also means the address of our origin infrastructure is not the address your browser connects to.

The origin is not exposed

Our application servers do not publish inbound ports to the public internet. Traffic reaches them through outbound-initiated tunnels established from inside our network to the edge, so there is no public listener to scan, and no direct path from the internet to an origin host.

Inside the network

• Databases, object storage, the secrets manager and internal services sit on segmented private networks and are not reachable from the internet. They accept connections only from the workloads that need them.
• Administrative interfaces are not published publicly. Reaching them requires being on the internal network, through a controlled route with authenticated access.
• Outbound connectivity from workloads is limited to what the workload actually needs, so a compromised component has fewer places to send data and fewer places to fetch a second stage from.

Abuse and automation

Sign-up, sign-in, password reset and contact endpoints are protected against automated abuse by rate limiting and by a bot-detection challenge. That challenge is strictly necessary to keep the Service working and available — it protects accounts from credential-stuffing and forms from bulk abuse — which is why it runs without a consent prompt, as explained in our Cookie Policy. It is not used for analytics, profiling or advertising.

What we monitor for

Unusual authentication patterns, unexpected administrative activity, sudden changes in traffic shape and failures of the components above raise alerts that a person sees. The logging and monitoring section describes what is recorded and for how long.

Application security

How a change reaches production

Every change to the Service starts as a change to source code in version control and follows the same route:

1. A pull request, reviewed by someone other than its author on the branches that matter.
2. Automated checks — build, tests, static analysis and dependency scanning — which must pass.
3. Promotion through environments. Changes move development to staging to production, in that order. Production is deployed from the release branch and from nothing else.
4. A container image built by the pipeline from a reviewed commit, identified by its digest, deployed by the same automation that holds the environment's configuration in Git.

Nobody edits production by hand as a way of shipping a change. The deployment system reconciles the live environment against the version-controlled definition, so an undeclared edit is reverted rather than quietly kept.

Automated checks on every change

• Dependency scanning, with alerts for known vulnerabilities in the packages we use, and updates applied on a defined schedule with a faster path for serious issues.
• Static analysis of our source code, run on each change, flagging the classes of defect it can find before the code ships.
• Secret scanning across our repositories, with pushes blocked where a credential is detected. Where a credential has been exposed, we treat rotating it at the provider as the fix — deleting it from the code is not the fix.
• Automated tests, which have to pass before a change can be merged or released.

Dependencies are installed through an internal package cache we run, which gives us a consistent, auditable view of what actually went into a build.

In the application itself

• Database access goes through parameterised queries and a mapping layer rather than assembled strings.
• Output is encoded for its context, and state-changing requests are protected against cross-site request forgery.
• Authentication, session handling and password storage use established libraries rather than anything we invented; passwords are hashed as described in the encryption section.
• Authorisation is enforced on the server for every request. A hidden control in the interface is not an access control.
• Input is validated at the boundary, and uploads are constrained by type and size.
• Browser-facing responses carry security headers, including a content security policy on the surfaces where one can be applied without breaking the product.

The honest limit

Automated tooling finds categories of defect, not all defects. Review catches more, and neither catches everything. That is why the sections on logging, incident response and responsible disclosure exist: they are what we rely on for the bugs that get through, and something always gets through.

Testing

What we test, and how often

• Automated test suites run on every change, in the pipeline, before anything can be merged or released.
• Static analysis and dependency scanning run on every change as well, as described in the previous section.
• Restore tests. We restore backups into a scratch environment and check the result against the source rather than assuming a backup that completed is a backup that works. This is the test most often skipped in the industry and the one most often needed.
• Manual review of changes that touch authentication, authorisation, payment flows, data export or the handling of credentials — the areas where an automated check is least likely to notice that the logic is wrong.
• Configuration review of the version-controlled definition of the live environment, which is where a surprising share of real exposure lives.

Penetration testing — what we do not have

We have not commissioned an independent penetration test of the hosted Service, and we do not claim one. There is no test report for us to send you, and any summary suggesting otherwise is not ours.

We would rather write that sentence than the usual formulation about "regular security assessments" that turns out on inspection to mean an automated scanner. When we do commission a test, this page will say who performed it, when, what was in scope and what was excluded.

Testing the Service yourself

You may not run security testing against the Service without our written agreement — automated scanning, load testing, fuzzing and exploitation attempts included. From our side an unannounced scan is indistinguishable from an attack, and it will be handled as one.

If you want to test, we will usually say yes. Write to [email protected] and we will agree the scope, the window, the accounts you use and how findings are reported. The conditions are the obvious ones: your own test data only, no other customer's data touched, nothing that degrades the Service for anyone else, and findings to us before they go anywhere else.

If you have already found something without meaning to, do not test further — go straight to the responsible disclosure section, which is written for exactly that situation and offers you protection for it.

Logging and monitoring

What we record

• Authentication events — sign-in, sign-out, failed attempts, password and multi-factor changes.
• Administrative and security-relevant events — permission changes, invitations and removals, token creation and revocation, changes to workspace settings, access to production systems.
• Application programming interface access — the request, its source, its outcome and its timing.
• Infrastructure and platform events — deployments, configuration changes, node and service state.
• Application errors and diagnostics — enough to work out what broke.

What we try not to record

We do not deliberately log passwords, session tokens, API keys or payment card numbers, and where such a value would otherwise appear in a log or an error report it is redacted. We will not claim this is perfect — a value can end up in a stack trace nobody predicted. When we find one, we treat it as an exposure: the credential is rotated and the log entry removed.

Where a product sends error reports to a third-party error-tracking service, that service is named in the product's annex and on the sub-processor page, because an error report can carry an identifier for the person who hit the error.

How long we keep it

Log type	Retention
Security, access and audit logs	12 months
Application and error logs, crash reports, diagnostics	90 days

These are the same periods published in the retention table of our Privacy Policy, and if the two ever disagree the Privacy Policy governs.

Access to logs is restricted to the people whose job needs it, and log access is itself an administrative event that gets recorded.

Monitoring and alerting

Metrics from the platform, the databases, the storage layer and the applications feed a monitoring system that raises alerts when something is wrong — a service failing, a certificate close to expiry, a backup that did not complete, a disk filling, an unusual pattern of authentication failures. Alerts go to people, not to a dashboard nobody opens.

We also run an independent external check that watches the Service and the monitoring system itself from outside our network, and raises an alarm if either goes quiet. Monitoring that cannot survive the failure it is meant to detect is decoration, and a failed backup that alerts nobody is the standard way a recovery turns out to be impossible.

Incident response

How we handle an incident

1. Detect and record. An alert, a customer report or a disclosure from a researcher opens an incident, with one named person responsible for running it.
2. Assess and classify. What happened, what is affected, whether personal data is involved, whose data, and how bad it could get. Severity drives everything that follows.
3. Contain. Cut the access, revoke the credential, isolate the component, block the route — stopping it comes before understanding it.
4. Eradicate and recover. Remove the cause, restore service, restore data from backup where that is what is needed, and verify the result rather than assuming it.
5. Notify. Under the timescales below.
6. Review afterwards. A written review of what happened, why, what we changed, and what would have caught it sooner.

Telling you about it

Where we are the controller — for the data described in our Privacy Policy as ours — and there is a personal data breach that is likely to result in a risk to people:

• We notify the CPDP within 72 hours of becoming aware of it, as Article 33 GDPR requires, and where we cannot give complete information in that window we give what we have and follow up.
• We notify the affected people without undue delay where the breach is likely to result in a high risk to them.

Where we are your processor — everything inside your workspace, including data your organisation collects about its own personnel — you are the controller and the notification duty to the authority is yours, so ours is to you:

• We notify you without undue delay after we become aware, and in any event within 72 hours.
• We give you what Article 33(3) requires you to have: the nature of the breach, the categories and approximate number of people and records involved, the likely consequences, the measures we have taken or propose, and a contact point who can answer follow-up questions.
• We assist you with your own notifications and with any questions from your supervisory authority. Our Data Processing Addendum sets that out contractually.

We notify you at the administrative contact addresses on your account. Keeping those current is worth five minutes of your time, because a notification that reaches a mailbox nobody reads has been made and not received.

What we will not do

• We will not sit on a breach to work out how it looks, or wait until we have a complete picture before telling you something is wrong.
• We will not require you to sign anything — a non-disclosure agreement, a waiver, an amended contract — as a condition of being told.
• We will not describe an incident as something else. If data was accessed, the notice says data was accessed.

Reporting an incident to us

If you think an account has been compromised, credentials have leaked, or you have seen something in the Service you should not be able to see, tell us immediately at [email protected]. If personal data is involved, copy [email protected]. Both addresses are monitored and reach the people who operate the Service.

If you have found a vulnerability rather than an incident in progress, the responsible disclosure section below is the route, and it offers you protection that this section does not.

Continuity and backups

Three tiers, and why there are three

Backups fail in three different ways — the copy is too old, the copy is on the machine that died, or the copy is in the building that burned. So there are three tiers, each answering a different failure:

• Tier 1 — a fast local copy. Recent database backups are staged on storage separate from the live database, on a different machine. This is the tier that answers "somebody dropped the wrong table twenty minutes ago" and it restores quickly because the data never left the site.
• Tier 2 — a durable on-site copy. Everything is copied into a private, backup-only object store that runs on a physically separate cluster from the systems it protects, with its own credentials, reachable only from inside our network and never from the internet. Losing the cluster that runs the Service does not lose the cluster that holds its backups.
• Tier 3 — an off-site copy with a third party. A further copy goes to object storage operated by an external provider, in a different place entirely, encrypted before it leaves our network. The provider stores ciphertext and holds no key. This is the tier that answers the loss of the whole site.

Deliberately, the credentials that run the Service are not the credentials that can delete its backups.

What is backed up

• Databases — continuous archiving of the write-ahead log for point-in-time recovery, plus periodic full backups and separate logical dumps. Two mechanisms, because they fail differently.
• Object storage — the files and media held for you, mirrored to the backup tiers.
• Cluster and platform state, including the configuration needed to rebuild the control plane.
• The secrets store, snapshotted on a short cycle.
• The version-controlled configuration that defines the environment, which is what makes a rebuild possible rather than merely theoretical.

Not backed up, on purpose: caches and queues, which are disposable by design and reconstructed on restart, and build artefacts that the pipeline can regenerate. Backing those up would add cost and restore time for nothing.

Recovery objectives

These are the objectives we design and test against. They are internal targets, not contractual commitments — no service level applies unless we have separately agreed one with you in writing, as the Terms of Service says.

Scenario	Recovery point — how much data is at risk	Recovery time — how long it takes
Loss of a machine or a service	None. Replicated components carry on	Minutes, usually without anyone noticing
Database corruption or an unwanted change	Minutes — continuous archiving supports point-in-time recovery	Hours, depending on the size of the database
Loss of the storage holding files	Last completed replication cycle	Hours
Loss of the whole site	Last completed off-site cycle	Hours to days. This is the honest number

We are candid about the last row. We are resilient to losing machines; we are not a multi-region service that fails over silently, and we will not describe ourselves as one.

We test restores

A backup nobody has restored is a guess. We restore into a scratch environment and verify the result against the source — record counts, integrity checks, and whether the restored system actually starts — rather than trusting a job that reported success. Restore drills are documented, and the outcome of the most recent one is available to customers on request at [email protected].

Monitoring alerts on a backup that is late, failing or stale, because a backup system that fails silently is functionally the same as no backup system, and is discovered at the worst possible moment.

How long backups are kept, and what deletion means

Each backup ages out on its own rolling cycle, within the period given in the retention table of our Privacy Policy. Backups are not individually edited to remove one record — that would defeat what a backup is for — so a deleted record persists in backup copies until that cycle completes. During that window the data is not used for anything, and we do not restore a backup in order to bring back data somebody asked us to delete. A backup is restored to recover a system, not to resurrect a record.

Your own copies

We maintain backups for our operational continuity and for the recovery obligations we owe you. They are not a substitute for your own copies, and the Service provides export so that you can keep some. If your business could not tolerate the loss of the data you keep with us, export it on a schedule that reflects that.

Retention, deletion and export

Getting your data out

You can export your data while your account is open — through the product's own export function where it has one, through the application programming interface, or by asking us. Exports are in structured, machine-readable formats — commonly CSV and JSON, with files delivered in their original format. Your product's annex says which export routes exist for it.

If you need an export we do not offer as a self-service function, write to [email protected] and we will produce it. We do not charge for a reasonable export, and we do not make leaving harder than joining.

After your agreement ends

Your data remains available for export for 30 days after the agreement ends. After that window we delete it. The same period, and the reasoning behind it, is in the retention table of our Privacy Policy.

If you need longer, ask before the window closes rather than after it.

Deletion on request

Where you delete something inside the Service, or ask us to delete your workspace:

• Live systems are updated straight away. The data is gone from the running service.
• Backup copies are not individually edited. A deleted record persists in backups until each copy ages out on its rolling cycle, within the period stated in the Privacy Policy. During that window the data is not used for anything, and we do not restore a backup to bring it back.
• Copies held by a provider we engage are deleted on our instruction, under the Article 28 terms in our contract with them.

Where we can keep something useful without keeping anyone identifiable — aggregate usage counts, for example — we anonymise rather than delete, and once anonymised it is no longer personal data.

Retention you control

For data inside your workspace we are your processor, and you set the retention period, not us. Where a product lets you configure how long activity data, captured media, logs or archived records are kept, that setting is yours and its default is documented in the annex. Choosing a period that is lawful and proportionate in your jurisdiction is part of your controller responsibility — see the shared responsibility section.

Our own retention periods, for the data where we are the controller, are published in full in the Privacy Policy as a table with actual numbers rather than the phrase "as long as necessary".

Legal hold

Where we are required to preserve data for a legal claim, an investigation or a regulatory request, we keep it until that ends, including any appeal period, and we do not delete it in the meantime. That obligation overrides the periods above. It applies to us; it will sometimes apply to you as well.

Disposing of hardware

Because we own our infrastructure, we also retire our own drives. Storage is encrypted at rest, and a drive is wiped, cryptographically erased or physically destroyed before it leaves our control. A retired drive is never sold, donated or returned intact.

Personnel

We are a small, long-standing team, and the people who build the Service are the people who operate it. That has a security upside — nobody is administering a system they do not understand — and a limit we set out in the access control section rather than hide.

Everyone with access to production systems or customer data:

• is bound by written confidentiality obligations that continue after their engagement ends, whether they are an employee or a contractor;
• works on a need-to-know basis, with access scoped to their role and granted for a purpose rather than by default;
• uses named individual accounts with multi-factor authentication, never a shared login;
• is briefed on how we expect data to be handled as part of joining, and again when something material changes;
• loses that access when they leave or when their role changes, with the credentials they held rotated as part of the same step.

Contractors and anyone working on our behalf are engaged on terms at least as strict as those above. We do not give a provider or a contractor access to customer data because it is convenient.

Devices

Machines used to access production systems or customer data run full-disk encryption, lock automatically, are kept patched, and are protected by multi-factor authentication on the accounts they hold. A lost or stolen device is treated as an incident: access is revoked and credentials are rotated before anything else is decided.

Two things we do not claim

• We do not run formal background screening as a standard step, and we are not going to describe an informal hiring process as vetting. Where your own contract or regulatory position requires screening for named individuals working on your account, tell us at [email protected] and we will arrange it.
• We do not run a certified annual security awareness training programme. Security expectations are part of onboarding and part of how we review changes, but that is a practice, not a curriculum, and the two should not be confused on a page like this.

Providers and vendor management

The first question is whether we need one at all

We run our own infrastructure, and that is a security decision as much as a cost one: a provider we do not engage is a provider that cannot be breached on our behalf. Before we take on a new one we ask whether the function can be served by something we already operate. Often it can, and the answer is no provider.

Before we engage one

• What data would it see, and can we send it less — or none — and still get the benefit?
• What is its security posture: its own certifications and reports, its published architecture, its breach history, how it handles vulnerability reports.
• Where does it process, which establishment contracts with us, and which transfer mechanism applies if processing happens outside the European Economic Area.
• Will it sign a data processing agreement meeting Article 28 GDPR, including the Standard Contractual Clauses where they are needed? If it will not, we do not engage it for anything involving personal data.
• How do we get out — can we export what it holds, and can we replace it without rebuilding the product around its absence?

What the contract has to contain

Processing only on our documented instructions; confidentiality binding its personnel; security measures at least as strict as our own; controls on its own sub-processors; assistance with data subject requests and with security, breach notification and impact assessments; notification of a breach without undue delay; deletion or return of the data when the engagement ends; and our right to the information needed to demonstrate compliance.

A provider may not use your data for its own purposes. Not to improve its own products, not to train models, not to build advertising profiles.

While it is engaged

We review the providers we use periodically, watch for security incidents and for changes in the legal basis for transfers to them, and remove one when the feature it served is gone. A provider that is no longer used does not stay on the list as decoration, and a provider that has been quietly replaced is a change we announce.

How this appears to you

Every provider that processes personal data for the hosted Service is published on our sub-processor page, in three tiers: those always engaged, those engaged only when you enable a specific feature, and those that appear only in a deployment you run yourself. That page also gives the advance notice period before we add or replace one, and the procedure for objecting.

Responsible disclosure

If you have found a security vulnerability in the Service, we want to hear about it, and we would rather hear about it from you than from someone using it.

How to report

Send it to [email protected]. If personal data is exposed, copy [email protected].

We do not operate a separate security mailbox, and we are not going to publish one we do not monitor. That address reaches the people who operate the Service.

A useful report contains: what the issue is, the exact URL, endpoint or component, the steps to reproduce it, what an attacker could actually do with it, and anything you need from us to prove it. Screenshots or a short recording help. Write in English.

What we do with it

• We acknowledge your report within three business days.
• We assess and reproduce it, and tell you what we found — including if we conclude it is not a vulnerability, and why.
• We keep you updated while we fix it, and tell you when the fix is live.
• We are happy to credit you publicly when the fix has shipped, or to leave you out of it. Your choice.

Serious issues jump the queue. We fix a critical vulnerability as quickly as we can build and verify a fix, and we will tell you what the timeline looks like rather than leaving you guessing.

Our commitment to you

If you follow the rules below, we will not pursue legal action against you, we will not report you to anyone, and we will not ask your employer to. We will treat your research as authorised access for the purposes of computer misuse legislation and our own Terms of Service, and we will treat your report as a contribution rather than a threat.

This protection covers you personally. It cannot cover you against a third party — if your testing reaches one of our providers' systems, that is between you and them.

The rules

• Do not access, modify, delete or download anyone else's data. Use your own test account. If you can reach another customer's data, that is the finding — stop there and tell us. You do not need to collect it to prove it.
• Stop as soon as you have demonstrated the issue. Do not pivot, escalate further, or establish persistence.
• No denial of service, volumetric testing, load testing or resource exhaustion.
• No social engineering of our people, our customers or our providers, and no physical attempts against our premises or equipment.
• No spam, no mass account creation, no brute forcing of live accounts.
• Give us a reasonable time to fix it before you publish — 90 days from your report, or the day the fix ships, whichever comes first. If a fix is taking longer, talk to us; we will not use the clock to bury a finding.
• Obey the law, and do not do anything that would harm the Service or the people who use it.

Reports produced by running an automated scanner against the live Service are not in scope, and running one is itself a breach of the testing section above.

Usually out of scope

Missing security headers or best-practice settings with no demonstrated impact; self-inflicted cross-site scripting; missing rate limits without a working attack; outdated version banners without a working exploit; results from a vulnerability scanner submitted without validation; social engineering; and issues in a third-party service rather than ours — report those to the provider that runs it.

Send it anyway if you are unsure. We would rather triage a duplicate than miss a real one.

There is no paid bounty

We do not run a paid bug bounty programme and we do not pay for vulnerability reports. We would rather say that plainly at the start than have you invest a weekend on the assumption that we do. What you get is a fast, straight response from the people who can fix it, and public credit if you want it.

Security issues in our open-source code

Where our software is published as open source, report a security issue in the code to the same address, in private. Please do not open a public issue or a pull request that describes the vulnerability — that publishes a working exploit to everyone running the code, including people who cannot patch quickly.

Shared responsibility — who secures what

Security of a hosted service is split between the provider and the customer, and most real incidents happen on the customer's side of that line: a shared password, a departed employee who kept access, an integration token that outlived its purpose, a laptop left on a train. That is not a criticism. It is the reason this section exists and is specific.

What we are responsible for

• The physical hardware, the facilities and the virtualisation platform.
• The container platform, the operating systems and the runtime the application runs on.
• Patching and updating everything in the list above, and the application itself.
• Encryption in transit and at rest, and the management of our keys.
• Network security, the edge, and keeping the origin off the public internet.
• Availability, redundancy, backups of the Service, and restoring it after a failure.
• Isolation between customers.
• The security of our own code, our build pipeline and our deployment process.
• Our own staff: their access, their devices, their confidentiality obligations.
• The providers we engage, and the contracts that bind them.
• Detecting, responding to and notifying you of incidents in our part.

What you are responsible for

Who gets in, and who stays in. Your users, their roles and their permissions. Inviting people, removing them the day they leave, reviewing periodically who still has access, and not sharing accounts. Choosing strong, unique passwords and turning on multi-factor authentication where the product offers it. If your organisation uses single sign-on, the security of your identity provider is yours.

How you configure the product. Every switch we give you is a decision you are making. Defaults are chosen to be safe, not to be right for you, and changing one is a deliberate act with consequences you own.

Your monitoring configuration. For products that can capture workforce activity, you decide which capture features are switched on, how often they run, and who can see the result. We supply the controls; which of them is lawful and proportionate in your organisation, in your jurisdiction, is your call. The next block is about that in more detail, because it is the sharpest edge in this document.

Your retention settings. Where the product lets you set how long data is kept, that period is yours. Keeping data longer than you need it is a risk you are choosing to hold, and it is one of the first things a supervisory authority asks about.

Your integrations and your tokens. Every third-party service you connect, every API key you issue, every webhook you point somewhere and every access token you grant to an application or an automated agent. Approving an integration is you deciding to send your data somewhere else. Scope those grants narrowly, review them, and revoke them when a person leaves or a project ends — a token issued by someone who has left your organisation still works until you revoke it.

Your devices and your endpoints. The laptops, phones and desktops your people use to reach the Service, including any desktop or mobile application we publish. Full-disk encryption, screen locks, patching, malware protection and what happens when a device is lost are yours. We cannot protect an account from a compromised machine that is already signed into it.

Your data, and what you put in it. What you choose to upload, whether it belongs in this product at all, and whether you have the right to process it. Also your own copies — see the backups section.

Telling your own people. Your privacy notice to your staff, customers and site visitors is yours to write. Ours describes what we do; it is not your notice, and our cookie banner is not your consent mechanism.

Where you use the Service to monitor people

Some of our products capture information about how an organisation's own personnel work — which can include screenshots, application and website usage, activity rates derived from keyboard and mouse events, and, where you switch them on, webcam stills, audio or screen recordings.

For all of that data, you are the controller and we are your processor. You decide why it is collected and how; we process it on your instructions. That split has consequences you should read carefully:

• The lawful basis is yours to establish. Consent is generally not a valid basis in an employment relationship because of the imbalance of power between employer and employee, so a signed form is unlikely to be the answer you need.
• The notice to the monitored person is yours to give, in advance, covering each type of capture that is switched on.
• The data protection impact assessment is yours to complete where one is required, which it commonly is for systematic monitoring of employees. We will help: ask [email protected] for the information you need about data categories, capture frequencies, retention, storage locations, sub-processors and transfer mechanisms, and we will provide it.
• Consultation with a works council, trade union or employee representative body is yours to run where local law requires it — which it does in several European countries, before the system is introduced, not after.
• Some capture types are restricted or prohibited in some countries. Continuous screen capture in particular is treated very differently across Europe.

We make no claim that any monitoring feature is lawful for you to use, anywhere. A feature existing in the product is not advice that you may switch it on, and our providing it is not our assessment of your legal position. Where you enable one, you confirm to us that you have done the work above — the Data Processing Addendum and the Terms of Service put that in binding terms, including who answers for it if it turns out not to have been done.

Where you run the software yourself

If you deploy our open-source software on your own infrastructure, everything above is yours — the servers, the database, the storage, the backups, the encryption, the patching, the access control and the incident response. You are the controller of the data in it. We have no access to it, we are not your processor for it, and no commitment on this page applies to it.

How to reach us about security

• A vulnerability you have found — [email protected]. Read the responsible disclosure section first; it tells you what protection you have and what rules go with it.
• An incident, a compromised account, or something you can see that you should not be able to see — [email protected], immediately. Copy [email protected] if personal data is involved.
• A security questionnaire, a due diligence request, a request for the Data Processing Addendum, evidence of a restore test, or permission to test the Service — [email protected].
• A question about personal data, a data subject request, or a breach affecting you — [email protected].

All of these addresses are monitored by the people who operate the Service. By post: Ever Technologies LTD, Mladost 2, bl. 211, ent. A, Sofia 1799, Bulgaria — registered in Bulgaria under company number 204599535. We correspond in English.

You may also complain to a data protection supervisory authority. Ours is the Commission for Personal Data Protection (Комисия за защита на личните данни), the CPDP, at https://www.cpdp.bg/. You may instead complain to the authority for the country where you live or work.

This document is version 1.0.2 of the Security Overview for ever.co, in force from 2026-08-02. It describes the measures in place at that date. Earlier versions, with the dates they applied, are at https://ever.co/security.