Fact 01
Your backups are failing silently and nobody has tested a full restore in months
The single most common finding we make inside new-client environments is that the backup job runs, a green checkmark appears in the console, and the underlying data is either partially captured, logically corrupt, or locked inside a format nobody has tested restoring from. Software vendors have an interest in the green checkmark. You have an interest in being able to restore last Tuesday's payroll to a clean machine in under two hours. Those are different goals.
The industry-standard framework is the 3-2-1 rule: three copies of your data, on two different media types, with at least one copy stored off-site and ideally immutable (meaning it cannot be altered or deleted by a compromised administrator account or by ransomware). Modern ransomware families actively search for and destroy backup shares before encrypting the primary environment. A snapshot sitting on a network drive mapped to the same domain as the server you are trying to protect is not a backup you can rely on.
What we actually do for clients: we run quarterly restore drills. Not a review of the backup report. An actual restore of a specific file or a specific virtual machine to a clean target, timed, with the recovery point and recovery time objective documented. If the restore fails or takes longer than the business can tolerate, that is a fix-it item, not a talking point. The question we ask every owner is simple: can your team produce last Tuesday's payroll register from backup before lunch tomorrow? If the honest answer is "I do not know," the backup posture is not finished.
- Confirm you have three copies on two media types, one off-site and immutable.
- Run a live restore drill at least quarterly and document elapsed time.
- Verify the backup service account is not domain-joined at administrator level.
- Keep a copy that is truly offline or vendor-held and cannot be reached from a compromised admin workstation.
Insider note: in roughly one out of three incident-response engagements we have handled for non-clients, the backups did not survive the intrusion. That is not a software problem. That is a design problem.
Fact 02
OneDrive and Google Drive are not a backup. They are a sync.
This is the fact that triggers the most arguments in the conference room and the most regret after an incident. Consumer and business file-sync products (OneDrive, SharePoint, Google Drive, Dropbox) replicate whatever happens in the source folder to the cloud within seconds. That is an excellent productivity feature. It is a disastrous recovery story when the source folder is being encrypted by ransomware, or when a well-meaning employee drags the wrong folder into the trash, or when a shared file is accidentally saved over with an empty version at 4:47 p.m. on a Friday.
A true backup is a point-in-time, immutable capture of your data that cannot be mutated by whatever happens to the live copy. Sync is continuous replication of whatever is happening, including deletes and corruption. Both have their place. Confusing them costs small businesses tens of thousands of dollars every year.
What this looks like in practice: the Microsoft 365 tenant almost certainly needs a third-party backup product layered on top. Built-in retention is narrow, version history is bounded, litigation hold is a different feature entirely, and Microsoft is explicit in its own shared-responsibility documentation that customer data recovery is the customer's responsibility. Same story for Google Workspace. The business needs a separate backup that captures mailboxes, OneDrive and SharePoint libraries, Teams chat history, calendars, and public folders with a 90-day to multi-year retention window and an immutable vault.
Insider note: we have walked three Triangle-area clients through the same painful realization in the last twelve months. Their OneDrive "backup" was sync. The ransomware encrypted the local copy, the encryption propagated to OneDrive, and the 30-day version history was not long enough because the user did not discover the damage until the 41st day. A proper backup would have captured a clean pre-encryption copy they could restore from.
Fact 03
Your cyber insurance policy is a liability until you read the conditions you signed up for
Cyber insurance renewed quietly for most businesses between 2022 and 2024. Premiums went up, coverage got narrower, and the application questionnaires got longer. What most owners and CFOs did not notice is that the policy now contains specific control requirements that are treated as warranties or conditions precedent. That is not paperwork. That is a claim-denial lever the carrier can pull when something goes wrong.
Common conditions we see in SMB cyber policies right now: multi-factor authentication on all remote access and privileged accounts, endpoint detection and response deployed to every endpoint (not legacy signature antivirus), tested immutable backups, regular patching on a defined cadence, security awareness training for every user, and email security with anti-phishing and impersonation protection. If you attested to these on the application and they were not actually deployed, or deployment lapsed mid-term, the carrier has grounds to reduce or deny a claim.
What we do with clients: we read the policy alongside the insured, map every condition to a specific technical control, and document evidence that the control is running. Screenshots, policy exports, MFA enforcement reports, EDR agent-health dashboards, backup restore logs. That package goes in a folder that is available to the broker and the carrier if a claim ever needs to be filed. We have watched claims get paid smoothly when the evidence was ready, and we have watched claims get argued for months when it was not.
- Pull the current cyber policy and highlight every "Insured warrants" or "It is a condition of coverage" clause.
- Map each clause to a specific control and capture evidence it is running.
- Re-verify evidence at policy renewal, not the day after a breach.
- Put the evidence package somewhere your broker can produce it in under an hour.
Fact 04
HIPAA does not give you a safe harbor for encrypted data in most real scenarios
Many SMB covered entities and business associates operate under the belief that encrypting data at rest and in transit is a safe harbor from the HIPAA breach-notification rule. That is an oversimplification that costs practices reputation and money when a real incident lands. The HHS guidance on "unsecured PHI" is specific about what qualifies: encryption or destruction that meets the NIST-specified process for that data state, including key management that excludes the attacker. Encryption that the attacker has the key to, because they compromised a privileged account or an application password, is not the same thing as the safe-harbor exception. Encryption that meets the spec at rest but not in transit at the moment of exfiltration is not either.
In practice, the scenarios where encryption actually removes the breach-notification obligation are narrower than the marketing copy suggests: a lost or stolen encrypted laptop with no associated credential disclosure, an encrypted storage array physically removed without its authentication chain, encrypted backups stolen without the encryption keys. The more common scenarios, ransomware via compromised admin account, phishing plus session-cookie theft, business-email-compromise with access to a mailbox that contains ePHI, do not qualify because the attacker had or obtained decryption capability.
For a detailed walk-through of what practices actually need to document and implement under the Security Rule, see our HIPAA compliance services page and the HIPAA services overview. The short version: encryption is necessary, but relying on it as a notification-exemption strategy without documented evidence of the attacker's scope is a bet most practices will lose.
Fact 05
North Carolina's Identity Theft Protection Act adds obligations HIPAA does not cover
Businesses operating in North Carolina have a state-law obligation that applies in addition to any federal framework. The North Carolina Identity Theft Protection Act (General Statutes Chapter 75, Article 2A) covers personal information of NC residents held by any business, not just regulated entities. It defines personal information broadly to include a name plus Social Security number, driver's license number, financial-account number with access credential, or biometric data. A breach affecting this information triggers notification obligations to affected residents and, in some cases, to the NC Attorney General and consumer reporting agencies.
The practical implication is that a Raleigh-area business without any HIPAA exposure, without any defense-contractor CUI exposure, still has a statutory duty to protect employee SSNs, benefits data, and financial-account credentials, and to notify affected people if that data is breached. Payroll, HR, and accounts-payable systems are in scope. Vendor portals that store account numbers are in scope. Old files on a retired server with legacy employee data are in scope.
What owners miss: the statute's notification timeline is "without unreasonable delay," which in practice is interpreted much more strictly than federal frameworks. It also requires the notification to describe what steps the business has taken to remediate. If the remediation story is thin because basic controls were not in place, the regulatory conversation gets harder and the plaintiff's-bar conversation gets easier.
"The single question that separates owners who have their data protection in order from owners who do not is this: if we told you someone just walked out of your office with the domain-admin password, what is the first thing you would restore from and how would you know it was clean? The answer tells you everything."
Craig Petronella, founder · CMMC-RP, CCNA, CWNE, DFE #604180
Fact 06
Your MSP is not necessarily your security provider. Check the contract.
The acronym soup in outsourced IT has meaningful distinctions that most contracts do not make plain. A managed service provider (MSP) is primarily responsible for keeping your environment running: patching, help desk, server and endpoint maintenance, Microsoft 365 administration, backups, connectivity. A managed security service provider (MSSP) adds 24/7 security monitoring, SIEM or log aggregation, incident triage, and vulnerability management. A managed detection and response (MDR) provider goes further: active threat hunting, containment on the client's behalf, and direct response authority when something is detected.
Many SMBs buy an MSP, assume they are getting an MSSP, and discover during an incident that the MSP contract explicitly excluded SOC coverage, threat hunting, and incident response. The MSP is then in the awkward position of helping clean up something that was not their job. We have watched that dynamic play out multiple times, and the owner is always surprised.
Practical recommendation: pull your current MSP contract and look for the words "security monitoring," "SOC," "SIEM," "incident response," "threat hunting," and "breach response." If those are absent or heavily qualified (for example, "as-needed at prevailing hourly rates"), you have an MSP, not an MSSP. That may still be the right choice for your business, but it needs to be a conscious choice with security coverage added somewhere, not an assumption. Our managed IT services overview and cybersecurity services overview describe exactly which layer of the stack each engagement covers.
Fact 07
CMMC is not just for defense primes. It flows downhill to subcontractors of subcontractors.
The Cybersecurity Maturity Model Certification framework published by the Department of Defense does not stop at the large prime contractor. If your business handles Federal Contract Information or Controlled Unclassified Information, whether directly or as a subcontractor to a subcontractor three layers up, you are in scope. Level 1 (FCI handlers) and Level 2 (CUI handlers) both impose specific controls. Level 2 requires 110 specific practices drawn from NIST SP 800-171, and a certified C3PAO assessment for most organizations handling CUI under contracts above certain thresholds.
The practical trap we see in the Triangle is businesses that support construction, engineering, manufacturing, or IT services firms that work with the Department of Defense, who never had the contracting conversation about flow-down clauses. A $40,000 subcontract to provide cabinetry fabrication for a Navy facility can include a DFARS 7012 clause that requires the subcontractor to implement NIST 800-171 controls. When the prime starts asking for CMMC evidence in the renewal, the subcontractor has to choose between absorbing a significant remediation cost and losing the renewal.
Petronella Technology Group is a CMMC-AB Registered Provider Organization (RPO #1449, verified at cyberab.org), and every member of our delivery team holds the CMMC-RP credential. Our CMMC compliance guide walks through the 110 controls and how they map to a realistic 9-to-18-month readiness program for a small business. The conversation is easier when it starts before the prime's renewal pressure, not after.
Fact 08
Supply-chain compromise is the single biggest unpatched attack surface for most SMBs
Individual software vendors can be hardened. The collection of third-party tools, plugins, and software updates feeding into a typical business environment cannot be hardened the same way. The SolarWinds Orion incident (2020) compromised thousands of organizations through a trusted software update. The 3CX desktop client incident (2023) did the same to a business phone platform. The Kaseya VSA incident (2021) used a managed-services platform to push ransomware to hundreds of MSP customers. The CCleaner incident (2017) proved the pattern on consumer utilities.
The common thread is that the victim organizations had done nothing wrong. They had patched promptly, followed vendor guidance, deployed the tools the way the vendors intended. The attack came through the trusted channel itself. That reality changes the recommendation: it is no longer sufficient to assume that a signed installer from a legitimate vendor is safe. You need to assume that any third-party component can be a delivery vector, and design the environment so that a compromise of any single vendor is containable.
What that looks like: application allow-listing on servers and high-value endpoints, EDR with behavioral detection that flags unusual parent-child process relationships, segmentation between the business LAN and the operational systems that matter most, limited use of remote-monitoring-and-management tools on the client network (or scoped visibility into which tools your MSP uses), and an incident runbook that addresses "your MSP itself is the breach vector." That last one is uncomfortable to write and necessary to have.
Fact 09
SMS-based multi-factor authentication is deprecated and attackers have known for years
The National Institute of Standards and Technology's Digital Identity Guidelines (SP 800-63B) have flagged SMS as a restricted authentication factor since 2017. The reason is straightforward: the short message service was never designed as a security channel. SIM swapping, SS7 signaling exploitation, malicious carrier-portal insiders, and phishing of MFA codes through real-time proxy sites have all been demonstrated repeatedly. We have handled SIM-swap incidents for Triangle-area clients where the attacker obtained control of the victim's mobile number, intercepted the SMS code, and moved significant funds out of a commercial banking account in under 40 minutes.
The better defaults are phishing-resistant authentication methods: FIDO2 security keys (such as YubiKey), platform authenticators like Windows Hello or Apple's passkey implementations, and, where keys are impractical, authenticator apps with number matching. These are resistant to real-time proxy phishing and to SIM swap. They are also a direct fit for most cyber-insurance conditions and for CMMC Level 2 identification-and-authentication controls.
The rollout is not free and it is not instantaneous. It usually requires a phased approach: privileged accounts and finance-related accounts first, critical SaaS applications second, the broader user base third. What it cannot be anymore is "everyone gets a text message and we call that MFA." That is not the bar any more, for SMB or enterprise.
Fact 10
Your team is storing PHI and PII in Slack, Teams, and SMS without telling compliance
Shadow data is regulated data that has moved into tools nobody planned for. It shows up in Slack DMs where a nurse asked a colleague about a patient's medication list. It shows up in Teams chat where an HR coordinator shared an SSN screenshot to work through a payroll issue. It shows up in personal email forwards where a salesperson sent themselves a client contract to finish at home. It shows up in text messages between partners discussing a case. Every one of those locations is a data repository that the business now has an obligation to account for.
Microsoft 365 and Google Workspace offer data-loss-prevention tools that can detect patterns like SSNs, credit-card numbers, and common PHI patterns in chat and email. They require actual configuration to work. Out-of-the-box tenant settings do not catch most of this. And enforcement is harder than detection: telling a user that they cannot send the message they are about to send, or quarantining the message for review, is a policy-and-change-management problem, not only a technical one.
The practical first step: run a data-classification discovery pass across the tenant, find out where regulated data is actually living, and decide which of those locations need DLP rules, retention adjustments, or user training. The volume of findings surprises almost everyone. The common response is to write a one-page policy that matches what people are actually doing, and to put light guardrails around the habits that matter most (SSN handling, patient identifiers, wire-transfer instructions).
Fact 11
Office 365 retention is not a legal hold, and neither is the recycle bin
When a dispute arises, a subpoena is served, or a regulatory investigation opens, the business has a duty to preserve potentially relevant information. That obligation goes beyond normal retention: it requires suspending automated deletion, holding mailboxes in place even if the employee leaves, and being able to produce a defensible record of what was preserved, when, and how. Microsoft 365 offers specific tools for this (Litigation Hold, In-Place Hold, Purview eDiscovery Premium), and they are not turned on by default. Retention policies and recycle bins do not satisfy a legal hold.
The pattern we see: an HR matter escalates, general counsel issues a hold memo, IT implements a policy they think will meet the requirement, and a deposition a year later reveals that certain chat messages or Teams channels were deleted because the hold did not cover them. That is a discovery sanction the business cannot negotiate away. It is also a reputation problem during the deposition itself.
Before litigation ever arrives: map the business's communication surfaces (email, Teams, OneDrive, SharePoint, Slack if applicable, and any SMS channels in use), document which tool's hold capability applies to which surface, and write a short legal-hold runbook that counsel can execute in under an hour. That runbook is much cheaper to produce in quiet times than during the week the hold memo actually arrives. For incident-preservation forensics, see our data-breach forensics services, which covers chain-of-custody work when preservation needs to meet evidentiary standards.
Fact 12
Quarterly security awareness training is the floor. The real program runs every week.
The compliance frameworks all converge on a minimum cadence: annual training at onboarding, plus periodic refreshers, typically quarterly. That is the bar for an auditor to tick the box. It is nowhere near the bar for actually changing user behavior. The attacker cadence is continuous. The email threat landscape shifts monthly as new phishing kits and brand-impersonation templates appear. Business-email-compromise tactics evolve in real time. A user who last thought about security in December is not going to recognize the April wire-fraud attempt.
What a practical program looks like: short, frequent touchpoints (three-to-five-minute videos monthly, not 45-minute courses quarterly), simulated phishing tests with immediate teachable-moment debriefs for users who click, separate onboarding modules covering the tools and data this specific role will encounter, and an off-boarding checklist that addresses mobile devices, personal accounts holding company data, and access revocation on day one. It also includes executive-level briefings for the CEO, CFO, and controller, since those roles are disproportionately targeted.
The honest truth: we still see plenty of SMB clients where the only awareness training is the computer-based course HR assigns during onboarding, never repeated. Those clients have higher click-through rates on simulated phishing, higher rates of social-engineering calls that succeed, and a longer recovery arc when something bad happens. The fix is modest in cost and large in outcome.
