Business software · 4 min read
"It's only for staff" is not a security plan
An internal software security checklist covering access, secrets, backups and incident ownership.
The short answer
An internal software security checklist should cover access controls, dependency updates, secrets handling, backups and incident ownership. Being used only by staff does not make a system automatically safe. Ask for evidence of permission testing, secure account handling and tested backup restoration rather than accepting a general claim that the system is secure.
By Raja Wahab, Co-founder, Fixby Studios · Published · Updated · 4 min read
Why internal tools still need a security checklist
An internal application still needs strong access controls, maintained dependencies and a recovery plan. Staff-only software can hold customer records, pricing or supplier data, and a mistake or compromised account can expose or change that data just as easily as on a public site.
This checklist helps you ask the right procurement and build questions. It is not a security audit, certification or guarantee of compliance, and higher-risk systems may need independent testing on top of it.
Start with the information and the consequences
List what the application contains and what could happen if it is exposed, changed or unavailable. A staff lunch planner and a system holding customer records carry different risks. Use that assessment to decide which controls need specialist review.
Assurance only
- — "It's secure, trust us"
- — No permission tests shown
Evidence requested
- — Tests showing restricted access works
- — A tested backup restoration
Define access by job need
Users should receive only the access their role needs. Separate everyday work from administration, and review access whenever someone changes role or leaves. Shared accounts make it harder to remove access and to know who made a change.
Ask how the system handles an employee leaving, a lost device and a compromised account. The answers should describe actions someone can actually take that day, not a general policy statement.
“Staff-only software still holds real risk; judge it by what it contains, not who uses it.”
What evidence to ask a developer for
| Area | Evidence to request |
|---|---|
| Permissions | Tests showing one user cannot access another's restricted records |
| Authentication | Appropriate account recovery and stronger protection for sensitive access |
| Secrets | Credentials kept out of public code and browser responses |
| Updates | Named responsibility for dependencies and patches |
| Backups | A tested restoration process, not just a backup schedule |
| Monitoring | A way to notice failures and suspicious activity |
Check the less obvious routes in
Downloads, exports and integrations need the same access thinking as ordinary pages. A hidden navigation link is not protection. Ask what happens if a user changes a record identifier in a request, or keeps an old document link after their access is removed.
Logs should help investigate an incident without unnecessarily collecting passwords, tokens or sensitive content. Agree who can read them and how long they are kept.
Plan a response before an incident
- Name the person who can disable access and coordinate recovery.
- Keep that contact information available outside the affected application.
- Agree how the supplier can be reached outside normal hours.
- Decide what essential work continues if the system or a third party goes down.
- Review the NCSC small business guidance as a starting point for the policy itself.
Sources
Your questions
- What should an internal software security checklist cover?
- Access controls by job need, maintained dependencies, secrets kept out of code, tested backups and a named incident contact. Ask for evidence of each rather than a general assurance that the system is secure.
- Is staff-only software less risky than a public website?
- Not automatically. Internal tools often hold customer or financial data, so a compromised staff account can cause just as much damage as a public vulnerability.
- Who should own security for an internal business application?
- Name one person who can disable access, contact the supplier and coordinate recovery. Without a named owner, incidents get slower and less consistent responses.
- Do small businesses need a formal security audit for internal tools?
- Not always, but higher-risk systems holding sensitive data benefit from independent testing. For most small businesses, NCSC's Cyber Essentials and this checklist cover the basics.
Raja Wahab is co-founder of Fixby Studios, a Huddersfield studio building websites, SEO, social media and business software for small, owner-managed businesses across West Yorkshire.
Next step
Let's get your business seen.
A free plan to replace spreadsheets and WhatsApp with one system.
Tell us which task takes too much time and we'll assess a focused software or automation project. Business automation and software
Prefer to talk it through? Contact Fixby Studios, email info@fixbystudios.co.uk or call 07737 067552.
