Internal software security: questions to ask

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 an operational system containing customer records have different risks. Use that assessment to decide which controls need specialist review.

This checklist helps you ask procurement questions. It is not a security audit, certification or a guarantee of compliance.

Define access by job need

Users should receive the access necessary for their tasks. Separate everyday work from administration and review access when roles change. Shared accounts make it harder to remove access and understand 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.

Ask for concrete evidence

Check the less obvious routes

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 retained.

Plan a response before an incident

Name the person who can disable access, contact the supplier and coordinate recovery. Keep the information available outside the affected application. Consider the impact of third-party outages and how essential work continues.

Use established guidance

The NCSC small business guidance provides practical starting points, and OWASP's verification standard can inform a developer's testing approach. Higher-risk systems may need independent security testing. Ask what has actually been assessed and what remains untested; a checklist tick should not replace evidence.