Security and data
Fewer moving parts means fewer ways in.
This page is written for the person who has to sign it off, not for other engineers. No acronyms you have to look up, and no claims we cannot stand behind.
Why this matters
Most break-ins are not clever. They are opportunistic.
The picture people have of a security incident involves somebody targeting their company specifically. That is rare. What actually happens is far more ordinary, and far more preventable.
A typical off-the-shelf website runs dozens of add-ons, each written by a different person, many of them no longer maintained. Millions of other sites run the same ones. When a weakness turns up in a popular add-on, automated tools go looking for every site using it, within hours. Nobody chose you. You were simply on the list.
The fix is not a more expensive security product. It is having less to attack in the first place, and knowing exactly what you are running.
The usual setup
- Dozens of add-ons from many authors
- The same code as millions of other sites
- Updates arrive when a volunteer gets to them
- Nobody can list what is actually installed
How we build
- A short, reviewed list of outside parts
- Your business logic written by us, for you
- We patch on a schedule we control
- A written record of every component
An honest note about open source
Some agencies will tell you open source is the danger. That is not true, and any technical person on your team will know it is not true. The language we build in, the database that stores your records and the servers everything runs on are all open source, and they are safer for it, because thousands of engineers examine them constantly.
The real risk is different. It is depending on a long chain of small, unmaintained add-ons that nobody at your company can name, and having no control over when they get fixed. That is what we avoid, and it is a very different thing from avoiding open source.
Our practice
What we actually do on every build.
Your data lives where you choose
On your own servers, in your own cloud account, or in ours. You decide at the start and you can move it later. We will tell you the cost and trade-offs of each option honestly.
People see only what their job needs
Access is set by role. A warehouse user does not see payroll. Every change to a record leaves a trace showing who did it and when, which matters when something goes wrong.
Backups get tested
A backup nobody has ever restored is a guess. We restore from backup on a schedule and confirm the result, so you know it works before the day you need it.
Everything travels encrypted
Traffic between your users and the system is encrypted as standard, and sensitive fields are encrypted where they are stored. Passwords are never stored in a readable form.
Nothing ships unreviewed
Another engineer reads every change before it goes live. Automated checks run on each release. It is a simple habit and it catches a great deal.
We keep a list of what you run
A written record of every outside component in your system and what it is for. When a warning is published, we can answer within the hour whether it affects you.
Ownership
What belongs to you, in writing.
This is the part people forget to check until they want to leave a supplier. Ours is simple.
You own
- All source code written for your project
- Your database and everything in it
- The designs and documentation
- Your domains, accounts and hosting
- Every conversation NyViA has on your behalf
We will never
- Sell or share your data with anyone
- Use your data to build something for a competitor
- Charge you to take your own information out
- Hold code back as leverage in a disagreement
- Publish your name or your work without permission
On South African law. Systems we build for South African clients are designed to support your obligations under POPIA, including consent records, access controls, retention rules and the ability to find and remove an individual’s data on request. Meeting POPIA is a duty that sits with your business, and we build software that makes it straightforward rather than something you fight.
Use this on us too
Seven questions worth asking any software supplier.
Including us. If a supplier cannot answer these clearly and in writing, that tells you something useful before you sign anything.
The only good answer is you, in writing, with the code in a repository you control while the work is happening rather than handed over at the end. Ours is in your repository from week one.
Ask about exit fees, data export and how long a handover takes. If leaving is expensive or slow, that is by design, and you should know it before you commit. With us there is no exit fee and your data exports in a standard format.
If nobody can produce that list, nobody can tell you whether the security warning in the news affects you. We keep the list, it is short on purpose, and you get a copy.
Most suppliers take backups. Far fewer test them. The date of the last successful restore is the number that matters, and it should be recent.
You want a short list of named people, access granted only when needed, and a record of who looked at what. Blanket standing access for a whole development team is common and it should not be.
An uncomfortable question and a fair one. Because you hold the code, the documentation and the hosting accounts, another competent team can pick your system up. That is the real protection, not a promise.
Anything a supplier will not write down is not a commitment. Ownership, exit terms, confidentiality and response times all belong in the agreement. Ours are.
Next step
Send this page to whoever has to approve it.
If your IT team, your auditor or your board has questions we have not covered here, ask them. We will answer in writing and we will not hide behind jargon.
- NDA
- Signed on request
- Written answers
- Always
- Data export
- Any time, no charge
- POPIA
- Built to support it