Data Processing Agreement
Version 2026-10-01
The moment you use EventDrop in a professional context, you are the controller for your event's photos – and we process them on your behalf. The full agreement is here to read, with both annexes. Concluding it takes a minute; the record then sits in your account.
BetaEventDrop for business is new, and we are developing it further with the first companies; feedback is welcome at office@gotzendorfer.at.
Mandatory content under Art. 28(3) GDPR
Every mandatory item is covered in the agreement. The list is meant to be ticked off – every row jumps to the place in the agreement.
- point (a)Section 4 Processing on Documented Instructions (Art. 28(3)(a) GDPR)
- point (b)Section 5 Confidentiality (Art. 28(3)(b) GDPR)
- point (c)Section 6 Technical and Organisational Measures (Art. 28(3)(c), Art. 32 GDPR)
- point (d)Section 7 Further Processors (Art. 28(2) and (4), Art. 28(3)(d) GDPR)
- point (e)Section 8 Assistance with the Rights of Data Subjects (Art. 28(3)(e) GDPR)
- point (f)Section 9 Assistance with the Obligations under Art. 32 to 36 GDPR (Art. 28(3)(f) GDPR)
- point (g)Section 10 Deletion or Return after the End of the Provision of Services (Art. 28(3)(g) GDPR)
- point (h)Section 11 Evidence and Audits (Art. 28(3)(h) GDPR)
- subpara. 2Section 4 Processing on Documented Instructions (Art. 28(3)(a) GDPR)
Conclude the agreement
You need an account to conclude it
The conclusion is recorded against your account, so it only works while signed in. You can read, print and pass on the agreement above without an account.
Sign in and concludeAgreement
Section 1 Parties, Subject Matter of this Agreement and Order of Precedence
This agreement on the processing of personal data on behalf of a controller (the “Agreement”) is concluded between:
{{controller.name}}, {{controller.address}}, represented by {{controller.representative}} — hereinafter the “Controller”.
Data protection officer of the Controller, where one exists: {{controller.dpo}}.
and
Bernhard Götzendorfer (sole proprietorship), Rittingergasse 15/11, 1210 Vienna, Austria, GISA number 38550959, GLN 9110028021398, email office@gotzendorfer.at — hereinafter the “Processor”, operating under the name EventDrop.
The Controller uses the Processor’s platform in the course of a professional or commercial activity. It is therefore the controller within the meaning of Art. 4(7) GDPR for the personal data processed within its event; the Processor is a processor within the meaning of Art. 4(8) GDPR and processes exclusively on documented instructions.
The Controller is the organisation named in the header of this Agreement, not the individual acting for it. Employees who operate the account or administer an event do not thereby become controllers themselves. This Agreement covers all events assigned to the account named, insofar as the organisation determines the purposes and essential means of the processing and the Processor carries it out for the organisation.
Where the Controller itself acts as a processor for a third party — for instance an agency acting for its client — the sub-processing required for that arrangement must be agreed separately; this Agreement does not cover that case. The Controller documents the purposes and legal bases of its processing, fulfils its information obligations towards data subjects, and names the persons authorised to issue instructions.
This version of the Agreement carries the version identifier 2026-10-01.1. The version and the date of conclusion are recorded in the Controller’s account and can be retrieved there at any time.
In the event of a conflict between this Agreement and the general terms and conditions of the service relationship, this Agreement prevails insofar as the processing of personal data on behalf of the Controller is concerned. In the event of a conflict between the body of this Agreement and its annexes, the body of the Agreement prevails.
Section 2 Subject Matter, Scope and Duration of the Processing
The subject matter of the processing is the provision of a platform through which guests at an event organised by the Controller upload image and video files, and through which those files can be displayed, managed, moderated and downloaded within an access-restricted album.
The Processor processes the personal data processed on behalf of the Controller exclusively for the purpose of providing that service and of fulfilling its obligations under this Agreement. Processing of that data for the Processor’s own purposes — in particular for advertising, profiling, the training of artificial intelligence models, or disclosure to third parties for their own purposes — does not take place.
This is to be distinguished from processing which the Processor carries out under its own responsibility and which is not the subject of this order: the handling and billing of the service relationship including the payment services used for it, reach and conversion measurement on the Processor’s own marketing pages, statutory obligations that apply to it directly as a provider, and the counting of the use of the service per event in order to measure and improve the service. Usage counting records counts of operations such as gallery views, downloads and views of the live photo wall — without names, session identifiers or IP addresses —, links them to the Controller’s account via the event, and is deleted together with the event, at the latest after one year. Those operations concern the Processor’s own contract, usage and visitor data, not the content of an event; they are described in the Processor’s privacy policy.
The duration of the processing is tied to the service relationship between the parties. The Agreement begins upon its conclusion and ends automatically upon termination of the service relationship, without any need for separate notice. There is no separate minimum term.
Obligations which by their nature extend beyond the end of the Agreement — in particular confidentiality under Section 5, deletion or return under Section 10, and the evidentiary obligations under Section 11 — continue to apply after termination until they have been fulfilled.
Section 3 Nature and Purpose of the Processing, Types of Personal Data, Categories of Data Subjects
Nature of the processing: collection, recording, organisation, storage, adaptation, retrieval, consultation, use, disclosure by transmission to the recipients authorised by the Controller, restriction, erasure and destruction — in each case within the scope of hosting and operating the platform.
Purpose of the processing: provision of access-restricted photo and video albums for the events of the Controller, including moderation, administration by the persons authorised by the Controller, and provision for download.
Types of personal data:
- Image and video files including the persons depicted therein, together with the technical metadata of those files (file name, file type, file size, image dimensions, and time of capture where contained in the file). Location data contained in the EXIF data of image files is removed on upload and is not stored.
- Names of guests provided voluntarily when uploading, commenting or reacting. Providing a name is optional; uploading without a name is possible and is the normal case.
- Comment texts written by guests and reactions to individual items, insofar as the Controller has enabled those functions for its event.
- A technical session identifier for the guest. It is generated randomly on the server, stored in an HttpOnly cookie, and serves to associate a guest’s own contributions, to enforce limits, and to group a guest’s contributions in the Controller’s event analytics. It is not linked to any user account and is not displayed to the Controller. It is a pseudonymous, not an anonymous attribute: it groups the contributions of the same device and is therefore capable of relating to a person.
- Reports concerning individual items, including the IP address of the reporting person as well as a contact address and language voluntarily provided by that person, used solely to process the report and to communicate the decision pursuant to Art. 16(5) of Regulation (EU) 2022/2065.
- Results of the automated image analysis (image description, keywords, a score used for pre-selection, a flag for potentially inappropriate content), insofar as the Controller has not disabled that function for its event (Section 12).
- Account and contact data of the persons the Controller has authorised for the event (email address, display name, language setting, role).
Categories of data subjects:
- Guests at the event who upload, comment on, react to or view content.
- Employees of the Controller, insofar as they attend the event or are depicted in uploaded material.
- Third parties depicted in uploaded image or video material without having uploaded it themselves.
- Persons whom the Controller has authorised to administer the event (host, co-administrators, helpers).
The Processor discloses the scope of the event analytics because it goes beyond a purely technical quota check: the basis of the count is the voluntarily provided name, failing which the session identifier. The analytics show the number of uploads per guest identifier and present the most active guests in a ranking ordered by upload count. That ranking is labelled with a serial number; neither the name provided nor the session identifier is displayed. There is no matching across several events, and no biometric identification.
This is therefore a pseudonymous evaluation capable of relating to an individual, not an anonymous statistic. The Controller determines whether it is necessary and permissible for its purpose, informs the data subjects accordingly, and observes any applicable co-determination rights where employees are affected. The Processor does not pre-empt that assessment.
The Controller may disable the ranking of the most active guests for each event individually. For an event with the ranking disabled, the ranking is neither produced nor displayed, and the number of uploads per guest identifier is not shown. For events created with the occasion “Corporate Event”, the ranking is disabled by default at creation; the Controller may change this default.
Special categories of personal data within the meaning of Art. 9(1) GDPR are not a purpose of the processing. The Processor points out that image material may in fact reveal such data; there is no targeted collection, evaluation or enrichment of such data. The Processor does not employ facial recognition, biometric identification, or any matching of persons across multiple images.
Section 4 Processing on Documented Instructions (Art. 28(3)(a) GDPR)
The Processor processes the personal data only on documented instructions from the Controller, including with regard to transfers of personal data to a third country or an international organisation, unless required to do so by Union or Member State law to which the Processor is subject; in such a case, the Processor shall inform the Controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.
The following constitute documented instructions: this Agreement including its annexes, the scope of service selected by the Controller within the service relationship, and the settings made in the application by the Controller or by the persons it has authorised — in particular access protection, runtime, enabling of the comment and reaction functions, and the settings governing the AI-assisted functions under Section 12.
Any further individual instructions shall be issued by the Controller in text form to the contact address stated in Section 8. Instructions given orally shall be confirmed in text form without undue delay.
If the Processor is of the opinion that an instruction infringes the General Data Protection Regulation or other data protection provisions of the Union or of the Member States, it shall inform the Controller thereof without undue delay (Art. 28(3), second subparagraph, GDPR). It is entitled to suspend execution of the instruction concerned until the Controller has confirmed or amended it.
The Processor does not access the content of the event unless this is necessary to provide the service, to remedy a fault, to process a report, to carry out an instruction of the Controller, or to comply with a legal obligation.
Section 5 Confidentiality (Art. 28(3)(b) GDPR)
The Processor ensures that the persons authorised to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. That obligation continues to apply after the respective activity has ended.
The Processor is a sole proprietorship without employees. The person authorised to process the data is the owner; he is himself directly bound to confidentiality. The deputy he has designated is authorised to process the data exclusively in the event of his unavailability under Section 9, and only after having been bound in text form to confidentiality and to data secrecy under § 6 of the Austrian Data Protection Act (DSG); before that, the deputy is given no access to the systems. This statement is made expressly, because wording suggesting an organisation with committed staff would not correspond to the actual circumstances.
Should employees, freelancers or contractors be engaged in future who may gain access to the Controller’s personal data, they shall be bound to confidentiality in text form and informed of the obligations arising from this Agreement before commencing their activity.
Access to personal data is limited to what is necessary for the respective task.
Section 6 Technical and Organisational Measures (Art. 28(3)(c), Art. 32 GDPR)
The Processor takes all measures required pursuant to Art. 32 GDPR to ensure a level of security appropriate to the risk. The measures in place at the time this Agreement is concluded are described in Annex 2 (Technical and Organisational Measures). Annex 2 forms part of this Agreement.
The measures are subject to technical progress and further development. The Processor is entitled to adapt them; the level of protection described in Annex 2 may not be reduced in doing so. Material changes are documented and communicated to the Controller on request.
The Processor reviews the effectiveness of the measures where there is a specific reason to do so and whenever there are material changes to the processing.
Section 7 Further Processors (Art. 28(2) and (4), Art. 28(3)(d) GDPR)
The Controller grants the Processor general written authorisation within the meaning of Art. 28(2), second sentence, GDPR to engage further processors. The further processors engaged at the time this Agreement is concluded are listed in Annex 1 (Sub-processors), together with their processing purpose and their place of processing. Annex 1 forms part of this Agreement.
Where the Processor intends to engage or replace a further processor, it shall inform the Controller in text form at least 30 days before the change takes effect — to the email address held in the Controller’s account and, where provided, to the data protection officer contact named in the Agreement — stating the name, the processing purpose and the place of processing.
The Controller may object to the intended change on data protection grounds within 14 days of receiving that information. Where the Controller has objected in time, the change does not take effect as against that Controller before its objection period has expired; because the objection period is shorter than the advance notice period under paragraph 2, at least the difference between the two periods remains thereafter, before the change takes effect, for a termination under this paragraph. No suspension of the change beyond that point for individual Controllers, and no waiver of a recipient required to operate the service, is undertaken (Annex 1, “Consequence of an objection”). In the event of an objection, the parties shall seek an amicable solution until the intended effective date of the change. If no such solution is reached by then, the Controller is entitled to terminate the service relationship and this Agreement extraordinarily with immediate effect before the change takes effect. Fees already paid in advance shall be refunded pro rata for the period that can no longer be used following termination. An objection shall not result in any disadvantage for the Controller.
The Processor imposes on each further processor, by way of a contract, the same data protection obligations as are set out in this Agreement, in particular sufficient guarantees to implement appropriate technical and organisational measures in such a manner that the processing meets the requirements of the General Data Protection Regulation. Where a further processor fails to fulfil its data protection obligations, the Processor remains fully liable to the Controller for the performance of that further processor’s obligations, as for its own conduct (Art. 28(4) GDPR); the extent of that liability is governed by Section 13.
Ancillary services obtained by the Processor from third parties which are not intended to involve access to the Controller’s personal data — such as telecommunications and postal services or cleaning services — do not constitute the engagement of a further processor within the meaning of this provision. The Processor nevertheless takes appropriate precautions to protect the data in those cases as well.
Section 8 Assistance with the Rights of Data Subjects (Art. 28(3)(e) GDPR)
Taking into account the nature of the processing, the Processor assists the Controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the Controller’s obligation to respond to requests for exercising the data subject’s rights laid down in Chapter III of the General Data Protection Regulation.
The following routes, already implemented in the application, are available to the Controller for this purpose:
- Deletion of individual images, videos, comments and reactions by the Controller and the persons it has authorised, directly through the interface (Art. 17 GDPR).
- Hiding individual items as a measure less severe than deletion, for example while processing an objection under Art. 21 GDPR.
- Complete deletion of an event including all associated records and all stored files, including derived thumbnails and uploaded logos.
- Export of the records stored in the Controller’s account via the account settings, as a structured JSON file (Art. 15 and Art. 20 GDPR). The export covers the records on the account, events, uploads, comments, reactions, authorisations, reports and the further tables held against the account; it contains the metadata of the image and video files, not the files themselves. Those are provided separately via the next route. The export alone is therefore not a complete return within the meaning of Section 10.
- Download of an event’s image material as an archive file. Where that route is not included in the scope of service booked, the Processor shall make the material available on request in text form within 14 days; the right to return under Section 10 exists irrespective of the scope of service booked.
Where a data subject contacts the Processor directly, the Processor shall forward the matter to the Controller without undue delay and shall not answer it itself, unless legally obliged to do so. Contact address of the Processor for all matters arising from this Agreement: office@gotzendorfer.at.
The assistance under this Section is included in the fee for the service. Reimbursement of expenses may be considered only for demonstrably exceptional manual effort which does not originate from the Processor’s sphere of responsibility, and only insofar as it has been agreed in advance in text form. Compliance with statutory time limits may not be made contingent upon any such agreement.
Section 9 Assistance with the Obligations under Art. 32 to 36 GDPR (Art. 28(3)(f) GDPR)
Taking into account the nature of the processing and the information available to it, the Processor assists the Controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 of the General Data Protection Regulation.
Where the Processor becomes aware of a personal data breach affecting the Controller’s data, it shall notify the Controller without undue delay and in any event within 48 hours of becoming aware. The binding contact address of the Controller for notifications under this Section, for notices under Section 7 and for any other declarations arising from this Agreement is the email address held in its account; where a data protection officer contact is stated in the header of this Agreement, the notification is additionally sent to that contact. The Controller keeps both entries up to date; a change takes effect once stored in the account or, as the case may be, upon documented receipt by the Processor. The notification shall contain, where available:
- a description of the nature of the breach, including where possible the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned;
- the name and contact details of a point of contact where more information can be obtained;
- a description of the likely consequences of the breach;
- a description of the measures taken or proposed to address the breach and, where appropriate, to mitigate its possible adverse effects.
The Processor maintains a permanently reachable point of contact for notifications under this Section and for requests under Sections 8 and 10. It has designated a deputy. In the event of unavailability, the deputy is given access to the necessary systems and information after having been bound in text form to confidentiality under Section 5; the time limits under this Agreement apply irrespective of the availability of any individual person. The point of contact is named in the preamble; the identity of the deputy is disclosed to the Controller on request.
Where not all information is available immediately, the Processor shall first notify the information available to it and supplement it without undue delay. The Processor makes clear: the 72-hour notification deadline under Art. 33(1) GDPR applies to the Controller. The notification obligation under this Section exists precisely so that the Controller is able to meet that deadline at all.
The Processor shall not make any notification to the supervisory authority or to data subjects on behalf of the Controller unless the Controller expressly instructs it to do so.
On request, the Processor assists the Controller with a data protection impact assessment pursuant to Art. 35 GDPR and with prior consultation pursuant to Art. 36 GDPR by making available the information on the processing available to it, in particular Annex 1 and Annex 2 in their respective applicable versions.
Section 10 Deletion or Return after the End of the Provision of Services (Art. 28(3)(g) GDPR)
After the end of the provision of processing services, the Processor shall, at the choice of the Controller, delete or return all personal data and delete existing copies, unless Union or Member State law requires storage of the personal data.
The Controller shall communicate its choice in text form. If it does not communicate a choice within 30 days of termination, the data shall be deleted. Deletion is the default because it is the outcome more favourable to data protection.
Routes implemented:
- Every event carries an expiry date. After expiry the content is no longer served; after a further 30 days the records and the stored files are deleted automatically.
- The Controller may delete an event itself at any time. Deletion covers the associated records across all tables involved as well as the stored files including derived thumbnails and uploaded logos.
- Where the Controller deletes its account, a period of 30 days begins during which the deletion can still be averted; thereafter the account and all associated events are permanently deleted.
- Before any deletion, the routes for return set out in Section 8 remain open to the Controller (export of account data, download of image material).
Excluded from deletion are exclusively those records which the Processor must retain on the basis of a statutory retention obligation, in particular payment and accounting records pursuant to § 132 of the Austrian Federal Fiscal Code (BAO), as well as the minimised record of the conclusion of this Agreement under Section 14. Those records concern the contractual relationship between the parties, not the content processed within the event; image and video files, comments, guest names and session identifiers are subject to no retention obligation and are deleted in full. The excluded records are restricted in processing for the duration of the retention period.
If a request for return is received in text form before the applicable deletion deadline expires, the Processor completes the return before the data concerned is finally deleted. The Processor expressly points out that this is a manually operated procedure: the automated deletion runs have no per-event suspension. It ensures the precedence of the request for return by making the data concerned available after receipt of the request or — where the remaining time is insufficient — by extending the term of the event concerned until the return is complete, but for no longer than 30 days from receipt of the request. The Controller receives confirmation in text form that the return is complete.
The Processor shall confirm the deletion in text form on request.
Section 11 Evidence and Audits (Art. 28(3)(h) GDPR)
The Processor makes available to the Controller all information necessary to demonstrate compliance with the obligations laid down in Art. 28 GDPR and allows for and contributes to audits, including inspections, conducted by the Controller or another auditor mandated by the Controller.
On request, the Processor shall in particular make available:
- Annex 1 and Annex 2 in their respective applicable versions;
- information on the places of processing of the further processors engaged;
- information on the status of the contracts concluded with further processors;
- information on the implementation of the measures described in Annex 2.
The following conditions apply to on-site or remote inspections. They serve to order the procedure and neither exclude nor restrict the right to audit:
- Announcement in text form with a notice period of, as a rule, 14 days. Where there is a specific reason, in particular following a personal data breach or at the request of a supervisory authority, the audit shall be enabled without undue delay and without observing that notice period.
- Conduct during usual business hours and without disproportionate disruption of operations.
- The auditor is bound to confidentiality and is not a competitor of the Processor. Any alleged conflict of interest must be substantiated by the Processor in concrete terms; the selection of a suitable independent auditor remains with the Controller.
- As a rule once per calendar year. Where there is a specific reason within the meaning of the first bullet point, that limitation does not apply.
Each party bears its own costs arising from an audit. Reimbursement of expenses may be considered only for repeated audits within a calendar year that are requested without a specific reason; it is agreed in advance in text form, is reasonable in amount, and must not impede the effective exercise of the right to audit. Audits for a specific reason, and compliance with statutory time limits, are not delayed by questions of cost or of auditor selection.
The Processor discloses the following: there is no certification pursuant to Art. 42 GDPR and no attestation under a recognised audit standard. Where other providers present such a document, the information under paragraph 2 and the description in Annex 2 take its place here. This disclosure is made expressly so that the Controller can take it into account in its selection decision under Art. 28(1) GDPR, rather than discovering it only during an audit.
Section 12 Places of Processing and Transfers to Third Countries
The places of processing are stated per further processor in Annex 1. A blanket assurance that all processing takes place exclusively within the European Union or the European Economic Area is expressly not given. This clarification is made because such an assurance would not hold true in relation to individual service providers engaged; the per-provider statement in Annex 1 is verifiable, a blanket statement would not be.
For the AI-assisted functions, the Processor engages Google LLC, United States of America, as a further processor. This concerns the automated image analysis, the suggestion of an invitation text, the suggestions offered when creating an event, and the support chat. Where image analysis is enabled, the image concerned is transmitted to Google for analysis.
The basis for the transfer is the European Commission’s adequacy decision on the EU-US Data Privacy Framework pursuant to Art. 45 GDPR; Google LLC is certified under that framework.
Should that adequacy decision or the recipient’s certification cease to apply, the Processor will base the transfer on the European Commission’s standard contractual clauses pursuant to Art. 46(2)(c) GDPR together with any necessary supplementary measures, and will inform the Controller in advance of the basis then relied upon. If no viable basis can be established, the transfer will be discontinued; in that case the function concerned ceases to be available — this Agreement does not.
The Controller may disable the event-level AI functions for its event. These are two separately switchable functions: the automated image analysis including image description and pre-selection, and the suggestion of an invitation text. Where image analysis is disabled, the uploaded images of that event are not transmitted to Google for that analysis; where the invitation text suggestion is disabled, that event’s details are not transmitted for that purpose.
The Processor expressly points out the limit of that opt-out: the event-level switches do not end every transfer of event data to Google. Two further AI-assisted functions are account-level rather than event-level — the suggestions offered when creating an event, and the support chat. A switch at event level does not reach them.
Neither processes image material. In the support chat, however, in addition to the text entered by the user, the email address of the signed-in account and, for up to five of the most recently created events, their title, plan, active state, storage used and expiry date are transmitted to Google automatically, so that the answer fits the account. The suggestion offered when creating an event concerns only the details entered there, such as an event title. Anyone wishing to exclude those transfers should not use those two functions; there is no separate switch for them.
Section 13 Liability and Limitation of Liability, Termination, Form, Governing Law
Towards data subjects, the parties are liable under Art. 82 GDPR. That liability is neither excluded nor limited by this Agreement. The following paragraphs govern exclusively the relationship as between the parties.
As between the parties, each party bears the damage for which it is responsible. Claims of one party against the other for damages or for reimbursement of expenses arising from this Agreement or from the processing of personal data on the Controller’s behalf are governed by this Section, on whatever legal basis the claim is founded — including the service relationship, tort, or the apportionment under Art. 82(5) GDPR. The liability provisions of the general terms and conditions of the service relationship do not apply to those claims. Where the parties have agreed standard contractual clauses of the European Commission, those clauses prevail in the event of a conflict.
Each party is liable without limitation for intent and gross negligence, for damage resulting from injury to life, body or health, and under the Austrian Product Liability Act (Produkthaftungsgesetz).
In cases of slight negligence, each party’s liability for all damage events of a calendar year together is limited to the higher of the following two amounts: EUR 10,000 or the sum of the fees paid, and not refunded, for the service via the Controller’s account in the twelve months preceding the first damage event of that calendar year. A damage event is attributed to the calendar year in which the event giving rise to the damage occurred. Several items of damage arising from the same cause constitute a single damage event, attributed to the calendar year of the first occurrence. Lost profit is not compensated in cases of slight negligence. The parties agree on this limitation having regard to the relationship between the fee for the service and the potential damage.
The limitation covers all damage and expenses of a damage event, however they are described, in particular costs of investigating and containing a personal data breach, of notifying the supervisory authority and notifying data subjects, of legal advice and legal proceedings and of restoring data, as well as payments to data subjects and fines. Whether any such item is recoverable at all is determined by law; this paragraph does not create any claim.
For further processors, the Processor is liable to the Controller as for its own conduct (Art. 28(4) GDPR): their fault is attributed to the Processor, and the same rules apply as for its own fault, including the limitation in cases of slight negligence. The obligations under this Agreement and its annexes are binding; they do not give rise to any liability without fault beyond what the law provides. Words such as “ensure” or “make sure” denote the respective obligation, not a guarantee.
Annex 2 discloses that there is no backup for the file store holding image and video files. Material that the Controller needs permanently or independently of the service is secured by the Controller itself using the means set out in Section 8. If it fails to do so although this was possible and reasonable for it, this is taken into account as contributory fault in the event of a loss.
Where a party is held liable by a data subject or another third party, or is fined by a supervisory authority, and intends to seek recourse against the other party for that reason, it shall notify the other party thereof without undue delay in text form and give it the opportunity to take part in the defence. An acknowledgement or settlement without the other party’s consent does not bind the other party; it may object that the claim did not exist or did not exist in that amount.
The term follows from Section 2. In addition, the Controller may terminate this Agreement and the service relationship extraordinarily with immediate effect if it objects to a change of further processors under Section 7 and no amicable solution is reached, or if the Processor seriously breaches obligations under this Agreement and fails to remedy the breach within a reasonable period despite being requested to do so.
Amendments and supplements to this Agreement require the consent of both parties in text form; this also applies to any amendment of this form requirement. Transmission by email is sufficient. Publication of an amended version together with continued use of the service is not sufficient; a deemed acceptance through continued use, as provided for in the general terms and conditions of the service relationship, does not apply to this Agreement. Updates to Annexes 1 and 2 are made in accordance with the procedure set out in Sections 6 and 7 and do not require a separate amendment of the Agreement.
Austrian law applies, excluding its conflict-of-law rules and excluding the United Nations Convention on Contracts for the International Sale of Goods. The General Data Protection Regulation and the mandatory data protection provisions to which the Controller is subject at its place of establishment remain unaffected.
Where the Controller is an entrepreneur within the meaning of the Austrian Commercial Code, the exclusive place of jurisdiction for all disputes arising from this Agreement is Vienna, Austria. Mandatory statutory places of jurisdiction remain unaffected.
Should any provision of this Agreement be or become invalid or unenforceable, the validity of the remaining provisions shall remain unaffected. This also applies within the liability provisions of this Section: the limitation to a maximum amount, the exclusion of lost profit, the rule on data backup and the rules on recourse are independent of one another. The parties shall replace the invalid provision with a valid provision that comes closest to the economic and data protection purpose of the invalid provision.
Section 14 List of Annexes
The following annexes form part of this Agreement:
- Annex 1 — Further processors (sub-processors), stating the processing purpose, the place of processing and the basis for any transfer to a third country.
- Annex 2 — Technical and organisational measures pursuant to Art. 32 GDPR.
Changes to Annex 1 are governed exclusively by Section 7. Equivalent or improving technical adjustments to Annex 2 are permitted; the Processor actively notifies the Controller of material changes. Neither the purpose nor the scope of the data may be extended thereby, and the agreed level of protection may not be lowered.
The Processor keeps the wording of every concludable version of this Agreement, including both annexes, unchanged and assigns it to the version identifier under which the Agreement was concluded. A later change to the text creates a new version identifier and does not replace a record of an agreement already concluded. The full record of conclusion (company details, authorised representative, data protection officer contact) is kept for as long as the Controller’s account exists; for that period the Processor will make the contract document available again in text form on request. If the Controller deletes its account, the Processor retains a minimised record — company name, country, version identifier and language version, time of conclusion and of account deletion, and a hash of the account identifier, without any personal details and without the address — and deletes it 3 years after the end of the calendar year in which the account was deleted. This record serves solely as evidence of the conclusion of this Agreement in the event of legal claims or enquiries from a supervisory authority. Anyone who needs the full contract document beyond that point should retrieve it before deleting the account.
The version of the annexes applicable at the time of conclusion, identified by its version identifier, is authoritative. It forms part of the generated contract document and is recorded in the Controller’s account together with the version identifier 2026-10-01.1. The respective current version is additionally available at any time.
Annex 1 — Further processors (sub-processors)
Version of this annex: 2026-10-01 · Version of the continuously maintained list: 2026-09-30 (/datenschutz)
The continuously maintained version of this list lives in the privacy policy. The version stated below is the one that applies to your conclusion.
Supabase Pte. Ltd.
- Role
- sub-processor
- Seat
- Singapur
- Purpose and place of processing
- Database, authentication and file storage. The project is operated in region eu-central-1 (Frankfurt am Main).
- Data categories
- Controller's account data (email address, display name, language preference)
- Event data (title, description, date, runtime, settings)
- Photos and videos uploaded by guests, including technical metadata
- Comments, reactions and photo reports
- Randomly generated guest session identifiers
- Third country and transfer basis
- Seat in Singapore; there is no adequacy decision of the European Commission for Singapore. Transfer basis: EU Standard Contractual Clauses (Art. 46(2)(c) GDPR), incorporated in the provider’s data processing addendum. Database, authentication and file storage are operated in the EU region eu-central-1.
Stripe Inc.
- Role
- EventDrop's own responsibility (not a sub-processor)
- Seat
- San Francisco, USA
- Purpose and place of processing
- Processing of payments for the contract between EventDrop and the controller. Guest data is not transmitted.
- Data categories
- Email address and billing details of the ordering person
- Payment and transaction data
- Third country and transfer basis
- Seat in the USA, DPF-certified. Transfer basis: Art. 45 GDPR (adequacy decision, EU-US Data Privacy Framework), with EU Standard Contractual Clauses (Art. 46 GDPR) as a fallback.
Vercel Inc.
- Role
- sub-processor
- Seat
- San Francisco, USA
- Purpose and place of processing
- Application hosting and content delivery. Server functions are pinned to region fra1 (Frankfurt am Main). The global delivery network serves not only static design assets but also the photo thumbnails of accessible events. The provider’s visitor and page-speed measurement is additionally embedded.
- Data categories
- IP addresses and request metadata of visitors and guests
- Request and response content for the duration of processing
- Cached thumbnails of the uploaded photos
- Page visited, referrer, device and country signal of the visitor and page-speed measurement
- Third country and transfer basis
- Seat in the USA, DPF-certified. Transfer basis: Art. 45 GDPR, with EU Standard Contractual Clauses (Art. 46 GDPR) as a fallback.
Resend Inc.
- Role
- sub-processor
- Seat
- San Francisco, USA
- Purpose and place of processing
- Delivery of transactional email, in particular invitations to co-administrators and helpers of an event, notifications about new uploads, and notices on runtime, expiry and deletion.
- Data categories
- Recipient email address and first name
- Title and dates of the event concerned
- In notifications about new uploads, the display name voluntarily provided by guests
- On escalation from the support chat, additionally the conversation transcript and its summary
- Third country and transfer basis
- Seat in the USA, DPF-certified. Transfer basis: Art. 45 GDPR.
Google LLC
- Role
- sub-processor and EventDrop's own responsibility
- Seat
- Mountain View, USA
- Purpose and place of processing
- Two distinct purposes. (1) As a sub-processor via the Google Gemini interface: automated image screening and captioning, and suggestions for the invitation text — these two can be switched off per event; event suggestions and the support chat, by contrast, run account-wide and are not reached by a per-event switch. In the support chat, in addition to the text entered, the account email address as well as the title, plan, status and expiry date of up to five associated events are transmitted. (2) Under EventDrop’s own responsibility: conversion measurement for EventDrop’s own Google Ads campaigns; this purpose only occurs with the person’s marketing consent and processes no photos and no guest data. Transmitted are the type of the event created and the order data named below; the hash of an email address is personal data, not an anonymous value.
- Data categories
- For purpose (1): image content of uploaded photos including event context, event title and description, support chat messages including account and event context
- For purpose (2): type of the event created, order value, currency, the payment session identifier as an order reference, email address as a SHA-256 hash, advertising click identifier
- Third country and transfer basis
- Seat in the USA, DPF-certified. Transfer basis: Art. 45 GDPR (adequacy decision, EU-US Data Privacy Framework).
Functional Software Inc. (Sentry)
- Role
- sub-processor
- Seat
- San Francisco, USA
- Purpose and place of processing
- Error and performance monitoring of the application. Before transmission, email addresses, access capabilities and session cookies are removed server-side; automatic collection of IP addresses is switched off. This is filtering, not anonymisation: technical identifiers (event, upload and user identifiers) remain, and messages from the rate limiter may contain identifiers that include an IP address. Content Security Policy violation reports are sent by the browser directly to this recipient; they contain the address visited and do not pass through this scrubbing.
- Data categories
- Technical error contexts (call path, browser details, timestamps)
- IP address, insofar as it is transmitted by the network path rather than by the application
- Third country and transfer basis
- Seat in the USA, DPF-certified. Transfer basis: Art. 45 GDPR (adequacy decision, EU-US Data Privacy Framework), in the alternative EU Standard Contractual Clauses (Art. 46 GDPR).
Upstash Inc.
- Role
- sub-processor and EventDrop's own responsibility
- Seat
- San Francisco, USA
- Purpose and place of processing
- Two distinct purposes. (1) As a sub-processor: request rate limiting on the functions of the controller’s events (uploading, access code checks, comments, reactions, reports, thumbnails, exports, invitations) and on forwarding error reports from the browser to the application’s error monitoring (see the Sentry entry) to protect against abuse and overload, and the bundling of upload notifications so that the controller receives an hourly summary instead of individual emails. (2) Under EventDrop’s own responsibility: request rate limiting on functions of EventDrop’s own contractual relationship (withdrawal function, purchase and redemption of package codes, generating the data processing agreement PDF, trial access to the sister product FotoDrop, sign-in and ordering). All rate-limiting entries expire automatically with their time window (one minute to 24 hours), at the latest after twice the window.
- Data categories
- For purpose (1): IP address of the requesting party, combined with the event’s access code for per-event limits; for helper invitations and AI text suggestions the user identifier of the signed-in account instead of the IP address; request counters per time window
- For purpose (1), for bundling: event identifier, identifiers of the new uploads and the display names voluntarily provided by guests, each with a two-hour expiry; markers against duplicate emails per event or upload (technical identifiers only)
- For purpose (2): IP address, combined with the page path when counting page arrivals; the user identifier of the signed-in account when redeeming package codes, requesting a FotoDrop trial, buying a package and generating the data processing agreement PDF; for the withdrawal function the SHA-256 hash of the recipient address of the confirmation of receipt (never the address itself), time window 24 hours; request counters per time window
- Third country and transfer basis
- Seat in the USA. Transfer basis: EU Standard Contractual Clauses (Art. 46 GDPR).
Meta Platforms Ireland Limited
- Role
- EventDrop's own responsibility (not a sub-processor)
- Seat
- Dublin, Irland
- Purpose and place of processing
- Conversion measurement for EventDrop's own Facebook and Instagram advertising. This purpose only takes effect with the person’s marketing consent. Photos, event content and guest data are not transmitted; what is transmitted is the type of the event created and the order data named below. The hash of an email address is personal data, not an anonymous value.
- Data categories
- Advertising network browser identifier (cookie `_fbp`)
- Page view on the marketing pages, event type when an event is created
- Order value, currency, order reference, email address as a SHA-256 hash
- Third country and transfer basis
- Seat in Ireland (EU). Transfer to Meta Platforms, Inc. (USA) is possible; Meta is DPF-certified. Transfer basis: Art. 45 GDPR.
Hetzner Online GmbH
- Role
- sub-processor
- Seat
- Gunzenhausen, Deutschland
- Purpose and place of processing
- Operation of EventDrop's own servers: rendering the recap videos from an event's photos, and generating the PDF documents (QR print card, data processing agreement). EventDrop operates those services itself; Hetzner provides the machines only.
- Data categories
- For the recap: the event's photos themselves, fetched via short-lived signed references, together with their machine-generated image description
- For the QR print card: the event name and the host's free text
- For the data processing agreement: the controller's company details (name, address, authorised representative, and the data protection officer's contact where provided)
- Third country and transfer basis
- Seat and processing in Germany, i.e. within the EU. No transfer to a third country takes place; neither an adequacy decision nor Standard Contractual Clauses are required.
General authorisation
The controller grants the processor the general written authorisation pursuant to Art. 28(2) sentence 2 GDPR to engage the sub-processors listed in this annex.
The current version of the list is published at /datenschutz (section 5 of the privacy policy) and is the authoritative, continuously maintained version. The version of the list as at the date of this annex is 2026-09-30.
The processor contractually binds every sub-processor to data protection obligations equivalent to those under this contract. The processor remains fully liable to the controller (Art. 28(4) GDPR).
What counts as a change
The following count as notifiable changes: adding a further sub-processor, replacing an existing one, adding a NEW PROCESSING PURPOSE for an already listed sub-processor, and changing the legal basis relied upon for a transfer to a third country.
Purely editorial changes to this annex that affect neither recipient, purpose, data categories nor transfer basis are not notifiable.
Advance notice and objection
The processor notifies an intended change in text form at least 30 days before it takes effect, to the email address held in the controller’s account and, where provided, to the data protection officer contact named in the agreement. The notice names the recipient, its seat, the processing purpose, the data categories concerned and the transfer basis.
The controller may object to the change in text form within 14 days of receiving the notice. An objection must be reasoned, and the reasons must relate to data protection.
The processor puts the change into production only after the notice has been sent and the advance notice period has expired. This sequence is a contractual obligation, not a mere intention. For a controller that has objected within the deadline, the change does not take effect before that objection period has expired. Because the objection period is shorter than the advance notice period, at least the difference between the two periods remains after any timely objection before the change takes effect; within that window the controller may terminate under the following section before any data reaches the rejected recipient.
Consequence of an objection
In the event of a reasoned objection, the parties shall seek a mutually agreeable solution until the intended effective date of the change. If no such solution is reached by then, the rights of the controller regulated in Section 7 of the agreement apply: it may terminate the service relationship and the agreement extraordinarily with immediate effect before the change takes effect; fees already paid in advance are refunded pro rata for the period that can no longer be used. An objection shall not result in any disadvantage for the controller.
The processor does not undertake to forgo a sub-processor whose service is required to operate the service, nor does it undertake to suspend a disputed transfer for the duration of the clarification. Neither would be keepable for a service of this size; the right to terminate BEFORE the change takes effect takes their place.
Scope of this annex
This annex lists every service provider that processes personal data in connection with the service and states, per entry, whether processing is carried out on behalf of the controller or exclusively for EventDrop’s own purposes.
Entries serving exclusively EventDrop's own purposes — payment processing for the contract between the parties and conversion measurement for EventDrop's own advertising — are not sub-processors of the commissioned processing. They are listed here so that this annex and the published list stay congruent.
No certification
The processor holds no certification under Art. 42 GDPR and no ISO/IEC 27001 certification. Copies of the agreements in place with the sub-processors are provided on request at office@gotzendorfer.at.
Annex 2 — Technical and organisational measures pursuant to Art. 32 GDPR
Version of this annex: 2026-09-30
Every measure here is verifiable in the code. What is not built is not listed.
Confidentiality
- Row level security is enabled for the application-schema tables holding personal data. Cross-table checks predominantly run through encapsulated database functions executed with their owner’s privileges, so that a rule does not depend on the caller holding privileges on another table. Excluded are a few older rules which carry the check inline. Some of those functions set the search path explicitly; the remainder instead qualify their identifiers with the schema.
- The anonymous database role holds no privileges on the tables containing photo, comment and reaction data. Anonymous application queries against those tables run through server-side read paths that re-evaluate the visibility rules. Retrieval of the media files themselves is a separate path, described under “retrieval capabilities”, and is not covered by this statement.
- Both file stores — uploaded photos and videos, and rendered recap videos — are created as non-public. Retrieval via an unsigned public object address is therefore blocked. Authorised retrieval happens through signed addresses or through checked application endpoints; a signed address does not require a logged-in account, but its server-side issuance.
- Original files and gallery media are served through short-lived, server-signed retrieval capabilities valid for one hour and renewed before expiry while the page remains open. Thumbnails are excluded from that mechanism and are served through a server-checked endpoint which, on an event with an access code, requires a passed access check; those responses are cached in the delivery network and are purged by tag on hiding, deletion or deactivation. Separate, longer-lived retrieval capabilities are issued for rendering the recap videos.
- An event’s optional access code is stored exclusively as a bcrypt hash. A passed access check is evidenced by an HttpOnly cookie carrying an HMAC-SHA256 signature valid for 24 hours; for signatures of equal length the comparison runs without an early exit from the comparison loop. The evidence is bound to the event and its expiry time, not to the access code currently in force: changing the access code does not immediately invalidate evidence already issued, it lapses with its 24 hours.
- A role model with four roles (owner, co-administrator, helper, guest) and a centrally maintained permission matrix is in place. The matrix is evaluated server-side before an action is carried out; selected role and ownership boundaries are additionally enforced at database level. Excluded from that additional enforcement is the helper’s restriction to the visibility field: in PostgreSQL a write policy cannot be restricted to individual columns, which is why that restriction is enforced in server-side code alone.
- Separation control: every content record belongs to exactly one event, and every event to exactly one account. For the photo, comment and reaction tables that assignment is additionally enforced at database level: an authenticated user without a role in an event does not receive those records, not even by bypassing the application. Account and billing data as well as the security log exist alongside and belong to the account or to the operation, not to an event.
- On the protected lookup of an individual photo, “does not exist” and “not visible” are answered identically; a photo identifier cannot be used there to probe the existence of third-party content. Only the prompt to enter the access code is shown separately: it can arise solely for content that is visible in any event, and it is a prompt, not a disclosure. No general prohibition on any inference of existence across all paths is promised.
- Guests upload without an account. An upload is linked to a guest through a randomly generated session identifier held in a signed HttpOnly cookie; providing a name is optional. The processor employs neither facial recognition nor biometric identification; persons are not re-identified across images. The uploads of one guest session are, however, grouped: in the event analytics the controller sees a ranking of active guests ordered by upload count, unless that ranking has been disabled for the event. That overview is NOT by name, and the session identifier itself is not disclosed to the controller; the evaluation is pseudonymous, not anonymous. The controller decides whether it is necessary and permissible for its purpose, informs the data subjects and observes co-determination rights where applicable.
- The public application is served over HTTPS and sets HTTP Strict Transport Security with a two-year validity including subdomains. For EventDrop’s own services addressed server-side, the use of HTTPS is enforced in production.
- HTML pages carry a Content Security Policy with a per-request nonce in the enforcing header; global response headers complement that protection, preventing embedding in third-party pages, suppress MIME type sniffing, restrict referrer disclosure, and disable camera, microphone and geolocation access via the permissions policy.
- In error and performance monitoring, email addresses, access capabilities (tokens, signed media addresses) and session cookies are removed before transmission; scrubbing is configured at every initialisation point of the monitoring service, and automatic collection of IP addresses is switched off. This is filtering, not anonymisation: technical identifiers expressly remain — event and upload identifiers as well as the identifier of the signed-in account — because without them no error could be attributed. Messages from the rate limiter may contain identifiers that include an IP address. Content Security Policy violation reports are sent by the browser directly to the monitoring service and do not pass through this scrubbing. That automatic IP collection is switched off does not mean the recipient does not receive the source IP of the network connection.
- Browser-side error monitoring records no session replay: no replay integration is registered, and the corresponding sampling rate is set to zero. It does not follow that the remaining telemetry collected is free of personal data; the preceding statement on scrubbing applies to that.
- Credentials are supplied through environment variables and are not held in source code. A secret scanner is configured as a blocking step ahead of source commits and runs again in the deployment pipeline; if it finds no executable scanner it aborts rather than letting an unscanned state through. A developer can explicitly bypass the local step; the pipeline step cannot be bypassed.
- The privileged database key is used exclusively server-side. The module that reads it is marked server-only and the key itself is not exposed as a public environment variable; an import from browser code therefore fails the build.
Integrity
- For image files the file type is determined server-side from the file bytes; if it does not resolve to a permitted image type the upload is rejected. Files declared as HEIC or HEIF are excluded, because their signatures vary by capture device: for those the subsequent conversion to JPEG takes the place of signature detection and rejects the upload when the bytes are not HEIC. For video files the client-declared type is relied upon, and stored, where signature detection yields no result.
- Location data and remaining EXIF metadata are stripped from image files server-side on upload by re-encoding the file; the stored file no longer carries them. The capture time is read out before stripping and stored as a separate field of the upload record, so that photos can be ordered chronologically. Excluded from stripping are images in GIF format, stored unchanged in order to preserve animation and palette, as are video files, from which no metadata is removed.
- If the server-side re-encoding of an image fails, the upload is rejected: no released upload record is created, and the unmodified original file is not taken into the event’s holdings. For large files the browser uploads the original into the non-public file store before the check; if the upload is then rejected, its removal is initiated and a failure is reported. A downstream reconciliation clears away leftover files without a record. Re-encoding, and therefore this rejection, does not apply to the exceptions named under metadata.
- Images in HEIC or HEIF format are converted to JPEG server-side; metadata is discarded in that step as well.
- Upload records are created by a server-side transactional database function that checks runtime, storage and guest quota and duplicate uploads within the same transaction. Direct insertion by clients has been revoked.
- An event’s commercially relevant fields (plan, storage and guest quota, contract duration, expiry date, payment reference, scheduled deletion date) cannot be modified outside the privileged service role. The check is enforced twice at database level — as a trigger and as a column-level revocation of write privileges — and therefore holds independently of the calling code. Creation of an event by the client has likewise been revoked.
- Administrative and system actions are recorded in a dedicated log. No update privilege and no privilege to delete individual entries is granted on that log, not even to the privileged service role; a correction is made by adding a new entry. The only deletion path is an automated retention run which removes exclusively entries older than twelve months; more recent entries are not covered by it, and a particular entry cannot be addressed through that path.
- Completing an upload written directly into the file store requires a time-limited, server-signed token binding the event, storage path, file name, file size and declared file type. The token binds the intended upload parameters; it is not an assurance about the actual content of the stored file.
- Before automated photo analysis the event setting is checked server-side. If analysis is switched off the step does not run; if the setting cannot be read the step aborts with an error rather than proceeding. This statement covers that analysis step alone and not the other transfers to the same recipient disclosed in Annex 1.
- A binding rule applies to write operations: read the result back and assess it against the records actually affected, not against the return value of the call. A write filtered down to zero records by access rules then counts as a failure, not a success. The rule is set out in writing and checked in review; it is not machine-enforced for every individual write.
- Incoming notifications from the payment provider are signature-verified before any processing.
Availability and resilience
- Database, authentication and file storage are operated in a database provider project in region eu-central-1 (Frankfurt am Main). The region was read out against the account and recorded, with date and query command, in the processor register. The statement covers that one project; further places of processing are disclosed per recipient in Annex 1.
- The application’s server functions operated at the hosting provider are pinned to region fra1 (Frankfurt am Main). Excluded are the separately operated services rendering the recap videos and the print templates; their location is disclosed in Annex 1. No evidence is thereby given for the location of a processing step at any other recipient.
- Static assets and the thumbnails of accessible events are served from a global delivery network and may be cached at locations outside the European Union in the process. Transfers to recipients outside the European Union are disclosed per recipient in Annex 1; no undertaking is given that no data whatsoever leaves the European Union.
- Selected abuse-prone endpoints are rate limited, among them endpoints that write and an event’s access check; there is no blanket limit covering all publicly reachable endpoints. The access check additionally carries two per-event budgets: a narrow one which only takes effect against callers that have a failed attempt of their own, so that a single attacker does not lock out the remaining guests, and above it an emergency brake at a markedly higher threshold whose exhaustion rejects every further access attempt for that event for the duration of its time window, including a correct one. Only failed attempts are counted; a correct entry never consumes a budget. If the counting service is unavailable the request is allowed through; the limiter is deliberately designed so that an outage of the counting service does not block the service. For thumbnail delivery, only rejected requests are counted, per caller and event; successfully delivered thumbnails are not covered by that count and never consume a budget. Once the budget is exhausted, further requests from that caller for that event are rejected until its time window elapses.
- Notification about new uploads and automated photo analysis run as downstream steps through a durable job queue with a recurring catch-up run. A failed job is retried up to a fixed number of attempts and is then recorded as permanently failed, rather than disappearing unnoticed. Other follow-up steps are not covered by it; no unlimited self-healing is promised.
- For existing events, a nightly reconciliation scans the uploads file store for objects without a matching database record and reports them. It removes orphaned objects after a grace period only where that step is armed via an environment variable; without it the run merely reports. Not covered are the storage prefix of an already deleted event and the second file store; the reconciliation is not a substitute for deleting an event.
- Runtime errors and selected performance data of the application are collected automatically; a documented triage procedure exists for their investigation. Of the recurring background runs, one is currently checked for absence by the monitoring service directly. The remaining runs record their execution in a dedicated database table which the monitored run evaluates at the end of its daily pass, reporting any gap as an error. For those remaining runs the detection time therefore follows the cadence of the daily carrier run and not their own. Continuous staffed availability for handling alerts is not promised.
- The processor operates no backup of its own independent of the providers. For the database it relies on the backup and restore features of the database provider within the plan booked. For the file store holding photos and videos there is no backup and no automated restore path; if objects are lost there, a fresh upload by the guests is the only route. No recovery time objective, no recovery point objective and no rehearsed restore test are promised.
Deletion and storage limitation (Art. 28(3)(g), Art. 5(1)(e) GDPR)
- Every event carries an expiry date. Further uploads become impossible on expiry; the next daily background run deactivates the event and schedules its deletion date. Where an already deactivated, expired event is left without a deletion date, a dedicated step of the same run supplies it, so that the event does not persist indefinitely.
- The deletion date is computed per event from its own expiry date: thirty days after expiry. Deletion and the notifications are carried out by a daily background run; the periods stated are therefore windows of that run and not points in time accurate to the hour. The controller is notified in the run in which expiry falls within the next 48 hours, and again in the run in which the deletion date falls within the next seven days. Each run processes a limited number of events; a backlog is worked off in the following runs.
- Deleting an event covers the dependent database tables and both file stores, including nested storage prefixes and derived image sizes. The listing of storage objects pages through the store so that large holdings are covered as well. After removal the state is read back; if an object or a record remains, the run counts as failed, no success is reported, and the next run retries it.
- When an event is deactivated or a photo is hidden or deleted, a purge of the corresponding entries in the delivery network is requested, in so far as the access required for it is configured; without that configuration no purge takes place and the affected responses instead carry a short cache lifetime. A failed purge is reported, does not abort the deletion and is not retried automatically. Not covered are copies already held in the retrieving browser and retrieval capabilities already issued; both lapse with their own validity.
- The controller can delete an event and individual content at any time. When a single photo is deleted, and when several selected photos are deleted, removal of the associated files from the file store is requested first, including the derived image sizes; only then is the database record removed with a verified result. If the removal request to the file store fails, the deletion is reported as failed; the database record remains in place, and neither the live signal to open guest pages nor the purge in the delivery network is triggered. For a multiple deletion this applies to the entire selection, because the file store interface does not report a failure per individual path. The promise relates to a failure of the removal request: an object that is already absent is not reported as a failure by that interface, and a silent filtering of the request by the access rules is indistinguishable from that case. Excluded is the removal of a photo in the procedure following a report of illegal content: there, a failed removal request is reported but the deletion of the database record proceeds, because the decision on the report and its notification to the reporting person have already been issued at that point — for that path it is not promised that the file is removed in the same operation. For the deletion of an event or of an account, an object left behind makes the run fail. Deletion of the entire account is carried out by the daily background run after a waiting period of thirty days; if one of its steps fails, the deletion request remains in place and the next run retries it.
- The controller can export selected master data and metadata of the account and its events as a structured file in JSON format at any time. Not covered are the image material, which is provided through the event’s download function, and data outside the selected categories; the export is a self-service feature and not a conclusive disclosure under Art. 15 GDPR. For return under Section 10 of the agreement, see there.
- Excluded from the thirty-day period of the event are the following data, each with its own period and its own reason. Payment records are retained for seven years (statutory retention obligation, § 132 of the Austrian Federal Fiscal Code). The log of administrative and system actions is cleared after twelve months. Metadata of support conversations is removed after ninety days, or after one year where a conversation was handed to a member of staff; conversation content is not stored in the first place. Telemetry of the checkout process and of advertising conversion reporting is removed after thirteen months. The full record of this agreement persists for as long as the controller’s account; after the account is deleted, a minimised record without personal details and without the address is kept for three years from the end of the calendar year in which the account was deleted. Removal is carried out in each case by an automated retention run evaluating the end of retention recorded on each individual record. Not excluded are the server-side usage counters: they are recorded per event, are linked to the controller’s account via the event, and are deleted together with the event and, independently of that, one year after being recorded. They are the processor’s own processing under Section 2 of the agreement and not part of the commissioned processing.
- On termination of the contract, data is deleted or returned at the controller’s choice. Statutory retention obligations, in particular § 132 of the Austrian Federal Fiscal Code for payment records, remain unaffected; the records concerned are retained separately and solely for that purpose. A nightly retention run deletes them automatically once the period has elapsed, evaluating the end of retention recorded on each individual record. The individual periods are named under “Diverging retention periods”.
Procedure for regular testing, assessment and evaluation
- The regular deployment pipeline contains mandatory automated checks that verify specified properties of the source; a subset of them concerns access rules, data minimisation and telemetry scrubbing. The failure of a mandatory check blocks the regular deployment step. No statement about the effectiveness of an individual check follows from the number of such checks; routes bypassing this pipeline are not covered.
- Static source analysis with rules tailored to this application, and a secret scan, run as blocking steps in the regular deployment pipeline. Separate deployment privileges and routes bypassing this pipeline are not covered.
- The dependencies used in production are checked for known vulnerabilities on every regular run. Findings rated high or critical block deployment. Dependencies used solely for development are not covered by this check.
- Separate tests against a real database instance exist for the database access rules, because tests using mocked database clients cannot observe access rules. That run is triggered by hand and is not part of the automated deployment pipeline; no binding execution cadence is promised.
- In the regular release process the read path is exercised against the release candidate before it receives any traffic; the upload path is exercised in addition where the separate configuration required for it is in place. An executed test that fails blocks the release. Excluded are an explicitly set break-glass switch and a missing upload configuration; both are recorded in the log of the run, and in both cases the run continues.
- Sub-processors are tracked in a dedicated register recording contract status, transfer basis and review date per recipient. The register is updated whenever the set of recipients changes.
- No certification under Art. 42 GDPR and no ISO/IEC 27001 certification is held. The measures are mapped internally against ISO/IEC 27001:2022 Annex A; that mapping is a self-assessment and not a certification claim.