The good news: small practices don’t need to outrun the bear. They just need to be harder to penetrate than the practice down the street.
Attackers are opportunistic. Most ransomware groups run automated scanning that flags easy targets — unpatched VPNs, legacy protocols left exposed, admin accounts without MFA. Solid MFA, current patches, and offline backups will stop a large percentage of the automated attacks before they ever become incidents.
The sophisticated operators — the ones who do hands-on intrusion, move laterally, and exfiltrate data over weeks — are typically targeting larger organizations with deeper pockets and more valuable data. A regional medical practice, a local accounting firm, a construction company with $10M in annual revenue: these aren’t their primary targets.
That doesn’t mean small businesses are safe. It means the bar is different. You’re not defending against nation-state APT groups. You’re defending against automated toolkits, opportunistic ransomware operators, and the occasional targeted attack that lands in your inbox.
**Multi-factor authentication on everything.** Every remote access point, every admin console, every cloud service. This alone stops the majority of automated attacks. If your VPN doesn’t support MFA, replace the VPN.
**Patch management that actually runs.** Not “we try to patch within 30 days.” Automated patching for endpoints, and a documented process for critical infrastructure patches within 72 hours. Most exploited vulnerabilities in recent attacks were known and patched months before the incidents happened.
**Offline backups, and test them.** Ransomware operators know backups. They target them. Your backup strategy needs to assume that your online backups will be compromised alongside the primary systems. One offline copy, tested quarterly, with a documented restore procedure.
The goal isn’t perfection. It’s making your practice harder to compromise than the one down the street. Attackers aren’t making emotional decisions — they’re running economics. The time and cost to breach your network versus the likely payoff.
When you harden your environment, you move yourself off the automated target list and into the “too much work for too little return” category. That’s a winning security strategy for a small organization.
You don’t need a massive security budget. You need the right controls, applied consistently, with backups you can actually rely on when it matters.
Most organizations are deploying AI faster than they’re building security controls for it. The result is a growing gap between what AI can do in your environment and what your security team can actually see or defend.
AI security governance is about closing that gap — establishing a structured set of policies, controls, and oversight mechanisms before an incident forces the conversation.
**AI Asset Inventory**
You can’t secure what you don’t know exists. Build a comprehensive catalog of every AI model, AI-enabled tool, and AI-integrated system in your environment. This includes vendor-hosted models your users access through SaaS applications, internal models served via APIs, and anything connected to your data pipelines. Treat this inventory with the same rigor you’d apply to your critical asset list.
**Model Risk Tiering**
Not all AI systems carry the same risk. A model that summarizes internal documents sits in a different risk category than one that makes access control decisions or processes customer PII. Tier your models by consequence: what happens if this model is compromised, poisoned, or leaks data? Use that consequence level to drive controls — higher tier means stricter access controls, more logging, and more frequent evaluation.
**Input and Output Monitoring**
AI systems are an attack surface through their inputs and outputs. Monitor for adversarial inputs — prompt injection attempts, malformed requests designed to bypass safeguards, or data that signals reconnaissance against your AI infrastructure. Log AI outputs with enough context to support forensic investigation if something goes wrong. This is also where you catch model behavior drift that might indicate tampering.
**Incident Response for AI-Specific Breaches**
Your existing IR playbook probably doesn’t cover what happens when a threat actor manipulates a model’s behavior, steals training data, or uses your AI system as an attack vector against other targets. Build AI-specific scenarios into your tabletop exercises. Define escalation paths, containment steps, and communication protocols for AI incidents before they happen.
MITRE ATLAS — the Adversarial Threat Landscape for Artificial-Intelligence Systems — documents the specific techniques adversaries use against AI systems. Once you have your AI inventory and risk tiers, you can map your existing controls against ATLAS techniques most relevant to your environment. Gaps in coverage become your priority remediation list.
You don’t need to build all four pillars at once. Start with inventory and tiering — those two steps alone give your team enough visibility to have an honest conversation about AI risk. From there, add monitoring where the consequence of an incident is highest, and build the IR playbook as a distinct workstream.
The organizations that will be in the best position two years from now are the ones that started building governance structures today. Not perfect structures — just functional ones, with enough foundation to grow as the threat landscape evolves.
If you’ve heard of MITRE ATT&CK, you already know the basic idea: a curated knowledge base of adversary tactics and techniques, built from real-world observations. ATLAS is the same concept, purpose-built for AI systems.
ATLAS stands for Adversarial Threat Landscape for Artificial-Intelligence Systems. It documents the techniques threat actors use to attack AI models, exploit AI-integrated systems, and steal or manipulate AI outputs. The framework is organized around three core areas: ML pipeline attacks, AI model exploitation, and the exfiltration or manipulation of AI-generated content.
The need for this is real and growing. Security teams built entire programs around traditional infrastructure — endpoints, networks, identities. Then came the AI pivot, and suddenly there are new attack surfaces that most teams don’t have mapped, monitored, or defended.
The framework organizes threats into categories that map to the AI lifecycle: from reconnaissance on ML infrastructure to initial access through model APIs, through privilege escalation via compromised training pipelines, all the way to impact techniques like model corruption or adversarial output generation.
What makes it distinct from standard threat frameworks is the focus on the unique properties of AI systems — things like prompt injection, training data poisoning, model inversion, and the abuse of model APIs as an attack vector. These don’t map cleanly to traditional MITRE ATT&CK techniques.
Real threat actors are already active in this space. Forest Blizzard, a Russian state-sponsored group, has been documented using generative AI for target research. Aquatic, associated with Chinese state interests, has targeted ML development environments. These aren’t theoretical attacks.
The gap between AI deployment and AI security readiness is wide. Most organizations have AI systems in production — whether internal copilots, customer-facing chatbots, or integrated SaaS tools with AI components — that security teams don’t have visibility into.
ATLAS gives you a vocabulary and a reference point. You can use it to assess your current AI exposure, map controls against documented adversary techniques, and build detection logic for the most relevant threats in your environment.
The starting point is simpler than it sounds: take inventory of where AI lives in your stack, pick the ATLAS techniques most relevant to those systems, and ask whether you have logging, monitoring, or controls covering those specific attack paths.
You don’t need to become an ML security expert overnight. But the adversaries are already thinking about your AI systems. ATLAS gives you a way to start thinking about them too.