Terms of use

Version 2026-09-15. Holder: its identifying details are pending publication (legal notice). The Spanish version is the reference text.

1. What SkyORM is
2. Flight safety notice
3. Your account
4. If you publish an ORM: you are the controller
5. Data processing agreement (GDPR art. 28)
6. Sub-processors and third parties
7. Content and intellectual property
8. Availability and changes
9. Governing law

1. What SkyORM is

SkyORM is a web tool to build and fill operational risk management (ORM) forms for aviation and parachuting. Whoever is about to fly or jump answers a set of scored factors; the score falls into a risk band; some factors can suspend the ORM on their own; and, from the band set by whoever publishes the ORM, a designated person has to authorise the operation. The person filling it chooses how to answer: anonymously, under an alias, or signing.

These terms apply to anyone who creates an account and to anyone who publishes an ORM. To fill an ORM without an account, the notice shown by the ORM itself and its privacy page are enough.

2. Flight safety notice

3. Your account

• Minimum age: 14. Platform accounts may only be opened by people aged 14 or over (art. 7 of Spanish Organic Law 3/2018). If we learn that an account belongs to someone under 14, we will close it.
• How these terms are accepted. Opening an account means accepting them in the version shown above, and that acceptance is the basis for processing your account data. Where sign-up says so expressly, the platform stores the version you accepted and the date: today that is sign-up with Google, whose screen warns you before continuing that you accept the terms and declare you are 14 or older. The email-and-password sign-up form does not yet show that tick box; until it does, signing up that way leaves no record of the version accepted or of the age declaration, even though the server already requires them as soon as the form presents them.
• Give truthful details and keep your password secret. If you suspect someone has accessed your account, change your password and tell us at the privacy address: privacy@skyorm.com.
• Do not use the platform to test vulnerabilities without permission, impersonate others, collect data about people without a legal basis, send unlawful content or launch mass automated requests.
• We may suspend an account that breaches these terms or endangers other users' security, warning beforehand unless urgency prevents it.
• You can close your account at any time by writing to the privacy address. The platform administration carries out the closure. If you own any ORM, the platform will not close your account until its ownership moves to another account: its responses are its controller's record, and deleting the account would destroy them.

4. If you publish an ORM: you are the controller

Whoever publishes an ORM decides what it is used for and what it asks. That makes them the controller, in the GDPR sense, of what is filled in it, and SkyORM their processor. By publishing you take on these obligations:

1. Declare who the controller is. Name or company name, tax ID where applicable, address, privacy contact and data protection officer if there is one. The platform does not let an ORM be published without that declaration, and while an ORM has no declaration that has accepted the agreement in section 5 in some version, it only accepts anonymous responses; to publish it, the accepted version has to be the current one. Keep it up to date: changes apply to later responses.
2. Have a legal basis for what you ask. The platform proposes the legal basis and the rule according to the type of organisation you declare (club or individual, employer or operator, military unit), but the decision and the responsibility are yours: if your case does not fit, correct it. If you are a club and the basis is consent, nobody may suffer any consequence for not identifying themselves: the anonymous mode has to be available, because it is what makes that consent free. The platform does not let a club ORM be published without it, and if it stops offering it, the ORM takes no responses.
3. Inform whoever fills it. The notice shown by the ORM and its privacy page are built from your declaration. If you process the responses for anything beyond what they say, you have to inform about it.
4. Adapt templates to your case. If you start from a platform template, review it factor by factor: remove the health questions you do not need, adjust scores, suspensions and bands to your operation, and check who receives the authorisation notices. A template copied unchanged is still your decision.
5. Assess the impact. If your ORM asks about health, you most likely need a data protection impact assessment (GDPR art. 35). SkyORM gives you the template with the technical part filled in (section 5, letter f).
6. Minors. If a minor may fill it, make sure you have the legal basis and, where applicable, the consent of their legal representatives that your case requires.
7. Access. You decide who gets access as collaborator or reader and who receives the authorisation emails. Remove access that is no longer needed.
8. Labels without people, if you switch artificial intelligence on. The labels of scored factors, bands and modifiers leave for the provider exactly as you write them, together with the values of a response or of its statistics. The platform removes emails, phone numbers, links and aircraft registrations from them, but it does not recognise a name: do not put names or other identifiers of people in them (not even whoever authorises). The options of a factor, page and section titles and the authorisation texts of a band do not leave: of an option, the provider only receives its position.
9. Rights. Handle the requests of whoever fills your ORM with the tools in section 5, letter e, and give us in writing the instructions you need for whatever you cannot do yourself.

5. Data processing agreement (GDPR art. 28)

For the ORMs you publish, this section and the next are the processing agreement between you, as controller, and SkyORM, as processor, required by article 28(3) GDPR. They are accepted when you save the controller declaration with the agreement box ticked, in the version stated above.

Subject matter, duration, nature and purpose

• Subject matter: hosting and running your ORMs: collecting the responses, scoring them, storing them, showing them to whoever you authorise, exporting them and notifying whoever has to authorise.
• Duration: while your ORMs are on the platform, until the end of processing (letter g).
• Nature: automated processing on the hosting provider's servers.
• Purpose: the one you declare; usually self-assessment before the operation, evidence of the declared situation and its authorisation, and prevention statistics.
• Types of data: the answers to the factors, which may be health data (medication, illness, substances, fatigue, stress, rest); score, band, suspension and its reasons; operation metadata (rank, aircraft, date, remarks); the identity that goes with the chosen mode (alias, name, handwritten signature stored as an image, link to the account); signatures of third parties acting in their role; the emails of whoever authorises and their decision; and the weather data for the location.
• Data subjects: whoever fills it (crews, parachutists, employees, members, students, military personnel), third parties who sign in their role (jumpmaster, assessor, authoriser) and the people who authorise.

a) Documented instructions

Your instructions are the ORM's configuration (factors, admitted identity modes, bands, access, authorisation recipients and identity periods), your declaration as controller (including whether you allow artificial intelligence) and whatever you ask us in writing at the holder's privacy address. SkyORM does not process the responses for any other purpose. Data are only transferred outside the European Economic Area in the cases in section 6. If a law required us to process them otherwise, we would tell you first, unless that law forbids it. If we think one of your instructions infringes the GDPR, we will tell you (art. 28(3), last paragraph).

b) Confidentiality

The people SkyORM authorises to access the data, namely the holder and anyone with platform administration access, are bound by confidentiality, also after their access ends. Platform administration can see any ORM and act as another user to give support; that access is limited to the administration role, and it is only used to give support, supervise the service or follow your instructions. Acting as another user can only be started from the administration screen that offers it, which validates its token and issues a single-use ticket: a link prepared by someone else cannot impersonate anyone.

c) Security (GDPR art. 32)

These are the measures that exist today in the platform's code:

• Passwords stored with an adaptive hashing algorithm, never in clear; lockout after 5 failed attempts in 5 minutes; email second factor when the platform has it enabled, with trusted devices.
• Protection against forged requests (CSRF) on forms, and rate limiters on ORM submission, on the ORM access password, on artificial intelligence and on email sending.
• Per-ORM permissions (owner, collaborator and reader). Only the owner hands out access, changes the public address, the admitted identity modes and the controller declaration, and handles data subjects' rights. Administration screens are for the administration role only.
• Everything submitted is validated on the server. In an anonymous response the server discards the alias, the signature, fields asking for identity and free text, and rounds dates and times down to the hour. No response stores the network address or the browser, and on the fill routes neither do the request metrics, the error log or the error email.
• An ORM without a declaration that has accepted the agreement, and any platform template, only accepts anonymous responses.
• The authorisation email carries neither the factors nor a link to the result, and the decision page shows neither the breakdown nor the signature. Links to share a result expire after 7 days and decision links after 14.
• Deleting from the builder a factor, section or page that already has responses archives it: it does not destroy responses. And the account of an ORM's owner cannot be closed while it owns it.
• The identity in responses expires in three phases (readable, blocked and removed) through a daily process on the server. Removing the identity, when its period ends or earlier, leaves the response like an anonymous one: besides the name, the alias, the account link and the signatures, the free text and the email of whoever authorised it are removed, and dates and times are rounded down to the hour.
• Whatever is sent to an artificial intelligence provider leaves through a single point in the code, which only accepts what is built from a closed list of what may leave, and automated tests seed responses with an alias, signature, name, email, phone number, time, coordinates, people's names in the options, aircraft registrations and the club's name in the titles, ask with an administration account, and fail if any of it appears in what is sent. Only from ORMs whose controller has switched it on, what leaves is: while filling, the values of the scored factors of that response (of an option, its position, not its text); in the analysis of one's own responses, aggregate statistics of at least 5 responses of whoever asks for it; and in an ORM's dashboard, its rounded total and average and the split by band. They travel with the labels of factors, bands and modifiers as the controller writes them, who is bound not to put people's names in them (section 4), and without identity, alias, signatures, free text, the date or time of any response, coordinates, identifiers, the ORM's name or address, or the account or its roles. From the assistant the question also leaves, without the account of whoever writes it: emails, phone numbers and links are removed, and so are dates, times and coordinates written in figures, but whatever is written in words, such as a name or a date spelled out, arrives as it is.
• Database backups before each deployment, rotated after 14 days.
• The web server's access log does not keep requests that fill an ORM, show its result or open its privacy page. What the web server does log (access and errors) is deleted by its rotation within 37 days at most, the period the deployment has measured on this server, provided each log receives some line in every rotation period: if one stays empty for a whole period, logrotate may not rotate it, and its previous copy waits for the next rotation (privacy policy, section 6).
• In production, database queries are not logged, and the session cookie is marked SameSite=Lax and secure when the connection is HTTPS.

What it does not do, and you should know: the application does not itself encrypt the database or the backups, which are kept on the same server; encryption at rest depends on the hosting provider (Hetzner Online GmbH).

Security breaches. If we suffer a breach affecting your data, we will tell you without undue delay, aiming to do so within 48 hours of becoming aware of it, with what article 33(3) GDPR requires: its nature, the categories and approximate number of people and records affected, its likely consequences and the measures taken or proposed. What we do not yet know we will give you in phases, as soon as we know it.

d) Sub-processors

You give us general authorisation to use the sub-processors in section 6. SkyORM undertakes that each sub-processor is bound by contract to data protection obligations equivalent to these, and remains liable to you for their performance (GDPR art. 28(4)).

• Hosting, email and SMS. If we add or replace one, we will publish it on this page at least 30 days in advance and tell everyone with published ORMs by email; within that period you may object and, if we cannot agree, end the processing under letter g. Having the contract with each of them on record is an obligation of the holder, who does not run the platform in production with one whose contract it lacks; no program checks it.
• Artificial intelligence. The platform can only send anything to a provider whose processing contract is declared in the server configuration, and from your ORMs only to the providers you accepted when you switched artificial intelligence on in your declaration: the box names them and the platform records which they were. A provider added later receives nothing from your ORMs until you save the declaration again with it named; and if one you accepted stops being available, it is not replaced by another.

e) Assistance with data subjects' rights

These tools are on the result of every response that carries identity, and only the ORM's owner sees them:

• Access and portability: in each ORM you see the list and detail of responses and can export them to CSV; and from a response's result you download as JSON what it holds about its person, to hand it over. Responses are located by account, alias or signature; an anonymous one cannot be attributed to anyone, and you are not required to collect more data to do so (GDPR art. 11(2)).
• Rectification: from the result you correct the declared name or alias; the previous one is not kept. The answers to the factors document a situation at a point in time and are not rewritten: if the person wants another situation on record, they fill a new ORM.
• Erasure, objection and withdrawal of consent: from the result you remove the identity from the response, which becomes like an anonymous one (letter c) and keeps counting for statistics; the identity leaves the database. In a club ORM, whoever signed with their account can withdraw their consent themselves from their response's result, with the same effect.
• Restriction: from the result you block the identity, so that no screen, export, email or artificial intelligence payload shows it; it is held for courts and authorities until it is removed.

You carry out these operations, and they are recorded with your account, the action, the response and the date, never with the person's name. If you cannot do it yourself, ask us at the privacy address and we will confirm it in writing in time for you to answer within the month set by article 12(3) GDPR.

f) Assistance with security, breaches and impact assessment (GDPR arts. 32 to 36)

Besides the measures and breach notice in letter c, we give every controller who asks the SkyORM impact assessment template: the technical description of the processing already filled in and checked against the code (what is collected in each mode, where it is stored, who has access, which measures exist and which do not), the risks and an annex per type of organisation. You complete the purpose, legal basis, necessity and signature. If your assessment leads you to consult the authority (art. 36), we give you whatever technical information is needed.

g) End of processing

When processing ends, at your choice:

• Return: you export your ORMs' responses to CSV. The export does not include the signature images; it does show which responses are signed.
• Erasure: as the platform does not destroy responses, erasure is achieved by removing the identity from every response collected under your declaration: the name, alias, account link, signatures, free text and the email of whoever authorised leave the database, and times are rounded down. What remains (scores, bands and scored answers) is like an anonymous response.

We will do it with a platform process that goes through all those responses, within 30 days of your request, unless a law requires us to keep something, in which case we will tell you what and why. What is removed may remain for up to 14 days in the pre-deployment backups, until they rotate.

h) Information and audits

We make available the information needed to show we meet these obligations: these terms, the impact assessment template, the description of the measures and, if you ask, the technical documentation behind them. We allow audits and inspections, by you or an auditor you appoint, with 30 days' notice except in case of a breach, without access to other controllers' data, at your expense and no more than once a year except after a breach or at an authority's request.

6. Sub-processors and third parties

These are the providers that process personal data on SkyORM's behalf. Where a provider is in the United States, the transfer is made only under standard contractual clauses, or the EU-US Data Privacy Framework where the provider is certified under it: that is the condition for using the provider, not an intention.

Artificial intelligence is switched off by default in every ORM. It is only used in ORMs whose controller has switched it on in their declaration, and only when someone presses the function. Until they do, nothing filled in their ORMs leaves for these providers: those ORMs do not offer the function or the fallback summary, and the assistant does not use their statistics. Of the possible providers, this server records a processing contract for Cerebras, OpenAI: the platform can only send anything to those, and any other provider's key is inert. On this installation there is at least one provider with a key the platform can use, so in ORMs that have it switched on the function sends only what the table says.

Cerebras is Cerebras Systems Inc., based in the United States. The processing is governed by its data processing agreement (DPA), which forms part of the terms of its inference service, accepted by the holder in the course of its business and not personally, and transfers rely on the European Commission standard contractual clauses included in that agreement. What it receives from ORMs is what the table says: values and statistics without identifiers, without the respondent's free text, without the date or time of any response and without the ORM's name, so Cerebras has no reasonable means of knowing whom they refer to, even when they concern health, as long as the labels do not name people (section 4). Under those conditions, for Cerebras they are not data about identifiable people, in line with the judgment of the Court of Justice of the European Union of 4 September 2025 (case C-413/23 P, EDPS v SRB), and so what it receives from ORMs fits that agreement, whose published version does not list special categories of data. The question written into the assistant is not covered by that guarantee: if someone writes a name and a health detail in it, they arrive as they are; that is why the assistant asks people not to. For the controller of each ORM, who keeps the responses, they are personal data: that is why Cerebras is still listed here as recipient and sub-processor, with its agreement accepted. According to its privacy policy, Cerebras does not retain the inputs or outputs of its inference service; its terms allow it to retain that content only to the extent necessary to provide the service and comply with the law.

Third parties that are not sub-processors of personal data

• Open-Meteo receives from our server the coordinates of airfields and drop zones to return the weather forecast. It receives no data about any person. On the location management screens, your browser also asks it for the point's elevation, and in that request Open-Meteo sees your network address.
• OpenStreetMap serves the maps directly to your browser on the management screens that show a map, and sees your network address in that request.
• Google Fonts serves the Lato typeface to the browser on the application screens, including those of each ORM (its fill form, its result and its privacy page) and the sign-in screens. In that request Google sees the network address and browser of whoever opens the screen, also when they answer anonymously; it receives nothing that is filled in. The home page and the legal pages load no third-party resources.
• Google, if you choose to sign in with Google, acts as controller of its own sign-in service and gives us your email, your name and an identifier.

7. Content and intellectual property

What you create in SkyORM (your ORMs, their factors and texts) is yours. You give us the permission needed to host it, show it to whoever you decide and back it up. If you publish an ORM with public access, any account can copy its definition (its factors, thresholds and texts; never its responses, your controller declaration or the authorisation emails) as a starting point for an ORM of its own, and you give us the permission needed to offer it that way. With a password or private, no. You may copy and adapt the platform templates for your organisation. The software and the SkyORM brand belong to the holder.

8. Availability and changes

We do what is reasonable to keep the service available, but it may be interrupted for maintenance or faults; during a deployment the platform shows a notice page. That is why an ORM cannot be your only record of a critical operation.

If we change these terms, we will publish a new version with its date. Changes affecting the processing agreement (sections 5 and 6) are announced 30 days in advance to everyone with published ORMs, and each controller's declaration has to accept the new version to publish again.

9. Governing law

These terms are governed by Spanish law. If you are a consumer, you may go to the courts of your place of residence; otherwise, to those of the holder's registered address.