ChockOps Data Processing Agreement (DPA)

Under Article 28 of Regulation (EU) 2016/679 (GDPR)

Effective: 31 October 2026, version 1.0 · Hungarian version: Adatfeldolgozási megállapodás

Preface: when this DPA applies

ChockOps has two kinds of workspace. A personal workspace holds a user's own pilot logbook, credentials and exams. An aircraft workspace is run by an owner and holds aircraft, the techlog, maintenance, documents, defects, trips and the inbox.

• This DPA applies when a business or organisation owns an aircraft workspace and processes personal data of other people in it: its pilots, maintenance staff, crew, passengers, handlers and email correspondents. Examples are a company, a club, a flight school, a co-ownership association or a self-employed operator. The workspace owner is the controller for that data, and DataEdge Kft. is its processor.
• This DPA does not apply when a natural person uses ChockOps for purely personal or household purposes, for example their own logbook or a privately owned aircraft flown privately (GDPR Art. 2(2)(c)). In that case DataEdge Kft. processes the account and service data as controller, under the ChockOps Privacy Policy.
• Account data of every user (login, billing and security data) is always processed by DataEdge Kft. as controller under the Privacy Policy, whether or not this DPA applies.

Where it is unclear whether an aircraft workspace is used for business or for private purposes (for example when a few private individuals co-own one aircraft), the workspace owner decides by accepting this DPA when the workspace is created. If the owner accepts it, this DPA applies to that workspace.

---

Parties

Controller: the customer who owns the aircraft workspace and accepted this DPA in the ChockOps application ("Customer"). Name, registered office and registration number come from the Customer's account and billing data, or from the signature block below.

Processor: DataEdge Kft., registered office 6724 Szeged, Bakay Nándor utca 24. D2. ép. 1. em. 13.; company registration number 06-09-023337, registered by Szegedi Törvényszék Cégbírósága; tax number 25866948-2-06; EU VAT number HU25866948; represented by Lekeny Márk, managing director; privacy contact privacy@chockops.io; phone +36 30 436 0799 ("DataEdge" or "Processor").

Together, the "Parties".

1. Definitions

Terms such as "personal data", "processing", "controller", "processor", "data subject", "personal data breach", "supervisory authority" and "special categories of personal data" have the meanings in GDPR Art. 4 and Art. 9. "Terms" means the ChockOps Terms of Service. "Service" means the ChockOps software-as-a-service at https://app.chockops.io and its related services. "Customer Data" means the personal data that DataEdge processes for the Customer under this DPA. "Sub-processor" means another processor that DataEdge engages.

2. Subject matter, duration, nature and purpose (Art. 28(3))

2.1 Subject matter: DataEdge provides the Service, and in doing so processes Customer Data on the Customer's behalf.

2.2 Duration: this DPA runs for as long as the Customer's subscription or use of the aircraft workspace lasts, and after that until all Customer Data has been deleted or returned under Section 12.

2.3 Nature and purpose: hosting, storing, structuring, displaying, searching, exporting and transmitting Customer Data; automated checks and calculations (counters, maintenance due dates, validity, airworthiness warnings); sending and receiving email; notifications; AI-assisted classification, extraction, summarising and drafting, always as a suggestion that a person confirms; backups; and keeping the Service secure. Annex 1 gives the details.

2.4 The data types and categories of data subjects are listed in Annex 1.

3. Documented instructions (Art. 28(3)(a))

3.1 DataEdge processes Customer Data only on the Customer's documented instructions. The complete instructions are: (a) this DPA and the Terms; (b) the Customer's configuration and use of the Service, for example the features it switches on, the members it invites, the emails it sends and the AI functions it enables; and (c) any other reasonable written instruction from the Customer that the Parties agree, sent to privacy@chockops.io.

3.2 DataEdge may process Customer Data in other ways only when Union or Member State law requires it. In that case, before processing, DataEdge informs the Customer of the legal requirement, unless the law forbids this on important grounds of public interest.

3.3 If DataEdge believes an instruction infringes the GDPR or other Union or Member State data-protection law, it tells the Customer immediately (Art. 28(3), last subparagraph) and may suspend carrying out that instruction until the Customer confirms or changes it.

3.4 DataEdge does not sell Customer Data. It does not use Customer Data for its own purposes, and it does not use it, or let any Sub-processor use it, to train AI models. It may use aggregated, anonymised usage statistics (for example feature counts or AI credit use), which contain no personal data, to run and improve the Service.

4. Confidentiality (Art. 28(3)(b))

DataEdge ensures that everyone authorised to process Customer Data has committed to confidentiality or is under an appropriate legal duty of confidentiality, and gets access only where needed (need-to-know). The platform administration console does not display workspace content (only the waitlist, beta invitations and aggregate counts). DataEdge staff access the contents of a workspace only: (a) on the Customer's express written request for a specific support case, for the time and to the extent needed for that case; or (b) where needed to meet a legal obligation, or to prevent or deal with a security incident, in which case the access is recorded and the Customer is informed unless the law forbids it.

5. Security of processing (Art. 28(3)(c), Art. 32)

5.1 DataEdge implements the technical and organisational measures in Annex 2. Taking into account the state of the art, the cost of implementation, and the nature, scope, context and purposes of the processing, these measures give a level of security appropriate to the risk, including the risk to special categories of data.

5.2 DataEdge may update the measures over time, provided the overall level of security does not fall.

6. Sub-processors (Art. 28(2), (4))

6.1 General written authorisation. The Customer gives DataEdge a general written authorisation (Art. 28(2)) to engage the Sub-processors listed in Annex 3 and, under the procedure in 6.2 and 6.3, to add or replace Sub-processors. DataEdge plans to add an off-site backup storage provider with data centres in the EEA; that provider is not a Sub-processor today and will be added only through the procedure in 6.2 and 6.3.

6.2 Changes. DataEdge gives the Customer at least 30 days' notice before adding or replacing a Sub-processor. Notice goes by email to the workspace owner and as an entry in the public Sub-processor list or changelog at https://chockops.io/subprocessors/ (Hungarian: https://chockops.io/hu/alvallalkozok/). The notice names the Sub-processor, its location, the processing and the transfer mechanism.

6.3 Objection. The Customer may object on reasonable data-protection grounds within the notice period. The Parties then try in good faith to find a solution, for example by DataEdge not using that Sub-processor for the Customer's workspace, or by the Customer switching off the affected feature. If no solution is found, the Customer may terminate the affected subscription before the change takes effect. In that case DataEdge refunds the prepaid fees for the unused period, through the Merchant of Record.

6.4 Flow-down. DataEdge places on each Sub-processor, by written contract, data-protection obligations in substance at least as protective as those in this DPA, in particular sufficient guarantees under Art. 28(4). DataEdge remains fully liable to the Customer for its Sub-processors' performance.

6.5 Emergency replacement. If a Sub-processor must be replaced urgently for security or continuity reasons, DataEdge may make the change at once and notifies the Customer as soon as it can. The right to object in 6.3 still applies.

6.6 Not Sub-processors. The following are not Sub-processors of DataEdge: recipients the Customer chooses to send data to (airports, handlers, maintenance organisations, instructors and other users); the browser push services the user's browser picks; and Paddle as Merchant of Record, which processes payment data as an independent controller.

7. International transfers

7.1 Customer Data is hosted in the European Union, in Frankfurt am Main, Germany. DataEdge transfers Customer Data outside the EEA only in line with Chapter V GDPR, and only to the Sub-processors and for the purposes in Annex 3.

7.2 Transfers to the United States rely on: (a) Anthropic (AI processing): the Standard Contractual Clauses of Commission Implementing Decision (EU) 2021/914 (Module 3, sub-processing) in Anthropic's Data Processing Addendum. DataEdge does not rely on the EU-US Data Privacy Framework (DPF) for this transfer. (b) Mailgun (EU region): message data stays in the EU; for access by the US parent and for globally replicated account data, the SCCs in the Sinch data protection agreement (Modules 2 and 3) apply. In addition, Mailgun states that Mailgun Technologies, Inc. participates in the DPF (Commission Implementing Decision (EU) 2023/1795).

7.3 DataEdge carries out and keeps a transfer impact assessment (TIA) for transfers that rely on SCCs, and will provide a summary to the Customer on request.

7.4 Note: the validity of the EU-US Data Privacy Framework is being challenged before the Court of Justice of the EU (Case C-703/25 P, Latombe v Commission, appeal lodged on 31 October 2025). If a transfer mechanism becomes invalid, DataEdge will switch to another lawful mechanism or stop the transfer, and will tell the Customer.

8. Assistance with data subject rights (Art. 28(3)(e))

8.1 Taking into account the nature of the processing, DataEdge helps the Customer, through appropriate technical and organisational measures and as far as possible, to answer data subject requests under GDPR Chapter III. In the Service these are: viewing, correcting and exporting data (CSV, PDF and ZIP exports), deleting or voiding records where the record-keeping rules allow it, and removing members.

8.2 If a data subject contacts DataEdge directly about Customer Data, DataEdge forwards the request to the Customer without undue delay and does not answer it itself, unless the Customer authorises it or the law requires it.

8.3 Built-in features are free of charge. For extra assistance beyond them, DataEdge may charge a reasonable fee, announced in advance.

9. Assistance with Art. 32–36 obligations (Art. 28(3)(f))

DataEdge helps the Customer, taking into account the nature of the processing and the information available to DataEdge, to meet its obligations on security (Art. 32), breach notification and communication (Art. 33–34), data protection impact assessments (Art. 35) and prior consultation (Art. 36). For this purpose DataEdge provides on request a description of the processing, the TOMs (Annex 2), the Sub-processor list (Annex 3) and the relevant parts of its own DPIA.

10. Personal data breaches (Art. 33(2))

10.1 DataEdge notifies the Customer without undue delay, and in any case within 48 hours of becoming aware of a personal data breach that affects Customer Data. The 48 hours run from DataEdge's own awareness, including when DataEdge learns of the breach from a Sub-processor. The notice goes by email to the workspace owner and, if useful, also appears in the application.

10.2 As far as the information is available, the notice contains the details in Art. 33(3): (a) the nature of the breach, including where possible the categories and approximate number of data subjects and records concerned; (b) the name and contact details of DataEdge's contact point; (c) the likely consequences; and (d) the measures taken or proposed, including measures to mitigate possible adverse effects. Information may be given in stages if it is not all available at once.

10.3 DataEdge takes the reasonable steps needed to contain and remedy the breach, and documents it. Notifying the supervisory authority and the data subjects is the Customer's decision and responsibility as controller. DataEdge does not inform the Customer's data subjects without the Customer's consent, unless the law requires it.

10.4 Notifying a breach is not an admission of fault or liability.

11. Special categories of personal data and AI processing

11.1 Medical certificates and health data. The Service can store pilot medical certificates (class, limitations, expiry and scan), which are health data under GDPR Art. 9. In an aircraft workspace, the Customer may upload or process such data only if it has a legal basis under Art. 6 and a condition under Art. 9(2), for example explicit consent or Art. 9(2)(b) employment law. The Customer must also apply data minimisation; for example it should record only the validity date where that is enough. DataEdge treats such data with the measures in Annex 2. AI extraction from medical scans runs only with the pilot's separate explicit consent given in the Service.

11.2 AI processing. When the Customer uses AI features, DataEdge sends the relevant content (for example a document or scan, an email, a logbook page or trip data) to the AI Sub-processor in Annex 3 (Anthropic, Claude API). DataEdge does this only to produce the requested result. The AI Sub-processor may not use the content to train its models (Anthropic Commercial Terms), and by default deletes API inputs and outputs within 30 days. AI results are always suggestions that a person must confirm. Every AI feature can also be done manually. There is no per-workspace switch for AI features; if the Customer does not want AI processing, its users should not start the AI functions. AI processing of medical and "other" pilot documents requires the pilot's separate explicit consent.

11.3 The Customer shall not upload, through the Service, special-category data that the Service does not need, for example health data beyond the medical certificate, or criminal data.

12. Deletion or return at the end of processing (Art. 28(3)(g))

12.1 At any time before the end of the subscription, and for as long as the workspace stays in read-only mode afterwards, the Customer can export Customer Data (CSV, PDF and full ZIP export).

12.2 When the Customer deletes the workspace or account, or after the DPA ends at the Customer's request, DataEdge deletes the Customer Data after a 30-day grace period in which the deletion can be reversed. Customer Data then leaves the backups through normal rotation (all backups are on the same server in Frankfurt): the daily database dump within 7 days, deleted uploaded files in the file backup within 14 days, and the point-in-time database backups (pgBackRest, two weekly full cycles) within about 3 weeks. Content sent to the AI Sub-processor is deleted by it within 30 days under its standard terms. If DataEdge adds off-site backups, it announces their retention periods with the notice under Section 6.2. During that time the backups are not accessed for any other purpose. If a backup is restored, the deletion log is used to delete the data again.

12.3 Deletion does not apply where Union or Member State law requires DataEdge to keep the data. DataEdge then keeps only what is required, for only as long as required, and protects it.

12.4 On request, DataEdge confirms the deletion in writing.

12.5 Note: under the Terms, the workspace stays readable and exportable after cancellation, and DataEdge does not delete data automatically without a request; inactive workspaces are not deleted automatically. If DataEdge introduces an inactivity rule, it notifies the Customer at least 30 days in advance. The Customer as controller sets its own retention periods and deletes the data through the Service.

13. Information and audits (Art. 28(3)(h))

13.1 DataEdge makes available to the Customer the information needed to demonstrate compliance with Art. 28: first of all this DPA, Annexes 2–3, written answers to reasonable security questionnaires and, once available, summaries of independent tests such as a penetration test.

13.2 If this documentation is not enough, the Customer, or an independent auditor it appoints who is bound by confidentiality and is not a competitor of DataEdge, may carry out an on-site audit under these conditions: at most once a year (except after a personal data breach, or if a supervisory authority requires it); at least 30 days' written notice; during normal business hours; at the Customer's cost; and without risking other customers' data or the security of the Service.

13.3 Audits by a supervisory authority are allowed at any time, as the law provides.

14. Obligations of the Customer

The Customer is responsible for: the lawfulness of the processing and of its instructions; having a legal basis for all Customer Data, including the data of third parties listed in Annex 4; informing data subjects (Art. 13–14); its own retention periods; the accuracy of the data; and choosing appropriate members and roles. The Customer keeps its account credentials secure.

15. Liability

Each Party's liability under this DPA follows the limits and exclusions in the Terms, without prejudice to GDPR Art. 82 and to mandatory law, in particular Ptk. 6:152 (2013. évi V. törvény). Liability to data subjects is governed by Art. 82; between the Parties, Art. 82(5) applies.

16. Precedence, changes, term

16.1 On matters of personal data protection, this DPA takes precedence over the Terms and over any other agreement between the Parties.

16.2 DataEdge may amend this DPA to reflect changes in the law, a decision of a supervisory authority or court, or a change of Sub-processor (Section 6). Other material changes are announced at least 30 days in advance; if the Customer does not accept them, it may terminate before they take effect. A change may not lower the protection of Customer Data.

16.3 This DPA ends when the Customer's use of the aircraft workspace ends. Sections 12, 13 (for 12 months), 15 and 17 continue to apply after that.

17. Governing law and jurisdiction

This DPA is governed by Hungarian law, in particular the GDPR and Act CXII of 2011 (Infotv.). Disputes go to the Hungarian court with subject-matter jurisdiction for the registered office of DataEdge (Szeged), without prejudice to the powers of supervisory authorities and to mandatory rules of jurisdiction.

18. Conclusion

18.1 Electronic acceptance. A workspace owner who uses the Service for business or organisation purposes accepts this DPA electronically in the application. Acceptance is a separate checkbox, given when the aircraft workspace is created. The owner of an aircraft workspace created earlier can accept this DPA by email to privacy@chockops.io or with a signed copy (18.2). DataEdge records the date and time of acceptance, the version of the DPA, the workspace and the accepting user. Acceptance creates a written contract under Art. 28(9) (electronic form).

18.2 Signed copy. A Customer may also ask for a signed copy:

---

Annex 1 — Description of the processing

Annex 2 — Technical and organisational measures (Art. 32)

Hosting and infrastructure

• Hosting in the EU: a VPS at Hostinger, data centre Frankfurt am Main, Germany.
• Firewall; only the necessary ports are open; the database is not reachable from the internet.
• Operating-system and dependency updates; unattended security upgrades.

Encryption

• TLS (HTTPS) on all connections between the browser and the Service; HSTS (one year) on the website and the application.
• Web push payloads are encrypted end to end (RFC 8291).
• Backups are kept on the same server and are accessible to the system administrator (root) only.
• Passwords are hashed with bcrypt (cost 12), never stored in plain text; minimum 10 characters; common passwords rejected.

Tenant isolation and access control

• Two layers of isolation between workspaces: (1) every query is filtered by workspace in the application, with a membership check; (2) PostgreSQL Row-Level Security (ENABLE + FORCE) on every tenant table. It fails closed: without a set context, tenant tables look empty.
• Least privilege: the application and the worker connect with a role that is neither superuser nor BYPASSRLS. Production refuses to start with a privileged connection. Migrations use a separate owner role.
• Composite foreign keys, so the database cannot hold a reference between workspaces by accident.
• An automated isolation test suite covers every API endpoint with two tenants, and the whole backend test suite runs as the restricted application role.
• Roles inside a workspace (owner, pilot, maintenance, viewer) and per-aircraft access rights.
• Files are served only after an authorised database row is found; storage keys never come from the client.

Authentication and session security

• Session cookies are httpOnly (access token 15 minutes; rotating refresh token 30 days, stored hashed, with reuse detection), Secure in production and always SameSite=Strict.
• CSRF protection with the double-submit pattern.
• Rate limiting (in memory) on sign-in, sign-up, password reset, invitation preview, public signature links and public endpoints.
• Email verification (24-hour token); password-reset links valid for 60 minutes; two-factor authentication (TOTP) not available.
• Signature links are signed, expire, can be revoked and are stored only as a hash. Signed fields are sealed with HMAC.

Integrity and accountability

• An append-only audit log of every change, with the before and after state.
• Records are not physically deleted, only voided. Entries lock after 24 hours, and changing a locked entry needs a reason.
• Inbound email: sender allowlist, DKIM/SPF/DMARC checks, quarantine, HTML sanitisation, and checks on file types.
• Logs: web server access logs are kept for 14 days, with secret tokens in URLs masked; application (system journal) logs for 7 days.

Availability and recovery

• On the same server: pgBackRest weekly full and daily differential backups, continuous WAL archiving (point-in-time recovery), two full cycles retained (about 3 weeks); weekly verify, daily check; daily pg_dump kept 7 days; a mirror of uploaded files in which deleted or overwritten files are kept for 14 days. There is no off-site backup at present.
• After a restore, account deletions are re-applied from the deletion log (deletion_log).
• Monitoring of uptime, error rates, the job queue and disk.

Organisation

• The platform administration (staff) console does not display tenant content. Staff access to tenant data only under Section 4.
• Confidentiality obligations for staff and contractors.
• A security review at the end of every development phase.
• Vulnerability management: monitoring of dependencies and a security contact (security@chockops.io).
• A documented procedure for handling personal data breaches (Section 10).
• AI use and cost are capped; AI processing of medical data needs the pilot's separate consent.

Annex 3 — Authorised Sub-processors

The current list, with its changelog, is also published at https://chockops.io/subprocessors/ (Sub-processors).

Not Sub-processors (Section 6.6): OpenStreetMap Foundation (UK), whose map tiles (tile.openstreetmap.org) the user's browser requests directly; flight-data sources (the Service can query api.adsbdb.com, OpenSky Network or Flightradar24 with a registration/ICAO24 address and a time window and no personal data; none of them is enabled at present); browser push services; Paddle.com Market Limited (UK), the Merchant of Record and an independent controller, only once paid plans start; and recipients the Customer chooses.

Annex 4 — Data for which the Customer is responsible as controller

The Customer, as controller, ensures that it has a legal basis and informs the data subjects, in particular for:

---

Legal sources: GDPR Art. 28, 32–36, 44–49, 82 — https://eur-lex.europa.eu/eli/reg/2016/679/oj · SCCs: Commission Implementing Decision (EU) 2021/914 — https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj · EU-US DPF: Commission Implementing Decision (EU) 2023/1795 — https://eur-lex.europa.eu/eli/dec_impl/2023/1795/oj · DPF list — https://www.dataprivacyframework.gov/list · Infotv. (Act CXII of 2011) — https://net.jogtar.hu/jogszabaly?docid=a1100112.tv · Ptk. (Act V of 2013) — https://net.jogtar.hu/jogszabaly?docid=a1300005.tv · NAIH — https://naih.hu · Anthropic Commercial Terms — https://www.anthropic.com/legal/commercial-terms · Hostinger DPA — https://www.hostinger.com/legal/dpa · Anthropic DPA — https://www.anthropic.com/legal/data-processing-addendum · Sinch (Mailgun) DPA — https://sinch.com/legal/terms-and-conditions/other-sinch-terms-conditions/data-protection-agreement/