Privacy Policy

The Hungarian text governs. This is a translation for convenience.

1. Who we are


Name	Kántor Attila egyéni vállalkozó
Registered seat	7940 Szentlőrinc Pécsi út 14/A, 2/7
Registry number (register of sole traders)	59856054
Tax number	90593761-1-22
E-mail	kantor.attila@carbonhost.hu
Phone	+36 70 416 8003
Physical location of the servers (data centre)	RendszerNET Kft., 7030 Paks, Kölesdi út 44.

We run the platform and the servers ourselves; the data centre above provides the physical housing of the servers and their network connection.

We have not appointed a data protection officer; Article 37 GDPR does not require one of us. We answer privacy questions at the address above.

2. What we process, why, and on what basis

2.1 Account and billing

Registration requires: e-mail address, first and last name, billing country, postal code, city, and street and house number. Registering as a company also requires the company name and tax number. Optional: floor/door, for a company the company registration number, and a phone number. Without the required data, registration and entering into the contract are not possible.

Only for registering a .hu domain do we ask for the identifier the .hu Registry makes a condition of registration: an identity-document number from a private individual, a tax number from a company. It is used solely to register the domain and to pass to the Registry, and is asked for only when you order a .hu domain. The identity-document number is not held by our central identity system (Keycloak), only by our own records.

Basis: performance of the contract (Art. 6(1)(b)); for billing and tax identifiers, a legal obligation (Art. 6(1)(c)).
Retention: data appearing on accounting documents is kept for at least 8 years under the Hungarian Accounting Act (2000. évi C. tv. § 169); there is currently no automatic deletion when that period ends, so the data is currently kept without a time limit. There is currently no automatic deletion period for the rest of the account data; see sections 5 and 7.

The data above, except the phone number, is also held by our central identity system (Keycloak), as a separate user record. On an erasure request we proceed in both records as described in section 7.

2.2 Sign-in and passwords

The platform's database does not store your password; the central identity system stores it, as an irreversible hash. When you sign in, the portal passes the password you enter on to the identity system and does not save it; for the web security filter's log, see section 2.11. If you use two-factor authentication, its secret key is also stored by the identity system.

Password-reset and e-mail-verification links are stored in the database only as irreversible SHA-256 digests; in full they appear in the e-mail sent, in the mail queue (after a successful send, for at least a day unless more than a thousand messages have been sent since, and then until the next message is sent successfully; without a time limit if sending fails) and, when opened, in the operational logs (section 2.11). They expire after 30 minutes and 24 hours respectively.

We keep your signed-in state in an encrypted cookie. It holds the access, refresh and ID tokens issued by the identity system, and your account identifier, e-mail address and roles. The cookie is set when you sign in, or when you change your password in the portal, and expires 30 days after that; using the portal does not extend it. Your sign-in may end before the cookie expires. If you did not tick "Keep me signed in" when you signed in, or if you changed your password in the portal, your sign-in ends no later than 10 hours after you signed in or changed your password; if you ticked it, the identity system issues a long-lived refresh token, and, provided you have not changed your password since, your sign-in ends no later than when the cookie expires. The cookie may then remain in the browser until it expires, but no longer gives access. The cookie is deleted when you sign out. The Cookie Policy gives the details.

Basis: performance of the contract (Art. 6(1)(b)).

2.3 Fraud prevention and automated decisions

Called out separately, because it can produce legal effects concerning you.

Registration is automatically refused if the e-mail address belongs to a disposable (single-use) domain or to a domain we have blocked. This is a solely automated decision: the account is not created.

We do not currently score risk from IP addresses, and we do not hold back orders on the basis of a risk score. The system records a risk score at registration against the account and in the event log, and at checkout against the order, where the reasons for the score and the screening result are recorded as well; without IP-based scoring the score is currently always 0. Before introducing IP-based scoring we will amend this notice and describe the criteria and the consequences.

The sign-in, registration, password reset, order, ticket, contact and withdrawal forms run Cloudflare's Turnstile bot check: it loads from Cloudflare's servers, reads technical characteristics of your browser to filter out automated abuse, and sends them to Cloudflare together with your IP address (section 4).

Basis: legitimate interest (Art. 6(1)(f)) — preventing fraud and abusive use.
Your right: under Article 22 GDPR you may ask for the decision to be reviewed by a person, express your point of view and contest the decision. Write to kantor.attila@carbonhost.hu.
Retention: see section 5.

2.4 IP addresses and device data

At checkout we record your IP address and keep it with the order.
At sign-in and on security-relevant actions the event log (section 6) records the IP address and the browser user agent.
Basis: legitimate interest (Art. 6(1)(f)) — security and abuse prevention.
Retention: see section 5.

2.5 Support

We store the data of tickets opened in the portal, enquiries sent with the contact form and e-mails written to the support address — the sender's name and e-mail address, the message and the attachments — together with the internal notes added to them and any satisfaction rating you give, in order to answer you and to be able to look the matter up later. E-mails arriving at the support address may also be recorded as tickets.

Basis: for customers, performance of the contract (Art. 6(1)(b)); for enquirers, steps prior to entering into a contract (Art. 6(1)(b)) or legitimate interest (Art. 6(1)(f)); for consumer complaints, a legal obligation (Art. 6(1)(c); Hungarian Consumer Protection Act, 1997. évi CLV. tv. § 17/A).
Retention: see section 5.

2.6 Data arising from use

For hosting and virtual servers the system records resource usage (storage, processor time, traffic) to monitor plan limits, to plan capacity and to show usage in the portal. Traffic served per web hosting site is measured by the requested domain name, without visitors' IP addresses. The plan's traffic allowance is not currently enforced: going over it only shows in the usage figures.

Basis: performance of the contract (Art. 6(1)(b)); for capacity planning, legitimate interest (Art. 6(1)(f)).
Retention: see section 5.

2.7 The declarations made when ordering

When you order we record whether you ordered as a consumer or as a business (with the tax number given, for a business), the version of the Terms you accepted and of the Privacy Policy shown to you, whether you as a consumer asked for the service to start immediately and the version of the declaration text shown, and when all of this happened. No IP address is attached to this record.

Basis: performance of the contract (Art. 6(1)(b)) and legitimate interest — establishing and defending legal claims (Art. 6(1)(f)).
Retention: at least 5 years from the end of the contract, the general limitation period for civil claims (Hungarian Civil Code § 6:22). The record cannot be altered afterwards. There is currently no automatic deletion when that period ends, and no established deletion procedure, so the entries are currently kept without a time limit.

2.8 Withdrawal statements

When you send a withdrawal statement — with the "Withdraw from contract here" function on the website, in the portal, by e-mail, phone or post — we record the name given, the contract identifier (an order number, for example), the e-mail address given for the acknowledgement of receipt, any domain names named, the text of the statement, when it was sent and when it arrived, for a statement sent while signed in, the account and the order, and for a statement recorded by staff, the staff member who recorded it and any note they added. For a statement sent through the public form or in the portal, the record of the statement does not hold the full IP address, only the network prefix (/24 for IPv4, /48 for IPv6); the request itself, with the full IP address, is kept in the operational logs as sections 2.11 and 5 explain. We e-mail the acknowledgement of receipt and keep it as a PDF as well; a support ticket may be opened to process the statement. For a statement received through the public form, the event log (section 6) records the reference number and the network prefix, without a name or e-mail address.

On the public form we also record whether the bot check succeeded; the basis for this is also legitimate interest (Art. 6(1)(f)) — preventing abuse of the function.

Basis: a legal obligation (Art. 6(1)(c)) — receiving the withdrawal, acknowledging its receipt and refunding (Government Decree 45/2014. (II. 26.) §§ 22–23); for the network prefix, legitimate interest (Art. 6(1)(f)) — preventing abuse of the function; for keeping the record, legitimate interest — establishing and defending legal claims.
Retention: at least 5 years from the closure of the withdrawal case (Hungarian Civil Code § 6:22); there is currently no automatic deletion when that period ends, so the data is currently kept without a time limit. The statement cannot be altered afterwards: the only change allowed is a one-time erasure of its personal data — the name, e-mail address, contract identifier, domain names, the text of the statement, the staff note and the network prefix — after which what remains is an irreversible digest of the content, the reference number, the timestamps and, where there were any, the identifiers of the account, the order and the staff member who recorded it. In addition, the event log (section 6) keeps, without a time limit, the reference number and network prefix of a statement received through the public form; for a statement sent in the portal, the reference number, the identifiers of the order and of the items selected, and the identifier and e-mail address of your account; for a statement recorded by staff, the reference number, channel, timestamps, the order identifier, and the identifier and e-mail address of the staff member who recorded it. There is currently no established procedure and no automated job for erasing the personal data — including the PDF copy of the acknowledgement of receipt and the personal data in the support ticket opened for the statement: on a justified request we carry out the erasure by hand, case by case, and our reply states what we erased.

2.9 Staff customer view and access

To handle a support request, troubleshoot or investigate abuse, an administrator may enter the view of your customer account for up to one hour and act on your behalf there, for example reveal your database credentials or open the database manager. We record the staff member's and your account's identifiers and e-mail addresses, when the session started, ended and expires, the IP address, the user agent, a summary of the functions viewed and every change made; these also go into the event log (section 6). The system does not currently record the reason for entering.

Basis: for handling a support request and troubleshooting, performance of the contract (Art. 6(1)(b)); for investigating abuse and for accountability, legitimate interest (Art. 6(1)(f)) — detecting abuse and keeping staff access accountable.
Retention: see section 5.

2.10 Referral programme

If you arrive through a referral link, we ask whether we may remember the referrer. If you consent, we keep the referrer's code in a cookie for 30 days and, if you register in that time, record on your account which referrer brought you. This serves to account for the referrer's commission: commission arises only while the referral programme is running, and only after your first successful payment; we then record the referrer, you, the payment and the commission amount.

Basis: consent (Art. 6(1)(a)); for placing the cookie, § 155(4) of the Hungarian Electronic Communications Act (2003. évi C. tv.).
Withdrawal: you may withdraw your consent at any time as described in the Cookie Policy, which deletes the cookie. If you have already registered, you can ask at kantor.attila@carbonhost.hu for the referrer recorded on your account to be erased; we do this by hand. The referrer's identifier remains in the event log entry of your registration (section 6) even then and, if a commission has already been recorded, in the commission accounting data (section 5). Withdrawal does not affect the lawfulness of earlier processing.
Retention: see section 5.

2.11 Operational and security logs

The portal, the API and the servers keep logs as they run: we record a request identifier and time, the requested URL, the IP address and the user agent; the API's log also holds the request's other headers, except cookies and the authorisation header. For debugging we record technical traces, on the servers we record security events (such as sign-ins to the servers), and we also store the security (CSP) reports browsers send. The logs of the servers of the platform's cluster (the web entry point and the control, database and hosting servers) are kept in our own segregated logging and security monitoring system; a local copy also remains on the server where the log was written (section 5). That system does not currently collect the logs of the mail servers, the DNS servers or the virtualisation system.

The web security filter (WAF) in front of the servers logs requests it judges suspicious with their full content — the headers, including cookies, and the form data submitted. If such a request was a sign-in form, the password entered may also end up in that log.

The central identity system also stores sign-in events (time, account identifier, IP address, event type and, for a failed attempt, the error) and administrative changes made to accounts, including the changed data, in its own database.

Basis: legitimate interest (Art. 6(1)(f)) — operations, debugging and fending off attacks.
Retention: see section 5.

2.12 Organisations, SSH keys, phone number and notifications

Organisation invitations: if you invite someone to your organisation, we store the invitee's e-mail address, the role offered, who invited them and when. We receive this data from you. An invitation expires after 72 hours. The invitation link is stored in the database only as a digest; in full it appears in the e-mail sent, in the mail queue and, when opened, in the operational logs, as section 2.2 describes for password-reset links.
SSH keys: we store the public key you give — including any comment in it, which often contains a name or machine name — and the name you give the key, to set up access to the service.
Phone number: we use the phone number you optionally give to contact you about your account, for example to identify the sender of a withdrawal statement.
Notification e-mails: we send notices about the contract and your account (for example orders, proformas, payment reminders, suspension, termination, withdrawal acknowledgements, account security notices) by e-mail. We send no newsletters and no advertising e-mail.
Basis: performance of the contract (Art. 6(1)(b)); for notices required by law, a legal obligation (Art. 6(1)(c)); for invitees' data, legitimate interest (Art. 6(1)(f)) — managing access to the organisation.
Retention: see section 5.

2.13 Cookies and local storage

We use the cookies the portal needs to work, a cookie that keeps the display you chose, and your browser's local storage; the only cookie we ask consent for is the referral cookie, which is set only with your consent (section 2.10). Section 2.2 covers the sign-in cookie, and the Cookie Policy describes the cookies in detail.

3. Data you store — here we are a processor

What you put into your hosting, database, environment variables, mailbox, virtual server or DNS zone is not processed for our own purposes. For that data you are the controller and we are the processor, acting only on your instructions and only as far as providing the service requires. The details are in the data processing section of the Terms.

Two things must be said here as well:

Your visitors' data reaches us too. The web servers log the visitor's IP address, the requested host and URL (including query parameters), the response code, the number of bytes transferred and the response time; a hosting site's own access log may also contain the referring page (referer) and the user agent. We process these logs for our own purposes — operations and fending off attacks — as a controller; basis: legitimate interest (Art. 6(1)(f)), retention: section 5. If your website has its own privacy notice, this is worth stating in it.

Access to your data. In normal operation we do not read the content you store. Staff access through the portal — the customer view, revealing database credentials, opening the database manager — is described in section 2.9 and is written to the event log, which cannot be altered afterwards. As the operator of the servers, with administrator rights we can also access the data stored on them (files, databases, mailboxes, virtual servers) directly. We do so to troubleshoot, to investigate abuse or to comply with a legal obligation; such direct access is not written to the event log. On the servers of the platform's cluster (section 2.11), SSH sign-ins are recorded in the security log, but what is done after signing in is not recorded in full; this does not currently cover the mail servers, the DNS servers or the virtualisation system. Section 12 of the Terms currently in force says every access to the customer's database for troubleshooting or investigating abuse is logged. We log access through the portal as described above, but direct access on the servers with administrator rights is not logged, or only in part; we will amend the Terms accordingly.

4. Who we share data with

Only those who need it to provide the service, and those we are required by law to give it to.

The following we run ourselves, on our own servers: the central identity system (Keycloak), the mail system for customer mailboxes (Mailcow), a separate mail server of our own that delivers system messages, the DNS servers (PowerDNS), the store for invoice PDFs and web hosting backups, and the logging and security monitoring system. The mail server that delivers system messages is operated by us alone, and nobody else has access to it. The servers are housed in the data centre named in section 1; backups of some virtual machines we run and of customers' virtual servers are stored by the backup provider listed in the table below.

Recipient	What they receive	Why	Where
KBOSS.hu Kft. (Számlázz.hu)	billing name, address, tax number, e-mail address, line items and amounts	issuing proformas and invoices (as processor)	Hungary
Hungarian Tax and Customs Administration (NAV)	the data of the invoices issued, through Számlázz.hu	invoice data reporting required by law	Hungary
the bank that keeps our account	for a bank transfer, the payer's name, account number, the amount and the payment reference	receiving the payment (as an independent controller)	Hungary
Stripe Payments Europe, Limited	your e-mail address, the order or proforma reference and amount; you enter card details directly on Stripe's page	card payment and fraud prevention	Ireland, with transfer to the USA
Cloudflare, Inc. (Turnstile)	your IP address and technical characteristics of your browser when you submit a form	filtering automated abuse	USA
Wasabi Technologies	full disk images of some virtual machines we run and of customers' virtual servers (every virtual server that has not been terminated, and the last backup of terminated ones), which may contain any data stored on the machine, personal data included	backup and recovery (as processor)	European Union (the provider is a US company)
Komoot GmbH (photon.komoot.io, public OpenStreetMap search)	the street fragment typed and the city, without an IP address or any other identifier	suggesting street names when you fill in a billing address	Germany
Internet Security Research Group (Let’s Encrypt)	the domain name a certificate is requested for	issuing the HTTPS certificate	USA
ZeroSSL GmbH	the domain name a certificate is requested for, when Let’s Encrypt does not issue the certificate	issuing the HTTPS certificate as fallback issuer	Austria
RendszerNET Kft., 7030 Paks, Kölesdi út 44.	physical housing of the servers	operating the platform	Hungary

We start using a new recipient only after the version of this notice that lists it has taken effect.

We currently use no SMS provider.

About card payments: you enter the card number, expiry and security code on Stripe's payment page; they never reach us. Stripe's own notice covers its processing for running the payment and preventing fraud: https://stripe.com/privacy

About the geocoder: the lookup is made by our own server, so your IP address does not reach the provider — only the street fragment and the city name.

About certificates: to request an HTTPS certificate we send only the domain name, under our own technical account. Issuing the certificate publishes your domain name to public, worldwide Certificate Transparency logs. Those logs cannot be erased, and the entry outlives the service. A domain name is personal data only where it can be linked to a natural person.

Where processing takes place: the systems we run and the data in them are located in Hungary. Data leaves the European Economic Area through the recipients whose "Where" column names the USA. The backup provider is a US company: it stores the virtual machine backups in the European Union, but we cannot rule out access to the data from the USA.

For Stripe, the basis of the transfer is the Commission's EU–US Data Privacy Framework adequacy decision (Art. 45 GDPR) where the recipient is certified under it, and otherwise the Commission's standard data protection clauses (Art. 46(2)(c) GDPR).

For Cloudflare, the basis of the transfer is the Commission's EU–US Data Privacy Framework adequacy decision (Art. 45 GDPR) where the recipient is certified under it, and otherwise the Commission's standard data protection clauses (Art. 46(2)(c) GDPR).

Sending the domain name to Let’s Encrypt is necessary to issue the HTTPS certificate requested automatically for your domain (Art. 49(1)(b) GDPR).

5. How long we keep it

Where the table below says "currently without a time limit", there is no automatic deletion today and no retention period has been set; we would rather say so than state a period the system does not keep.

Data	Retention
Account data	currently without a time limit, including after the account ends; on an erasure request we proceed as set out in section 7
Data on accounting documents	at least 8 years (2000. évi C. tv. § 169); there is currently no automatic deletion when that period ends, so currently without a time limit
Orders, payments and balance movements	currently without a time limit; data on accounting documents for at least the period above
IP address recorded at checkout	with the order, currently without a time limit
Risk score at registration and at checkout, the reasons for the score and the screening result	with the account, the order and in the event log, currently without a time limit
Declarations made when ordering	at least 5 years from the end of the contract; there is currently no automatic deletion, so currently without a time limit
Withdrawal statements and acknowledgements of receipt	at least 5 years from the closure of the withdrawal case; there is currently no automatic deletion, so currently without a time limit; details in section 2.8
Tickets, enquiries, attachments	currently without a time limit; a consumer complaint and our reply for at least 3 years (Fgytv. § 17/A)
Event log	currently without a time limit, see section 6
Sign-in and administrative events of the identity system	currently without a time limit, including after the account is deleted
Record of staff customer-view sessions	currently without a time limit
Referrer recorded on the account	with the account; erased from the account on request after consent is withdrawn, but it remains in the event log entry of the registration (section 6) and, if a commission has already been recorded, in the commission accounting data
Commission accounting data (referrer, referred customer, payment, commission amount)	currently without a time limit
Organisation invitations	an invitation expires after 72 hours; its data is currently kept without a time limit
SSH keys	until you delete them, currently also after the service ends
Logs of the portal, the API, the servers and the web security filter, and access logs of visitors to websites	30 days in the central logging system; the local copies on the servers are not deleted by age, so they can remain for longer than 30 days, even without a time limit; for a web hosting site running on the OpenLiteSpeed web server, the web server on the hosting server closes the site's own access or error log and starts a new one once the log grows past 10 MB, and each time it closes a log it deletes that log's closed copies older than 3 days (access log) or 7 days (error log); as this deletion runs only when a log is closed, a closed copy (on a low-traffic site, possibly for a long time) and the log file currently being written can remain for longer
Technical traces	7 days
Alerts and events of the security monitoring system	90 days in the searchable alert indices; the same alerts in the monitoring system's local log files currently without a time limit
Resource usage and traffic data	48 hours in detail on the hosting server; in the central system, with the service, currently without a time limit
Files and databases of terminated web and Node.js hosting	30 days from termination, then permanent deletion
Backups of web hosting	for the period set in the platform's settings, at least 28 and at most 365 days from when the backup was taken; deletion runs weekly, so a backup can remain for longer, and while weekly backups are switched off, existing backups are not deleted; a site's last successful backup remains whatever its age, also after the service ends, until we delete it on request; if we delete the record of a terminated site whose data has already been permanently deleted, the site's remaining backups stay in the store without a time limit and can only be deleted by hand
Mailboxes of a terminated service	removed from the mail system at termination; the mail server keeps the messages for a further configured period — 5 days under Mailcow's default setting — and then deletes them permanently
DNS zones and records	currently without a time limit: deleted zones and records, and the records of zones belonging to a terminated service, remain in our database even once they have been removed from the name servers; a deleted record's data is only overwritten when a record with the same name and type is later written to the zone
Disk of a terminated virtual server	deleted at termination; for backups taken of it earlier, see the next row
Virtual machine backups at the backup provider	customers' virtual servers are backed up in full every week and only the latest backup of each server is kept, the previous one being deleted at the next successful backup; the virtual machines we operate ourselves are backed up daily and the latest 30 backups are kept; the last backup of a terminated virtual server currently remains until deleted by hand, with no automatic deletion
A database marked for deletion	30 days, restorable throughout
Data deleted from the live system but still in backups	until the retention period of that backup, above, ends

Section 11 of the Terms currently in force says the data of a terminated service is kept for 30 days and then permanently deleted. The files and databases of web and Node.js hosting are kept for 30 days from termination, as the table above shows; for several other kinds of data — among them a virtual server's disk, mailboxes, DNS zones and records, backups, resource usage data and SSH keys — the table describes the different practice we actually follow. We will amend the Terms accordingly.

6. Security

What we actually do:

The connection between your browser and the platform is available over TLS only, with HSTS.
Account passwords are not stored in the platform's database; the central identity system stores them as irreversible hashes. Password-reset and e-mail-verification links and organisation invitation links are likewise stored in the database only as digests; in full they appear in the e-mail sent, in the mail queue and, when opened, in the operational logs (sections 2.2 and 2.12). For a sign-in request judged suspicious, the password entered may also end up in the web security filter's log (section 2.11).
Credentials you can reveal in the portal (database passwords and a virtual server's initial password), and a hosting site's environment variables, are stored with AES-256-GCM encryption and decrypted only when displayed or when the service is configured. A virtual server's initial password is deleted from the database after it is first displayed. The same password is also included in plain text in the e-mail announcing that the machine is ready; the mail queue keeps the message's data, the password included, for the time section 2.2 describes, and without a time limit if sending fails. We recommend changing the password when you first log in to the server.
Your signed-in session and its tokens are kept in an encrypted cookie (section 2.2).
Two-factor authentication is mandatory for administrator access to the portal.
The servers run on a segregated private network.

Event log. We keep a log of actions that matter for security and accountability (for example sign-in, permission and settings changes, staff access, registration, orders, withdrawals). Its entries are protected by chained digests, so they cannot be altered or deleted afterwards. An entry may contain the identifier and e-mail address of the account that acted and of the account affected (for a failed sign-in, the e-mail address typed, even where no account has it), the IP address, the user agent, the risk score and referrer at registration, and the previous and new values of changed data. Basis: legitimate interest — detecting abuse and defending legal claims (Art. 6(1)(f)). Retention: currently without a time limit. The reason is that, because of the chained digests, an entry cannot be deleted or anonymised without breaking the chain; a retention period can only be introduced once the log has been restructured, and that has not happened yet. For the same reason entries are not altered on an erasure request. You may object to this as well under section 7, but even if we uphold the objection there is currently no technical means to delete or anonymise the entries; our reply will say so.

What we do not claim: database contents are not encrypted at the disk level, and internal network traffic is not end-to-end encrypted. We would rather say so than promise the opposite.

7. Your rights

Right to object. You may object at any time, on grounds relating to your particular situation, to processing based on legitimate interest, by writing to kantor.attila@carbonhost.hu. This covers fraud prevention and the handling of IP addresses (2.3, 2.4), enquiries from prospective customers (2.5), capacity planning (2.6), keeping declarations to defend legal claims and recording the network prefix of a withdrawal statement (2.7, 2.8), staff access for investigating abuse and its accountability (2.9), operational and security logs (2.11), invitees' data (2.12), the logs of visitors to websites (section 3) and the event log (section 6; even after an objection we cannot currently delete or alter its entries). We then stop processing the data unless we demonstrate compelling legitimate grounds for it which override your interests, rights and freedoms, or the processing is needed to establish, exercise or defend legal claims.

You may also request access, rectification, erasure or restriction, and portability of the data you provided that we process by automated means on the basis of contract or consent. You may withdraw your consent to the referral cookie and to recording the referrer at any time (section 2.10); withdrawal does not affect the lawfulness of earlier processing.

Requests are free of charge and go to kantor.attila@carbonhost.hu; if we have doubts about your identity, we may ask for more information. We will fulfil your request without undue delay and within one month at the latest; where we cannot fulfil any part of it, we tell you within the same period why not, and that you may complain to the authority or go to court. That period may be extended by two further months where requests are complex or numerous; if so, we tell you within the first month, with the reasons.

Plainly: the portal has no self-service account or data deletion and no data-export button today. We receive these requests by e-mail and handle them by hand. On an erasure request, today this happens: the sign-in account in the central identity system is disabled — in which case the data held there remains — or permanently deleted, and in our own database the account is marked as deleted. In either case the earlier events in the identity system's event store (section 2.11) remain. The account record, with its personal data, remains even then, because invoices, orders and the event log refer to it; there is currently no established procedure for anonymising the personal data. Data on accounting documents must be kept until the end of the statutory retention period, and event log entries cannot be deleted, as section 6 explains. Our reply lists exactly what we erased, what we kept, and why.

8. Complaints

Write to us at kantor.attila@carbonhost.hu.

You may also complain to the Hungarian National Authority for Data Protection and Freedom of Information (NAIH, 1055 Budapest, Falk Miksa utca 9-11.; postal: 1363 Budapest, Pf. 9.; phone: +36 1 391 1400; ugyfelszolgalat@naih.hu; www.naih.hu), or to the supervisory authority of the EU Member State of your habitual residence, place of work or place of the alleged infringement (Art. 77 GDPR). If your rights are infringed you may also go to court (Art. 79 GDPR); at your choice, the action may also be brought before the regional court (törvényszék) of your domicile or place of residence (Infotv. § 23).

9. Changes

We keep this notice aligned with how data is actually processed; a clarifying amendment takes effect on the day it is published. We also e-mail your registered address about material changes, in particular a new purpose or a new recipient; we start processing for a new purpose or using a new recipient no earlier than 15 days after that notice. The version shown when you ordered remains available at the link in the e-mail confirming receipt of your order.

This version introduces no new processing: it adds processing and recipients that were already in place but missing from the previous version — among them the backup provider, ZeroSSL, the Hungarian Tax and Customs Administration and the bank that keeps our account — and corrects inaccurate descriptions. It therefore takes effect on the day it is published, and no separate e-mail notice was sent about it. Among the recipients already in use but missing from the previous version, it also adds Stripe, which handles card payments (section 4).

In force from: 2026-10-28