Data Processing Agreement

Controller (principal): The Customer who registers an account on the Funnalized platform and processes personal data in its workspace.

Processor (contractor): Funnel-Link · Andrej Hirsch, Garmischer Straße 14, 82418 Murnau, Germany (hereinafter “Provider”).

(1) The Provider provides the Customer with the SaaS platform Funnalized — in particular sales and customer management, recruiting and applicant management, marketing and funnels, project and team management, customer portals, internal collaboration, support and ticket system, calendar, knowledge area and reporting as well as the management of users and their access, including sign-in via the Customer’s directory (company login) and automatic user provisioning (SCIM). In the course of providing these services, the Provider processes personal data on behalf of and on the instructions of the Customer within the meaning of Art. 4(8), Art. 28 GDPR.

(2) This agreement applies for the term of the user agreement and beyond that for as long as it takes until all personal data processed on behalf has been deleted or returned to the Customer in accordance with § 9 of this agreement.

(1) Nature and purpose: Storage, organisation, display, transmission and deletion of personal data for the operation of the modules used by the Customer — including sales/CRM, recruiting/applicant management, marketing/funnels, projects, team, customer portals, collaboration, support and tickets, calendar, knowledge area and reports — including automations configured by the Customer and email sending. If the Customer sets up the company login, this includes creating, changing and blocking user accounts and memberships on the basis of the information in its directory.

(2) Categories of personal data:

• Master data (name, company, position)
• Contact data (email, phone, address)
• Contract data (deals, quotes, invoices, customer relationships)
• Applicant data (CVs, qualifications, answers in application funnels, interview notes, ratings)
• Communication data (emails, notes, comments, appointments)
• Identity and access data of the users from the Customer’s directory (email address, name, identifier in the directory, status of the membership)
• Signatures (digitally drawn signature under quotes, contracts and contract offers, stored as an image file)
• Assessment and test results (answers, free-text solutions and evaluations from aptitude tests sent by the Customer)
• Onboarding data (tasks, documents and status information on the onboarding of new employees at the Customer)
• Usage and tracking data from funnels and campaigns operated by the Customer
• Working times of the Customer’s employees and team members (times booked per project and task with date, duration, description and whether they are billable; a running timer with its start time; the weekly capacity per person and the workload per person and week calculated from it)
• Learning progress in the Customer’s Team Academy (lessons worked on, answers and results of knowledge checks, number of attempts, courses passed with result and certificate number); the Customer sees the progress per member
• Answers to the Customer’s satisfaction and feedback surveys, including from applicants (rating, free text, answers to follow-up questions, approved testimonials, times of opening and response, browser identifier and country)
• Content that the Customer makes accessible by link without sign-in (Visualizer boards, folders of the document storage — there, if desired, also for uploading, renaming or deleting by the recipient), names from linked records on a board only if the Customer switches this on for the link, and the log of the retrievals (time, type of retrieval, shortened IP address; deleted after 400 days)

(3) Categories of data subjects:

• Leads, prospects, customers and contact persons of the Customer
• Applicants of the Customer
• Employees and team members of the Customer, including the persons whom the Customer’s directory keeps as users
• Visitors to the careers pages and funnels published by the Customer
• Users of the customer portals operated by the Customer
• Guests whom the Customer invites to individual areas, appointments or documents
• Contact persons named in the Customer’s quotation, contract and invoice documents
• Recipients of the Customer’s satisfaction surveys
• Persons who access content shared by the Customer by link

(4) Insofar as brought in by the Customer or data subjects in application documents, uploads or free-text fields, special categories of personal data within the meaning of Art. 9 GDPR may exceptionally also be processed (e.g. information on severe disability or health in applications). The Customer ensures that such data is only processed if it has a legal basis for this under Art. 9(2) GDPR — for applicant data in particular § 26(3) of the German Federal Data Protection Act (Bundesdatenschutzgesetz – BDSG). Targeted, systematic processing of special categories is not part of the service description.

(5) The users’ accounts as such and their sign-in — with a password or via Google, Microsoft, LinkedIn or Facebook — as well as the logs of sign-ins (time, email address, IP address, browser identifier and result), including those via the company login, and the recording of sessions are not the subject of this agreement; nor are the passkeys that users set up for their sign-in, the confirmation before security-critical actions and the security entries on the accounts (for example on sign-in, sign-out and password change), even insofar as the Provider keeps them in the activity history of a workspace of the Customer. The Provider processes this data under its own responsibility in order to provide access and to protect the accounts and the platform against attacks (privacy policy, sections 4 and 8, where the periods are also stated). By contrast, the creation, modification and blocking of accounts and memberships on the basis of the information in the Customer’s directory (paragraph 1) and the information taken over in the process (paragraph 2) remain the subject of this agreement.

(1) The Provider processes personal data exclusively on documented instructions from the Customer — including with regard to the transfer of personal data to a third country or an international organisation (Art. 28(3)(a) GDPR) —, unless Union law or the law of a Member State obliges the Provider to process it; in such a case, the Provider informs the Customer of these legal requirements before processing, unless the law prohibits this.

(2) Instructions are generally given through the use of the platform’s functions (e.g. creating, changing, exporting, deleting records; activating integrations; setting up the company login, confirming domains and determining whether and with which role new users are added). The requests that the Customer’s directory makes with the SCIM access key generated by the Customer also count as instructions from the Customer. The platform uses the name that the directory transmits for a person for their account as a whole, including in workspaces of other customers. A deletion via this interface suspends the person’s membership in the workspace and ends their sessions; the membership is not deleted in the process, and the person’s account remains in existence. The Customer can remove the membership in the member management of its workspace. Instructions going beyond this require text form.

(3) If the Customer opens a support ticket, this counts as an instruction in text form to carry out the processing necessary to deal with the matter described in it. This includes viewing the affected workspace as well as creating and correcting records, insofar as this is necessary for dealing with the matter. The scope, start and end of such access result from § 4(2).

(4) The Provider informs the Customer without delay if it is of the opinion that an instruction violates the GDPR or other data protection provisions (Art. 28(3) sentence 3 GDPR).

(1) The Provider ensures that all persons authorised to process the data have committed themselves to confidentiality or are subject to an appropriate statutory obligation of confidentiality (Art. 28(3)(b) GDPR). Access to customer data is limited to the minimum necessary for operation, support and troubleshooting.

(2) To deal with a support ticket opened by the Customer, an authorised employee of the Provider may receive time-limited access to the affected workspace. The access is tied to the ticket, ends at the latest upon its closure, but in any case after 14 days, and is logged. It is not established covertly: the employee acts under their own identifier, is listed as a regular time-limited membership in the workspace and is shown in the history of the ticket. The Customer can end the access early at any time and, on request, receives a report on the course of the ticket and the actions taken in the process.

(3) Activities of the Provider in the Customer’s workspace that go beyond dealing with support requests (e.g. working together on campaigns or setup) take place exclusively with the Customer’s express approval. The Provider requests such access stating the reason; the Customer decides on the approval and determines the role with which the access is equipped. The access is time-limited, revocable at any time and logged. If the Customer runs its own workspaces for its customers, such collaboration there is excluded without separate approval.

(4) Irrespective of paragraphs 2 and 3, in urgent cases in which there is no support ticket and the Customer cannot be reached in time — in particular in the event of faults that can only be traced in the affected workspace —, the Provider may set up time-limited access. This route is only open to employees with authorisation to manage accounts, mandatorily requires a reason to be stated, is limited to a maximum of 90 days and is logged. This access too is kept as a regular time-limited membership and is visible to the Customer in the member list of its workspace; the Customer can end it at any time. The Customer is informed of the set-up without delay, both in the application and by email to the owner of the workspace; the information states the reason given verbatim, the role assigned and the end of the time limit. It is sent as a mandatory notification and cannot be unsubscribed from by the Customer.

The Provider takes the following technical and organisational measures to protect the personal data. The measures are continuously developed in line with the state of the art; the agreed level of protection must not be undercut in the process.

Place of processing: The application, database and file storage are operated in Germany (Nuremberg; additional backup copy in Falkenstein). Transfers to recipients outside Germany only take place within the scope of the sub-processors and integrations named in § 6. For independent monitoring, the Provider operates a further server in Helsinki (Finland, EU) at the same hosting provider; it checks the availability of the application from outside and only has access to operational data (run logs, monitoring probes, error messages), not to the content of the workspaces.

• Encryption: TLS for all connections — including the connection between application and database within the private network; encryption of sensitive stored access credentials (AES-256-GCM); passwords exclusively as a bcrypt hash.
• Physical and system access control: hosting in ISO-27001-certified data centres in Germany; server access only via personalised key-based sign-in; deactivated direct administrative login; intrusion prevention and system auditing. The Provider’s internal administration interface cannot be reached from the public network, but only via a secured network connection operated by the Provider itself.
• Authentication: Every account can activate two-factor sign-in via time-based one-time codes; the Customer can make it mandatory for all members of its workspace. The associated secret is stored encrypted (AES-256-GCM), and the recovery codes issued can each only be used once. An activated second factor is required on every sign-in route; when signing in with a passkey, the passkey itself provides it. Every account can set up passkeys according to the WebAuthn standard (a maximum of 20): the private key remains on the user’s device or in their password manager; what is stored is the public key, the identifier of the passkey, a name assigned by the user, a signature counter, the time of last use and technical characteristics of the authenticator (algorithm, transports, model identifier, backup status). Every sign-in with a passkey requires unlocking on the device (a PIN or a biometric characteristic that only the device checks), is bound to the address of the platform and answers a one-time challenge that is valid for five minutes and is deleted when redeemed; a signature counter running backwards is rejected. Security-critical actions — such as deleting or exporting a workspace, setting up or removing a passkey, generating API keys, changing the company login, payment details, plan or administrator rights — are only carried out by the server if the sign-in or the last confirmation of the session was no more than 15 minutes ago; otherwise, it requires renewed confirmation with a passkey, second factor or — for accounts without a second factor and without a mandatory company login — password; a new sign-in is always sufficient. Sign-in via Google, Microsoft or LinkedIn is only assigned to an existing account, and only via an email address confirmed by the respective service — for Microsoft organisational accounts only if Microsoft additionally confirms that the organisation owns the domain of the address; no account is created in the process. Only someone who has previously signed in to their account and linked it using their password signs in via Facebook; there is no assignment via the email address there. The Customer can set up sign-in via its company directory (company login via single sign-on with OpenID Connect or SAML 2.0, user provisioning via SCIM 2.0); it only applies to email domains that the Customer has confirmed as its own by means of a DNS entry. If it makes the company login mandatory, sign-in with a password and via the services mentioned is blocked for addresses from these domains — including for workspaces of other customers —, but not for members with addresses from other domains. Regardless of whether it makes the company login mandatory: if its directory blocks or removes a person, all their sessions are ended, including in workspaces of other customers. The client secret of the company login is stored encrypted (AES-256-GCM), the SCIM access key only as a hash value.
• Data access control: role-based authorisation system with fine-grained module and object rights; strict tenant separation — every query is restricted to the Customer’s workspace (workspace isolation at database level).
• Input control: audit logs for security-relevant actions (logins, changes to authorisations, data exports, administrative access, changes to the company login and generation and revocation of the SCIM access key).
• Availability control: Database backups are created automatically every day, encrypted with AES-256, kept for 14 days and additionally stored on a system separate from the database server; without the separately kept key, they cannot be read. The application and database servers are separate systems in a private network and are operated at the same data centre location in Germany (Nuremberg). The backups and a daily mirror of the uploaded files are additionally stored at a second location in Germany (Falkenstein); files deleted there remain recoverable for 14 days. Operation of the application itself across locations does not currently exist. Monitoring and process supervision monitor ongoing operation; a monitoring server at another location (Helsinki) additionally checks the application from outside and alerts the Provider even if the main location fails.
• Separation control: logical separation of the data per workspace (multi-tenant architecture with a mandatory workspace identifier on all tables); separate production and test environments.
• Resilience and defence: rate limiting on all API endpoints, security headers, CORS restriction, protection against brute-force attacks on all sign-in routes, the password reset and the SCIM interface (including proof-of-work, hashed reset tokens); a daily automatic integrity check reports unexpected changes to the system files.
• Resilience and regular review (Art. 32(1)(b) and (d)): The data carriers of the database server are encrypted; the key is not stored on the server but is released at start-up by one of two separate servers located at different locations. Restoring from backup and the failure of individual services are rehearsed regularly. Availability is measured continuously and shown as a monthly average under /status; operational alarms and resource checks report deviations to the Provider. Source code and the running application are automatically checked for vulnerabilities; every change goes through these checks before rollout. Retention periods are defined per type of data and enforced automatically. The application is operated on two application servers behind a load balancer; a second database server runs as a standby, and the switchover is carried out by the Provider according to a documented procedure, not automatically.
• Organisational measures: central secrets management via a dedicated password manager with service accounts; principle of least privilege; regular security audits of the source code.

(1) The Customer grants the Provider general authorisation (Art. 28(2) GDPR) to engage the further processors (sub-processors) listed below. By way of a contract concluded in writing or in electronic format, the Provider imposes on each sub-processor the same data protection obligations as are set out in this agreement, in particular sufficient guarantees for the implementation of appropriate technical and organisational measures in accordance with Art. 32 GDPR (Art. 28(4) sentence 1 GDPR). If a sub-processor fails to fulfil its data protection obligations, the Provider is liable to the Customer for the fulfilment of the sub-processor’s obligations (Art. 28(4) sentence 2 GDPR).

(2) The Provider informs the Customer of intended changes (addition or replacement of sub-processors) at least 30 days in advance in text form (email to the account owner’s address). The Customer may object to the change within 30 days for an important reason under data protection law. In the event of an objection, both parties have an extraordinary right of termination if the use of the new sub-processor is necessary for the provision of the services.

(3) In the case of transfers to third countries, the Provider ensures appropriate safeguards in accordance with Art. 44 et seq. GDPR (EU Standard Contractual Clauses, adequacy decisions, EU-US Data Privacy Framework).

(4) If the Customer connects its own email accounts or sending services to the platform, their provider is not a sub-processor of the Provider; the Customer is itself responsible for the permissibility of this connection under data protection law and for any separate data processing agreement that may be required. The same applies to the directory that the Customer connects for the company login and automatic user provisioning (e.g. Microsoft Entra ID, Okta, Google Workspace): it is a system of the Customer and not a sub-processor of the Provider. On the Customer’s instructions, the Provider only transmits there what sign-in and user provisioning require; the Customer is responsible for any transfer to a third country that results from the choice of directory.

Current sub-processors

Recipients acting under their own responsibility (not sub-processors)

(5) The recipients named below are commissioned by the Provider but are not sub-processors within the meaning of this agreement: as payment service providers, they are subject to their own regulatory obligations and therefore process the payment data under their own responsibility under data protection law, not on the Provider’s instructions. Payment processing is therefore not the subject of this processing on behalf; card and account data do not reach the Provider’s systems. The advance notification obligation under paragraph 2 does not apply to them.

• Stripe Payments Europe Ltd. (Dublin, Ireland) — Payment processing for subscriptions and invoices (processes payment data under its own responsibility; card and account data do not reach our servers). Intra-group transfer to the USA possible — EU Standard Contractual Clauses + EU-US Data Privacy Framework

(6) Third-party services connected by the Customer itself. If the Customer or one of its users connects a third-party service to the platform (Meta Platforms Ireland Ltd.; Google Ireland Ltd.; Microsoft Ireland Operations Ltd.; Zoho Corporation B.V. (Zoho Books); sevDesk GmbH; easybill GmbH; FastBill GmbH; bexio AG; BuchhaltungsButler GmbH), its provider is not a sub-processor of the Provider. The data protection relationship with this service is governed by the Customer’s own agreement with it; the Customer is itself responsible for the permissibility of the connection and for any separate data processing agreement that may be required. In the case of advertising and reach services, there may additionally be joint controllership under Art. 26 GDPR between the Customer and the service; this is to be assumed for the use of the Meta Pixel on pages operated by the Customer. The activation of an integration by the Customer counts as a documented instruction within the meaning of § 3; the transfer takes place exclusively within the scope of the integration activated in each case. Sign-in via Google, Microsoft, LinkedIn or Facebook is not an integration in this sense: every user chooses it for their own account, and the Provider processes it under its own responsibility (§ 2(5)); in doing so, it does not transmit any data from the Customer’s workspaces to these services.

The Provider supports the Customer with appropriate technical and organisational measures in responding to requests from data subjects (Art. 12–23 GDPR) (Art. 28(3)(e) GDPR). For this purpose, the platform provides in particular functions for access (machine-readable data export per data subject), rectification and erasure. If a data subject contacts the Provider directly, the Provider forwards the request to the Customer without delay.

The Meta connection is excluded (section 8 (c) of the privacy policy). If a person removes Funnalized in their Facebook settings or requests the deletion of their data via Facebook, Meta reports this directly to the Provider; Meta’s platform terms require the operator of the app to comply with this. By connecting a Meta Business account, the Customer instructs the Provider to carry out such reports itself: the Provider disconnects or deletes the connection of this person, including the information transmitted by Meta, in every workspace and notifies the owners of the workspaces concerned. Campaigns, ads and their evaluations remain unaffected.

(1) The Provider notifies the Customer of personal data breaches without delay after becoming aware of them, at the latest within 48 hours, with the information required under Art. 33(3) GDPR, insofar as available.

(2) Taking into account the nature of the processing and the information available to it, the Provider supports the Customer in complying with the obligations under Art. 32 to 36 GDPR (security of processing, notification of personal data breaches, data protection impact assessment, prior consultation).

(1) After termination of the user agreement, the Provider deletes all personal data processed on behalf or, at the Customer’s choice, returns it to the Customer, unless statutory retention obligations prevent this (Art. 28(3)(g) GDPR). The return takes place via the platform’s export functions in common, machine-readable formats (CSV, JSON), which the Customer can use itself at any time; on request, the Provider instead provides a complete data export. The Customer communicates its choice within the period under paragraph 2; if it does not make a choice, the Provider deletes.

(2) After the end of the contract, the data remains available for export for 30 days. This period exists in favour of the Customer; the Provider does not delete within this period, but only after it has expired — then without delay, at the latest within a further 30 days. At the express request of the Customer, the Provider deletes earlier; if the Customer triggers the deletion itself via the platform, the grace period under paragraph 3 also applies. Backups that still contain deleted data are overwritten as part of the daily backup run after 14 days at the latest.

(3) If the Customer triggers the deletion of its workspace itself via the platform, the workspace is marked for deletion and deleted 30 days later. This grace period exists in favour of the Customer and protects against accidental data loss; within the period, the owner of the workspace can revoke the deletion. The Provider carries out an immediate deletion without a grace period on the Customer’s express instruction in text form.

(1) The Provider provides the Customer with all information necessary to demonstrate compliance with the obligations under Art. 28 GDPR (Art. 28(3)(h) GDPR), in particular this agreement, the description of the technical and organisational measures (§ 5) and the list of sub-processors (§ 6).

(2) The Customer is entitled to carry out reviews — including inspections — or to have them carried out by a suitable auditor bound to confidentiality. Audits take place after reasonable advance notice, during normal business hours, without disproportionate disruption of operations. The Provider may refer to current attestations or certificates (e.g. ISO 27001 of the data centres), insofar as these cover the subject of the audit.

(1) In the event of contradictions between this agreement and the Terms, the provisions of this agreement take precedence with regard to the processing of personal data.

(2) German law applies. The invalidity of individual provisions does not affect the validity of the remaining provisions.

Questions about data protection or this agreement: datenschutz@funnalized.app · See also our privacy policy.