Business owners commissioning custom software usually focus on features, timelines and cost. Security tends to be assumed: "the developers will handle it". Most good developers do — but security involves decisions the business must make too: who can see what, how much data to collect, who has administrator access, what happens if a laptop is stolen. This guide explains the basics in plain language, so you can ask the right questions.
Authentication: proving who users are
- Strong passwords — minimum length, checks against common passwords, secure storage (never stored in plain text).
- Two-factor authentication — especially for administrators and users with access to sensitive data.
- Single sign-on where your business already uses a central identity provider and it's practical.
- Account lockout or throttling after repeated failed logins.
- Session expiry after inactivity.
- Prompt removal of access when people leave.
Authorisation: controlling what users can do
Define roles and permissions carefully. A technician may see only their jobs; a branch manager only their branch; finance may see prices that others can't; only a few people can export data or change settings. Permissions should be enforced on the server, not just hidden in the user interface. Review who has administrator rights regularly — it's often more people than necessary.
Encryption
- In transit — all traffic over HTTPS, with modern settings.
- At rest — database and file storage encrypted where the hosting supports it; particularly sensitive fields encrypted additionally where justified.
- On devices — mobile apps relying on device encryption and storing only what's needed offline.
Secure hosting and configuration
Use reputable hosting, keep servers and services patched, close unused ports, separate production from test environments, and restrict administrative access to servers. Secrets — database passwords, API keys — should be stored securely, not in source code.
Keeping components updated
Applications depend on frameworks and libraries that receive security fixes. Regular updates are one of the most effective security measures and part of normal software maintenance.
Secure development practices
Ask your developer how they protect against common web application weaknesses: injection attacks, cross-site scripting, broken access control, insecure file uploads and similar. Code reviews, use of well-maintained frameworks and testing are signs of good practice.
Backups and recovery
Automatic, regular backups stored separately from the main system, with tested restores, protect against hardware failure, mistakes and ransomware. Agree how much data you could afford to lose (for example, the last hour or the last day) and how quickly the system must be restored — these decide the backup design.
Logging and monitoring
Record important events — logins, failed logins, permission changes, data exports, deletions — and monitor for unusual activity. Logs help detect problems early and investigate them afterwards. Audit trails of business changes (who changed this price?) are valuable for both security and operations.
Collect only what you need
Every piece of personal or sensitive data you store is something you must protect. Ask whether you really need each field — full dates of birth, ID numbers, bank details — and how long you need to keep it. Data you don't collect can't be leaked. Data protection laws in many countries also require this kind of minimisation; take advice on what applies to you.
Third-party access and integrations
Integrations with payment providers, messaging services or other systems should use the minimum access needed, with keys stored securely and rotated when people with access leave. Review which external services receive your data.
Plan for incidents
Decide in advance what happens if something goes wrong: who is contacted, how access can be cut off quickly, how users and customers are informed, and how the system is restored. A one-page incident plan is far better than improvising under pressure.
Questions to ask your developer
- How are passwords stored, and do you support two-factor authentication?
- How are permissions enforced on the server?
- Is all traffic encrypted, and is data encrypted at rest?
- How are servers and components kept updated?
- How are secrets and API keys stored?
- How are backups done, and when was a restore last tested?
- What is logged, and who reviews it?
- What would you do if you suspected a breach?
An example
A distributor's custom ordering portal had been running for years with shared administrator accounts and no two-factor authentication. After a former employee's account was found still active, the company worked with its developer to remove shared accounts, introduce two-factor authentication for administrators, review roles, add login and export logging, and test backup restoration. The changes took a few weeks and gave management much greater confidence in the system.
How we help
Corposol builds custom web and mobile applications with security practices built in from the start. Talk to us about your application.
Frequently asked questions
Is a small business app really a target?
Yes. Many attacks are automated and target any system with known weaknesses, regardless of size. Basic security practices stop most of them.
Should our app have two-factor authentication?
For administrators and users with access to sensitive data, two-factor authentication is strongly recommended. For other users it depends on the risk and the user experience you need.
Does using a cloud host make the app secure?
Cloud providers secure their infrastructure, but the application, its configuration, user access and data handling remain your and your developer's responsibility.
How do we know our app is secure?
Ask your developer how they address each area in this guide, keep components updated, and consider an independent security review for applications holding sensitive data.
Will following these basics make us compliant with data protection laws?
Not by themselves. They support good data protection, but legal obligations depend on your jurisdiction and data, and you may need legal advice.
