Can you trust us with your participants' data?

The data of an event — registrations, teams, projects, scores and results — belongs to the organisation that runs it. We process it only to run that organisation's events. Each person's own account belongs to them.

• We do not sell personal data and do not use it to build profiles for anyone else.
• No advertising, no third-party analytics and no tracking scripts: the site's Content Security Policy lets scripts load from our own address only.
• Cookies are used only to sign you in and remember your settings; the cookie policy lists every one of them.

• Every connection is encrypted (HTTPS), and browsers are told to use only HTTPS for this site for a year (HSTS).
• Every page is sent with security headers: a Content Security Policy that keeps scripts, styles, fonts and connections to our own origin and forbids framing the site; X-Frame-Options: DENY; X-Content-Type-Options: nosniff; Referrer-Policy: strict-origin-when-cross-origin; and a Permissions-Policy that switches off the camera, microphone, location, payments and USB. The camera is allowed only on the check-in scanner pages.
• Passwords are stored only as bcrypt hashes (cost factor 12), never in a readable form.
• New accounts confirm their e-mail address. Changing the address needs a link sent to the new one, and the old address gets a link to report the change if it was not you.
• E-mail confirmation and password reset links are stored only as hashes, work once and expire — after 72 hours and one hour.
• Sessions live in a cookie the page's scripts cannot read (HttpOnly, SameSite=Lax, HTTPS-only in production). Changing or resetting a password ends every other session, and in your account settings you can sign out of all other devices at once.
• Failed sign-ins are limited per network and per account, so a password cannot be found by guessing. Password reset e-mails, confirmation links, invitations, exports and the AI assistant have their own limits.
• Changes sent from pages on other websites are refused: the platform checks where every write request comes from (the Origin and Sec-Fetch-Site headers), on top of the SameSite cookie.
• Uploaded files are checked by their content, not their name — a script disguised as an image is refused — and files are served so that a browser cannot run them as pages.
• Spreadsheet exports are protected against formula injection: a cell a spreadsheet would run as a formula is neutralised.
• Webhooks are signed (HMAC-SHA256) and delivered only to public HTTPS addresses, never into our own or a private network.

• Every request is checked on the server against the organisation and the event it concerns. One organisation cannot see another organisation's events, people or files.
• These rules are covered by automated tenant-isolation and access-control tests that run on every change before it is released.
• Seats follow least privilege. Owner and Admin run everything; a Coordinator runs the event day (registrations, check-in, teams, announcements, chat, the help queue); an Editor builds events; a Viewer can only look. Coordinators and editors cannot publish, delete or archive events, touch judging, results or certificates, or manage seats, billing or webhooks.
• Judges, mentors, volunteers and participants see only their own part of the events they belong to.
• Sensitive actions — role and password changes, e-mail confirmations, decisions on orders, publishing and archiving events, chat moderation — are written to an audit log with who acted, when, and from which IP address.
• The platform owner's console runs on its own address; on the public site its pages do not exist.

• Every person can download a copy of their data (JSON) and delete their account themselves, in their account settings.
• When an account is deleted, the name and e-mail address are erased, the profile, registration answers and uploads are removed, and every session ends. Invoices are kept because accounting law requires it; scores and team results stay under “Deleted user” because other people's results depend on them.
• Organisers can export a whole event as a ZIP file — settings, people, teams, projects, scores, results, certificates, announcements, help requests and feedback as CSV, with the uploaded files — and export participants and invitations as CSV and certificates as PDFs.
• Fourteen days after it ends, an event is archived: it can still be read and exported, but nothing in it can be changed. An organiser can delete an event, and its registrations, teams, submissions, scores, chat, certificates and files go with it.

Records that are only needed for a while are deleted automatically:

• In-app notifications after 90 days.
• The mail log — the recipient, subject and outcome of each e-mail, never its content — after 90 days.
• Webhook delivery records after 30 days.
• Messages received from Telegram after 7 days.
• AI assistant drafts a week after they expire.
• The text of a removed chat message at once.

Everyone chooses which e-mails and Telegram messages they receive, per category: announcements, team, results, mentors and reminders. Those e-mails carry a one-click unsubscribe link. Security e-mails, such as confirmations and password resets, are always sent. Your rights over your data are set out in the privacy policy.

We use a small number of providers, each only for its part of the service:

• Vercel

  What for

  Hosts the website and the web app.

  What it receives

  Page requests from your browser.

• Render

  What for

  Runs the platform's API servers, in its Frankfurt (Germany) region.

  What it receives

  The data the platform works with, while it works with it.

• Supabase (PostgreSQL)

  What for

  The database, uploaded files included.

  What it receives

  All platform data, stored.

• Resend

  What for

  Sends the platform's e-mails. Brevo or an SMTP mail server can be used instead, depending on our configuration.

  What it receives

  The recipient's address, the subject and the message.

• Telegram

  What for

  Notifications and announcement posts — only when a person or an organiser links Telegram.

  What it receives

  The message and the chat it goes to.

• AI model provider

  What for

  Drafts an event — only when an organiser uses the AI assistant. The provider is configurable; the assistant's page names the one in use.

  What it receives

  The organiser's description of the event, its language and time zone (to rewrite a section, also the draft and the organiser's instruction). No participant data.

• GitHub

  What for

  Checks when a submitted project's public repository was created and worked on.

  What it receives

  Only the repository's address.

We take no card payments: orders are paid by bank transfer against an invoice, so no card processor receives your data. Some of these providers process data outside Azerbaijan, for example in the European Union or the United States.

• The public status page shows whether the API, the database, background jobs and e-mail are working right now.
• Our backup script takes a full copy of the database, uploaded files included, and counts it done only after checking that the copy can be restored. A restore goes only into an empty database, so it can never write over live data.
• Database changes only add, so a release can be rolled back to the previous version straight away.
• During an incident a notice appears at the top of every page of the platform. To report an outage, write to info@hack-os.app.

Running an event for a bank, a telecom operator, a public body or a university? We sign a Data Processing Agreement or an NDA on request. Write to info@hack-os.app or use the contact form.

Service

HackOS

E-mail

info@hack-os.app

If you find a security problem, please write to info@hack-os.app with the steps to reproduce it. We will confirm that we received it and keep you informed while we fix it.

• Test only with your own account and events; do not open, change or delete other people's data.
• Do not run denial-of-service, spam or social-engineering tests.
• Give us reasonable time to fix the problem before you tell anyone else.

Our contact details for security researchers are also in security.txt.