Solva Systems › Security

How your business data is kept secure.

Built like somebody will try. Every software company tells you its product is secure and almost none of them tell you what they actually did, which makes the claim worth nothing. Here is what was done, in specifics you can hold us to, and who checks it before you rely on it.

Where your data is stored, and under whose law

On servers in Frankfurt, Germany, on hardware we rent and nobody else shares. Germany is inside the EU, and the UK and EU each recognise the other as adequate for data protection, so a UK company holding data there sits inside both UK GDPR and the EU regulation without a transfer mechanism being needed.

You are the controller of the data in your system and we are the processor, which is set out in the agreement rather than left to be assumed. If your work means data has to stay physically in the UK, which happens in healthcare and parts of the public sector, say so early: it changes the hosting arrangement rather than the system.

The database, the job-sheet photos and the local backups all sit on an encrypted volume. If the disk were pulled out of the rack, detached, or handed back to the data centre at the end of its life, what leaves the building is unreadable.

Encrypted twice where it matters

Some fields are worse to lose than others. Gate codes, key locations and access notes describe how to get into a customer's building, and a job management system full of them is a burglary shopping list.

Those fields are encrypted individually, on top of the encrypted disk, with AES-256-GCM. They are bound to the record they belong to, so a value cannot be lifted from one property and replayed against another, and the key is versioned so it can be rotated without a flag day. The practical result: they are still ciphertext inside a database dump. Somebody who walked off with a complete backup would have the shape of the business and not one gate code.

Getting in

The server itself

Most breaches are not clever. They are a forgotten port, a reused password, or a patch nobody applied.

The code

Database queries are parameterised, so a malicious value arrives as a value rather than as an instruction. Every request is validated against a schema before it reaches any logic, which closes off the trick of adding a field the form never showed you. Uploads are checked by reading the file's actual bytes rather than trusting its name, then held inside a confined path.

Every push runs static analysis, a secret scanner and a dependency audit, and dependency updates are raised automatically. That is the boring half of security, and it is the half that catches the thing nobody was thinking about.

We attacked it on purpose

A security review that only asks "did we build it correctly" will always answer yes. So the system was tested adversarially instead: sixteen tests that each try to do something they should not be allowed to do.

It found three things. All were low or informational, all were fixed, and the fixes were verified running in production rather than marked done in a document. One of them, an image endpoint that checked you were signed in but not that the job was yours, is exactly the class of bug that only ever surfaces when somebody goes looking for it.

Tested before you rely on it

That was one system. Every system is penetration tested before your company starts using it, and again whenever something significant changes. Critical and high findings are fixed and retested before go-live rather than logged and scheduled. It is a gate, not a milestone: the system does not go into use with them open.

We run those tests ourselves, and we would rather say so than let you assume otherwise. A team testing its own work shares its own blind spots and no amount of care removes that. So instead of claiming an independence we do not have, we are specific: you get the report for your own system, what was tested, what was found, what was fixed and what was accepted, in the same detail as the table above.

If you want a test we did not run, commission one. We will give the tester whatever they need, fix what they find, and treat the findings as useful rather than as something to argue with. A security page you cannot check is marketing, and the useful half of this one is that you can.

What you get to ask for

Your data is yours, exportable in a standard format whenever you want it, including on the way out. If your industry needs specific commitments about where data sits, how long it is kept, or who may see it, those go in the agreement rather than being left to assumption. Tell us early: it changes the hosting arrangement rather than the system.