Security statement
Running on one site
We run Watchdog on our own hardware, in our own server room in Denmark. Here is what we hold, how it is protected, and what happens when something breaks. The full statement, including the supplier list and the data processing agreement, is on Security & data handling.
Two kinds of claim on this page. Most of what follows is checked by a script that runs on the machine itself every time we deploy. It knows which published sentence it is protecting, and if that sentence stops being true, the deploy fails. Those are marked checked. The rest — where the hardware physically stands, who holds a key, that Stripe is our only supplier — is not something a machine on our network can verify, so we are simply telling you. Those are marked our word. We would rather show the difference than let one borrow credibility from the other.
One site, on purpose
Everything is in one building. That is why we can tell you there is no cloud provider, no CDN and no third-party AI anywhere near your code, and why your source is never written to one of our disks. It is also the obvious weakness, so the numbers are on this page rather than in a follow-up email.
Where we are weaker than we would like, we say so, and we say what would fix it.
Four machines, and what happens if one stops
| Machine | What it does | If it stops |
|---|---|---|
| Public edge (our word) | Handles encryption for everything you reach over the internet, and runs the AI model we use during a scan. It stores nothing of yours. | You cannot reach us. Nothing is lost and nothing has to be restored. |
| App and scanning (checked) | Runs the application, the database, the report files and the scanner. Your reports, findings, scores and account details are here. Your source code is not — it only exists in memory, while a scan is running. | The service is down until we restore the database from the previous night's backup. |
| Key holder (checked) | Holds the key that unlocks stored credentials — payment keys, tokens for your code host. It is deliberately not the server and not the backup drive. | The application refuses to start until it can reach this machine. We would rather it stopped than ran without being able to read its own credentials. |
| Backup drive (checked) | Every night it takes a copy of every database, our configuration and the wrapped credential key, and keeps the last seven. It also runs our email, so there is no email provider in the picture either. | We still have the copies on the main machine, so we would lose no more data than usual. |
Where they are (our word). All four are ours, and they sit in our server room at Vestervej 26, 8500 Grenaa. Two people have physical access and nobody else. Nothing of ours runs in a cloud, and there is no CDN in front of any of it.
What we get from owning the hardware
- No AI provider sees your code (checked). The model behind the AI parts of a scan runs on our own machine. Nothing goes to OpenAI, Anthropic, Google or anyone else, and we do not train on your code.
- Your code is never written to a disk (checked). A scan copies your repository into memory, works there, and deletes it when it finishes — including when it fails. A reboot clears it either way. The one exception is a zip you upload, because we cannot fetch that again: we keep it for up to seven days.
- The scanner cannot browse the internet (checked). It runs stripped of privileges and can only reach a fixed list of package registries and vulnerability databases, and only when your build needs them — the same downloads your own CI does to restore your dependencies. Everything else is blocked, and blocked attempts are logged.
- One supplier, and only if you pay us (our word). Stripe handles payments from Ireland, and card details never reach our servers. No analytics, no error tracking, no CDN, no hosted fonts — our website loads nothing from anyone else. Login, email, the database, report storage and the AI model are all ours.
What is encrypted, and what encryption does not cover
Checked. The database files and the report files share one encrypted disk — LUKS2 with AES-256 — on its own drive. It unlocks at boot from a key file, and the spare key is kept off the machine. Our deploy refuses to run if that disk turns out not to be the encrypted one.
What that does not cover. Encryption protects a disk that gets pulled out, stolen, returned under warranty or thrown away. It does not protect against someone taking the whole machine, or getting root on it while it is running, because the key that unlocks it sits on the same machine. That is the price of a server that comes back on its own after a power cut. The stronger point is the one above: your source code is not on a disk at all.
Credentials are handled separately (checked). They are encrypted with a key kept on a third machine — not the server, not the backup drive — so a stolen disk, or a stolen copy of a backup, is unreadable without it.
How much we would lose, and how long we would take
| Question | Answer | Why |
|---|---|---|
| How much data could we lose? | Up to a day | We take two backups a night, an hour apart: one on the machine, one copied off it. Both are checked as they are written, and the job fails loudly rather than leaving a half-finished file that looks fine. Either one on its own is enough. We do not run a live copy of the database, so we cannot rewind to a particular moment between backups. |
| How fast is the application back? | Minutes | The application keeps nothing locally. We switch to the standby copy or redeploy it. Nothing has to be restored. |
| How long to restore the database? | About an hour | If the machine itself is fine. The backups are plain SQL files and go back one database at a time. The hour is the restore running, not us deciding what to do. |
| What if we lose the machine? | Days | The data is already on a second machine and rebuilding the server is scripted. Getting hold of replacement hardware is the slow part. |
| What if we lose the building? | Not covered yet | Both machines are in the same room, so a fire or a break-in would take both. We are fixing that with a copy kept somewhere else, and it is the next thing on our list. We would rather tell you than have you find it. |
Why we have not built more than this
It is a money decision and we made it on purpose. A server like ours costs around 200,000 kroner. We buy the next one when a customer's contract pays for it, rather than charging everyone for spare capacity nobody has asked for.
What makes that workable is the kind of product this is. A scan is a scheduled review — you choose quarterly, monthly, fortnightly, weekly or daily — and nothing in your build, your release or your production depends on us. If we are down, your scan is late. On a fortnightly schedule an hour does not show up. Nor does a day. A whole week means one scan arrives later than planned; nothing is lost, and the next one still covers every commit in between.
If you scan daily, or a scan has to pass before you can ship, tell us early. That changes the answer, and it is exactly what would move the second site up our list.
Your reports do not depend on us staying up. Every survey gives you a signed package tied to one commit and one version of the rubric. You can check it with the published key and the open rubric at codeassuranceindex.info/verify — no account, and nothing of ours needs to be running. Anything published to the Code Assurance Index stays published: the standard has no withdrawal and no replacement, so a restore on our side cannot remove one. And if you would rather we were not in the picture at all, we can run inside your own network, where the code never leaves and only the results come back.
What we will add, and what makes us add it
| What | What it changes | What makes us do it |
|---|---|---|
| A copy of the backup kept elsewhere | The same encrypted backup, at a second address. Fixes the last row of the table above, and does not need another server. | Next — during Q4 2026 |
| A second site | Properly hosted near Aarhus, running a standby of the application and the database. | Our first enterprise contract paying for it, or a customer asking for it |
| Automatic failover | A live copy of the database and an automatic switch, turning days into hours. | A contract requiring a recovery time we cannot hit from cold |
| ISO 27001 or SOC 2 | We hold neither today and will not imply otherwise. Until we do, you get this page, our supplier list and a data processing agreement we will sign. | On the list. No date promised |
How to check any of this
The claims marked checked are verified on the machine itself on every deploy — encryption at rest, keeping your code in memory only, how long we hold an upload, the self-hosted AI model, the locked-down scanner and the nightly backup. If one of those sentences stops being true, our deploy fails rather than the page quietly going stale.
The claims marked our word are the ones no machine can settle: where the hardware is, who has physical access, and that Stripe is our only supplier. Those are ours to stand behind, which is why they are labelled differently rather than mixed in.
Everything on this page was read off the live system on 6 September 2026. Canine Development, CVR 42092134, Vestervej 26, 8500 Grenaa. If your review needs something this page does not answer, ask us — a person answers, usually the same day.