How to Protect Against Cyber Threats

A cyber threat is any attempt to steal, damage, lock, or misuse your data and systems. That covers a wide range:

• Social attacks. Phishing emails, fake phone calls, SMS scams, and deepfake video calls that trick a person into giving access.
• Malicious software. Ransomware, spyware, keyloggers, and infostealers that quietly collect passwords.
• Technical attacks. Exploiting a bug in software you never patched, or an exposed database with no password.
• Access abuse. Stolen logins, forgotten admin accounts, and staff who kept access after they left.
• Supply chain attacks. Someone breaks into your vendor, then uses that trust to reach you.
• Internal mistakes. Data sent to the wrong person, a public storage bucket, an API key pasted into a public repository.

Notice how many of these have nothing to do with hacking skill. That is the point.

If your security plan was written three years ago, it is probably still aimed at the wrong things. Here is what the two most widely read industry reports found this year.

From the IBM Cost of a Data Breach Report 2026 (released 29 July 2026, based on 602 breached organisations):

• The global average cost of a breach reached about $4.99 million, roughly a 12 percent rise and a record for the report.
• In the United States the average was around $11.5 million, more than double the global figure.
• Roughly one in four malicious breaches involved AI on the attacker side, up about 56 percent year over year. These AI-enabled breaches cost an average of approximately $6 million, about $1 million more than the global average of $4.99 million.
• The average time to find and contain a breach rose to about 247 days, which reversed five straight years of improvement.

From the Verizon Data Breach Investigations Report 2026, which analysed more than 22,000 data breaches and over 31,000 security incidents:

• The human element appeared in about 62 percent of breaches, slightly up from 60 percent the year before.
• Exploitation of vulnerabilities accounted for 31% of breaches, overtaking stolen credentials as the leading initial access vector in Verizon's 2026 DBIR.
• Third party compromise showed up in roughly 48 percent of breaches, a large jump on the previous year.
• Verizon reported that organisations fully remediated approximately 26% of vulnerabilities in CISA's Known Exploited Vulnerabilities (KEV) catalogue, according to its 2026 DBIR.

Please verify these figures against the original IBM and Verizon reports before you quote them in a board pack. Numbers get repeated online with small errors, and the two reports use different definitions and different time windows.

Two things stand out. Attackers are using AI to scale up old tricks rather than invent new ones, and patching has quietly become the weakest link for most companies.

1. Phishing, and its louder cousins

Email phishing still works, but the growth is in voice and SMS. Attackers call, sound convincing, and ask for a code. Deepfake audio has made this much easier for them. Very few companies run simulations for phone-based attacks, which is exactly why it works.

2. Ransomware

Files get encrypted, then a demand arrives. The newer version is worse: attackers copy your data first and threaten to publish it, so backups alone no longer end the problem.

3. Unpatched software

The dull one that now leads the charts. A public bug is disclosed, an exploit appears within days, and automated scanners find every server still running the old version.

4. Stolen or reused passwords

Infostealer malware collects saved browser passwords by the million. If your team reuses passwords across services and MFA is off, one leaked password is enough.

5. Third party and supply chain risk

Your vendor gets breached, and the access token they hold for your system does the rest. Compromised integration tokens can allow attackers to access connected SaaS platforms. An annual vendor questionnaire does not cover this.

6. Insider mistakes

No malice required. A misconfigured storage bucket, a spreadsheet emailed to the wrong client, a repository made public for five minutes.

7. Shadow AI

Staff pasting source code, contracts, or customer records into AI tools nobody approved. It rarely feels like a security event at the time. It is one.

Step 1: Turn on multifactor authentication everywhere

Start with email, cloud consoles, finance systems, and admin panels. Prefer phishing resistant methods like security keys or passkeys over SMS codes, because SMS can be intercepted and codes can be talked out of people. This is still the highest value hour you will spend on security.

Step 2: Patch on a schedule, not when you remember

Given that exploiting known bugs is now the most common way in, this matters more than it used to.

• Keep an inventory of every server, app, and library you run.
• Assign a named owner to each one.
• Patch critical issues within days, not quarters.
• Watch your dependencies too, not just the operating system.

Step 3: Give people the least access they need

Most staff do not need admin rights. Most integrations do not need full account access.

• Remove access the same day someone leaves.
• Review admin accounts every quarter.
• Delete old service accounts nobody remembers creating.

Step 4: Back up using the 3 2 1 rule, and test restores

Keep three copies of important data, on two different types of storage, with one copy offline or in a separate account attackers cannot reach with your normal credentials.

Then restore something. A backup you have never tested is a hope, not a plan. We have watched a client discover during a live incident that their nightly backup had been failing silently for eleven weeks.

Step 5: Train people for phone and text scams, not just email

Annual click through training is no longer enough. Cover:

• Voice calls asking for MFA codes or urgent payments.
• SMS links pretending to be delivery or bank alerts.
• Video calls where the face and voice look right but the request does not.
• A simple rule: any payment or access change gets verified on a second channel, always.

Step 6: Lock down your email domain

Set up SPF, DKIM, and DMARC so attackers cannot easily send email that looks like it came from your domain. Move DMARC to a quarantine or reject policy after validating legitimate senders and monitoring reports once you have checked your legitimate senders. Add alerts for new inbox forwarding rules, a classic sign of account takeover.

Step 7: Watch your endpoints and cloud

You cannot respond to what you cannot see. Modern endpoint detection flags unusual behaviour rather than just known virus signatures. Turn on logging in your cloud accounts, keep those logs somewhere separate, and set alerts for new admin users, disabled logging, and large data downloads. Assign someone to review alerts and define an escalation process for suspicious activity.

Step 8: Treat vendors as part of your attack surface

• List every third party tool that holds your data or has an integration token.
• Review those tokens and cut the permissions they do not need.
• Put breach notification timelines into contracts.
• Ask vendors what happens to your data if they are breached, before you sign.

Step 9: Write a one page incident response plan

Not a fifty page document nobody reads. One page: who to call, in what order, who can approve shutting systems down, where the backups live, which lawyer and insurer to notify, and what you tell customers. Print it. Systems being down includes the document you stored on the system that is down.

Step 10: Set AI rules before your team sets their own

Decide which AI tools are approved, what data may never be pasted into them, and how AI generated code gets reviewed before it ships. This is a policy problem more than a technical one, and it is far easier to solve now than after a leak.

For a small team with no security staff, this order gives you the most protection for the least effort:

• Day 1: Turn on MFA for email, cloud, and finance systems.
• Day 2: List every system and who owns it. Patch anything critical.
• Day 3: Check your backups exist, then restore one file to prove it.
• Day 4: Remove old accounts and unnecessary admin rights.
• Day 5: Set up SPF, DKIM, and DMARC on your domain.
• Day 6: Write the one page incident plan and share it.
• Day 7: Run a fifteen minute team session on voice and SMS scams.

That is a week of unglamorous work that closes off the routes behind most breaches.

1. Contain the incident; do not wipe affected systems. Disconnect affected machines from the network, but leave them powered on where possible. Evidence lives in memory.
2. Reset access. Rotate passwords, revoke active sessions, and disable suspicious accounts and integration tokens.
3. Call your people. Follow the plan from Step 9. Bring in your IT provider, legal counsel, and cyber insurer early.
4. Write things down. Times, actions, and screenshots. You will need this for insurance and regulators.
5. Do not pay anything yet. Paying a ransom does not guarantee recovery and may carry legal consequences depending on where you operate.
6. Check the backups before you restore. Restoring an infected image simply restarts the incident.

Common security issues in web, cloud, and DevOps environments our team at Meissasoft has taken over from other vendors, the same handful of issues keep appearing:

• Secrets committed to code repositories. API keys and database passwords sitting in commit history, often from years earlier, are still valid.
• Cloud root accounts without MFA. Everything else is locked down, and the one account that can delete the entire environment has a password from 2021.
• Real customer data in staging environments. Same data, weaker protection, wider access, fewer eyes.
• Backups that were never restored. Nobody notices until the day it matters.
• CI/CD pipelines with far too much permission. A build tool that can deploy anywhere is a very attractive target.

None of these need an expensive product to fix. They require regular security reviews, clear ownership, and consistent maintenance.

We build software, so security is part of delivery rather than a separate service we bolt on afterwards. That usually means secure architecture from the first sprint, hardened CI/CD pipelines, and cloud setup and migration with sane access controls, and performance and security testing before anything reaches production.

If you want a second pair of eyes on an existing system, our team is happy to walk through your setup and tell you plainly what we would fix first. You can get in touch here.

What is the single most effective step to protect against cyber threats?

Enabling multifactor authentication across email, cloud, and financial systems. It blocks the large majority of attacks that rely on stolen passwords, and it costs nothing on most platforms. Use security keys or passkeys where you can.

Are small businesses really targeted?

Yes, and often more heavily in proportion to their size. Attackers automate their scanning, so they find whoever is exposed rather than choosing famous names. Ransomware shows up in a far higher share of small business breaches than large enterprise ones. One widely repeated claim, that 60 percent of small businesses close within six months of an attack, traces back to a 2012 era source and is disputed. The real risk is serious enough without it.

How much should we spend on cybersecurity?

There is no fixed percentage that fits every business. A more useful question is what a week of downtime would cost you, and whether your current spending is proportionate to that. The first tier of protection, MFA, patching, backups, and training, is mostly time rather than money.

Is antivirus software enough on its own?

No. Traditional antivirus matches known threats. Many current attacks use legitimate tools and stolen logins, so nothing looks like malware. You need detection based on behaviour, plus logging you actually review.

Does AI make attacks more dangerous?

It makes them cheaper and more convincing. IBM found roughly a quarter of malicious breaches in its 2026 report involved AI on the attacker side, with deepfake and impersonation attacks the largest slice. Verizon's read is that AI mostly scales existing techniques rather than creating new ones. So the defenses do not change much. The tolerance for sloppiness does.

How often should we run security testing?

For most business applications, once a year plus after any major release or infrastructure change. Anything handling payments, health records, or large volumes of personal data should be tested more often, and continuously scanned in between.

Should we pay a ransom?

Treat it as a last resort, with legal advice and your insurer involved. Payment does not guarantee working decryption, does not stop stolen data being published, and may breach sanctions rules in some jurisdictions. Tested backups are what remove the question entirely.

What does zero trust mean in practice?

It means no user or device is trusted just because it is inside your network. Every request is verified, access is limited to what the role needs, and sessions are checked continuously. For a smaller company this looks like MFA everywhere, strict access rules, and network segmentation rather than an expensive platform purchase.

• Most breaches trace back to people, passwords, and patches. Fix those first.
• Unpatched software is now the leading way attackers get in, so patching deserves a named owner and a schedule.
• Backups only count once you have restored them.
• Voice and SMS scams are the fastest growing social attack, and almost nobody trains for them.
• Vendors and integrations are part of your attack surface, whether or not you treat them that way.
• Verify any statistic in this article against the original IBM and Verizon reports before using it in a formal document.

Security is not a project with an end date. It is a habit, and the businesses that come through incidents well are usually the ones that did the boring things consistently.

• IBM and Ponemon Institute, Cost of a Data Breach Report 2026, released 29 July 2026.
• Verizon, Data Breach Investigations Report 2026.