In this article:
- Start with the systems that keep work moving
- 1. Protect business email
- 2. Remove unused accounts
- 3. Verify supplier bank changes
- 4. Assign vendor and remote-access ownership
- 5. Review backup and restoration evidence
- 6. Give staff a reporting path
- 7. Prepare offline fallback procedures
- 8. Assign owners and dates
Start with the systems that keep work moving
For an agricultural retailer, farm-supply business, agronomy provider, or smaller cooperative, a disrupted mailbox, unavailable supplier records, locked account, or questionable payment request can create a real operational problem at the wrong time. Consider a plausible example: the office receives a supplier bank-change request while seasonal orders are being placed. If the team cannot quickly verify the request, find a trusted contact, or reach the records they need, an ordinary administrative task can turn into a delay or loss.
This agribusiness cybersecurity checklist is a planning aid for a conversation with your team and IT provider. It does not establish that every safeguard is effective, does not prove an environment is secure, and does not replace a scoped assessment. Its value is in making the evidence, owner, and next action clear before your busiest period.
1. Protect business email and require appropriate MFA
Question: Are business email accounts protected by appropriate multifactor authentication, and do employees know how to recognize an unexpected sign-in request? Evidence to request: the Microsoft 365 or email-provider MFA policy, a current list of excluded accounts or exceptions, and confirmation that administrator accounts have stronger protections where supported.
If the answer is unclear, ask the responsible IT person to identify which account types are covered, which exceptions remain, and how those exceptions are reviewed. Public SPF, DKIM, and DMARC signals can be useful context, but they do not prove internal email controls are configured correctly. DMARC can help address some direct-domain spoofing; it does not stop lookalike domains, compromised legitimate mailboxes, or every fraudulent request.
2. Remove unused employee accounts and review administrator access
Question: Can the business show that former employees, temporary users, and unneeded vendor accounts no longer have access? Evidence to request: an active-user list, a list of administrator roles, the offboarding checklist, and a recent example showing that access was removed after a departure.
If the answer is unclear, assign an owner to reconcile the employee roster with the account list and to identify every privileged account. The goal is not to create paperwork for its own sake. It is to make sure the business can explain who has access to email, files, supplier portals, and remote tools—and why.
3. Verify supplier bank changes independently
Question: Does accounting verify a supplier bank-detail change through an established phone number or trusted channel rather than using the phone number, reply address, or link in the change request? Evidence to request: a written verification step, approval requirements, and a redacted example of a completed callback or trusted-channel confirmation.
If the answer is unclear, choose a simple rule that fits the business: no bank-detail change is processed until a known contact confirms it using independently sourced contact information. Email authentication is useful, but it is not a substitute for this process because fraudulent requests can come from lookalike domains or compromised legitimate mailboxes.
4. Identify who owns vendor and remote-access accounts
Question: Does the business know which vendor, support, remote-access, and shared accounts exist, who owns each one, and whether access is still needed? Evidence to request: an inventory of remote-access methods, vendor account owners, access approvals, and the process for disabling access when a relationship changes.
If the answer is unclear, start with the systems used for email support, accounting, point-of-sale or ordering support, file sharing, and any remote administration. Do not assume public visibility proves exploitability or that every remote tool is a problem. Confirm the owner, business purpose, authentication method, restrictions, and support responsibility first.
5. Review backup coverage and restoration evidence
Question: Which business systems and records are backed up, who watches for failures, and is there documented evidence of a successful restoration? Evidence to request: a backup coverage summary, job-status reports, restore-test records, known exclusions, and named owners for failed jobs.
If the answer is unclear, prioritize the information required to continue basic business operations: email, shared files, order and supplier records, financial data, and the contact information needed to coordinate a response. A successful backup job is not the same as a successful restoration, so ask what was restored, when it was tested, and what limitations were found.
6. Give staff a clear way to report suspicious requests
Question: Do staff know exactly where to send a suspicious email, payment request, sign-in prompt, or unexpected attachment without worrying that they are overreacting? Evidence to request: a short reporting instruction, a monitored email address or support route, escalation contacts, and a recent staff reminder or training record.
If the answer is unclear, publish a simple instruction that works under time pressure: stop, do not reply or use the supplied contact details, and report the request through the business's established IT or manager channel. Practical phishing testing can reinforce this habit with realistic scenarios and short follow-up training.
7. Prepare an offline contact list and practical fallback procedures
Question: If email, shared files, or a primary business system is unavailable, can the team reach key people and continue the next essential tasks? Evidence to request: a current offline contact list, IT-provider escalation information, supplier and banking contacts, and short fallback procedures for communicating with customers and staff.
If the answer is unclear, do not begin with a long disaster-recovery binder. Identify the first few decisions your business would need to make during a disruption, who makes them, and how those people contact one another without depending on the unavailable system. Review the list before planting, harvest, or seasonal ordering changes the pace of work.
8. Assign every unresolved issue an owner and completion date
Question: Does every unresolved safeguard have one named business owner, an agreed next step, and a completion date? Evidence to request: a short action list showing the issue, accountable person, due date, dependency on an IT provider or vendor, and the evidence that will show completion.
If the answer is unclear, reduce the list to a manageable first set of actions. A clear owner and date are more useful than a broad statement that security needs improvement. Review the list with leadership and the IT provider so responsibilities are agreed rather than assumed.
Example action table
These suggested owners are examples. Actual responsibilities vary by business, provider relationship, and system owner.
| Check | Evidence to request | Suggested owner |
|---|---|---|
| Supplier-payment verification | Written callback or trusted-channel procedure; a recent approval example with sensitive details removed | Controller or accounting lead |
| Employee and administrator accounts | Current user list, administrator-role list, and offboarding checklist or ticket evidence | IT provider with a business owner |
| Backup recovery | Coverage summary, restore-test record, system owner, and follow-up for failed jobs | IT provider and operations lead |
| Suspicious-request reporting | Published reporting path, escalation contacts, and short staff reminder | Operations manager or office manager |
Practice the pause before the next urgent request.
Managed phishing testing and staff training can use realistic office, purchasing, and operations scenarios to help employees verify requests and report suspicious messages.