Business Software Security: Questions and Evidence

Ask for evidence that your software protects the right data and can recover from failure. You do not need to implement the controls yourself, but you should know who owns them and how they were checked. This guide is a conversation checklist, not an assessment of any particular application.

1. Check permissions, not just sign-in #

A logged-in user should only see and change the records their task requires. Ask the developer to demonstrate a normal action and a denied action, including one client trying to access another client’s record or file. Enforce checks on the server; hiding a button does not enforce permission.

Use the OWASP authorisation guidance as a technical reference. Review administrator and support access as well as ordinary staff roles.

2. Distinguish password hashing from encryption #

Authentication passwords should normally be stored as salted, adaptive hashes through a well-maintained authentication system, not as plaintext or reversibly encrypted passwords. Hashing allows a password to be checked without keeping a recoverable copy. Password hashing and encryption protect different things.

OWASP Password Storage explains suitable approaches, including Argon2id. Ask who manages authentication, how password storage is configured and how accounts are recovered. Do not invent your own password storage scheme.

3. Understand what encryption protects #

Encryption in transit protects information moving over a connection. Encryption at rest can protect stored data, but the protection depends on where encryption happens and who can use the keys. Disk encryption does not stop an attacker who has valid access to the running application from reading data that application can decrypt.

Ask which threats the design addresses, where keys are held and whether backups and exports are covered. OWASP Cryptographic Storage describes the different layers and trade-offs. Encryption complements access controls; it does not replace them.

4. Keep database commands separate from input #

SQL injection occurs when untrusted input can change the meaning of a database command. Parameterized queries separate values from SQL code and are a principal defence. Input validation is useful too, but checking that a value looks plausible is not a substitute for safe query construction.

Ask whether the application uses parameterized queries, limits database permissions and tests relevant input paths. The OWASP SQL Injection Prevention guide explains the distinction.

5. Protect accounts and sessions #

Use appropriate multifactor authentication, especially for privileged and sensitive access. Agree session expiry, account recovery, shared-device use and prompt removal of departed staff. Different authentication methods resist different attacks; avoid describing every second factor as equivalent.

The OWASP multifactor guidance and session guidance provide review questions for your technical team.

6. Keep useful records without collecting unnecessary data #

Record important access and changes where justified, with an actor, action, time and outcome. Protect logs against inappropriate access and define retention. Do not put passwords, credentials or unnecessary personal information in debug output. A useful audit trail supports investigation; it does not guarantee every incident will be detected.

7. Maintain dependencies and integrations #

Give someone responsibility for supported versions, security updates, expired credentials and failed integrations. APIs need authorisation appropriate to each operation, limited credentials and protection against misuse. Public endpoints can be legitimate; the question is whether their data and permitted actions are safe to expose.

8. Prove recovery with a restore #

Set backup frequency and retention from the amount of lost work and downtime the business can tolerate. Include database records, files, configuration and critical dependencies. Store and protect copies so the same failure does not destroy both the live system and recovery material.

Use the recovery guide and exercise record to test a restore. A backup job’s success message is not evidence that the complete service will return.

A review record the business can use #

Download the security review worksheet (CSV). Open in a spreadsheet or text editor; the example rows are illustrative.

Prioritise gaps by the data involved, likelihood and consequence. A provider assurance report is one input, not certification of your application or business. Revisit the review when the software or its use changes.