Security and compliance
What we commit to doing with your data.
Writing software for a company means holding its data, its access and the continuity of its work. This page says what we do to deserve that, in terms you can check rather than terms meant to reassure.
Warranty
Twelve months of support, in the price.
Every project we deliver is covered for twelve months from go-live, at no extra cost and with no separate contract to sign. That is the period in which software is genuinely used, and in which the things no test run finds come out: the month-end edge case, the supplier who sends the file in a different format, the printer nobody mentioned during analysis.
We say it here because it is a commitment rather than a sales line: the cover is written into the contract alongside the scope, with the same response times you will find in the table further down.
What it covers
- Fixing defects in the software we wrote, with no cap on the number.
- Security updates to libraries and dependencies, including vulnerabilities published after delivery.
- Runtime updates needed to keep the system on supported versions.
- Restoring from backup in the event of data loss or corruption.
- Helping the people who use it with how the delivered system works.
- Adjustments made necessary by changes to the interfaces of services we integrated during the project.
What it does not cover
- New features and changes of scope: quoted separately and approved before anything is built.
- Faults caused by changes other people make to the code or the infrastructure without agreeing them.
- Third-party service costs — hosting, licences, platform fees — which stay with you and are stated at the estimate stage.
- Third-party software we did not write, unless a dedicated support contract covers it.
At the end of the twelve months the relationship can continue on an operating retainer, or stop. Either way the software stays yours and stays working.
Data protection
GDPR: roles, paperwork and limits, before we start.
When we build or maintain a system that processes personal data belonging to your customers or your staff, you are the data controller and we are the processor. That is not a formality: it decides who determines what, who answers for what, and which documents have to exist before the project starts.
We draft the art. 28 processing agreement and sign it with the contract, together with the list of sub-processors we touch on your behalf — the cloud provider, the mail service, the payment platform — and an undertaking to tell you before any of that changes.
Processor agreement, art. 28
A data processing agreement signed before work begins, setting out purposes, categories of data, duration and documented instructions. Part of the project, not an extra on request.
Minimisation and purpose
During analysis we decide which data the system genuinely has to hold, and drop the rest. A field collected just in case is a risk with nothing on the other side of it.
Records, notices and consent
We give you what you need for your record of processing activities, and build notices, lawful bases and consent capture into the software rather than bolting a banner on top.
An impact assessment where one is due
If the processing falls into the high-risk categories — health data, systematic monitoring, profiling — the DPIA happens at design time, while changing the approach is still cheap.
Data subject rights, implemented
Access, rectification, erasure, portability and restriction do not stay on paper: the software has to be able to carry them out, and the statutory deadlines are short.
Breaches: 72 hours
An agreed notification procedure: we tell you without undue delay and in time for you to meet your own 72-hour deadline to the supervisory authority.
How we write the code
Security is designed in, not added at the end.
Most security problems in a business system do not come from a sophisticated attack: they come from a permission nobody checked, a library three years out of date, or a password that ended up inside the source code. Those are avoidable while building, and cost ten times as much to fix on a live installation.
Code review
No change reaches production without being read by somebody who did not write it, and without passing the automated checks.
The ten things that go wrong
We build against the OWASP list: injection, missing authorisation checks, weak sessions, configuration left as the installer found it. Checked before release, not after a report.
Dependencies under watch
The libraries we use are checked automatically against known vulnerabilities on every build, and updated when one affects us. During the twelve-month warranty, at our cost.
No secrets in the code
Keys, passwords and tokens live in a secrets store, separated per environment, and get rotated. The repository holds none, and that is verified on every change.
Separate environments
Development, staging and production are distinct installations with distinct credentials. Real data does not end up in staging: where realistic data is needed for testing, it is anonymised first.
Releases that repeat and reverse
Every version is tracked, rebuildable and revertible. If a release introduces a problem we roll back in minutes, rather than fixing it live by hand.
Once it is live
Who watches the line, and what happens when it breaks.
A production system needs somebody who notices before the customer does. Monitoring, backups and the restore procedure are part of the delivery, not of a later contract.
Monitoring and alerting
Availability, application errors, stalled queues and integrations that stop answering: watched automatically, with an alert that reaches us before it reaches you.
Backups, and restore drills
Daily copies, held in a different region from the installation, encrypted. And tested: at least once a year a full restore is genuinely performed on a separate environment.
A stated worst case
The contract states how much work can be lost in the worst case and how long the system takes to come back. Figures, not adjectives: agreed up front, with the infrastructure sized to match.
Named access, revoked on exit
Anyone touching your systems does so under their own account with a second factor. Access is the minimum needed, it is logged, and it closes when the work ends.
Encrypted in transit and at rest
TLS on all traffic, certificates renewed automatically, data and backups encrypted on disk. User passwords are stored with modern derivation functions — never in the clear, never reversible.
Incidents follow a procedure
Containment, restoration, root cause analysis and a written account of what happened and what changes so it does not happen again. Including when the cause was us.
Independence
Built so that you can also let us go.
The usual way of getting stuck with a supplier is not a punitive contract: it is not having the code, not having the documentation, and not knowing where the data is. That kind of hold does not interest us. If a client stays, it should be because the work is good.
You own the source
The code we write for you is yours, from day one and by contract, on your repository or handed over on request with the full history of changes.
Infrastructure in your name
Where it makes sense, cloud, domain and services sit on contracts in your name with us as delegated administrators. If the relationship ends there is nothing to migrate: you remove our access.
Documentation, handed over
Architecture, data model, release and restore procedures. Written for an engineer who was not there, because sooner or later one turns up.
An orderly exit
A complete data export in open formats and an assisted handover to whoever comes after us. It is a clause in the contract, not a courtesy.
Confidentiality
A non-disclosure agreement signed before the analysis, if you are coming to us with something you would rather not half-explain. It holds for conversations that never become a project too.
Nobody is indispensable
What is known about a project lives in the documentation and the code, not in one person's head. That goes for your team and for ours.
Service levels
How long we take to respond.
These are the response times we write into contracts, during the twelve-month warranty and on operating retainers. They are times by which somebody starts work, not promises of resolution: how long a fix takes depends on what happened, and saying otherwise in advance would be a lie.
| Severity | Response | How it proceeds |
|---|---|---|
| Blocking — the system is down, or data is at risk | Within 4 working hours | We work it without interruption until service is restored, with an update every four hours. |
| Major — a central function is broken, work continues with difficulty | Within 1 working day | An immediate workaround where one exists, a fix in the next release, a daily update. |
| Standard — a contained defect, or a minor request | Within 3 working days | Scheduled into the next suitable release, with the date given when we take it on. |
| New work — something that does not exist yet | Quoted within 5 working days | A written estimate with impact and timing. Built after your approval, never before. |
Service hours: Monday to Friday, 09:00–18:00 CET, public holidays excluded. Extended cover and out-of-hours standby are agreed on the operating retainer, for when your work does not stop in the evening.
The above are the practices we work by and the commitments we accept into a contract: they are not certifications issued by a third party, and we do not present them as such. If your sector requires a formal certification — ISO 27001, a national cybersecurity qualification, a tender requirement — say so during analysis: it gets addressed at the start, together with whoever issues it.
Get started
Is there something in your processes worth automating?
Describe the situation in a few lines. We come back with an assessment of feasibility, timing and the order of magnitude of the cost.