Cybersecurity Essentials for Business Teams

Welcome. In this lesson, we will explore everyday cyber responsibility.

Identify everyday actions that reduce avoidable risk.

Know who owns important systems and information. Report suspicious activity promptly through an agreed route. Combine staff habits with technical controls and management oversight.

Make reporting easy and specific: staff should know a trusted contact and an alternative when email is unavailable. Describe what happened and when, without sharing passwords or secret codes. Managers should welcome early reports even when they prove harmless. Technical investigation and containment belong to the authorised response team; staff should follow its instructions.

Consider this example. A staff member reports an unexpected login alert immediately. The team checks the account and responds before assuming that the alert is harmless.

Pause here and try this activity. Identify your security contact and one business system whose loss would interrupt work.

Here is one possible response. Record the time of the unexpected alert and the affected service. Contact IT through the established help route, without clicking the alert's link. The authorised team checks the account. If that route is unavailable, use the organisation's agreed alternative contact.

Before moving on, think about this question. What should staff do with an unexpected account-security alert? The best answer is: Report it through a trusted internal route. Prompt reporting allows the organisation to investigate and respond.

Welcome. In this lesson, we will explore strong, unique passwords.

Use safer account credentials without relying on memory alone.

Use a unique password for each important account. Use an approved password manager to create and store strong passwords. Never share passwords or recovery codes in messages.

Unique passwords reduce the damage from one compromised service. Use your organisation's approved password manager and recovery process. Protect the manager itself and avoid putting credentials in a shared spreadsheet or training worksheet. For shared business functions, ask IT for an approved access arrangement rather than circulating an individual's password.

Consider this example. A staff member reuses a password for a supplier portal and business email. A breach at one service can put the other account at risk.

Pause here and try this activity. Review one important account. Check that its password is unique and stored in an approved manager.

Here is one possible response. For business email, confirm that the credential is unique and stored using the approved method. If it has been reused, change it through the genuine service and follow IT guidance for other affected accounts. Record only 'review completed' in this workbook, never the password.

Before moving on, think about this question. Why is password reuse risky? The best answer is: One compromised password can expose other accounts. Attackers may try a stolen password on other services.

Welcome. In this lesson, we will explore multi-factor authentication.

Explain how MFA adds protection to an account.

Enable MFA on important accounts wherever available. Prefer stronger, phishing-resistant options when supported. Do not approve an unexpected login prompt or disclose a one-time code.

MFA adds protection beyond a password, but its methods differ. Where supported, ask IT about phishing-resistant options such as FIDO security keys or appropriate passkeys. Plan enrolment, lost-device recovery and alternative access before rollout. Never approve a request you did not initiate, and never read a one-time code to an unexpected caller.

Consider this example. A staff member receives an approval request while not signing in. They reject it and report the attempt rather than approve it to stop the notifications.

Pause here and try this activity. Check whether your business email has MFA and locate the approved recovery process.

Here is one possible response. Check the business email security settings through the trusted service. Confirm the approved MFA method and recovery contact. If an unsolicited prompt appears, reject it and report it. Do not treat repeated prompts as a reason to approve access.

Before moving on, think about this question. What should you do with an MFA request you did not initiate? The best answer is: Reject it and report the unexpected request. Unexpected prompts may indicate an attempted account compromise.

Welcome. In this lesson, we will explore phishing and payment changes.

Recognise pressure tactics and verify requests independently.

Be cautious with urgency, unusual attachments and unexpected links. Verify payment-detail changes using a known contact route. Report suspicious messages instead of interacting with them.

Urgent language and a familiar logo are not reliable evidence of identity. Payment changes deserve an independent verification step and the usual approval controls. Use contact details already held in a trusted record, not details supplied in the change request. If someone has already interacted with a suspicious message, prompt reporting matters more than blame.

Consider this example. An email asks finance to replace a supplier bank account urgently. Finance calls its established supplier contact rather than the number in the email.

Pause here and try this activity. Write a short verification procedure for requests to change bank details.

Here is one possible response. Pause the payment-detail change. Call the known supplier representative using a previously verified number. Follow the finance approval process, record the verification, and only then update the authorised supplier record. If the request cannot be verified, escalate it without changing the details.

Before moving on, think about this question. How should a supplier bank-account change be verified? The best answer is: Call a trusted contact using an independently held number. Independent verification avoids relying on contact details controlled by an attacker.

Welcome. In this lesson, we will explore updates and supported software.

Treat updates as part of routine business maintenance.

Install legitimate security updates through approved processes. Assign responsibility for devices and business applications. Plan replacement or mitigation for unsupported software.

Use legitimate updates through your organisation's approved route. Business-critical systems may need compatibility checks, a maintenance window and a recovery plan. Delaying an update should be an owned risk decision with a deadline, not an indefinite habit. Keep an inventory so shared devices and unsupported applications are not overlooked.

Consider this example. A shared workstation misses updates because everyone assumes someone else owns it. Naming an owner makes routine maintenance visible.

Pause here and try this activity. Identify one shared device and confirm who checks its update status.

Here is one possible response. The shared reception PC has a named owner. IT checks support status and applies approved updates in a scheduled window. After restarting, the owner checks essential functions. Any deferred update is logged with a reason, temporary controls and a review date.

Before moving on, think about this question. What is the best approach to shared-device updates? The best answer is: Assign an owner and an approved update process. Named responsibility helps prevent devices from falling outside routine maintenance.

Welcome. In this lesson, we will explore backups and recovery.

Understand why having a backup is different from proving recovery.

Protect backup copies from the same incident as the original data. Restrict backup access and protect sensitive backup data. Test restoration and check the recovered information is usable.

Recovery evidence should show what was restored, from which recovery point, how long it took and who checked usability. Protect backups from the same account compromise or incident that affects the originals. Test in a controlled environment and agree recovery priorities with the business owner. A green backup-job status alone cannot establish that business service will recover.

Consider this example. A company discovers that its backups do not include a critical shared folder. A restoration test finds the gap before a real outage.

Pause here and try this activity. Ask when a critical file or system was last successfully restored and who verified the result.

Here is one possible response. Restore a sample critical folder into an approved test location. Confirm that required files open and that dates and contents are correct. Record elapsed time, the recovery point and any missing data. Assign remediation and repeat the test after addressing gaps.

Before moving on, think about this question. What best demonstrates that a backup supports recovery? The best answer is: A successful restore with usable data verified. A restore test checks that the data and process can support recovery.