If you are about to commission custom software and someone asks “is it secure?”, the honest answer depends on how it will be built, hosted and maintained, not on whether it is custom. Custom software security comes from a short list of practices that any competent supplier should be able to explain and show you.
This guide is for UK and US decision-makers who need confidence that new software will not add risk to the business. It covers what to expect, what to ask and where the real trade-offs are.
What does secure actually mean?
In short: only the right people see the data, nobody can quietly change it, and the system can be recovered.
For business software, security means three things in practice. Confidentiality: customers, staff and suppliers only see what they should. Integrity: records cannot be altered without permission and without a trace. Availability: the system stays up, and if something goes wrong, it can be restored quickly with little data lost.
No software is perfectly secure. The aim is to make attacks hard, limit the damage if one succeeds, and notice quickly when something is wrong.
Secure software development practices
In short: security has to be part of how software is built, not a check at the end.
The clearest public reference is the US National Institute of Standards and Technology’s Secure Software Development Framework (SSDF), SP 800-218. It is written for software producers of any size, including custom software developers, and NIST notes that buyers can use it as a common vocabulary when talking to suppliers. Version 1.1 is the final edition; NIST published a draft version 1.2 in December 2025. Its practices fall into four groups:
The four practice groups of the NIST SSDF
- Prepare the organisationPeople, processes and tools ready for secure development: roles, training, secure build environments
- Protect the softwareAll code and components protected from tampering and unauthorised access
- Produce well-secured softwareSecure design, code review, testing and safe default settings
- Respond to vulnerabilitiesFind, fix and learn from weaknesses after release
In business terms: are the engineers trained, is the code protected, is every change reviewed and tested, and is there a plan for when a weakness is found after launch?
The common risks: OWASP Top 10
In short: most web application attacks exploit a well-known, published list of weaknesses.
The OWASP Foundation describes its Top 10 as “a standard awareness document for developers and web application security”. The current edition is the OWASP Top 10:2025. Here it is in plain English:
| OWASP 2025 risk | What it means for your business | What good looks like |
|---|---|---|
| A01 Broken Access Control | A user sees or changes data they should not, such as another customer’s invoices | Permissions checked on the server for every request |
| A02 Security Misconfiguration | Default passwords, open storage, debug pages left on | Hardened, documented settings for every environment |
| A03 Software Supply Chain Failures | A third-party package or build tool is compromised or outdated | Trusted sources, pinned versions, automated update alerts |
| A04 Cryptographic Failures | Sensitive data is readable in transit or in storage | Encryption everywhere, with current algorithms |
| A05 Injection | Malicious input tricks the system into running commands or queries | All input validated; database queries parameterised |
| A06 Insecure Design | The weakness is in the design, so perfect code cannot fix it | Threats considered when features are designed |
| A07 Authentication Failures | Weak logins, guessable passwords, sessions that never expire | MFA, rate limits, sensible session timeouts |
| A08 Software or Data Integrity Failures | Code, updates or data are trusted without being checked | Signed, verified releases and controlled deployments |
| A09 Security Logging and Alerting Failures | An attack happens and nobody notices | Security events logged and alerts sent to a person |
| A10 Mishandling of Exceptional Conditions | Errors leak information or leave the system in an unsafe state | Errors handled safely, failing closed rather than open |
Ask any supplier how their process addresses these. A specific answer for each is a good sign.
Logins, MFA and access control
In short: strong logins, least privilege, and permissions enforced on the server.
Multi-factor authentication (a code or app prompt as well as a password) should be required for administrators at minimum, and offered or required for everyone else depending on the data. Where your team already uses Microsoft or Google accounts, single sign-on lets you switch off a leaver’s access in one place.
Each role should see only what it needs. Crucially, permissions must be checked on the server, not just hidden in the interface; broken access control is the first risk in the OWASP list for a reason.
Encryption in transit and at rest
In short: encrypt data on the move and in storage, including backups.
All traffic should use HTTPS. Databases, file storage and backups should be encrypted at rest, which major cloud platforms support as standard. The ICO’s guide to data security recommends encryption if you store personal data or transmit it over the internet. Particularly sensitive fields, such as identity documents or bank details, may justify extra encryption inside the database.
Secrets management
In short: passwords and API keys never belong in the code.
Every system holds secrets: database passwords, payment provider keys, e-mail service tokens. They should live in a dedicated secrets store, separate for test and live environments, with access limited to the services that need them. They should never be written into the code or shared in chat messages, and they should be rotated when someone with access leaves.
Dependencies and supply-chain updates
In short: most of your application is other people’s code, so keeping it updated is part of security.
Modern applications are built on open-source packages, which is efficient but means a weakness in a popular package becomes a weakness in your system. OWASP now ranks software supply chain failures third. Automated alerts should flag vulnerable packages, versions should be pinned, and updates should be applied on a regular schedule, faster for critical issues. The FTC’s Start with Security guidance tells businesses to update and patch third-party software.
The same applies to integrations with other systems: each connection needs its own limited credentials and should fail safely if the other side misbehaves.
Logging and monitoring
In short: record who did what, and alert a person when something looks wrong.
An audit log of sign-ins, permission changes, exports and deletions lets you answer “who did this?” after the fact. Monitoring and alerts let you notice repeated failed logins, unusual exports or errors before customers do. Logs should not contain passwords or more personal data than necessary, and someone must be named to receive the alerts.
Backups and recovery
In short: an untested backup is a hope, not a plan.
Agree two numbers in business terms: how much data you could afford to lose (an hour, a day) and how long you could afford to be down. Backups should be automatic, encrypted, stored separately from the live system and restored in a test at least periodically. Under UK GDPR, the ICO says you must be able to restore the availability of and access to personal data in a timely manner after a physical or technical incident.
Hosting and data location
In short: host in your own cloud account, in the region your customers and contracts require.
The cloud account should be in your company’s name, with the developer given access you can revoke. Choose a hosting region that matches your obligations; major cloud providers offer UK and US regions. Keep test and live environments separate, and avoid copying real personal data into test systems.
Location also covers people. The ICO’s guidance on international transfers treats making personal data accessible to a separate organisation outside the UK as a restricted transfer. If your supplier’s engineers or support staff work outside the UK, as some of DataVolve’s do, their access to live personal data needs a valid transfer mechanism, or should be avoided where possible. Our software development outsourcing guide covers the contract terms that go with this.
Penetration testing
In short: automated checks on every change, and an independent test where the stakes justify it.
Security testing works in layers: code review and automated scanning on every change, then, for internet-facing systems that hold sensitive data, an independent penetration test before launch and after major changes. A penetration tester tries to break in the way an attacker would and reports what they found. The ICO lists vulnerability scanning and penetration testing among the ways to regularly test whether your security measures work. Ask who fixes the findings, and when.
Data protection law in the UK and US
In short: the law asks for appropriate security, and you stay responsible when a supplier builds for you.
UK. UK GDPR requires personal data to be processed with appropriate security, using appropriate technical and organisational measures. The ICO’s guidance explains that this includes regularly testing those measures, and that when you use a processor you must choose one that gives sufficient guarantees about its security and put security requirements in the contract.
US. There is no single federal law equivalent to UK GDPR; sector and state rules may apply depending on your data. The FTC’s Start with Security guide sets out practical expectations for businesses, including strong authentication, encrypting sensitive data in storage and transmission, training engineers in secure coding and testing for common vulnerabilities, and putting security standards for service providers in writing and verifying them.
This is general information, not legal advice. If your software handles health, financial or children’s data, take specialist advice early.
Cyber Essentials as a supplier baseline
In short: a useful UK check on a supplier’s own IT, not a test of the software they build.
The NCSC describes Cyber Essentials as the minimum standard of cyber security recommended by the Government for organisations of all sizes. It covers five controls: firewalls, secure configuration, security update management, user access control and malware protection. Cyber Essentials Plus adds independent technical testing of those controls.
Because it covers how a supplier runs its own laptops, accounts and networks, it reduces the chance that your project is compromised through them. It does not assess the application they deliver. Ask suppliers whether they are certified; if not, ask how they meet each of the five controls.
Custom vs off-the-shelf security
In short: neither is automatically safer; maintenance decides.
Large vendors have dedicated security teams, patch quickly and are often independently audited. But they are attractive targets, your data sits alongside many other customers’, and you cannot change how access, logging or data location work.
You control hosting, data location, access and logging, and the system exposes only the features you need, so the attack surface is smaller. The catch: that is only true while someone keeps it patched and monitored. Unmaintained custom software becomes a liability.
If security is part of your build-or-buy decision, our comparison of custom software vs off-the-shelf software covers the wider trade-offs.
What to ask a vendor about security
In short: ask for specific answers, in writing.
- How does your process cover secure design, code review and testing? Which OWASP Top 10 risks do you test for, and how?
- Will the code, cloud hosting and data sit in accounts we own?
- Will your engineers access live personal data? From which countries?
- How are passwords, API keys and other secrets stored?
- How do you track and update vulnerable dependencies after launch?
- What is logged, who receives alerts, and how quickly do you respond?
- How are backups taken, and when was a restore last tested?
- Do you recommend an independent penetration test, and who fixes the findings?
- Do you hold Cyber Essentials? If not, how do you meet its five controls?
- Who does what if there is a security incident?
For the wider supplier evaluation beyond security, see how to choose a software development company.
Custom software security checklist
In short: check these before launch, and keep checking them after.
| Area | Before launch | After launch |
|---|---|---|
| Ownership | Code, cloud and domain in your company’s name | Review who has access every quarter |
| Development | Peer review and automated tests on every change | Same process for every fix and feature |
| Logins | MFA for admins; roles and server-side permissions | Remove leavers promptly |
| Encryption | HTTPS everywhere; data and backups encrypted at rest | Keep certificates and settings current |
| Secrets | In a secrets store, separate per environment | Rotate when people with access leave |
| Dependencies | Known vulnerabilities fixed before go-live | Automated alerts; regular update schedule |
| Logging | Audit log and alerts configured | A named person reviews alerts |
| Backups | Automatic, encrypted, stored separately; restore tested | Restore tested periodically |
| Data location | Hosting region chosen; transfer mechanism if needed | Re-check when suppliers or staff change |
| Testing | Scanning; penetration test where justified | Re-test after major changes |
Budget for the right-hand column. Maintenance, including security updates, typically costs 15–25% of the build per year, and it is what keeps custom software secure.
At DataVolve, clients own the code, cloud accounts and domain from the first commit, so you control access and can revoke ours at any time. We build on React, Node.js, Python and AWS and show working software every week, so security decisions are visible as they are made. Learn more about our custom software development service, read how we work in the custom software development process, or, if you are in the US, see our US software development service. Then tell us what you are planning; you will get a written scoped plan within 24 hours, and you can put us through every question above.