Authentication done properly
Established libraries and protocols rather than hand-rolled sessions. Modern password hashing, secure cookie flags, and second factors where the data warrants it.
Security & data practices
What we actually do, stated plainly enough that you can check it. No badges we have not earned, and no claim to certifications a company of our size does not hold.
What we do not claim. HALDIR LTD does not currently hold ISO 27001, SOC 2 or any comparable certification, and we will not display a badge suggesting otherwise. If your procurement process requires certified suppliers, tell us early — it may rule us out, and that is a fair outcome.
What follows is a description of practices we can evidence during due diligence if you ask.
01 — Our own systems
How we run the company
- Access to client systems
- Named individual accounts, never shared logins. Access is granted per engagement, scoped to what the work requires, and revoked when the engagement or the person's involvement ends.
- Authentication
- Multi-factor authentication on every account that touches client work — source control, cloud consoles, email and the secret store. Hardware keys or authenticator apps; SMS is not used as a second factor.
- Credentials
- Held in a managed secret store, scoped per environment and rotatable without a code change. Nothing is committed to a repository, pasted into a ticket, or sent by email.
- Workstations
- Full-disk encryption, automatic screen lock, current operating system with automatic updates, and no client source code on removable media.
- Confidentiality
- Everyone working on your project is bound by written confidentiality obligations. We are happy to sign your NDA rather than insisting on ours.
- Third-party tooling
- Client source code and production data are not sent to external services — including AI assistants — without your written agreement. Where a client prohibits such tooling, we work without it.
- Offboarding
- When an engagement ends, we return or destroy client material at your choice, and confirm in writing which accesses were revoked and when.
02 — In what we build
Security decisions we make by default
These are not optional extras that appear in a "hardening phase". They are how the first version is written.
Least privilege
Roles defined narrowly, authorisation checked on the server for every request, and administrative capability separated from ordinary use.
Input treated as hostile
Schema validation at every boundary, parameterised queries without exception, and output encoding appropriate to its destination.
Secrets outside the code
Configuration and credentials injected at runtime from a secret store, distinct per environment, with production values never present on a developer machine.
Audit logging
Append-only records of who did what and when on anything sensitive — the thing nobody wants until an incident or an auditor makes it urgent.
Dependency hygiene
Lockfiles committed, advisories checked on a schedule, and an upgrade plan that runs continuously instead of arriving as an annual emergency.
03 — Client data
Personal data in development environments
The most common avoidable risk in software projects is a copy of the production database sitting on a laptop because it made testing easier.
Our default is that development and testing environments contain synthetic or pseudonymised data. Where working with real data is genuinely unavoidable, it happens inside your infrastructure, under a written data processing agreement, with the access logged and time-limited.
Where we process personal data on your behalf we act as a processor under Article 28 GDPR, and we engage a sub-processor only with your prior authorisation. Full detail is in our Privacy Policy.
This website, specifically
- Static files only — no database, no login, no server-side form handling
- No cookies, no analytics, no advertising or tracking pixels
- No third-party requests: fonts and every asset are served from this domain
- Served over HTTPS with HSTS and a strict Content Security Policy
- The contact form composes a message in your own mail client and posts nothing
The smallest attack surface we could give it. See the Cookie Policy for the single item stored in your browser.
04 — Disclosure
Reporting a vulnerability
If you believe you have found a security issue in this website or in a system we operate, please tell us before telling anyone else. We will not take legal action against anyone who reports a genuine issue in good faith, avoids accessing or modifying data belonging to others, and gives us a reasonable opportunity to fix it.
Write to [email protected] with the subject line SECURITY, and include enough detail to reproduce the issue.
- We acknowledge reports within two business days.
- We give an initial assessment, with a remediation plan, within ten business days.
- We will tell you when the issue is resolved, and credit you publicly if you would like that.
Please do not run automated scanning that degrades service for others, do not attempt denial of service, and do not access, alter or retain data that is not your own. If a report concerns a system we built for a client but do not operate, we will pass it to them and help them respond.
HALDIR LTD
Filippou, 11 Agios Dometios, 2363, Nicosia, Cyprus
Registration number: HE 459882
Security contact: [email protected]
Send us your security questionnaire
We answer them properly, and we mark "no" where the answer is no rather than reaching for a favourable interpretation.
HALDIR LTD · HE 459882 · Nicosia, Cyprus