Skip to content
Digital trust

AI Scams Are Changing the Inbox: A Small Business Cybersecurity Plan That Staff Can Use

An operational approach to suspicious messages, payment changes, account access, backups and incident practice for a small team.

By BDS Portal Editorial DeskEdition Published Reviewed
Digital equipment illustrating business information security
Illustrative photograph via Unsplash; not a documented Ethiopian client project or field visit.

A message arrives with the right supplier name, a familiar-looking invoice and an urgent explanation for a changed payment destination. Another message sounds like the owner asking a colleague to send a file quickly. The problem for a small business is not simply whether staff can recognize a spelling mistake. It is whether the business has a dependable way to verify a sensitive request when the message looks convincing.

Generative tools make polished writing easier to produce, but the operating weakness is often older: a request can bypass the normal approval route because someone is busy, embarrassed or responding to apparent authority. This article presents a practical security exercise for a small team. Its examples are fictional and no local incident rate is claimed. The objective is to make secure actions specific enough for staff to use during an ordinary working day, including when the owner is unavailable.

Give the business a small, understandable framework

NIST’s Small Business Quick-Start Guide introduces cybersecurity risk management for organizations with modest or no existing plan. It uses the Cybersecurity Framework 2.0 functions of Govern, Identify, Protect, Detect, Respond and Recover. These are organizing ideas, not a certificate of security and not a substitute for technical assessment. [NIST SP 1300: Cybersecurity Framework 2.0 Small Business Quick-Start Guide]

Translate them into business questions. Who decides what matters? Which accounts and records support essential work? What prevents an avoidable mistake? How would someone notice a problem? Who coordinates the response, and how would operations resume? A small firm can answer those questions in a short document. The aim is not to create a large policy file. It is to make sure that a worrying message or an inaccessible account does not leave every employee inventing a separate response under pressure.

Identify the requests that deserve an independent check

Not every message needs the same level of scrutiny. Focus on actions that can cause a significant loss or expose important information: changing a payment destination, adding an account administrator, releasing customer records, approving a new integration or resetting a business credential. Write these categories in language staff use.

For a hypothetical wholesaler, the rule might be that a supplier’s bank-detail change is checked through an existing, independently held contact route before the master record is updated. A reply to the same email is not independent verification. Neither is a telephone number supplied only in that message. The business should decide who performs the check and how the result is recorded. This procedure remains useful whether the suspicious request was written by a person, copied from a real invoice or drafted with AI assistance.

Build a verification route that works without the owner

A rule to call the owner can fail if the owner is travelling, unavailable or apparently the person making the request. Create a fallback based on the sensitivity of the action and the roles available in the team. An urgent request should not automatically create new authority.

Prepare a contact list through a trusted process and keep it available to the people who need it. Define what happens if verification cannot be completed: the action waits, the customer receives a clear explanation or a designated deputy reviews the request. Staff should know they will be supported for following that process. If a team member is criticized for delaying an unverified instruction, the written policy becomes difficult to apply. Verification works best as an ordinary operating habit, not as a test of whether an employee is brave enough to question a senior person.

Give accounts individual owners and recoverable access

Start with the accounts that matter most to business continuity: email, shared files, payment administration, customer systems and the website. Record who owns each account and who can authorize a change. Where supported, use separate user identities and additional authentication rather than sharing one password across the team.

Check how account recovery works before there is an incident. A business can lose control even without an attacker if a former employee owns the recovery email or a critical phone number is no longer available. Review access when someone changes responsibilities or leaves. Keep the review focused on the ability to do the assigned work, rather than granting broad access because it is convenient. Technical configuration may require qualified support, but the management decision about who should have authority belongs to the business and should be documented clearly.

Reduce the information a convincing message can expose

A staff member may receive a request that appears reasonable because the requested file is easily accessible. Review where customer records, identity documents, contracts and internal price information are stored. Separate material intended for public use from material that requires restricted access.

Avoid using a large messaging group as the default archive for sensitive documents. Copies are difficult to control and can remain on devices after someone no longer needs them. Ask what information a colleague genuinely needs to complete a task and use an appropriate sharing method. For AI services, do not assume that every account has the same retention or data-use conditions. NIST’s AI Risk Management Framework emphasizes considering trustworthiness and risk in context; it does not establish that a particular service is appropriate for confidential files. [NIST: AI Risk Management Framework] Verify the actual product settings and approved uses before staff upload business information.

Practice a suspicious-message conversation

Awareness sessions are more useful when people rehearse the next action. Use a fictional request that asks for a sensitive change and ask staff to explain what they would do. Do not collect real passwords or create a humiliating exercise designed to catch someone out.

The wholesaler’s practice scenario could involve an invoice with the correct amount but an unfamiliar account number. The person at the counter identifies the request category, pauses the change and contacts the designated verifier through the trusted list. The verifier checks the existing supplier record and records the outcome. Discuss where the process became unclear. Perhaps the list was missing a deputy or the invoice record had no owner. Those findings are operational improvements. They matter more than counting how many people correctly used a technical term during the training session.

Decide what staff should do in the first minutes

An incident plan should make the immediate communication route clear. Staff need to know whom to contact, how to describe what happened and which information to preserve. A short record might include the time, the account involved, the action taken and the message or transaction reference, without copying sensitive data unnecessarily.

Avoid a universal instruction to delete suspicious material immediately. Evidence may be needed for technical investigation or a provider’s support process. The appropriate containment action depends on the system and event, so a qualified support person should help define the procedure for critical accounts. The business can still decide the coordination roles: who communicates with staff, who contacts the provider and who authorizes a temporary change to operations. A coordinated response reduces the risk that several people make conflicting changes while trying to help.

Test recovery as a business activity

A backup is useful only if the business can recover the information it needs in a usable form. Identify the records required to continue essential work and ask how they would be restored if the main device or account became unavailable. Confirm that the recovery process is appropriate for the systems actually in use.

A practical exercise can involve retrieving a non-sensitive test file from an approved backup and checking that the responsible person understands the steps. Do not overwrite live records merely to demonstrate a recovery. Also examine the work that can continue manually and the information needed to reconcile it later. A service business might use a temporary appointment record during an outage, then enter and check it once systems return. The purpose is continuity with traceable records, not an improvised parallel system that creates a second set of unresolved customer commitments.

Use a short review instead of an annual surprise

Accounts, staff and suppliers change. A security plan that was sensible at the start of the year can become inaccurate without any dramatic event. Schedule brief reviews of critical access, recovery information, unresolved incidents and changes to the business’s tools.

Include new integrations in that conversation. Ask what a new application can read or change and who will remove its access if the trial ends. Keep a record of the decision and its owner. The same review can examine whether staff are reporting suspicious requests early and whether verification is practical during busy periods. If the process creates unnecessary delay for low-risk work, refine it. A proportionate system concentrates effort on meaningful exposure while preserving a clear route for staff to raise uncertainty without being blamed for asking a reasonable question.

Judge readiness by behaviour that survives pressure

No small-business checklist can guarantee that an incident will not occur. The useful question is whether the team can carry out a few important actions consistently: verify sensitive changes independently, control access to essential accounts, protect important records and coordinate a response when something goes wrong.

The next step is not necessarily another security product. It may be a trusted contact list, a corrected recovery address or a short practice session around one realistic request. Those improvements are observable and can be reviewed. In an inbox where convincing language is easy to generate, dependable business procedures provide a stronger basis for trust than a person’s confidence that a message simply looks or sounds familiar.

Keep provider support information in that trusted contact list as well. During an incident, a search result or a number supplied in an unsolicited message may lead staff to the wrong place. Confirm official support routes when setting up the account and explain where the approved information is kept. This small preparation step gives the response coordinator a reliable starting point when time is limited and several colleagues are asking what to do next.

Methodology and sources

Prepared by the BDS Portal Editorial Desk using primary-source desk research in digital trust. Factual statements are linked to their source; proposed workflows and fictional examples are editorial analysis. The collection was drafted with AI assistance. No independent field interviews, original survey or external professional audit was performed.

Data limitations: No original incident survey or technical security audit was performed. The proposed exercises are illustrative and require adaptation to actual systems and qualified support where appropriate.

  1. NIST SP 1300: Cybersecurity Framework 2.0 Small Business Quick-Start Guide. Source checked 6 November 2026.
  2. NIST: AI Risk Management Framework. Source checked 6 November 2026.

Edition dates organize this collection and do not claim prior online publication. This article was prepared for publication and reviewed on 6 Nov 2026. Read our editorial standards or send a correction with the article URL to [email protected].