Ask who could export your customer list today, and the answer may involve more people than expected. A former administrator might still have an account, a contractor could hold the only recovery details, or a backup might depend on the same login as the main system. Small business data security starts with understanding these everyday arrangements and assigning someone to review them.
You do not need to describe every technical control yourself. You do need clear answers about who can use important records, who can change access, and how the business would continue if the main account became unavailable. Use this review to identify questions for your application partner. It is an operating exercise, not a certification that the business is secure.
Follow one important record through the business
Choose a record your team relies on, such as a customer order. Trace where it enters, where it is stored, who edits it, and where copies are sent. Include exports, email attachments, shared folders, and messages. A permission setting inside the sales application does not describe what happens to a spreadsheet after someone downloads it and shares it elsewhere.
For each location, name a business owner and explain why the information is needed there. Look for copies that no longer support an active task. Do not delete records casually; agree what must be kept and who can approve disposal. The immediate goal is to understand the spread of information and the decisions needed, rather than quietly changing retention practices during an access review.
Describe access through real staff tasks
Separate viewing, editing, approving, exporting, and managing accounts. A staff member may need to see an order without changing a payment status or downloading every customer record. Write those differences in plain language. Ask the application partner to show how the actual system enforces them. A role name such as admin or operator is not enough to establish what someone can do.
- What records does this person need for their job?
- Which actions need another person's approval?
- Who can create accounts or grant broader permissions?
- Who can export records outside the application?
- How will temporary access end and be checked?
Review a sample of current accounts against those tasks. Test changes with sample records so the review does not accidentally interrupt a real order. Staff also need a way to request legitimate access when their work changes. Otherwise, they may fall back to shared accounts or forwarded exports that make responsibility harder to establish.
Keep account control with the business
Check who controls the main business email, domain, hosting, and application administration accounts. Record the responsible person and the supported recovery route without placing passwords in a general document. Ask how an approved substitute would take over if that person were unavailable. Access held only through a supplier's personal account needs an explicit handover arrangement, not a verbal assumption.
Use individual accounts where the service supports them, and ask about available stronger sign-in controls. Review recovery details as well as normal login access. A former staff member should not remain the default recipient for account recovery. Check the actual settings with the authorized administrator. A written account list is useful only when it matches what the services currently allow.
Make staff changes a repeatable handover
When someone joins, changes roles, or leaves, include account access in the same handover as their other responsibilities. Identify the applications they use, the work they own, and any shared files that need a new owner. Agree when access changes take effect. Coordinate the timing with the person responsible for staffing decisions so that access is removed through an authorized process.
After the change, check the accounts rather than marking the task complete from memory. Confirm that active orders, scheduled reports, and shared inboxes have a new owner. Review contractor access too, including temporary accounts created during a project. Removing a login without transferring an important task can leave the business with a different operational problem the next morning.
Ask for a recovery demonstration
Choose a limited set of sample records and ask the responsible team to demonstrate restoration in a separate test environment. Confirm what was recovered and what was not. Keep the outcome and follow-up actions. NCSC's incident preparation guidance supports testing that backups can be restored. A successful test is evidence about that test, not a promise that every incident will be simple.
Discuss the business effect of losing recent changes or waiting for access to return. Which orders would need checking, and who would reconcile temporary records? Agree recovery needs with your support partner using these consequences. Ask about backup access if the main account fails. Keep the discussion specific to your setup instead of assuming a backup label answers every recovery question.
Prepare a short incident contact list
Name the internal decision maker, application support contact, and relevant provider contacts. Keep the list available through a route that does not depend entirely on the affected application. Staff need to know how to report suspicious access and who can authorize restrictions. Avoid asking them to investigate alone or send sensitive exports into a group chat while trying to explain the problem.
Review the changes that matter
Revisit access when you add a supplier, connect another tool, or change staff responsibilities. Ask what data the connection can read or change and how to stop it. Keep a short record of decisions and unresolved gaps. That record helps you distinguish a control that was discussed from one that has actually been checked in the application.
Bring those gaps to a discussion of business application and integration services. Start with one record, one access decision, and one recovery check. Talk to Loomora about the data-handling questions your business needs to resolve.
