In this guide 6 sections
Start with a register of every application, the data it holds, and each person or supplier who can log in to it, including the old accounts. Next, test logins and settings. Book authorised testing for the riskiest system, and give every finding one owner and a fixing date before the report is filed.
Inventory of applications, data and access
Start with a list, not a scanner. Nobody has written down what needs protecting. Open a spreadsheet and list every application the business runs, the data each one holds, such as customer contacts or payslip PDFs, and who can log in today.
This list alone produces the first findings. A retired point-of-sale reporting tool may still log in and pull sales figures from every branch, long after the vendor contract ended and the project team moved on. A former employee’s account may never have been deactivated, and an admin panel that everyone assumed was internal-only may answer requests from the open internet.
Include the unglamorous items. Shared mailboxes, the website contact form plugin, the cloud folder where scanned invoices land and the old test server a developer left running all hold data behind a login.
Logins, permissions, patches and settings
Authentication confirms who is logging in. Check the minimum password length, whether multi-factor authentication covers every account that can change records, and whether shared logins are still in use.
Authorisation is the next layer. Each role should see only what its job needs, so a delivery driver never opens the supplier invoice screen and a trainee never exports the customer table. Patches and settings finish the section. Frameworks, libraries and operating systems need scheduled updates, and every setting a product shipped with should be read and tightened, because defaults favour installation over safety.
Test the weak spots yourself. Try a leftover default login on each admin page, read what the password reset email reveals about an address, and confirm that a session closes after an idle period.
Secrets, logs, recovery and supplier access
API keys, database passwords and SMTP and payment gateway credentials do not belong in code, spreadsheets or WhatsApp groups, where they leak and cannot be rotated when someone leaves. Logs should answer who did what, and when. They should not store card numbers or passwords.
Recovery access needs a written answer. Decide who may reset another person’s password, and who holds the master credentials when the one administrator is unreachable on a holiday or has already left. A memory is not a recovery plan. Suppliers deserve the same scrutiny as staff, and a vendor with standing production access years after the project closed is the gap most often missed.
Write down the break-glass steps. A sealed envelope or a password manager vault entry, opened by two named people and logged when used, beats a shared admin password pinned to a noticeboard.
Authorised security testing
Testing comes after the basics. A vulnerability assessment or penetration test, scoped to the systems holding the most sensitive data, finds problems a checklist review cannot see. It shows how components behave when combined, such as a payment form feeding a reporting database, instead of judging each setting alone.
Get written authorisation first. The letter should name the systems, dates and methods, and the work should be done by a tester the business has checked, outside peak trading hours. Testing without permission is risky. A well-meant probe of a live order system can take it offline, and the person who ran it carries the legal exposure.
Choose the scope with care. Customer login, the payment page and the file upload form usually carry the most risk, so they go first, while a brochure page can wait for the next round.
Remediation and review ownership
A report nobody owns gets ignored. Give each finding one owner and a realistic date, and fix items touching sensitive data or wide access before the rest of the list.
Security is never finished. Every new integration and hire reopens questions the checklist answered once, so a short review each quarter keeps the register and access list from going stale.
SMB application security checklist
A working sheet holding a row for every application, with columns for data held, access list, login controls, patch date, key storage, last test and fix owner. Every row shows its status. Revisit it each quarter.
Open a blank worksheet to printQuestions owners ask
Where should a small business start?
Start with the register. List each application, the data it holds and who can open it, including suppliers and former staff whose accounts were never closed. Forgotten accounts, retired tools that still connect and admin panels without an owner usually surface here, weeks before any scanner is booked or any consultant is hired.
Is HTTPS enough protection?
No. HTTPS protects data while it travels between a browser and a server, which matters, but it says nothing about weak logins, loose permissions or unpatched software behind the page. It is one control among many.
Who should own the checklist?
One named person, usually the operations head, holds the checklist and chases each fixing date, while IT staff or a supplier do the technical work. Shared ownership means no ownership.