LIT Technology Solutions

Your cyber insurance might not pay out. Insurers now require MFA, real endpoint protection, tested backups, and security training, and if you claimed to have them but didn't, they can deny the claim. Read your policy's conditions now, not after an attack.

Anyone can send an email that looks like it's from your company. Three DNS records stop it: SPF, DKIM, and DMARC. The catch is DMARC is often set to 'monitor only,' which watches spoofing happen without blocking it. Ask your IT provider: is ours set to reject, or just none?

Many ransomware groups delete your backups before they lock your files, so paying becomes the only way out. Keep one backup copy offline with its own login, separate from your admin password, and test a restore this month. If you've never tried it, you don't know it works.

INC Ransomware Emerges as Major RaaS Threat in 2026 with 830+ Victims Since 2023 INC Ransomware Emerges as Major RaaS Threat in 2026 with 830+ Victims Since 2023 | Read more hacking news on The Hacker News cybersecurity news website and learn how to protect against cyberattacks and software vulnerabilities.

Your team is using AI right now, whether you have a policy on it or not.

ChatGPT, Gemini, Copilot, Claude, and a dozen niche business tools are in the workflow of someone in your business this week. These tools learn from what you type, sometimes retain it for training, and live outside whatever data security setup you've built for the rest of the business.

Without a written policy, you have no way to know what client data is being pasted into prompts, which business decisions are being made with AI assistance, or how your insurance views any of it if something goes wrong.

An AI Acceptable Use Policy doesn't have to be 30 pages. A one-page version covers the essentials: which tools are approved, what data is forbidden as input, what disclosure rules apply to AI-generated work, and who reviews AI output before it goes to a client.

If you want a full AI Acceptable Use Policy template to implement in your business, comment below with "AI Policy" and we'll send it to you.

Smishing is text message phishing, and it's now more effective at reaching people than email phishing.

The reason is mechanical. Most businesses spent the last decade hardening their email gateways and training people on suspicious links. Almost nobody applied the same effort to text messages. The result is a channel where employees still tap first and think later.

The patterns repeat: a "delivery failed" message with a link asking for login credentials, a "this is your CEO" text from a number nobody recognizes asking for gift cards or a wire, a fake account-lockout message that looks identical to a real bank alert, and a "hey, I'm in a meeting, can you help me with something quick?" text impersonating a senior person.

These work because texts feel personal in a way email doesn't. They land on the same screen where your spouse, your kids, and your coworkers reach you, which makes the brain default to trusting them. That's the entire attack.

The rules to give your team:

1. No business decision happens over text. That includes wire transfers, vendor changes, payroll changes, gift card requests, and password resets.
2. If a text claims to be from a coworker, verify through a different channel before responding. A 30-second Slack message or phone call kills most of these attacks.
3. Never click a login link inside a text. Open the app or website directly.
4. Forward suspected smishing to 7726 (which spells SPAM on a phone keypad). Carriers use it to block the source.

Smishing works when the response happens before the thinking. Train your team to slow down, and most of these attacks dead-end before the attacker has time to react.

Your salesperson stops at a coffee shop between meetings. They set up at a table, open their laptop, order a drink, and walk back to the counter when their name is called. The laptop is unattended for 90 seconds. That's enough time for someone to ruin your business week.

The attacker doesn't need to be sophisticated. A $40 USB device called a "Rubber Ducky" plugs in and looks like a keyboard to the computer. It runs pre-loaded keystrokes faster than any human can type. In 90 seconds it can open a terminal, download a remote access tool, install it, and disable the screen lock notification, all without a click from your salesperson.

When your salesperson comes back to the table, the laptop looks the same as they left it. The next time they connect to your office network, the attacker has a path in.

This kind of attack has been demonstrated at every major security conference for the last 10 years. The hardware is cheaper now than it was then.

The defense is straightforward.

- Set every laptop to lock automatically after 30 seconds of inactivity, and train your team that any unattended laptop gets locked first.
- Disable USB device auto-execute across your fleet. On Windows, that's the "AutoPlay" setting plus USB device blocking in Group Policy or Intune.
- Use endpoint detection and response (EDR) software that flags new processes, persistence mechanisms, and suspicious network connections within seconds of installation.
- For people who travel often, give them USB data blockers (small adapters that allow charging but block data transfer) for airports and coffee shops.

Physical security still matters even though most of your defenses sit in software. Don't let the five steps from your laptop to the counter at the coffee shop be the weakest part.

On May 19, 2026, Google Cloud's automated abuse-detection system incorrectly suspended Railway, one of its largest customers. The decision took Railway's entire platform offline for eight hours and pulled thousands of small businesses down with it.

Railway is a platform other businesses use to run their applications. Their production environment lives on Google Cloud, where Railway spends more than $10 million a year. That spend didn't matter when an automated system decided the account looked suspicious. The suspension happened instantly. Railway waited about an hour for a human at Google to respond, and the total outage ran around eight hours. For Railway's customers, that meant unreachable apps for a full workday with no warning and no path to escalate.

This matters to your business even if you've never heard of Railway. Your business depends on services you don't control and run on platforms you don't manage. Most of those platforms reserve the right to override their own SLAs when an automated system flags your account or your vendor's account. A cloud provider's automated decision can take you down as fast as a hacker can, and you have less recourse.

The work to do this month is in three pieces. Start with a dependency map. Each SaaS tool your business depends on (QuickBooks, HubSpot, payroll, CRM, file storage) runs on a cloud platform somewhere, and you need to know which.

With that map, identify which workflows have a manual fallback. Can you take orders without your CRM for a day? Can you process payments without your usual processor? The answer might be no, but knowing now is better than discovering it during an outage.

Last, read the SLA for the services you depend on. Most cloud SLAs include carve-outs for "automated abuse detection" and similar events. The recourse, even when the provider is at fault, is usually a service credit on your next bill, not the cost of your lost workday.

Cloud providers fail by accident and by their own systems making wrong calls. Your business should be able to function for at least a workday without any one of them.

Google Cloud suspended major customer Railway.com without cause, causing outage This is the service we get when we spend $10m plus? asks automated code deployment outfit

When an employee leaves your business, the security gap is usually bigger than you'd guess.

A typical 25-person business has dozens of cloud accounts per employee.

Email, payroll, file storage, CRM, accounting, internal tools, and third-party SaaS subscriptions.

When the employee leaves, every one of those accounts should be disabled, but in most businesses only the obvious ones (email, computer login) get touched.

The rest sit dormant for months or years, still with the employee's credentials, still accessible if those credentials were ever leaked in a breach.

That's how a fired employee from 18 months ago becomes the entry point for next year's breach.

The fix is a written offboarding checklist that includes every account, not just the obvious ones.

- Day of departure: disable email, computer login, VPN, and any single-sign-on (SSO) accounts that gate everything else.
- Within 48 hours: revoke access on every SaaS tool by checking the actual admin panel of each.
- Within 7 days: change shared credentials the employee knew
- Within 30 days: do a "did we miss anything" review with someone who worked closely with the employee.

Without a checklist, "what did this person have access to?" is impossible to answer in a few months.

On May 7, 2026, an Amazon Web Services data center overheated and took out an entire availability zone in US-East-1, AWS's most popular region. Several core AWS services went down, and any business application hosted in that zone was unreachable for hours.

Cloud outages happen to every major provider, not just AWS. Azure, Google Cloud, Cloudflare, Microsoft 365, Salesforce, and Slack have all gone down long enough to break a business day in the last three years.

If your business loses meaningful money during downtime, you need a "the cloud is down" plan. The plan has three parts.

A dependency map. Every critical workflow in your business should be mapped to the SaaS or cloud service it depends on. Your accountant uses QuickBooks Online, which runs on AWS. Your sales team uses HubSpot, which also runs on AWS. Your phones might be VoIP, which depends on a carrier you've never named. The map doesn't need to be pretty, but it does need to exist.

An out-of-band communications path. Phone numbers for your key vendors, your insurance broker, your IT provider, and a contact for every team lead. This list lives on paper or on a phone that doesn't depend on your office network. Use the same list from your incident response plan.

A decision tree for what stops and what continues. Some work has to keep happening even when systems are down (taking orders, handling client emergencies). Other work can wait. Pre-decide which is which, so that conversation isn't happening for the first time during an outage.

Test the plan once a year. Turn off access to one major SaaS tool for an afternoon and watch what your team does. Whatever you learn from the dry run is cheaper than learning it for real.

The AWS outage explained: What happened, who was impacted, and what services are back online? Overheating at a single data center has been identified as the cause of the AWS outage, which impacted customers such as Coinbase

The quarterly review with your IT provider is one of the most useful meetings on your calendar, but it's easy to let it run on autopilot. Walk in with six real questions and you turn it from a status update into a strategic check-in.

Six to ask at your next review:

1. What changed in our security posture since last quarter? Not "what did you do." What CHANGED. The answer should reference specific risks reduced.
2. Which CISA Known Exploited Vulnerabilities are still unpatched in our environment, and why?
3. When did we last test our backup restore on a real workload, and what did the test show?
4. How many user accounts have privileged or admin access, and is that list smaller than it was last quarter?
5. What incidents (security events, near-misses, alerts) did we have this quarter that I didn't hear about, and why didn't I hear about them?
6. If we were hit by ransomware tonight, what's our realistic Recovery Time Objective for the most important systems?

If your IT provider can answer all six with specifics, they're operating at the standard you're paying for. Hedging or "let me get back to you" on more than one is information worth acting on.