# Privacy Policy

> What personal data we hold, why we hold it, how long we keep it, and the rights you have over it under the GDPR.

Source: https://hyperjobs.io/legal/privacy

This policy explains what personal data we hold about you, why, and what you can
do about it. It covers two different things: the data we collect when you use the
portal and the API, and the personal data that occasionally turns up inside job
postings in our dataset. Section 7 deals with the second one, and it is the part
most people come here to read.

## 1. Who we are

The data controller is <LegalEntity />.

We have not designated a Data Protection Officer. We are not a public authority,
our core activity is not large-scale monitoring of individuals, and we do not
process special-category data at scale, so the criteria in Article 37 GDPR are
not met. Privacy questions still go to a real address that a person reads:
<Email kind="dpo" />.

## 2. What this policy covers

It covers the HyperJobs portal at `hyperjobs.io`, the API at
`api.hyperjobs.io`, and the job dataset behind them.

HyperJobs is a business product sold to businesses and developers. It is not a
job board and not a job-seeker service. There is no application feature, no CV
upload, and no candidate profile. If you are looking for the part of this policy
that explains what we do with applicants' data: we do not have applicants' data,
because nobody applies for anything through us.

## 3. Data we collect about you

### Account data

When you register we store your email address, and — if you sign in with Google —
the display name and profile photo URL your Google account exposes. You may add a
company name. We also keep whether your email is verified, your role, and
timestamps for creation, update, and last login.

Authentication itself runs on Google Firebase Authentication. If you use a
password, **we never see it**: Firebase holds the credential, and it never
reaches our servers or our database.

### Billing data

Paid plans run through Stripe. **We do not store your card number.** Stripe does.
We keep your Stripe customer id, your plan, subscription status, billing interval,
start and end dates, whether it is set to cancel at period end, and a record of
billing events — invoice ids, amounts, currency, event type. That is enough to
show you your plan and to keep our books; it is not enough to charge a card.

### API usage data

We count requests per key per day. That is the whole of it: a key id, a date, and
a number. We use it to enforce your quota, draw the charts in your dashboard, and
bill correctly. We do not log the content of your API queries against your
identity as a matter of course.

For each key we also hold the name you gave it, its scopes, when it was created,
when it was last used, and whether it is revoked — plus a SHA-256 **hash** of the
key and its short display prefix. We never store the key itself and cannot
recover it.

### Session and security data

When you sign in we record a session: a session id, browser and operating system
parsed from your user agent, your IP address, and an approximate city, region and
country resolved from that IP. This is what the security page in your dashboard
shows you, so you can spot a session you do not recognise.

To resolve the location we send your IP address to **ip-api.com**, a third-party
geolocation service. It receives the IP and returns a city, region, and country.
It is listed in [Subprocessors](/legal/subprocessors).

We also keep an append-only log of authentication events — sign-in, failed
sign-in, sign-out, and similar — with the event type, timestamp, IP, user agent,
and the device fingerprint described below.

### Device fingerprint and signup IP

This is the part worth being specific about, because it is the part people assume
the worst about.

We record the IP address you signed up from, and a **device fingerprint** — a
visitor id plus the component values it was computed from (things like screen
dimensions, timezone, installed fonts, and GPU string). We store the fingerprint
at signup and with each sign-in.

The fingerprint is produced by the **open-source FingerprintJS library, which
runs entirely in your browser**. No data is sent to FingerprintJS. They are not
involved, they receive nothing, and they are **not a subprocessor** of ours. The
library computes an identifier locally and hands it to our page; only then does it
reach our server, like any other form field.

We use it for **abuse prevention only**. Concretely: spotting when one person
farms many accounts to multiply a free quota. It is a signal a human looks at
during an investigation.

<Note>
  There is **no automated blocking and no automated decision-making** based on
  the fingerprint. Nothing is denied to you because of a fingerprint score. No
  profile is built. Because there is no automated decision-making producing legal
  or similarly significant effects, **Article 22 GDPR does not apply** to it.
</Note>

**In the EU/EEA, the UK, and Switzerland we ask first, and the legal basis is
your consent (Article 6(1)(a)).** Reading characteristics from your device
engages Article 5(3) of the ePrivacy Directive whether or not a cookie is
involved, so the cookie banner asks about exactly this, and declining means the
fingerprint is never computed — the check runs before the library loads, not
after. Withdraw it any time from **Cookie settings** in the footer; withdrawal is
as easy as consent and takes effect immediately.

Everywhere else the basis is **legitimate interests, Article 6(1)(f)** — keeping
a metered free tier from being drained by bulk account creation, which is what
lets us offer one at all. The same controls sit in the footer, and you can object;
see sections 8 and 9.

We could have leaned on the strictly-necessary exemption everywhere and shown no
banner. We decided not to: the exemption for fraud prevention is genuinely
contested, and we would rather lose a signal than assume a permission.

Related, and in the same spirit: at signup we limit how many accounts may be
created from one IP address (3 per hour, 10 per 30 days), and we block disposable
email domains using a static list and the **DeBounce** API, which receives the
email address you typed. DeBounce is a subprocessor.

### Product analytics

We use **PostHog** to measure how the site is used — how many people read the
quickstart, where they stop, what they searched the docs for. It runs in one of
two modes, and which one you get is entirely your choice at the cookie banner.
[Cookie Policy](/legal/cookies) has the full detail; this is what it means for
your data.

**If you consent**, PostHog stores an id on your device (a `ph_*` cookie and
localStorage), creates a person profile, links the pages you read before signing
up to your account through an `identify()` call on your user id, and records
**session replay** — a reconstruction of what happened in your browser window.

**If you do not**, PostHog still runs, and we would rather write that here than
let you find it. It runs with `persistence: 'memory'` (nothing is written to your
device), never calls `identify()`, creates no person profile at all, and records
no replay. That is anonymous, aggregate counting.

In both modes we collect: the events listed below, page URLs, referrer, browser
and device characteristics, and — where you are identified — your user id.
**Your IP address is not sent to PostHog in either mode** (`ip: false`); PostHog
never receives it.

The events are a short, fixed list, not a general capture of everything you do:
`docs_search`, `docs_search_empty`, `docs_page_helpful`, `pricing_plan_selected`,
`signup_started`, `checkout_started` from the browser, and `signup_completed`,
`api_key_created`, `api_first_request`, `plan_purchased`, `plan_changed`,
`subscription_cancelled` from our backend. Properties are ids, plan names, and
counts. We do not put your email address or your name into an event.

Traffic reaches PostHog through a reverse proxy on our own domain (`/ingest`)
rather than from your browser to a PostHog domain. That changes who your browser
connects to, not who processes the data: PostHog is a **subprocessor**, listed in
[Subprocessors](/legal/subprocessors), and processes on their **EU cloud in
Germany**.

<Warning>
  **Session replay records your screen, and search records what you typed.** Two
  specifics a careful reader will want, so they are here rather than discoverable.

  Replay captures the page, but every form input is masked — it never records what
  you type into a field. The one place a full API key is ever displayed, the
  "copy your key" dialog, is excluded from capture entirely, because that key
  renders in a code block that input-masking would not have covered.

  The docs and help search boxes send **the text you typed** to PostHog, as a
  property on `docs_search` and `docs_search_empty`. This is a search box on
  public documentation, and what people type into it is `salary_annual_max`.
  Zero-result searches are how we learn what the documentation is missing. It is a
  deliberate exception to the no-free-text rule, and the only one.
</Warning>

### Analytics about your account, from our servers

Some events are sent to PostHog by our own backend rather than your browser:
`signup_completed`, `api_key_created`, `api_first_request`, `plan_purchased`,
`plan_changed`, `subscription_cancelled`. They carry your user id, a plan name,
and counts.

**These are not gated by the cookie banner, and you should know that from this
page rather than from a network tab.** The banner is an ePrivacy Article 5(3)
question — it governs storing information on your device and reading information
from it. This path touches no device: it records that an account we have a
contract with created a key or bought a plan, from our own backend, out of our own
database. `plan_purchased` fires from the Stripe webhook, where there is no
browser in the path at all. Declining a cookie does not un-sell a subscription.

It is still processing of personal data, so it still needs a basis, and it has
one: **legitimate interests** (Art. 6(1)(f)) in knowing whether our own product
works, and **contract** (Art. 6(1)(b)) for the billing events we would be
recording regardless. You can object under Article 21 — see sections 8 and 9.

### Newsletter and marketing email

We are building a developer newsletter. If you subscribe, we store your **email
address**, where you subscribed from (a short source tag like `blog-index` or
`docs`), and the timestamps that make the record meaningful: when you subscribed,
when you confirmed, and when you unsubscribed. Nothing else. There is no name
field and no profile.

**It is double opt-in.** Entering your address does not subscribe you: it sends
one email with a confirmation link, valid for 48 hours, and only clicking that
link puts you on the list. Until then, and if you never click, the row is a
pending address and nothing is ever sent to it. We store a hash of the confirm
token, never the token itself.

**The legal basis is your consent, Article 6(1)(a)** — the click on that
confirmation link is the affirmative act, and it is the only thing that puts you
on the list. We log the opt-in in our consent record (`marketing_opt_in`) so we
can demonstrate it, as Article 7(1) requires, and we log the withdrawal
(`marketing_opt_out`) the same way.

**Withdrawing needs no account and no permission from us.** Every issue carries
an unsubscribe link. It is cryptographically signed and keyed to your address
rather than tied to a login session, so it keeps working from an email years old,
without you signing in, replying, or asking. Issues also carry the
`List-Unsubscribe` headers, which put an unsubscribe button in Gmail's and
Yahoo's own interface — one click, and it lands directly on us. Withdrawal is as
easy as consent, which is what Article 7(3) requires and also simply how this
ought to work.

The one place we deliberately add a step: the link in the body opens a page with
a single confirm button rather than unsubscribing the instant it is fetched. That
is not a dark pattern, it is the fix for one — mail scanners and link-safety
checkers prefetch every URL in an inbox, and an unsubscribe that fires on fetch
silently drops people who never clicked anything.

<Note>
  **Transactional email is not marketing and is not part of this.** Email
  verification, password resets, and billing notices are sent because you have an
  account and need to know things about it — the basis is contract, not consent,
  and they have no unsubscribe link because unsubscribing from your own password
  reset is not a thing anyone wants. Subscribing to the newsletter does not
  change what transactional mail you get; unsubscribing from the newsletter does
  not stop it either.
</Note>

When you unsubscribe we keep the row rather than delete it, marked with the date
and that it was user-initiated. That is deliberate: it is the proof we honoured
your withdrawal, and deleting it would let a later signup form quietly add you
back.

### Consent records

We keep a log proving what you agreed to and when — the event, which document,
which version of it, how you agreed, the timestamp, your IP, and your user agent.

This exists because **Article 7(1) GDPR requires a controller relying on consent
to be able to demonstrate it**. A record that you accepted version 1.0 of the
terms on a given date, from a given address, is that demonstration. It is
deliberately narrow: it proves an agreement happened; it does not track you.

### Communications

If you email support, sales, security, or the privacy address, we keep the
correspondence so we can answer and follow up. Transactional email — verification,
password reset, billing notices — is sent through Resend, which receives your
email address and the message.

### Post-deletion record

When an account is deleted we keep a small record of it: the email address, the
display name, the signup IP, the IP and user agent that requested the deletion,
prior subscription details, and the deletion timestamp and reason. Section 5
explains why this is not us quietly keeping your account.

## 4. Why we use it, and our legal basis

| What | Why | Legal basis |
| --- | --- | --- |
| Account data | Create your account, authenticate you, run the service | Contract, Art. 6(1)(b) |
| Billing data | Charge you, invoice you, keep accounting records | Contract, Art. 6(1)(b); legal obligation, Art. 6(1)(c) for the records |
| API usage counts | Enforce quotas, show your usage, bill correctly | Contract, Art. 6(1)(b) |
| Session and device list | Show you your active sessions; detect account compromise | Legitimate interests, Art. 6(1)(f) — account security |
| Auth event log | Investigate compromise and abuse; support | Legitimate interests, Art. 6(1)(f) |
| IP geolocation | Show you where a session came from | Legitimate interests, Art. 6(1)(f) — account security |
| Product analytics in its identified mode — device storage, person profile, session replay | Understand how the docs and the product are actually used, and connect what someone read to what they later did | **Consent, Art. 6(1)(a)** in the EU/EEA/UK/CH (the cookie banner asks); legitimate interests, Art. 6(1)(f) elsewhere |
| Anonymous audience measurement — no device storage, no profile, no IP | Know that the docs are being read at all, and what people search for and do not find | Legitimate interests, Art. 6(1)(f). No consent because ePrivacy Art. 5(3) is not engaged: nothing is stored on or read from your device |
| Server-side account telemetry — signup, key creation, first request, purchases | Know whether our own product works; count revenue accurately | Legitimate interests, Art. 6(1)(f); contract, Art. 6(1)(b) for the billing events. **Not gated by the cookie banner** — no device access is involved |
| Device fingerprint | Abuse prevention; stop bulk free-tier account farming | **Consent, Art. 6(1)(a)** in the EU/EEA/UK/CH (the cookie banner asks); legitimate interests, Art. 6(1)(f) elsewhere |
| Signup IP | Abuse prevention; rate-limit account creation per IP | Legitimate interests, Art. 6(1)(f) |
| Disposable-email check | Keep throwaway accounts off a metered free tier | Legitimate interests, Art. 6(1)(f) |
| Consent log | Prove what you agreed to | Legal obligation, Art. 6(1)(c), with Art. 7(1) |
| Error monitoring | Find and fix bugs | Legitimate interests, Art. 6(1)(f) |
| Transactional email | Tell you things you need to know about your account | Contract, Art. 6(1)(b) |
| Newsletter subscription and sending | Send the newsletter you asked for | **Consent, Art. 6(1)(a)** — double opt-in, withdrawable in one click from any issue |
| Postings containing personal data | Run the dataset (section 7) | Legitimate interests, Art. 6(1)(f) |

Where we rely on legitimate interests we have weighed our interest against your
rights and concluded the processing is proportionate. Ask
<Email kind="dpo" subject="Legitimate interests assessment" /> if you want the
reasoning for a specific one.

## 5. How long we keep it

| Data | Retention |
| --- | --- |
| Account data | For the life of your account |
| API keys | Until revoked; revoked keys are retained as a record of what existed |
| API usage counts | For the life of your account — they are your usage history |
| Sessions | Until the session ends or you revoke it |
| Auth events | **365 days** from the event |
| Idempotency keys | **10 minutes** |
| Consent log | For as long as we may need to prove the consent, and for the limitation period after it |
| Analytics events and session replays | Held on our PostHog project. We have **not** set a custom retention period, so PostHog's own default for our plan applies. We are not going to quote you a number we have not configured — ask <Email kind="dpo" subject="Analytics retention" /> and we will tell you what it currently is |
| Newsletter — confirmed subscriber | For as long as you are subscribed |
| Newsletter — unsubscribed | The row survives, reduced to your email address and the dates: it is the proof that your withdrawal was honoured, and deleting it would let a later signup form add you back |
| Newsletter — address that never confirmed | **7 days** from signup, then deleted. We have no consent to hold it |
| Billing records | For the statutory accounting retention period under Italian law — currently **10 years** — regardless of account deletion |
| Post-deletion record | **30 days** of deletion cooldown, after which it is marked permanently deleted |
| Support email | As long as needed to handle the matter, and a reasonable period after |

The 30-day post-deletion cooldown exists to stop the delete-and-resignup loop
being a way to reset a free quota forever. It is the narrowest thing that works:
it keeps an email address and a couple of IPs, not your account.

Billing records outlive account deletion because tax law says they must. We
cannot delete an invoice on request, and neither can anyone else.

<Warning>
  Retention periods are commitments, and the 365-day and 10-minute expiries are
  set on the records themselves at the moment they are written. Deletion of
  expired records is not yet fully automated — that includes the 7-day purge of
  newsletter addresses that never confirmed, which is written but not yet running
  on a schedule. We would rather tell you that than let the table imply a cron
  job that does not exist. If you want the current state of a specific record,
  ask <Email kind="dpo" />.
</Warning>

## 6. Who we share it with

We do not sell personal data. We do not share it for anyone else's marketing.

We use service providers who process data on our behalf, under contract, on our
instructions: hosting, authentication, database, payments, email, product
analytics, error monitoring, rate limiting, edge delivery, signup validation, and
IP geolocation. Each is listed — with what it receives and where it runs — in
[Subprocessors](/legal/subprocessors).

Analytics is the newest of those and the one worth naming here rather than
leaving to a table: **PostHog**, processing on their EU cloud in Germany. They
process only for us and only on our instructions. Sending events through a proxy
on our own domain does not make them any less a processor of that data, and we
are not going to pretend it does.

Beyond those, we disclose personal data only:

- When the law requires it, or a valid legal order compels it.
- To establish, exercise, or defend legal claims.
- To professional advisers under a duty of confidence.
- To a buyer, if the business is sold or merged — you would be told, and this
  policy would keep applying until you were told otherwise.

## 7. Job postings and the people named in them

This is the interesting part, and we would rather answer it plainly than bury it.

**Where the data comes from.** We collect job postings from employers' own public
career boards — the Greenhouse, Lever, Ashby, Workday or SmartRecruiters page a
company publishes to advertise a role. These pages are published by companies, to
the public, in order to be read. We mirror what is there.

**Why it is mostly not personal data.** A posting is company data: a role, a
location, a salary band, a description. It is about a job, not a person.

**Where personal data creeps in.** Sometimes an employer writes a person into the
posting — "report to Jane Smith, VP Engineering", a named hiring manager, a
recruiter's contact email. We did not ask for it and we do not want it, but if the
employer published it, our copy of the posting contains it. That makes us a
controller of that incidental personal data.

**Our legal basis** is **legitimate interests, Article 6(1)(f)**. Our interest is
operating a dataset of published job postings for business use. The information
was published deliberately, by the employer, on a public page, in a professional
context, precisely so it would be read. The impact on the person named is low, and
it is not information they would reasonably expect to be private — it was put on
the open internet under a company's own name. We think that balance holds. If it
does not hold for you, say so and we will act; see below.

**What we do not do**, and this is the important half:

- We do not build profiles of individuals.
- We do not enrich people. The enrichment we do — skills, seniority, salary,
  taxonomies — describes **jobs**, not the humans named in them.
- We do not sell, or offer, a way to look people up. There is no person search,
  no contact database, no "find the hiring manager" endpoint.
- We do not scrape candidates, CVs, or profiles. We take employers' job ads.
- We do not deliberately collect special-category data, and a posting that
  reveals any is not something we are seeking.

**Transparency, and Article 14(5).** We do not have a relationship with a person
named in a posting and usually have no way to contact them without collecting more
data about them than we hold. Article 14(5)(b) GDPR allows a controller to rely on
public information of this kind in place of individual notice, which is what this
section is for.

**If you are named in a posting.** You can ask us to remove it. Email
<Email kind="dpo" subject="Removal request — named in a posting" /> with a link to
the posting or its job id and tell us which part is about you. We do not need you
to prove a legal basis or make an argument; ask and we will remove it from the
dataset. What we cannot do is take it off the employer's own board — we do not
control that page, and if the posting is still live there, ask the employer too,
or ours may reappear on a later crawl. Tell us and we will suppress the id so it
does not.

Corrections and removals for data that is simply wrong go through
[Data corrections](/help/data-corrections).

## 8. Your rights

Under the GDPR you have the right to:

- **Access** — get a copy of your personal data and be told what we do with it.
- **Rectification** — have inaccurate data corrected and incomplete data
  completed.
- **Erasure** — have your data deleted, where one of the Article 17 grounds
  applies.
- **Restriction** — have us pause processing while something is disputed.
- **Portability** — get the data you gave us in a machine-readable format, and
  have it sent to another controller where technically feasible.
- **Object** — object to processing based on legitimate interests, including
  everything in this policy resting on Art. 6(1)(f). If you object we stop unless
  we can show compelling legitimate grounds that override your rights.
- **Withdraw consent** — where we rely on consent, withdraw it at any time,
  without affecting processing already carried out.

Exercising a right is free and we will answer **within one month**. If a request
is complex we may extend that by two months and will tell you why. We may ask you
to confirm your identity — not as an obstacle, but because handing your data to
someone claiming to be you would be worse.

## 9. How to exercise them

**By emailing <Email kind="dpo" />.** That is the route for all of them.

<Warning>
  There is **no self-serve delete button** in the portal today. We are not going
  to pretend otherwise, or point you at a settings page that does not have one.
  Account deletion, data export, and every other right is handled by a person who
  reads that mailbox.
</Warning>

Some useful subject lines, which just route you faster:

- <Email kind="dpo" subject="Data Export Request" /> — a copy of your data.
- <Email kind="dpo" subject="Account Deletion Request" /> — delete the account.
- <Email kind="dpo" subject="Objection to Processing" /> — object under Art. 21.
- <Email kind="dpo" subject="Removal request — named in a posting" /> — you are
  named in a posting.

[Deleting your account](/help/delete-account) walks through what deletion
actually does, including what survives it and why — see section 5 on billing
records and the deletion cooldown.

## 10. Automated decision-making

We do not carry out automated decision-making that produces legal effects
concerning you or similarly significantly affects you. **Article 22 GDPR does not
apply to our processing.**

Specifically, and because this is the question we expect: the device fingerprint
does not automatically block, throttle, restrict, or deny anything. It is stored
for a human to look at if an abuse investigation happens. There is no score, no
model, and no automatic action attached to it.

Quota and rate-limit enforcement is automated, but it is arithmetic against the
plan you bought — not a decision about you as a person.

## 11. International transfers

We are in Italy. Some of our providers process data outside the EEA, principally
in the United States.

Where that happens we rely on the **European Commission's Standard Contractual
Clauses**, or on an adequacy decision where one covers the provider — including
the EU–US Data Privacy Framework for certified US providers — together with
additional technical measures such as encryption in transit and at rest.

[Subprocessors](/legal/subprocessors) lists where each provider processes data.
Several are configured to EU regions specifically, including our error monitoring
and our product analytics — PostHog ingests to its **EU cloud in Germany**, so
your analytics events are not a transfer at all.

To get a copy of the safeguards for a specific transfer, ask
<Email kind="dpo" subject="Transfer safeguards" />.

## 12. How we protect it

- **Passwords never reach us.** Firebase Authentication holds credentials; our
  servers never see a password.
- **API keys are stored as SHA-256 hashes**, never in the clear. A database leak
  does not leak working keys.
- **Session cookies are `httpOnly`**, so page JavaScript cannot read them, and
  `secure` in production.
- **CSRF protection** on state-changing requests, using a double-submit token.
- **A strict Content Security Policy**, nonce-based on every page that renders
  your data, which blocks injected scripts even if HTML injection succeeded.
- **Rate limiting** on authentication endpoints, and **account lockout** after
  repeated failed sign-ins.
- **Bot resistance** via Firebase App Check with reCAPTCHA Enterprise, and edge
  filtering at Cloudflare.
- **Breached-password checking** at signup, using the Have I Been Pwned range
  API. This uses k-anonymity: only the **first five characters of a SHA-1 hash**
  of the password are sent, so your password — and enough of its hash to identify
  it — never leaves your browser. HIBP cannot learn your password, and is not a
  subprocessor.
- **Error monitoring** through Sentry, configured to its **EU region**.
- **Encryption in transit** everywhere, and at rest at our hosting and database
  providers.

No system is perfectly secure, and we will not claim ours is. If you find a
vulnerability, tell <Email kind="security" subject="Vulnerability report" />. If a
breach ever puts your rights at risk, we will notify the Garante within 72 hours
and tell you where the GDPR requires it.

## 13. Children

The service is a business product for developers. It is not directed at children,
we do not knowingly collect data from anyone under 16, and you must be 16 or older
to hold an account. If you believe a child has given us data, tell
<Email kind="dpo" /> and we will delete it.

## 14. Cookies

The portal's own cookies are all strictly necessary — session, CSRF, and the
like — and those need no consent, because switching off the cookie that signs you
in just means not being signed in.

There is a consent banner, and it asks about the two things that are genuinely
your choice: **product analytics** in its identified mode (PostHog's `ph_*`
cookie, a person profile, session replay) and the **device fingerprint** taken at
signup for abuse prevention. Decline either and it does not happen. What
declining does not stop — anonymous page counts that touch nothing on your
device, and our own server-side record of what your account did — is set out in
sections 3 and 4 above, and on the banner itself.

[Cookie Policy](/legal/cookies) lists every cookie, every localStorage key, and
the reasoning for each.

## 15. Complaints

Talk to us first — <Email kind="dpo" /> — because we can usually fix it faster
than anyone else can.

You also have the right to complain to a supervisory authority. Ours is the
**Garante per la protezione dei dati personali**, the Italian data protection
authority, at `garanteprivacy.it`. If you live or work in another EU or EEA
country, you may instead complain to your own local supervisory authority.

## 16. Changes

We will update this policy when what we do changes. Material changes get at least
30 days' notice by email or in the portal before they take effect. Every version
carries a version number and a date, both at the top of this page.

We will not retroactively reduce your rights over data we already hold without
asking you first.

## 17. Contact

| Role | Contact |
| --- | --- |
| Controller | <LegalEntity /> |
| Privacy contact | <Email kind="dpo" /> |
| Security | <Email kind="security" /> |
| Everything else | <Email kind="support" /> |
| Supervisory authority | Garante per la protezione dei dati personali (`garanteprivacy.it`) |