How we keep data safe, and how we check.

Short answers

Do you encrypt data in transit and at rest?

In transit: always. All traffic to our sites and servers uses HTTPS (TLS 1.2 or 1.3), and browsers are told to never connect without it (HSTS). We log in to servers with cryptographic keys only; password login is disabled.

At rest: our email (Proton), CRM (Attio) and email delivery service (Brevo) encrypt stored data. On our own server, data is protected by key-only access, a firewall and per-application permissions, and nightly backups are encrypted and kept on a separate server.

Do you run vulnerability scans?

Yes, at two levels. Automatically, on every code change: tests, a build and a scan of the entire code history for accidentally committed passwords and keys. A change that fails doesn't reach production. Periodically, by hand: the 13-layer audit below, before any new system goes live, after major changes and at least once a year.

When was your last penetration test?

The first full cycle (audit, penetration test, fixes, re-audit) of our own systems runs in October 2026. We'll publish the date and a summary here when it's done.

We run the test ourselves, with automated testing tools. It is not an independent test by an outside firm. If your business or a tender requires one, we work with the firm you choose and give them everything they need.

Do you have an incident response plan?

Yes, a written one. In short, when something goes wrong we:

1. Stop the damage: cut access, rotate keys and passwords.
2. Tell you within 24 hours of finding out, if your data is involved, including what we know and what we don't know yet.
3. Report to the authority (Croatia's AZOP) within the legal 72 hours where we are the controller, and give you everything you need for your own report where you are.
4. Fix the cause and check that the fix holds.
5. Send a written report: what happened, why, and what we changed so it doesn't happen again.

Where is data stored?

• Systems we build for you normally run on your side: your computers, your software or your server. That's where the data stays.
• Our server is with Hostinger, in a data centre in Frankfurt, Germany (EU).
• Outside services we use, and where they are, are listed on our Privacy page. Some are in the US; transfers to them rely on the EU–US Data Privacy Framework and standard contractual clauses.

When a system we build processes your customers' personal data on our side, we sign a data processing agreement before work starts, based on the European Commission's official clauses.

How we check: audit, test, re-audit

Every system that runs on a server or is reachable from the internet, ours and the ones we build for you, goes through the same process:

1. Inventory. Everything that exists: addresses, servers, databases, outside services, and which personal data sits where. What isn't listed can't be checked.
2. 13-layer audit. Each layer is scored 0 to 3, with evidence. No evidence means a score of 0.
3. Fixes for everything serious, before the next step.
4. Penetration test. We attack exactly what the audit says is safe, so it's proven rather than assumed.
5. Fixes and a re-audit. The same 13 layers, with scores before and after.

The result is two documents: the audit scorecard and thepenetration test report. For systems we build for you, you get both at handover.

The 13 layers

1. Code correctness — logic bugs, silent failures, tests
2. Authentication — passwords, sessions, two-factor login, brute-force protection
3. Authorization — who may see and change what; nobody sees another customer's data
4. Input handling — checking everything that comes in: forms, files, webhooks
5. Database — structure, constraints, transactions, exposure to the internet
6. Secrets & configuration — keys and passwords never in code, logs or the browser
7. Dependencies — known vulnerabilities in the packages and images we use
8. Hosting & network — patches, firewall, key-only access, TLS, security headers
9. Deployment — only reviewed code that passed its checks reaches production
10. Monitoring & alerting — an outage is noticed by something outside, not by luck
11. Backup & recovery — backups exist and a restore has actually been done
12. Load & cost — rate limits, data growth, spending on outside services
13. Privacy & incidents — list of processors, data deletion, incident plan

Report a security issue

If you think you've found a vulnerability, or suspect an incident in our systems or in a system we built, write to hello@kyuro.tech with the subject "SIGURNOST". If it's urgent, also call +385 97 6124852.

Tell us what you saw, where, and how to reproduce it. We commit to:

• confirm we received it by the next working day,
• keep you posted until it's resolved,
• take no legal action against anyone who reports in good faith, accesses no more data than needed to show the problem, and doesn't publish it before we've fixed it.

Please don't run load tests, and don't access or change other people's data. The same contact is in our security.txt.