MI5 has a warning for tech startups: expect to be spied on!

What should a small business check first?

Start your small-business cyber security checklist with email protection, unique passwords, independent verification of unusual requests, software updates and access reviews. These five checks address familiar weaknesses. The full ten-point guide below adds device protection, email-domain security, backups, incident response and supplier access.

Foreign intelligence is not quite the international interest most founders had in mind.

On 13 October 2026, Director General Sir Ken McCallum told technology startups:

If you're a tech start up, expect to be spied on by foreign actors and sort your cybersecurity.

The original MI5 speech is a serious preparedness warning about foreign interest in technology businesses. It does not assign every company the same risk, but it gives founders a clear reason to examine their security now.

For a small business, the useful response is to examine the systems an attacker could misuse. You do not need to settle the geopolitical argument before protecting the account that resets your other passwords.

What the UK figures actually tell us

The government's Cyber Security Breaches Survey 2025/2026 found that 43% of businesses identified a cyber breach or attack in the preceding 12 months. Its most commonly identified types give us a practical starting point:

These are reports of identified activity, including unsuccessful attempts. They do not mean 43% were successfully hacked, or that your business has a 43% chance of being hacked next year.

The survey was published in April 2026, but fieldwork took place in August to December 2025. Its weighted sample contained 2,112 businesses; sole traders were outside its scope. The technical report explains the sampling and uncertainty.

These figures describe everyday cyber threats, not the prevalence of foreign espionage. Password sharing by email is another distinction: it is a risky practice that can expose access, rather than a separately measured attack category in this list.

The ten checks at a glance

Use this as a starting list, with “unknown” treated as something to investigate:

The first five are the starting points in our social post. Work through all ten with whoever looks after your systems. Use this as a review, not an instruction to change every setting during one sitting.

Checking is not the same as changing. Removing an administrator, replacing authentication methods or enforcing an email policy can disrupt legitimate work. Establish ownership and recovery before making changes.

1. Secure email and the accounts that unlock everything else

List the services whose loss would prevent you trading: business email, domain registration, website hosting, banking, accounting, customer records and backups. Include code repositories and automation platforms if your business depends on them.

Record the business owner, the person administering it and the recovery route. Do not put passwords or recovery codes in this inventory.

For each account, ask a simple question: if the usual person were unavailable, could an authorised colleague regain control? Check the answer using the provider's documented process. A recovery address belonging to a former employee is a problem even if the password is excellent.

Email deserves early attention because it can contain confidential correspondence and password-reset messages. The NCSC's current small-organisation guidance starts with securing email, followed by other important online accounts.

Ask whether recovery depends on one person's phone or an inbox you would also lose during an incident. A supplier can administer your systems without becoming the only person who can recover them.

What to verify: a named owner and a usable recovery process for each critical service. If those are missing, start there.

Check authentication, not just whether MFA exists

Multi-factor authentication, or MFA, adds protection beyond a password. But “we have MFA” can mean one administrator enabled it while everyone else remains password-only.

Check the account coverage and enforcement settings. Where available, use policy reports and sign-in logs with your IT provider. One successful test in a private browser window does not prove that every account and sign-in route is protected.

Prefer phishing-resistant passkeys or FIDO2 security keys where supported, especially for administrators and other high-impact accounts. The NCSC's comparison of MFA methods explains why these differ from approval prompts and typed codes. Number matching can improve an app prompt; it does not make it equivalent to FIDO2.

Set up recovery before removing an existing method. Where stronger options are unavailable, properly configured MFA remains preferable to password-only access.

Where your provider supports it, ask the administrator for a coverage report: who is required to use MFA, which methods are allowed and whether there are exceptions. Do not assume a passkey automatically removes every old password or recovery route. Have the maintainer review those routes as part of the same change.

There is substantial research behind prioritising MFA. A 2023 Microsoft-authored preprint, using commercial-account data from April to September 2022, estimated a 99.22% relative reduction in account compromise for MFA-enabled accounts. This was an observational study in one provider's environment, not a trial proving that MFA removes 99.22% of every company's cyber risk.

What to verify: covered accounts, enforced methods, exceptions and recovery. A tick beside “registered for MFA” is not the whole check.

2. Stop reusing or emailing shared passwords

Where passwords remain, make them unique. Reusing one lets a breach at one service create an opening at another.

A reputable password manager makes this manageable. Review its warnings about reused or exposed passwords, starting with email, finance, hosting and administrator accounts. Protect the manager and its recovery route too.

Free does not automatically mean suspicious. The NCSC recommends password managers, including suitable built-in options. What matters is the product, how it is configured and who can access the device or vault.

Avoid shared logins where individual accounts are available. They make it harder to remove one person's access and understand who performed an action.

Where a service genuinely requires a shared credential, use your manager's controlled-sharing feature and review the recipients. Forwarding a password through email or chat creates more copies to track and leaves access behind in old conversations.

Check what happens when somebody leaves. Can their access to shared vault items be removed without disrupting everyone else? If they previously knew a shared password, removing vault access does not make them forget it. The responsible administrator may need to rotate the credential and update the systems that depend on it.

For a suspected exposed password, open the genuine service directly and follow its recovery process. Never enter real credentials into an unfamiliar “password strength” or “breach check” website.

What to verify: unique credentials for important services, protected vault access and no unexplained sharing. Do not export everyone's passwords into a spreadsheet to perform the check.

3. Make unusual requests easy to question

A plausible message may ask someone to change bank details, approve an unexpected login, reset an account or share a confidential file. The practical defence is a process that allows them to stop and verify.

Confirm unusual payment or access changes through an independently established channel. Use a number or contact route already held by the business, not one supplied in the request you are checking. A familiar voice or email display name is not sufficient verification by itself.

Write the verification rule around the action, rather than only the delivery method. A bank-detail change arriving in a chat message deserves the same care as one arriving by email. For an unexpected password-reset request, use the organisation's identity-checking procedure instead of trusting whoever knows the employee's name.

Give people permission to pause. “The director said it was urgent” should trigger a faster route to verification, not the removal of verification. Keep enough of a record to establish who checked the request and approved the action, without copying sensitive information unnecessarily.

Give staff a clear reporting route and avoid blame when somebody reports a mistake. The NCSC's guidance on spotting cyber attacks provides a starting point.

Do not make a yearly training video your only defence. A 2025 study involving more than 19,500 healthcare employees found limited practical benefits from the training approaches it examined. Its randomised embedded-training experiment used simulated phishing; it does not prove that all training is useless. It does support taking technical protection and working procedures seriously.

What to verify: staff know where to report concerns, and payment or access changes have a verification step that survives urgency.

4. Check that security updates actually installed

Look beyond the laptop update notification. Include browsers, phones, the office router, remote-access software, website components and any services exposed to the internet.

An “automatic updates” setting is useful, but check the last successful installation and whether the product is still supported. An abandoned plugin cannot install a security fix its developer will never release.

In Verizon's 2026 DBIR executive summary, vulnerability exploitation accounted for 31% of the analysed initial-access category, ahead of credential abuse at 13%. Figure 4 covers 19,905 non-error, non-misuse breaches in a global dataset. It is evidence to prioritise exposed software, not a UK business probability or a promise that patching removes 31% of risk.

Use vendor update instructions. Your technical maintainer should prioritise actively exploited vulnerabilities and test changes proportionately. A generic patching timetable is not permission to leave an urgent exposure open.

For your website, establish who owns the hosting platform, application, plugins and integrations. A managed hosting subscription may not cover every component. Ask the supplier to explain what they update, how they identify an urgent fix and how they recover if an update breaks something.

Do not use a stranger's scanning service to probe systems you do not own or have permission to test. An inventory, vendor notices and your maintainer's records are sensible first checks. Technical vulnerability testing belongs within an agreed scope.

What to verify: supported versions, successful updates and a named maintainer for systems you do not manage yourself.

5. Review people, applications and administrator access

Check former employees, old contractors and suppliers alongside current staff. Look at what they can actually do, not merely whether their names appear in an address book.

Administrator access should be limited to the work that needs it. Arrange separate administrative use where appropriate, and preserve a secure emergency recovery route. Do not remove the last working administrator as a tidy-up exercise.

Connected applications need attention too. A tool may retain permission to read email or documents after the original project has ended. Microsoft's guidance on illicit consent grants explains why resetting a password or adding MFA does not necessarily remove an application's existing access.

Ask who owns each integration, what permissions it has and whether the business still needs it. Investigate unfamiliar entries before revoking them; an obscure service account may run invoicing.

Include service accounts, API keys and automation connections, not only people. These may continue operating without a human signing in. Record their purpose and owner, limit permissions to the work involved and establish how credentials are replaced safely.

Ask the same questions of AI tools: what can this connection read, what can it change and who can stop it? The model's helpful explanation is not an access control. The connected system should enforce permissions, and consequential actions should follow the business's agreed approval process.

What to verify: current users, justified privileges and owned integrations. Arrange revocation or changes with the maintainer, rather than disconnecting things blindly.

6. Check the devices used to access the business

Strong account settings still depend on the devices people use. Review business laptops and phones, including personal devices that are permitted to access company information.

The NCSC's device-protection guidance covers practical checks such as updates and antivirus/firewall protection. Check that supported protective features are enabled and reporting normally. Do not install competing security products simply because more icons feel reassuring.

Check the basics with the device owner:

• Does the screen lock when the device is left unattended?
• Is the operating system supported, with updates completing?
• Are protective tools active, with no ignored warning that needs investigation?
• Is access separated on shared devices, rather than everyone using one unlocked account?

For laptops holding business information, ask your IT provider to confirm appropriate device encryption and secure recovery-key storage. The NCSC's Small Business Guide actions includes encryption among its technical recommendations. Confirm recovery before changing encryption settings; a lost recovery key can become its own availability problem.

Agree what happens when a device is lost, replaced or returned. People need to know whom to tell promptly. The technical owner should understand what access can be revoked and which remote-management actions are available, without promising capabilities that have never been configured.

What to verify: a small device inventory, functioning protective settings and a named person who handles loss or warnings. Resolve uncertain settings with the maintainer rather than experimenting on a working device.

7. Protect your email domain without breaking delivery

SPF, DKIM and DMARC help receiving services assess mail claiming to come from your domain. Ask your email administrator to check them, including legitimate senders such as invoicing and marketing systems.

The NCSC recommends introducing DMARC gradually. A policy of none provides monitoring; it does not request rejection. After legitimate mail is accounted for, the administrator can progress towards enforcement and rejecting spoofed messages.

Do not paste a strict policy into DNS without checking existing senders. You could block your own invoices. These controls also do not prevent someone using a lookalike domain or a compromised genuine mailbox.

Ask for a list of services permitted to send as your business: ordinary email, website forms, invoicing, customer support and marketing platforms may be separate. An old service can remain in the configuration after the subscription ends, while a new service may have been added without completing its authentication.

Have the administrator explain the current state in ordinary language. Are reports being collected? Have legitimate senders been checked? Is the policy monitoring only, or asking recipients to quarantine or reject failures? This is more useful than a screenshot showing that a DNS record exists.

What to verify: the records, who monitors reports and whether enforcement has been tested with legitimate mail.

8. Restore something from backup

A backup notification is not a restoration test. Check which files and systems are covered, how far back you can recover and who can delete the backups.

Restore a sample into a separate, safe location. Do not delete live business data to test the process. For a website or application, ask the maintainer to test enough of its dependencies to establish that the service can run again.

Use the NCSC's backup guidance for small organisations. A backup accessible with the same compromised credentials can be vulnerable too. Cloud synchronisation and recoverable, protected backups are not automatically the same thing.

Make the test relevant to the business. Restoring a photograph proves less about your ability to recover an online shop than restoring its data and checking that the shop can operate in an isolated test environment. The right test depends on the service; your maintainer should explain what was and was not demonstrated.

Record the date, which data was restored, where it was restored and whether it could be opened or used. Also agree how much recent work the business could afford to lose and how long the affected service could be unavailable. These decisions inform backup frequency and recovery arrangements; a generic schedule cannot make them for you.

Keep recovery credentials separately protected. A backup that requires the same unavailable email account to recover access may fail exactly when it is needed.

What to verify: a recent successful restore, the scope of that test and protected recovery access. Backups can help you recover; they do not stop stolen information being disclosed.

9. Decide who notices and who responds

A warning has little value if it arrives in an unmonitored mailbox. Establish who receives alerts for important accounts, protective software and backup failures, and who covers that person when they are away.

Ask your IT provider which useful alerts the current services support. Examples to discuss include unexpected changes to administrator roles, unusual sign-in activity and changes to application access. Availability and detail vary by service and subscription; do not assume every alert exists.

Keep an incident contact list accessible if normal email is unavailable. Include your IT provider, essential service providers and, where applicable, your insurer. Agree who can authorise containment, speak to customers and coordinate recovery.

Walk through a simple scenario together: the business email account appears compromised. Who is contacted from a trusted device? How do you avoid sending the recovery discussion through that mailbox? Who can preserve useful logs and review connected applications?

If an incident is suspected, follow the NCSC's response and recovery guidance and obtain appropriate help. Do not wipe devices or delete evidence in a rush to make the warning disappear. If a fraudulent payment may have been made, contact the bank promptly through its known official route.

What to verify: the alert recipient, an escalation contact, an accessible response plan and one discussed scenario. This is about being able to act, not producing a document nobody can find.

10. Check the suppliers and partners with a route into your systems

External help can be valuable, but ownership must remain clear. List suppliers who administer systems, hold important data or operate integrations for the business. Start with your IT provider, web developer, hosting services and any contractor with significant access.

For each relationship, establish:

• What systems or information can they reach, and why?
• Who in your business approves that access?
• Who handles security updates, backups and incident notification?
• How is access removed and knowledge handed over when the work ends?

Use named accounts and the minimum access the work requires where the service supports them. If a supplier proposes sharing one administrator password among several people, ask for a more accountable arrangement.

A certificate, sales statement or familiar logo does not answer every question about how your particular service is managed. Ask for responsibilities and limitations in terms you can use. Avoid assuming that maintenance, recovery or out-of-hours response is included in an agreement that only covers the build.

For technology startups, also consider what is shared with prospective investors, research collaborators and commercial partners before a relationship is established. MI5's warning concerns valuable innovation as well as computer access. Confirm who you are dealing with, limit early disclosures appropriately and involve relevant professional advisers where the technology or relationship warrants it.

What to verify: an owner, a purpose for access, agreed maintenance/recovery responsibilities and an exit arrangement. You need a relationship you can manage, not a claim that a supplier can never have an incident.

Common small-business security questions

What is the first account we should secure?

Start with business email and other accounts that can reset access or control essential services. Confirm ownership, strong authentication and recovery. Then work through finance, domains, hosting, data storage and the systems specific to your business.

Is a password manager safe to use?

A reputable manager is a practical way to create and use unique passwords. Protect the vault, its recovery route and the devices that access it. Choose sharing and administration features appropriate to your team. Free pricing alone does not make a manager unsafe.

Are passkeys the same as a code sent to my phone?

No. Passkeys use key-based authentication linked to the service, rather than a reusable password or a code you copy into a page. Properly configured passkeys and FIDO2 keys can provide phishing resistance. Account recovery and device security still matter.

Does cloud storage mean we already have a backup?

Not necessarily. Check the service's version history, retention, deletion protections and restoration process. Synchronising a change across devices is different from proving that the business can recover a previous, usable copy after an incident.

Do we need to buy another security product?

Not as the first step. Establish what is already included, whether it is enabled and who maintains it. Missing ownership or ignored updates are not fixed merely by adding another subscription. Buy additional protection when a clear requirement justifies it.

Is this enough for a startup handling sensitive technology?

These are baseline checks, not a complete assessment of targeted espionage risk. A business developing sensitive technology or working in a critical supply chain should seek advice suited to its exposure, including people, partnerships and physical access.

Turn the checklist into assigned work

For each item, record verified, needs work or unknown. Add an owner and the next action. Keep passwords, recovery codes and confidential system details out of the shared checklist.

Fix a clear missing protection; investigate an uncertain one. Do not buy another tool simply to avoid finding out who already maintains the first.

If ownership is unclear, our company digital setup checklist covers the foundations. For connected tools, use the automation maintenance checklist to agree responsibility after launch.

Small teams need checks they can carry out, evidence they can understand and help where the changes are risky. Start with the account that matters most to the business and work through the gaps.

Keep the review alive when people join or leave, a supplier changes, or a new tool is connected. A clear owner and a dated next action make the checklist useful after the initial tidy-up.