The expensive security problems are the ones designed in by accident.
You rarely notice them at the time. A login flow that trusts an ID the browser sent. A field that gets written straight into a query. A library that was current when you shipped and three years out of date by the time someone comes probing. None of these looked like security decisions when they were made.
That is the trouble with treating security as a phase at the end. By then the decisions are already in the code, and a hardening pass can only paper over them. It is far cheaper to make the safe choice while the thing is still being designed than to unpick it once real customer data depends on the shape you got wrong.
In business operations software
Data moves between systems - a quoting tool, a finance package, a survey app - and every hop is somewhere personal data can leak or a request can be forged. The duty is UK GDPR, and the risk usually lives in the joins between systems that nobody quite owns.
In SaaS platform development
You hold a lot of people's data in one place, and a single slip in authorisation can show one customer another customer's records. Isolation between tenants and an access check on every request are most of the job.
01Authentication and access control
Proper authentication, with multi-factor where it matters, and authorisation checked on every request rather than assumed once someone has logged in. Access follows least privilege, so each part of the system can reach only the data its job needs.
02Encryption, in transit and at rest
TLS on everything that moves, and encryption at rest through AWS Key Management Service, so the data stays unreadable even to someone who reaches the storage underneath it.
03Input validation and the common web risks
We validate anything a client sends and build against the vulnerabilities that actually get exploited - injection, cross-site scripting, broken authentication and access control - following NCSC and OWASP guidance rather than guesswork.
04Data protection and UK GDPR
Data protection by design and by default, built in from the start: storing personal data properly, answering subject access and deletion requests without a scramble, and backups that account for both.
05Reviews of software you already run
If you want an honest second opinion on an application you already have, we audit PHP and JavaScript codebases and write up what we find with practical fixes, in priority order. We can carry out the remediation too, and keep things patched afterwards.
Built to be trusted with real data.
The stack is usually Node.js or PHP on AWS, with Cognito handling identity and the platform's own controls doing the heavy lifting. We are an AWS Select Tier Services Partner and we run a Well-Architected review on every engagement, its security pillar included, which is how a problem gets found on a whiteboard rather than in an incident.
Serverless API integration
Secure24
A serverless API carrying gym door-entry data to an AI monitoring platform. Only authorised devices get through, and tokens are handled carefully.
Spacesuit Media
Multi-factor authentication and tighter user management on the Collections image platform, with an AWS migration for more resilient footing.
Duwio
Every customer's images sit in an isolated workspace, with role-based permissions, cross-region backup and audit logging through CloudTrail.
Si Novi have been amazing. We were blown away by their responsiveness and the quality of their work. The journey is just beginning and we couldn't have found a better partner to help us on our way.
We work out what needs protecting before we decide how to protect it.
- 01
Design it in
We look at what data the system actually needs, where it will live and who should ever touch it, and we design for least privilege from the outset. Most security comes down to decisions made here, long before anyone writes an authentication check.
- 02
Build it securely
Authentication, authorisation checked on every request, validation of anything a client sends, and encryption in transit and at rest. Where identity is involved we use AWS Cognito rather than rolling our own, because a bespoke login layer is a liability you maintain forever.
- 03
Keep it current
A dependency that was safe at launch becomes a way in as vulnerabilities are found and patched. Someone has to keep libraries current, watch the logs and act when something looks wrong. In most of our engagements that is still us, years later.
The things buyers ask us first.
Are you ISO 27001 or Cyber Essentials certified?
No, and we would rather tell you that plainly than imply otherwise. What we do have is AWS Select Tier Services Partner status and a Well-Architected review on every engagement, its security pillar included, and we build to NCSC and OWASP guidance.
Can you review the security of software we already run?
Yes. We audit PHP and JavaScript applications, report what we find with practical fixes in priority order, and can carry out the remediation and keep things patched afterwards.
Who can see your data?
As few people and systems as possible. We work to least privilege, so we and the software itself touch only the data a task needs, and it is encrypted in transit and at rest. It is your business's data, held in your own AWS account, and we are registered with the ICO and treat it under the same duties as our own.
Will building security in slow us down?
Less than fixing it later will. Designing the safe choice in while the system is still on the whiteboard costs a fraction of unpicking an unsafe one after launch, and it means the answer to a security question is usually already in the code rather than sitting on a backlog.