Security & Data Processing

1. Scope

Three things in one place. What we do to keep eclean secure, how to tell us about a flaw, and the data processing terms for business customers.

This document has three parts.

• Security measures (section 2) describe the controls we run. They apply to everyone.
• Vulnerability disclosure (sections 3 and 4) explain how to report a security problem to us and what you can expect.
• Data Processing Addendum (sections 5 to 13), or "DPA", applies only if you are a business customer and use eclean in a way that makes eclean Labs AB a processor of personal data for which you are the controller. This is uncommon, because for ordinary eclean accounts we are the controller ourselves, as the Privacy Policy explains.

Everything here is a plain statement of what we do now, including the limits. We have not obtained a security certification such as ISO 27001 or SOC 2, and we do not claim one.

2. Security measures

What protects the systems and the data, based on how they are built and run. Where a protection has a limit, we state the limit.

Hosting and network.

• Our dedicated server is owned and operated by eclean Labs AB and stands in a Digital Realty datacenter (AMS5) in Amsterdam, the Netherlands. Digital Realty provides physical hosting only and has no logical access to our systems or data.
• Web and API traffic goes through Cloudflare, which provides TLS, DDoS protection and a web application firewall. The firewall of our gateway machines lets their public network interfaces accept connections from Cloudflare's published address ranges only, and the gateways require our Cloudflare zone's client certificate (authenticated origin pull) on those connections. Gateways accept TLS 1.2 or newer with modern cipher suites.
• The machines sit on separate virtual networks. Traffic between networks is blocked and logged unless a service has declared the port, and internal admin tools are placed behind Cloudflare Access with sign-in through company Google Workspace accounts. Two exceptions are on record: an external adviser can sign in to our internal reporting tool with their own Google account, and one staff console account signs in with a one-time code sent by email.
• Administration uses SSH with keys only and short-lived certificates issued through Cloudflare. Root login is off on the virtual machines and allowed with a key only on the hypervisor. Operating system security updates are applied to servers automatically. Proxmox packages and kernels on the hypervisor are updated by hand.
• By our build standard, each container runs rootless under Podman and as a non-root user inside, with a read-only file system, no extra capabilities and no new privileges, and its image is pinned by version and digest. A few tools need documented exceptions.
• Limit: traffic inside our private network is not always encrypted with TLS. Some links (for example between the cluster's coordination services) use TLS, but application-to-database, cache, object storage and monitoring links on the private network do not. They rely on the network segmentation above.
• Limit: all our machines run on one physical server in one datacenter. The database is a replicated cluster (one primary and two replicas), but a failure of the server or the site is recovered from backups, not by failing over.

Application security.

• Passwords are stored only as bcrypt hashes (cost 12). Two-factor sign-in with one-time codes (TOTP) is available. A code works once, five wrong codes in 15 minutes lock the factor, and recovery codes are stored as SHA-256 digests.
• The authenticator secret is encrypted with AES-256-GCM, bound to the account. Session and access tokens are random and stored on our side only as SHA-256 digests. A refresh token that is used twice revokes its session. Entitlement data sent to the desktop app is signed with Ed25519, and incoming Stripe and Amazon SNS messages are verified by signature.
• Sign-in cookies are HttpOnly, Secure and SameSite=Lax, set for the exact host only, and the access cookies use the __Host- prefix. Web sessions last 24 hours before a refresh, and a session ends 180 days after sign-in at the latest.
• We use no CSRF token. Instead, requests that change state and are authenticated by a cookie must come from the eclean website's origin, on top of SameSite=Lax. Staff cookies are refused from the website origin.
• The API sends a Content Security Policy of default-src 'none'; frame-ancestors 'none', together with nosniff, frame denial and a restrictive referrer policy. The website sends a Content Security Policy that limits scripts, frames and connections to a list of hosts, but it allows inline scripts (the website framework needs them) and includes our analytics and advertising providers, and it has no violation reporting.
• HSTS: Cloudflare sends Strict-Transport-Security with a one-year max-age, without includeSubDomains or preload, for the website, the API and the other eclean.gg services it serves.
• Bot protection (Cloudflare Turnstile) and rate limits protect sign-in, registration, typed referral codes and similar endpoints, and the gateways limit requests per address. For that, a gateway keeps a visitor's IP address in memory for up to 10 minutes after the visitor's last request.
• Our whistleblowing site (report.eclean.gg) is also served through Cloudflare, so TLS ends at Cloudflare, and it has a Tor onion address as well. Our security.txt is served by Cloudflare.
• Logs and telemetry exported from the API remove IP addresses, email addresses, usernames and similar fields before they leave the process. The gateways are the exception, because their error logs contain the visitor's IP address and the requested address. They are kept for about a month in the server's journal and are also sent to our own monitoring system, which keeps them for 5 days.
• Security-relevant actions by staff and by accounts are written to an audit trail that is kept for 24 months. Personal parts of it are erased when an account is deleted.

Staff access.

• Two-factor authentication is mandatory for staff. Staff sessions are short (one hour, ended after two hours idle and twelve hours at most) and bound to the sign-in network address. Staff roles are ranked, and nobody can act on an account of equal or higher rank, or on their own.
• Staff actions that change data, including deletions, data exports and settings, need a fresh second factor (within five minutes), and they are written to the audit trail with a reason. Staff can open the website as a customer (impersonation) for up to 60 minutes, read-only, only with a written reason, and each start is audited. Exports are also announced to the account holder by email.
• Support context view. While handling a ticket, staff can open a view of an account's usage report totals for the last 30 days and the health status of its drives. It needs a ticket reference as its purpose, a fresh second factor, and is limited to 60 views an hour per staff member. Every view is written to the audit trail with who looked, at whom and for what purpose, and if that record cannot be written nothing is shown. It returns nothing for an account that turned the usage report or Personalized tips in the app off.
• Service announcements. Sending one email to every verified account is a separate permission held by owners only. It needs a fresh second factor (within five minutes), is limited to 10 sends an hour per person, and is refused while impersonating a customer. The API accepts only five fixed subjects (maintenance, incident, security, terms or privacy change, service change) and fixed message templates, with plain text slots that cannot hold a link. A dry run returns only the number of recipients and sends nothing. A real send needs an idempotency key, so a retry cannot send twice, and goes out in pages of 100 every ten seconds. Each send is written to the audit trail with the sender, the subject and the number of recipients, but not the text, which is kept in its own table. Addresses that bounced or complained are skipped, both when the list is built and again at delivery. This is an owner-only control, not a second approver.
• Limit: apart from the support context view, looking at a customer's record in the staff console (the user list, family and community lookups) does not need a fresh second factor beyond the sign-in, and such reads are not logged one by one. Only denied attempts are logged. We have no audit trail of other staff reads, and we do not claim one.
• Staff who handle personal data are bound by confidentiality, and access to production is limited to staff who need it.

Deleting and erasing data.

• Deleting an account queues erasure jobs that retry until they succeed. They delete the Stripe customer, the newsletter record, the avatar image, the account's conversations and profile at Crisp, the data held by our Discord bot, and the account's identifiers at Google Analytics and GrowthBook. They overwrite the properties of the account's OpenPanel profile with empty values and, for an address that bounced, remove the entry on the Amazon SES suppression list. Hashed emails are removed from advertising audiences at the next daily sync. Stripe is asked to redact its remaining personal data 100 days after the deletion.
• Limit: some things stay. OpenPanel cannot delete a profile or its events through its API, so the profile row and the events remain until we erase them by hand once a month and for the 14 months OpenPanel keeps events. Conversions already sent to advertising platforms cannot be recalled. Stripe cannot redact invoices, and an SES entry for a complaint is kept. A Crisp chat from a visitor who never connected it to the account cannot be matched to it. Backups age out as described below. Anything else can be requested from us.

Retention of security and monitoring data.

Software supply chain.

• Source code and build automation run on GitHub. Renovate pins GitHub Actions and container images to exact commits and digests and waits three days before adopting new releases (security fixes are not delayed). Secret scanning (TruffleHog) runs in the CI of all our code repositories.
• The API server image is a static binary with no operating system layer, built in CI and published with signed SLSA provenance, a software bill of materials and a keyless cosign signature.
• Secrets are kept in a self-hosted secrets manager (OpenBao) and encrypted Ansible vault files, not in plain text in repositories. Servers receive secrets with short-lived tokens that are valid for five minutes and bound to the server's address.

On your PC.

• The Windows installer and the app are code-signed through Microsoft Azure Artifact Signing. The updater checks every update against our minisign signing key before installing and does not allow downgrades. The signed-in session is stored with Windows DPAPI.
• Changes that need administrator rights go through a Windows service that accepts only a fixed list of commands over a local pipe that remote clients cannot reach. For every request it checks that the caller is eclean.exe from the same install folder with a valid signature by the same publisher, and everything beyond a short list needs the user to be a local administrator. The service keeps an audit log of requests, which names the calling process and not the Windows account, in a protected log folder.
• Optimization playbooks are signed and checked against their checksums before they run.

Backups and resilience.

• Backups are encrypted before they leave our server. All restic repositories are encrypted. The document archive (Paperless) holds internal company documents, not customer personal data. A deliberately readable copy of its originals and OCR'd PDFs, never the manifest, is kept in a Google Drive folder in our Google Workspace.
• Backups include personal data that was deleted from live systems, until they age out. A deleted record can stay for about 100 days in the main database's backups and up to about 7 months in other backups (the longest chain is six months of snapshots plus Drive's 30-day trash). We do not purge backups early.
• Restores are tested on a schedule, for the database, the machines and the services. We do not publish recovery time or recovery point targets.

What we do not claim. We do not hold a security certification, and we do not claim that no incident can occur. If something goes wrong, section 12 explains what we do.

3. Reporting a vulnerability

Email security@eclean.gg. We acknowledge within 48 hours.

If you find a security problem in eclean's software, website, API or infrastructure, tell us. Report anything that could lead to information disclosure, data loss, privilege escalation, remote code execution, account takeover or another security or privacy issue. If you are unsure whether something is a security issue, report it and we will triage it.

How to report.

• Email security@eclean.gg. Start the subject line with "URGENT" if the issue is time-sensitive or clearly exploitable in production.
• You can encrypt your message with our PGP key. Our security.txt at /.well-known/security.txt lists the same contact details.
• Do not open public issues or pull requests, or publish details, before we have had a chance to investigate and coordinate a fix.
• If you want to report something confidential that is not a vulnerability, use our whistleblowing channel.

What to include. A short summary of the issue, its impact and the affected service or URL. Exact steps, commands or a minimal proof of concept. Logs, error messages or screenshots. What you saw compared with what you expected, and your view of the severity. Your contact details and whether you prefer to be credited, credited anonymously or not named.

4. What we do with your report

Acknowledgment in 48 hours, regular updates, fix targets by severity, and safe harbor for good-faith research.

1. Acknowledgment. We confirm receipt within 48 hours.
2. Triage. We reproduce the issue and assess severity.
3. Coordination. We keep you updated while we work on a fix.
4. Resolution. When it is fixed we tell you and agree the timing of any disclosure.

Our usual targets for a fix are 7 days for critical issues, 30 days for high severity and 90 days for others. They are aims, and complex issues can take longer. We will tell you if so.

Safe harbor. We ask reporters to avoid public disclosure until we have had a chance to coordinate a fix. In return, we give timely acknowledgment and status updates, we do not take legal action over good-faith security research, and we work with you on the timing of disclosure. If you want it, we credit you on the acknowledgements page once the fix has shipped.

Safe harbor applies to good-faith research that stays within these limits. Please do not:

• use social engineering against our staff or users, including phishing
• attack our premises or equipment physically
• run denial-of-service or volumetric tests
• test third-party services we use, for example by attacking their infrastructure. Report issues in those services to their owners
• access or modify other people's data beyond what you need to demonstrate the issue. Stop and tell us if you come across such data

5. Data Processing Addendum: when it applies

If you decide why and how personal data is processed and we do it for you, these terms are the Article 28 contract.

This DPA applies when eclean Labs AB ("eclean", the "processor") processes personal data on behalf of a business customer (the "customer", the "controller") in providing the Services under the Terms of Service. For example, a company that deploys eclean on staff computers under a volume agreement and uses the account features to administer them.

It does not apply where eclean decides the purposes and means of processing, such as for individual accounts, billing, security and fraud prevention, marketing choices and product analytics. For that processing eclean is a controller and the Privacy Policy applies.

This DPA forms part of the agreement between the customer and eclean from the date the customer starts using the Services in a way that it applies, and it ends when eclean stops processing the data. It follows Article 28 of the GDPR (Regulation (EU) 2016/679). If it conflicts with the Terms on personal data, this DPA prevails. If the signed Standard Contractual Clauses apply, they prevail over both.

6. Details of the processing

7. Processor obligations

We act on your documented instructions, keep the data confidential and secure, and help you meet your duties.

eclean will:

1. process personal data only on the customer's documented instructions, which are this DPA, the agreement and the customer's use of the Services, unless EU or member state law requires otherwise, in which case eclean tells the customer first unless the law forbids it
2. tell the customer without undue delay if it believes an instruction infringes data protection law
3. ensure that everyone authorized to process the data is bound by confidentiality
4. apply the security measures in section 2 and keep them appropriate to the risk, in line with Article 32
5. respect the conditions for sub-processors in section 8
6. taking into account the nature of the processing, help the customer respond to requests from data subjects. If a data subject writes to eclean about the customer's data, eclean forwards the request to the customer and does not respond itself unless told to
7. help the customer with its obligations on security, breach notification, data protection impact assessments and prior consultation under Articles 32 to 36, as far as the information is available to eclean
8. make available the information needed to show compliance and allow audits as set out in section 10

8. Sub-processors

We use the sub-processors on our public list. We publish changes in advance and you can object.

The customer gives general authorization for eclean to engage sub-processors. The current list, with the data each one receives, why, where it sits and the transfer safeguard, is at /trust/subprocessors. It includes our colocation provider, Digital Realty, which provides physical hosting only and has no logical access to data, and it names the tools we run ourselves on our own server.

• Notice of changes. eclean updates that page before a new sub-processor starts processing customer personal data, and gives at least 30 days' notice of the change. A business customer can ask at privacy@eclean.gg to be emailed about changes.
• Objection. The customer can object on reasonable data protection grounds within that notice period. We then try to find a solution. If we cannot, the customer can end the affected part of the Services and receive a pro-rata refund of prepaid fees for it.
• Terms with sub-processors. eclean engages each sub-processor under that vendor's published data processing terms, which are incorporated in our service agreement with it, and remains responsible to the customer for the sub-processor's performance. We do not claim signed, negotiated data processing agreements with every vendor.

9. International transfers

Our servers are in the EU. Where a sub-processor sends data outside the EEA, we rely on an adequacy decision or on the EU Standard Contractual Clauses.

eclean hosts its main systems in the Netherlands, and email, error reports and help desk data sit in the EU with Amazon (Ireland), Sentry (Frankfurt) and Crisp (the Netherlands and Germany). Some sub-processors, for example for payments, content delivery or advertising, process data in other countries, as the sub-processor list states for each. Where that involves a transfer of personal data to a country without an EU adequacy decision, the transfer relies on one of the following.

• An EU adequacy decision, including the EU-US Data Privacy Framework for a certified recipient.
• The EU Standard Contractual Clauses in Commission Implementing Decision (EU) 2021/914, as incorporated in the sub-processor's published data processing terms, with the supplementary measures that apply to them. The EU-US Data Privacy Framework is under legal challenge, so we keep the Standard Contractual Clauses as a fallback.
• Where the customer is established outside the EEA and eclean returns data to it, Module 4 (processor to controller), which the parties agree to incorporate.

If the customer needs signed copies of any clauses, it can ask at legal@eclean.gg.

10. Audits

Documents first. An on-site audit only if documents are not enough.

On written request, eclean provides the information necessary to show compliance with this DPA, such as an overview of its security measures and its answers to a reasonable security questionnaire. If that is not enough to meet a legal requirement, or after a personal data breach, the customer, or an auditor it appoints who is bound by confidentiality, may audit eclean's relevant processing once per year, after at least 30 days' notice, during business hours and without disrupting operations. The customer bears the costs of the audit. Audits do not extend to data of other customers.

11. Return and deletion

When the agreement ends, we delete the data or return it, as you choose.

On termination of the Services, and at the customer's choice, eclean deletes the customer's personal data or returns it in a commonly used format, and deletes existing copies unless EU or member state law requires storage. Deletion from live systems is carried out as described in the Privacy Policy. Copies in backups are overwritten as the backups age out, which takes about 100 days for the main database and up to about 7 months for some other stores (section 2), and eclean keeps protecting them until then.

12. Personal data breaches

If we learn of a breach affecting your data, we tell you without undue delay and within 72 hours.

eclean notifies the customer without undue delay, and in any case within 72 hours, after becoming aware of a personal data breach affecting the customer's personal data. The notice goes to the customer's account contact and describes, as far as known, the nature of the breach, the categories and approximate number of data subjects and records, the likely consequences, and the measures taken or proposed. eclean supplies further details as they become available, helps the customer meet its own notification duties to the supervisory authority and data subjects, and takes steps to contain the breach. A notice is not an admission of fault.

For personal data for which eclean is the controller, eclean notifies the Swedish Authority for Privacy Protection (IMY) and affected people as the GDPR requires.

13. Liability and general terms

The liability provisions of the Terms of Service apply to this DPA, to the extent the law permits and without limiting any liability the GDPR does not allow to be limited, including data subjects' rights against a controller or processor. The DPA is governed by Swedish law and the courts stated in the Terms, except that the Standard Contractual Clauses, if they apply, follow their own governing law clause. We may update this DPA under the change rules in the Terms.

14. Contact

• Security reports: security@eclean.gg
• Data protection and DPA questions: privacy@eclean.gg
• Legal: legal@eclean.gg
• Business and volume licensing: b2b@eclean.gg

eclean Labs AB
Organization number: 559546-5831
VAT number: SE559546583101
STORGATAN 41C
931 31 SKELLEFTEÅ, Sweden