top of page

Security & Compliance Policy for the ‘Lunda’ Fundraising Form

Our users trust us to keep their data safe and secure, a responsibility we take seriously. If you have any questions or concerns about this, please get in touch.

Vulnerability Disclosure

If you would like to report a vulnerability or security concern regarding any Estratos Digital product, please contact

We will verify the report and take corrective action as soon as possible. 


General Data Protection Regulation (GDPR)

Estratos Digital GmbH operates the ‘Lunda’ fundraising form and acts as a data processor on behalf of the individuals and organisations who are launching fundraising projects and receiving donations via ‘Lunda’ (thereinafter: Clients). Clients act as data controllers regarding their activity to process personal data for these purposes. Estratos Digital GmbH only acts as data processor for personal data processed in connection with ‘Lunda’ fundraising form for the data and purposes set down in Estratos Digital GmbH’s Privacy Policy as Data Controllers (see below).

Estratos Digital GmbH is fully GDPR-compliant, and we handle our customers’ personal data with great care and respect, as outlined in our terms of service, privacy policy, and throughout this document. We use industry best practices for security and privacy, and have vetted all third-party processors we employ for compliance as well. Data controlled by our customers and provided via our API is ultimately our customers’ responsibility under the GDPR, but we provide strict security practices, as well as (on the requests of the costumers) tools such as custom data retention policies, and APIs for permanent data deletion, which allows our customers to remain compliant as well.


Google Cloud Platform, which hosts the ‘Lunda’ fundraising form, undergoes regular independent audits for a range of standards including ISO 27001, ISO 27017, ISO 27018, SOC 2, SOC 3, CSA STAR, EU-U.S. Privacy Shield, HIPAA, and PCI DSS.

Infrastructure Security

Lunda is hosted on Google Cloud Platform, which employs some of the best security practices in the industry. 

The security practice of Google is described in the Google security whitepaper and Google infrastructure security design overview, and includes:

  • Physical security: All data centers have electronic access cards, alarms, vehicle access barriers, perimeter fencing, metal detectors, biometrics, laser beam intrusion detection, interior and exterior cameras with tracking, security guards, access logs, and more.

  • Hardware security: Stripped-down, custom-built servers and network equipment with a chip-based root of trust for verification, identification, and authentication, a secure boot stack with cryptographically signed BIOS, bootloader, kernel, and base operating system image, and automated patching of firmware and software vulnerabilities. Virtual machines are isolated from the host and each other via a specially hardened version of the open source KVM virtualization stack.

  • Network security: A private, global fiber-optic network extending to points-of-presence near the end user’s local ISP, with automatic encryption of all internal WAN traffic using AES and elliptic-curve Diffie-Hellman key exchange, logically isolated virtual private cloud networks spanning all data centers, hardware-rooted cryptographically authenticated control plane RPC calls, fully distributed firewall rule enforcement, IP spoofing protection, and systematic anomaly detection.

  • Data security: All data is encrypted at rest with the industry-standard AES cipher, using regularly rotated encryption keys that are integrated with cryptographically authenticated service identities and automatically deleted on service termination. Hard drives and SSDs are also encrypted at the hardware level, and decommissioned disks are securely erased with two independent verification processes and physically destroyed on-premise.

  • Employee security: All Google employees undergo relevant background checks and security training, and must sign confidentiality agreements. Only a small group of employees have access to customer data, on a least-privilege need-to-know basis, with all access monitored by dedicated audit teams. Less than one percent of employees have physical access to data centers. All employee access is authenticated, authorized, and encrypted using Google’s BeyondCorp security model.

Estratos Digital GmbH employees do not have physical access to data centers, nor access to the underlying Google infrastructure.

Application Security

Authentication and Access Control

Users log in to their Estratos Digital/‘Lunda’ accounts using external authentication providers (currently Google Accounts and GitHub) via an OAuth 2 flow, optionally with two-factor authentication, which we strongly recommend. The user’s password is never transmitted to us, and we do not gain access to any external resources that belong to the account. Users with our third-party login feature can also implement their own authentication solution.

The Client gains a Estratos Digital/‘Lunda’ access token, which is transmitted either as a cookie or a HTTP header, providing access to our HTTP API. The token automatically expires when not used for some time. This token is converted to a short-lived cryptographically signed JWT token when traversing our frontend infrastructure, which is used to authenticate and authorize all internal RPC calls.

Estratos Digital GmbH datasets can be configured with either public or private read access by default, and individual authenticated users can be assigned various roles giving them read or write access as required. Customers with custom access control can also set custom access rules on documents matching specific filters.


All access to Estratos Digital GmbH resources by end users is encrypted in transit with HTTPS transport layer security (TLS). Support for the older SSLv2, SSLv3, TLS 1.0 and TLS 1.1 protocols are disabled, as are several older cipher suites, since these have known security vulnerabilities. Internally, data is  encrypted in transit and at rest as outlined under the heading ’Infrastructure security’.

Estratos Digital GmbH is using full disk encryption for data storage during data processing based on the Google Cloud Platform and the data never reaches the cloud in an unencrypted state during network transmission. Estratos Digital employs “Customer provided – Google managed” model on key and secret management in the Google Cloud Platform. Estratos Digital GmbH might use tools to decrypt SSL connections in order to secure content above the transport layer. This process may involve resources from outside the Google Cloud Platform infrastructure.

Data Retention and Removal

We record a complete version history for transactions and documents submitted via our API. This version history has a maximum retention period determined by the project’s plan, after which the history is truncated. Users can configure shorter retention periods for various document types and can also purge the complete history of individual documents via a separate API endpoint. Uploaded assets and files can be deleted immediately via our API.

After removal, data will still be retained in our backups for some time, as outlined in our terms of service, to allow for recovery in the case of accidental or malicious removal. Deleted assets may also remain in public CDN caches according to their configured expiry time but can be removed on request.

Application Development Lifecycle

We use continuous delivery to enable rapid and systematic development, testing and deployment of our product, with automated error reporting and monitoring to alert us of problems. This ensures a quick and effective response to potential bugs and security issues and reduces the risk of human error.

Data Security and Privacy


All data is encrypted in transit and at rest as outlined under the heading ’Infrastructure security’.

Access Control

Employees access central resources using two-factor authentication via Google Accounts, and only have access to the systems required for their role. All remote access is encrypted, either via HTTPS transport level security or via VPN connections. Estratos Digital adopts Zero-Trust-Network-Access policy. Employees will never directly access customer-controlled data unless required for support reasons, and will generally ask the customer for permission first.

Internal services are isolated from the Internet to the extent possible, and only have access to the specific resources they need, with the minimum necessary privilege level, using a combination of service-specific cryptographically signed access tokens or passwords and network-level firewall rules. A set of our service related tokens, keys and secrets are stored encrypted in our orchestration platform, only available via authenticated and encrypted RPC calls from the specific agents and provided to individual applications in the relevant namespace, without ever hitting the disk or being exchanged between different applications.

Data Retention and Removal

All data is removed or anonymized as soon as possible after deletion or service cancellation, with a short grace period and backup retention as outlined in our terms of service to allow for recovery in the case of accidental or malicious removal. Users can also contact us to have their data removed. Storage devices are securely decommissioned after use as outlined under the heading ’Infrastructure security’.

Security Audits and Software Updates

We perform regular internal security audits and software security updates to ensure our systems are secure and reliable, and take immediate measures whenever significant security vulnerabilities are discovered.

Geographic Location

All customer-controlled data provided via our API is stored permanently by default, within the EU, unless customer’s business demands different datacenter location. However, during delivery to end users it may be stored transiently in locations outside of the EU, such as in CDN caches, networking equipment, and browser caches, depending on the project configuration (e.g. private data sets).

Third-Party Processors

Customer-controlled data provided via our API is only stored in Google Cloud Platform, and never shared with any other third parties. Other customer data for which we are a controller, such as our user database, email processing, error reporting, and so on, may be sent to certain third-party processors which we employ to deliver our services, as detailed in our terms of service. We have vetted the security and compliance of all such processors, and all transfers are performed securely and in line with best practices. Processors outside of the EU all comply with the GDPR, and have signed data processing addendums with us for the processing of personal data. We never share any customer data, personal or otherwise, with third parties unless employed by us under contract as data processors. A full list of Estratos Digital GmbH sub-processors shall be provided on request made to

Business Continuity

High Availability

‘Lunda’ is built using fully redundant and distributed systems, running across multiple data centers, and can withstand the loss of a single component or entire data center without significant service disruptions. Components are regularly taken out of service during routine maintenance, without affecting availability, and Google Cloud Platform’s live migration technology transparently migrates virtual machines to other hosts prior to infrastructure maintenance.

Incoming traffic is anycast-routed to Google’s globally distributed load balancers, which pass it on to the nearest available data center, automatically routing around outages. The load balancers and CDN can absorb many types of DDoS attacks (distributed denial of service), and many of our backend systems will automatically scale to handle increased load.

Data centers have primary and alternate power sources, as well as diesel engine backup generators, each of which can provide enough electrical power to run the data center at full capacity. Data centers also have automated fire detection and suppression equipment.


In addition to real-time replication across data centers, our databases are also continuously backed up to remote storage in multiple EU regions, and can be restored to any point in time within the past six months with per-transaction precision.

bottom of page