404 Emails

Data Processing Agreement (DPA)

English reference version. The Czech version of this DPA is the controlling version - see Section 22.3 below.

Version:
2026-08-28
Effective from:
28 August 2026

This Data Processing Agreement (“DPA”) governs the processing of personal data by 404 Branding s.r.o. when providing the 404 Emails service to the Customer and forms part of the contractual relationship between 404 Branding s.r.o. and the Customer.

Čeština · English

1. Parties

1.1 Processor

404 Branding s.r.o.
Company ID No.: 23561076
Západní 1396/2
789 85 Mohelnice
Czech Republic

registered in the Commercial Register maintained by the Regional Court in Ostrava, Section C, File No. 100309

Email: 404branding@gmail.com

hereinafter referred to as “404 Emails” or the “Processor”.

1.2 Controller

The Customer who has entered into a contractual relationship concerning the use of 404 Emails and who, through the service, processes personal data for which the Customer determines the purposes and means of processing,

hereinafter referred to as the “Customer” or the “Controller”.

The Processor and the Controller are hereinafter jointly referred to as the “Parties”.

2. Purpose of the DPA and roles of the Parties

2.1 This DPA applies to the processing of personal data carried out by the Processor on behalf of the Customer in connection with the provision of 404 Emails (“Customer Data”).

2.2 To the extent of such processing, the Customer acts as the controller and 404 Branding s.r.o. acts as the processor within the meaning of Regulation (EU) 2016/679 (“GDPR”).

2.3 The Customer determines, in particular, the purposes of processing Customer Data, the recipients of marketing communications, the contact lists used, the legal basis for the relevant processing and the configuration of marketing activities.

2.4 404 Branding s.r.o. may act as an independent controller for certain activities, in particular when processing data necessary for user account administration, the contractual relationship with the Customer, invoicing and payments, service security, fraud and abuse prevention, customer support, compliance with its own legal obligations, and the establishment, exercise or defence of legal claims.
Such processing is not processing carried out on behalf of the Customer under this DPA and is described in particular in the 404 Emails Privacy Policy.

3. Subject matter, nature, purpose and duration of processing

3.1 The Processor processes Customer Data for the purpose of providing, operating, securing and supporting the functionality of 404 Emails in accordance with the Customer’s documented instructions.

3.2 The subject matter and duration of the processing, the nature and purpose of the processing, the types of personal data and the categories of data subjects are described in further detail in Annex 1 – Details of Processing.

3.3 Processing continues for the duration of the provision of the relevant services and thereafter for the period necessary to carry out the Customer’s instruction concerning the return or deletion of Customer Data and for the duration of limited retention cycles applicable to backups or Subprocessors.

4. Documented instructions of the Customer

4.1 The Processor shall process Customer Data only on documented instructions from the Customer, including with regard to transfers of personal data to a third country or an international organisation, unless such processing is required by European Union or Member State law to which the Processor is subject.

4.2 Where such processing is required by law, the Processor shall inform the Customer of the relevant legal requirement before processing, unless that law prohibits such information on important grounds of public interest.

4.3 Documented instructions of the Customer include, in particular, this DPA, the agreement and Terms of Service, configuration of the service by authorised users of the Customer, use of 404 Emails functionality in accordance with its intended purpose, instructions submitted through available service functionality, and other written and legally permissible instructions of the Customer concerning Customer Data.

4.4 If the Processor considers that an instruction of the Customer infringes the GDPR or other applicable European Union or Member State data protection law, the Processor shall immediately inform the Customer thereof.

5. Rights and obligations of the Customer

5.1 The Customer has the right to provide documented instructions to the Processor within the limits of the contractual relationship and applicable law, obtain information necessary to demonstrate the Processor’s compliance with Article 28 GDPR, exercise audit rights under this DPA, be informed of intended changes concerning Subprocessors under this DPA, object to a new or replacement Subprocessor on legitimate data-protection grounds, request reasonable assistance from the Processor in fulfilling GDPR obligations to the extent set out in this DPA, and, upon termination of processing, choose between the return of Customer Data and its deletion in accordance with Section 14 of this DPA.

5.2 The Customer is responsible in particular for the lawfulness of the processing of personal data entered into or transferred to 404 Emails, the existence of an appropriate legal basis, compliance with information obligations towards data subjects, the lawful acquisition of contact details, obtaining and demonstrating consent where consent is required, compliance with rules governing commercial communications, the lawfulness of recipient lists, the lawfulness of campaign content, respecting unsubscribes and other rights of data subjects, the accuracy of its documented instructions, and configuring the service in accordance with its legal obligations.

5.3 The Customer shall not use 404 Emails in a manner contrary to applicable law, the Terms of Service or the Acceptable Use / Anti-Spam Policy.

6. Confidentiality

6.1 The Processor shall ensure that persons authorised to process Customer Data have committed themselves to confidentiality or are subject to an appropriate statutory obligation of confidentiality.

6.2 Access to Customer Data shall be limited to persons who reasonably require such access for the provision, operation, security or support of the service.

6.3 The confidentiality obligation shall continue after the relevant person’s authorisation to access Customer Data has ended.

7. Security of processing

7.1 The Processor shall implement and maintain technical and organisational measures appropriate to the risk, taking into account the state of the art, the costs of implementation, the nature, scope, context and purposes of processing, and the risks to the rights and freedoms of natural persons.

7.2 The current measures are described in Annex 2 – Technical and Organisational Measures (TOMs).

7.3 The Processor may modify or replace individual measures in response to developments in technology, the service or risks, provided that this does not materially reduce the overall level of protection of Customer Data.

7.4 The Processor reviews the appropriateness of its technical and organisational measures at least annually and following a significant security incident or a material change to the architecture, infrastructure or processing of the service.

7.5 Material deficiencies identified through such reviews are documented and appropriately addressed according to their significance.

8. Subprocessors

8.1 The Customer grants the Processor general written authorisation to engage other processors (“Subprocessors”) for specific processing activities involving Customer Data.

8.2 The Processor maintains a current Subprocessor List, identifying at least the Subprocessor, the purpose of its engagement, the relevant location or jurisdiction of processing, and information concerning the international transfer mechanism where applicable.

8.3 Before the intended addition or replacement of a Subprocessor, the Processor shall generally inform the Customer at least 14 calendar days in advance and allow the Customer to object during that period on legitimate grounds relating to data protection.

8.4 Where prior notice within that period is not reasonably possible because of an urgent security need, legal obligation, sudden termination by a provider or another exceptional circumstance necessary to preserve the security or continuity of the service, the Processor shall notify the Customer without undue delay as soon as reasonably possible.

8.5 If the Customer raises a substantiated objection, the Parties shall attempt in good faith to find a reasonable solution.
If a solution is not reasonably possible and the relevant Subprocessor is necessary for the provision of the service, the Customer may terminate the affected service in accordance with the terms of the contractual relationship.

8.6 The Processor shall impose on the Subprocessor, by means of a written contract or other legal act, the same data-protection obligations as are relevantly set out in this DPA, in particular the obligation to provide sufficient guarantees to implement appropriate technical and organisational measures.

8.7 The Processor remains liable to the Customer for the performance of the Subprocessor’s obligations to the extent provided by Article 28(4) GDPR.

9. Integrations selected by the Customer

9.1 404 Emails may allow connections to external services independently selected and configured by the Customer.

9.2 Where the Customer, on its own initiative, connects 404 Emails to its website, e-commerce platform, form platform or another external platform, personal data may be transferred between the relevant services in accordance with the Customer’s instructions.

9.3 An external provider independently selected by the Customer does not become a Subprocessor selected by 404 Branding s.r.o. solely as a result of such connection.

9.4 The Customer is responsible for the lawfulness of its instruction to establish the connection and for its legal and contractual relationship with the relevant external provider.

10. International transfers

10.1 The Customer acknowledges and, as part of its documented instructions under this DPA, authorises the processing and transfer of Customer Data through the Subprocessors identified in the current Subprocessor List, including transfers to third countries identified in that list.

10.2 Where Chapter V GDPR applies to a transfer, the Processor shall ensure that a valid transfer mechanism is used.
Such mechanism may include an adequacy decision of the European Commission, the European Commission Standard Contractual Clauses, the EU–U.S. Data Privacy Framework where applicable to the relevant recipient, or another mechanism permitted by the GDPR.

10.3 Where the use of Standard Contractual Clauses or another mechanism requires an additional assessment or supplementary measures, the Processor shall implement measures required by applicable law to the extent corresponding to its role.

10.4 The Processor shall provide the Customer with reasonably available information necessary for the assessment of relevant international transfers.

11. Rights of data subjects

11.1 Taking into account the nature of the processing, the Processor shall assist the Customer through appropriate technical and organisational measures in fulfilling its obligation to respond to requests from data subjects under Chapter III GDPR.

11.2 Depending on the nature of the request, available 404 Emails functionality may allow, in particular, searching for a contact, correcting data, exporting data, erasing identifying contact data, unsubscribing, recording suppression, exporting Customer Data at Workspace level and permanently deleting Customer Data.

11.3 If the Processor receives a data-subject request relating to Customer Data, it shall not itself determine the request as controller of that Customer Data unless required to do so by law.

11.4 The Processor may refer the data subject to the relevant Customer and shall provide the Customer with reasonable assistance necessary to handle the request.

12. Personal data breaches

12.1 If the Processor becomes aware of a personal data breach concerning Customer Data, it shall notify the affected Customer without undue delay after becoming aware of the breach.

12.2 The Processor shall not unjustifiably delay notification solely because the investigation of the incident has not yet been completed.

12.3 To the extent known and reasonably available, the notification or subsequent updates shall contain information necessary to enable the Customer to fulfil its obligations under Articles 33 and 34 GDPR, including in particular the nature of the breach, known or estimated categories and numbers of affected data subjects, known or estimated categories and numbers of affected records, likely consequences, remedial measures taken or proposed, and a contact point for further information.

12.4 Where all information is not available at the same time, it may be provided in phases without further undue delay.

12.5 The Customer, as controller, is responsible for assessing the risk and determining whether notification to the competent supervisory authority or communication to data subjects is required under Articles 33 and 34 GDPR.

12.6 The Processor shall provide the Customer with reasonable assistance with that assessment and with fulfilling the relevant obligations.

13. Further assistance under the GDPR

13.1 Taking into account the nature of processing and the information available to the Processor, the Processor shall provide the Customer with reasonable assistance in fulfilling obligations under Articles 32 to 36 GDPR, in particular in relation to security of processing, handling personal data breaches, data protection impact assessments and prior consultation with a supervisory authority.

13.2 The Processor is not required to carry out the legal assessment of the Customer’s obligations on behalf of the Customer.

14. Return and deletion of Customer Data

14.1 Following the end of the provision of services relating to processing, the Customer has the right to choose whether Customer Data shall be:

  • a) returned to the Customer and subsequently deleted by the Processor; or
  • b) deleted by the Processor without prior return,

unless European Union or Member State law requires further storage.

14.2 The Customer may change its choice until the point at which final irreversible deletion has been completed.

14.3 404 Emails uses a standard 30-day Workspace closure period, providing the Customer with an opportunity to perform an available export and to provide or change its instruction concerning return or deletion.

14.4 If the Customer chooses return of the data, the Processor shall make the data available for return through the available export mechanisms in commonly used formats supported by the service.

14.5 Following implementation of the relevant instruction and expiry of the closure period, the Processor shall securely and permanently delete Customer Data from active systems.

14.6 Final deletion of a Workspace includes, in particular, relevant data concerning contacts, subscriptions and topics, consent records, suppression, campaigns, messages and delivery events, forms, automations, integrations and sending domains.

14.7 Following final deletion, only a limited amount of information may remain that is not Customer Data processed on behalf of the Customer or whose continued retention is required by law or another independent legal basis, such as a minimal record necessary to demonstrate completion of a deletion request.

14.8 Data removed from active systems may temporarily remain in backups until expiry of their defined retention cycle.

Currently:

  • local database backups are subject to automatic deletion following a limited local retention period;
  • remote database backups in Object Storage are subject to a 30-day lifecycle rule;
  • non-current versions of remote backup objects are subject to a 7-day lifecycle rule.

Following deletion from active systems, backup copies are not intended to restore Customer Data into ordinary active processing, except where system restoration is necessary, in which case the relevant deletion requirements must be reapplied.

14.9 Where European Union or Member State law requires continued retention of specific personal data, the Processor shall inform the Customer where permitted by law and shall not further process the relevant data for purposes other than those justifying such retention.

15. Information necessary to demonstrate compliance

15.1 The Processor shall provide the Customer with information reasonably necessary to demonstrate compliance with the obligations under Article 28 GDPR.

15.2 Depending on the circumstances, such information may be provided in particular through this DPA, current TOMs, the Subprocessor List, relevant security and privacy documentation, information concerning processing, retention and data location, responses to reasonable compliance or security enquiries, and other relevant materials available to the Processor.

16. Audits and inspections

16.1 The Processor shall allow for and reasonably contribute to audits, including inspections, conducted by the Customer or another auditor mandated by the Customer to the extent required by Article 28 GDPR.

16.2 Where the required purpose of an audit can reasonably be fulfilled through current documentation, written responses or other available materials, the Parties may use such means in preference to an additional inspection.

16.3 Where a further audit or inspection is reasonably necessary, the Customer shall provide reasonable prior notice unless an urgent security or regulatory situation requires otherwise.

16.4 An audit shall be conducted in a manner that, to a reasonable extent, protects confidentiality, does not permit access to data belonging to other Customers, does not jeopardise the security of the service, and limits unnecessary disruption to operations.

16.5 These practical requirements shall not be used in a manner that effectively prevents or unreasonably restricts the Customer’s right to verify the Processor’s compliance with its obligations under Article 28 GDPR.

17. Supervisory authorities

17.1 The Processor shall cooperate with competent supervisory authorities to the extent required by applicable law.

17.2 The Processor shall provide the Customer with reasonable assistance in communications with a competent supervisory authority where those communications concern the processing of Customer Data carried out by the Processor on behalf of the Customer.

18. Special categories and criminal-offence data

18.1 404 Emails is not intended as a service for processing special categories of personal data under Article 9 GDPR or personal data relating to criminal convictions and offences under Article 10 GDPR.

18.2 The Customer shall not use 404 Emails for such processing unless expressly agreed in writing with 404 Branding s.r.o. and the relevant legal and security requirements have been satisfied.

19. Liability

19.1 The liability of the Parties under this DPA is governed by the GDPR, other applicable laws and the liability provisions of the principal agreement or Terms of Service to the extent such provisions may lawfully apply.

19.2 Nothing in this DPA excludes or limits liability that cannot validly be excluded or limited under applicable law.

20. Relationship with other contractual documents

20.1 This DPA forms part of the contractual relationship between the Customer and 404 Branding s.r.o.

20.2 If a provision of this DPA conflicts with a general provision of the Terms of Service concerning the processing of personal data on behalf of the Customer, this DPA shall prevail to the extent of that conflict.

20.3 Mandatory provisions of applicable law shall prevail over contractual provisions to the extent required by law.

21. Duration

21.1 This DPA remains effective for as long as the Processor processes Customer Data on behalf of the Customer.

21.2 Provisions which by their nature are intended to continue after termination of the contractual relationship, in particular provisions concerning confidentiality, return, deletion and protection of data, shall remain effective for the necessary period.

22. Governing law and language

22.1 This DPA is governed by the laws of the Czech Republic, without prejudice to mandatory provisions of the GDPR or other applicable European Union law.

22.2 The DPA may be made available in Czech and English.

22.3 The Czech version shall prevail.

22.4 The Czech and English versions of the same DPA version shall be updated together and shall bear the same version designation and effective date.

Annex 1

Details of Processing

1. Subject matter

Provision of 404 Emails for the management of contacts, subscriptions, consents, email campaigns, forms, automations, integrations, email sending and related marketing functionality in accordance with the Customer’s instructions.

2. Duration

For the duration of the contractual relationship and thereafter for the period necessary to carry out the return or deletion of Customer Data and the limited retention cycles under the DPA.

3. Nature of processing

Depending on the functionality used by the Customer, processing may include in particular collection, recording, organisation, storage, retrieval, display, alteration, segmentation, synchronisation, transmission, sending email messages, recording delivery events, managing subscriptions, managing consents, managing suppression, automated execution of workflows configured by the Customer, export and deletion.

4. Purposes

Processing takes place for the purpose of providing 404 Emails functionality in accordance with the Customer’s instructions, including in particular contact management, management of subscriptions and topics, consent records, sending campaigns, processing unsubscribes, suppression, processing forms, automations, integrations, monitoring technical delivery results, measuring interactions where the Customer uses the relevant functionality, and export and privacy functionality.

5. Categories of data subjects

Depending on the Customer’s use of the service, these may include in particular the Customer’s customers, prospective customers, newsletter subscribers, members or users of the Customer’s services, event participants, visitors to websites and forms, business contacts, and other persons whose data the Customer lawfully processes through the service.

6. Categories of personal data

Depending on the configuration of the service, these may include in particular first name, surname, email address, subscription information, topics and preferences, consent information, time, method and source of consent, IP address where recorded as part of consent evidence, contact source, unsubscribe information, suppression records, email message content, campaign information, technical sending and delivery information, bounce and complaint events, open/click data where the relevant functionality is used, data submitted through forms, and data synchronised through integrations activated by the Customer.

7. Special categories

Processing under Articles 9 and 10 GDPR is not a standard permitted purpose of the service and is subject to Section 18 of the DPA.

8. Frequency

Continuously, according to the Customer’s use of the service.

Annex 2

Technical and Organisational Measures (TOMs)

1. Logical separation of Customers

  • Data is logically separated by Workspace.
  • Isolation is enforced at the application layer through server-side authentication, Workspace membership and role checks.
  • Tenant-scoped database operations use server-derived Workspace context.
  • Background workers reload relevant authoritative state from PostgreSQL.
  • PostgreSQL Row-Level Security is not currently used in the architecture.

2. Authentication

  • Passwords are not stored in readable form.
  • Passwords are hashed using scrypt.
  • User sessions are stored server-side in the database and have limited validity.
  • Expired sessions are regularly removed.
  • The session cookie uses HttpOnly, Secure in production, and appropriate SameSite protection.
  • Registration, login and password-reset endpoints use rate limiting.
  • MFA is not currently provided by the service.

3. Authorisation

  • Access to a Workspace requires an authenticated user and valid membership.
  • The service uses OWNER, ADMIN and MEMBER roles.
  • Write operations are restricted server-side according to role.
  • MEMBER is currently limited to read-only access.
  • OWNER and ADMIN currently have a broadly equivalent scope of permissions for ordinary application write operations.

4. Production network

  • The public production application uses HTTPS.
  • HTTPS is terminated through a Caddy reverse proxy.
  • The host firewall denies incoming traffic by default except for explicitly permitted services.
  • SSH, HTTP and HTTPS are publicly permitted.
  • PostgreSQL, Redis, the application and the worker are not published on public host ports.
  • These services communicate through a local Docker bridge network.
  • This Annex does not claim separate TLS encryption for internal PostgreSQL/Redis communication within the local Docker network.

5. Transmission and storage

  • External web communication with the production application uses HTTPS/TLS.
  • Production session cookies use the Secure flag.
  • Remote database backup objects in OVH Object Storage use server-side AES-256 encryption.
  • This Annex does not claim that the production VPS filesystem or active PostgreSQL data volume uses application-verified encryption at rest.

6. Secrets and keys

  • Production secret values are provided to the application through environment variables.
  • Required production values are validated at startup.
  • Production secrets are not intended to be stored in the application Git repository.
  • CI/CD uses protected secrets for deployment credentials.
  • Integration API keys are, depending on their nature, stored as hashes where the service does not need their original value.
  • Inbound provider webhooks use cryptographic verification.

7. Logging minimisation

  • Always-on production worker paths use a safe logging boundary for unexpected errors.
  • Raw error messages, stack traces and complete Error objects are not normally logged through this boundary.
  • Context is limited to safe operational information.
  • Provider webhook processing does not use complete raw payloads as a general operational log.
  • The health endpoint does not expose raw database or Redis errors.
  • Access to manual administrative and diagnostic tools is limited to authorised infrastructure access.

8. Integrity and sending

Measures used depending on the relevant operation include:

  • database transactions;
  • deterministic idempotency;
  • provider-level idempotency;
  • duplicate-processing protections;
  • suppression checks immediately before sending;
  • unsubscribe enforcement;
  • suppression following hard bounce and complaint;
  • cryptographic webhook verification;
  • retry/backoff for background jobs; and
  • graceful shutdown of workers.

9. Retention and deletion

  • Workspace uses the ACTIVE / CLOSING / DELETED lifecycle.
  • The standard closure period before final deletion is 30 days.
  • Final deletion of Customer Data from active systems is performed through a controlled process.
  • The process includes relevant contacts, consents, subscriptions, suppression records, campaigns, messages, message events, forms, automations, integrations and sending domains.
  • Following final deletion, a limited DELETED Workspace record remains without the original marketing database.
  • Expired authentication sessions are regularly removed.
  • The individual contact-erasure mechanism supports deletion of identifying information.
  • Suppression information may be retained following individual erasure where necessary to prevent further unwanted sending.
  • Upon final deletion of an entire Workspace, Workspace-scoped suppression records are also deleted.

10. Backups

The production PostgreSQL database is automatically backed up daily.

The current technical configuration includes:

  • scheduling at approximately 03:00 UTC;
  • compression of the PostgreSQL dump;
  • integrity checking of the gzip archive before upload;
  • upload of the backup to separate OVH Object Storage;
  • automatic removal of local backup files older than the configured local retention period; the current rule removes files older than 7 days;
  • remote backup objects subject to an active lifecycle expiration of 30 days;
  • versioning enabled for the remote bucket;
  • non-current object versions expire after 7 days;
  • expired delete markers are automatically removed; and
  • remote backup objects use server-side AES-256 encryption.

The database restoration process has been operationally verified.

This DPA does not establish contractual RTO, RPO or uptime SLA commitments.

11. Availability and resilience

  • PostgreSQL and Redis use container health checks.
  • Production services use restart mechanisms.
  • The application provides a health endpoint for checking key dependencies.
  • Background jobs use retry/backoff.
  • Workers support graceful shutdown.
  • Database backups provide a recovery mechanism for selected data-loss or corruption scenarios.

12. Incident response

404 Branding s.r.o. maintains an internal Incident Response & Personal Data Breach Procedure governing, in particular, detection, triage, containment, investigation, appropriate preservation of evidence, assessment of personal data breaches, notification of the Customer without undue delay, regulatory assessment where 404 Branding s.r.o. acts as controller, recovery, remedial measures and post-incident review.

Incident records are subject to the principle of data minimisation.

13. Anti-abuse and suppression

  • Unsubscribe and suppression status is checked before sending.
  • Hard bounce and complaint events may result in suppression.
  • Sending workflows contain protections against duplicate sending.
  • Customer Data used for sending is processed in the context of the relevant Workspace.

14. Privacy by design

Measures used depending on the relevant functionality include in particular a Workspace-scoped data model, limited webhook metadata, not storing complete payment card details in 404 Emails, safer error logging, deletion of expired sessions, a controlled Workspace deletion lifecycle, individual contact erasure, suppression enforcement, consent records where used by the Customer, and minimisation of information retained following final deletion of Customer Data.

15. Review of TOMs

404 Branding s.r.o. reviews the appropriateness of the TOMs:

  • at least annually;
  • following a significant security incident; and
  • following a material change to the architecture, infrastructure or processing.

The review takes into account the nature, scope, context and purposes of processing and current risks.

Material deficiencies identified are documented and appropriately addressed.

Annex 3

Subprocessors

The current list of Subprocessors is maintained separately as the 404 Emails Subprocessor List.

The Subprocessor List includes in particular:

  • the identity of the Subprocessor;
  • the purpose of its engagement;
  • relevant data processed;
  • the relevant location or jurisdiction of processing; and
  • the international transfer mechanism where relevant.

Maintaining the Subprocessor List separately allows it to be updated in accordance with Section 8 of this DPA without requiring the entire DPA to be amended whenever a provider changes.