Last year, we were working with producers of a trade show we sponsor to develop thought leadership topics the GBQ Business Technology Solutions (BTS) team could present. Partway through the outline, they stopped us. “Not cyber. Anything but cyber. People are tired of hearing about cyber.”
Fair enough. I am tired of talking about it, too. Even so, it’s still one of the biggest risks a business carries, and part of our role is to serve as your paid paranoids and to flag what we are watching so you can decide what it means for you. The risk is yours to manage, but our job is to make sure you see it coming.
So let us talk about cyber, not because there is a new product to buy, but because the threats have shifted. The most valuable thing a leadership team can do this quarter is verify that the controls it already believes it has are actually in force.
On March 11, 2026, medical device manufacturer Stryker disclosed a cyberattack that disrupted its global internal network. The Iran-linked group Handala claimed responsibility, and the U.S. Department of Justice later attributed the group to Iran’s Ministry of Intelligence and Security. Stryker reported no indication of ransomware or malware. Rather, public reporting indicates the attackers obtained administrator-level access and used the company’s own device management console to issue a mass remote-wipe command, rendering tens of thousands of endpoints unusable within hours. They did not need malware or an unpatched vulnerability. Instead, they used the tools the company also uses to manage its IT.
A Fortune 500 manufacturer with a standing security function took real loss from an attacker who walked in with a working key. Order processing, manufacturing, and shipping were disrupted across dozens of countries, and Stryker reported the incident materially affected its first-quarter results. Much remains unresolved, and the root cause has not been publicly confirmed; attribution rests substantially on Handala’s own claims. And while Stryker was selected is still speculation, the business outcome is not.
This type of example is not confined to companies as big as Stryker, which runs on the same Microsoft stack as most mid-market organizations.
On April 7, 2026, the Federal Bureau of Investigation (FBI), the Cybersecurity and Infrastructure Security Agency (CISA), the Environmental Protection Agency (EPA), and partner agencies issued a joint advisory on Iranian-affiliated actors exploiting internet-connected Programmable Logic Controllers (PLCs) across U.S. critical infrastructure. The statement was updated on July 22 to add affected manufacturers and detection guidance.
According to the report, confirmed victims experienced operational disruption and financial loss, and the access methods are ordinary and include vulnerabilities such as stolen credentials, over-broad administrative rights, and systems reachable from the open internet. Bad actors scan for weak systems and attack what they find, and destruction rather than extortion is the objective. In other words, there is no negotiation and no decryption key. Systems and the data on them are just gone.
Iranian activity draws attention because it is U.S. national news. However, Russia’s campaign has run continuously for four years and does not stay inside the war zone.
On July 13, 2026, nineteen agencies across 13 countries, including CISA, the FBI, and the National Security Agency (NSA), published a joint advisory on Russian Federal Security Service (FSB) Center 16 actors compromising poorly configured network devices worldwide, naming communications, defense industrial base, energy, financial services, state and local government, and healthcare as the sectors most at risk. No zero-day (or unknown flaw in an organization's software or hardware) is required: default community strings on a legacy network management protocol and an eight-year-old router vulnerability are sufficient.
Jaguar Land Rover is the other marker. The 2025 attack halted production for roughly six weeks and, by the Cyber Monitoring Centre’s estimate, cost the U.K. economy £1.9 billion, making the attack the most financially damaging cyber incident in British history. The New York Times reported in June 2026 that investigators traced the intrusion to Russian hackers; whether they acted on state direction, for profit, or somewhere in between remains unresolved.
That ambiguity is deliberate. An attack that could plausibly be a foreign government, an activist group, or a criminal crew lets the state behind it deny involvement and avoid retaliation. It also means the statement: “we’re not a nation-state target” no longer holds.
If your company touches a supply chain or shipping route that matters to a conflict, it can take real damage as collateral in someone else’s fight.
Some of this will cost money. If the basics are not in place, closing the distance takes budget, and pretending otherwise helps no one. But cost is rarely the reason they are missing. After all, Stryker had a global technology team with a security function and still got hit.
The controls that prevent this class of event are already written down. It's in the framework you adopted, the questions your cyber carrier asks at renewal, the client risk questionnaires you complete every year, and the findings from your last risk assessment. The gap is not knowledge. It is execution.
What mid-market organizations lack is not technical awareness but a business structure that decides these controls are required, funds them, and confirms they stay in place. Absent that, decisions get made by default at the administrator level, optimized for daily operational friction rather than for enterprise survivability.
So the ask is narrow. Confirm the basics are there. Not the technical basics, which your team can speak to, but the business basics.
Here at GBQ, we advocate governing risk through a multi-functional risk steering committee with executive membership meeting on a schedule and holding authority to accept or reject risk for the organization. Not the IT department alone. Not a technology status meeting. Everything below is either the committee’s work or the proof it requires.
The committee owns the decisions everything else gets measured against.
Risk appetite.
The control framework the organization will be held to, which is where the technical specifics live.
The disposition of every item on the risk register.
The obligations that bind you (e.g., carrier expectations at renewal, regulatory requirements, client contract terms and market expectations, your own published policies).
Vendor risk.
The scope of independent assurance.
And the formal exceptions granted against all of it, which is where the safeguards that fail in these events usually went.
The following is what your risk steering committee should review, manage, and compile as proof that you are mitigating risk throughout the organization.
Keep two registers: 1) what you run and what data you hold, and 2) which outside parties can act as you inside your environment, under what contractual security obligations and with what audit rights. The second is the one almost nobody maintains.
Proof: Both registers, dated, with the count of outside parties holding privileged access and what changed since the last review, recorded in the minutes.
Privileged access accumulates through role changes, project work, and provider onboarding. It's rarely removed because nobody is asked to have this access removed. The committee should review administrative accounts and the outside parties holding those rights on the same cycle.
Proof: A dated review of every privileged account and third-party administrative grant. Should list who reviewed, what was revoked, and what was retained with a business justification.
Working off those registers: think through what could go wrong, how likely it is that something would go wrong, and what such an incident would cost. Add the question most frameworks skip: who do our customers, contracts, and supply chain make us interesting to, for reasons unrelated to our size?
Proof: The dated assessment, who performed it, and a recorded committee decision on every finding above appetite: accept, mitigate, or transfer, with an owner named.
Nearly everyone scans. Far fewer can show that findings close, how fast, and against the full asset register rather than a scope set years ago and never revisited. Internet-facing systems are named in every advisory above.
Proof: Note the scan coverage against the asset register, open findings by severity and age, and the time-to-remediate trend for internet-facing systems.
A test procured to satisfy a customer questionnaire will not tell you whether one compromised account can destroy the environment. An assumed-breach engagement (start from a compromised standard user, test the path to administrative control) will.
“Testers achieved global administrator” is a technical result; “the same access could render the endpoint estate unusable and reach the backups” is a decision.
Proof: Note the scope leadership approved, the report against it, and each finding closed with an owner and a date.
Detection is worth what someone above the technology team does with it. A monthly view shows whether alert volume is rising, whether the same issue recurs, and whether anything required a business decision without leadership hearing about it.
Proof: Compile a monthly summary of alerts raised, incidents opened and closed, time to detect and respond, and any event requiring a decision outside technology.
One client calls it “don’t do dumb stuff,” which is about right. Initial access in the events detailed earlier came through stolen credentials or social engineering, which makes awareness a control, not an annual chore. The two halves are recognizing the attempt (e.g., the phishing message, the help desk call impersonating an employee, the authentication prompt nobody triggered) and information handling (meaning where data belongs, where it does not, and what may leave the building).
Proof: Document employee-reported suspicious activity trended across periods, with completion by population and simulation results alongside it, and committee time spent on the trend.
A destructive attack is a restoration problem. Are the backups reachable when the identity platform meant to protect them is the thing compromised? Do they sit inside the environment they protect? How long does a full restore take when you run it rather than estimate it? An untested restore is an assumption.
Proof: Keep a dated restoration test naming the systems restored, elapsed time to usable, and variance against the stated Recovery Time Objective (RTO), signed by the business owner of the affected process.
Start with the Business Impact Analysis (BIA). Knowing what a day of downtime costs, process by process, turns resilience into a funded investment with a number attached. Then read what each plan assumes. Most mid-market incident response plans are ransomware plans wearing a broader label: a counterparty, a decryption path, a negotiation, a clock against a payment decision. A destructive attack takes all four away.
Continuity plans fail earlier, stopping at the company’s own walls (e.g., the outsourced payroll provider, the hosted system finance lives in, the single supplier feeding a production line). None are under your control, and any one can halt operations without a company asset being touched. A plan that has never been through a tabletop exercise is a document, not a capability. Exercise the scenario where there is nothing to buy and no one to negotiate with, and the environment has to be rebuilt while the business keeps transacting.
Proof: Maintain a dated exercise report naming the scenario, participants, where decisions stalled, and an owner and due date against each gap, with closure confirmed at a subsequent meeting.
Destructive attacks attributed to state-affiliated actors run straight into war and hostile act exclusions, and carriers have already litigated that ground. An event with no ransom demand, no clear exfiltration claim, and public attribution to a nation-state proxy is where coverage gets contested. Work from the scenario to the policy language, in that order. Read the policy first and imagine what it might cover to produce a more comforting answer than the one you get in a claim.
Applications and renewals also require representations about the controls you operate, and companies discover during that process that a control they attested to is not running as described. That gap is its own coverage problem, independent of any exclusion.
Proof: Have the current policy read against the named scenarios, the broker’s written answer on each, and every control representation in the application reconciled to evidence.
None of this is a technology project. Every item above is a decision about how much authority sits in just a few hands, and how long the company can run without the systems it depends on. Those decisions belong to executive leadership. In most mid-market organizations, they have been delegated by default to whoever administers the environment, and made by people who were never asked to weigh the alternative.
Oversight of this kind is not delegable. Directors and officers owe a duty of oversight that includes knowing what could stop the business and confirming someone is accountable for managing it, satisfied by the questions leadership asks and the evidence it accepts in return, not by a status update reporting that security is handled.
The record is what gets examined. After an incident, the first questions are what leadership knew, when it asked, and what it did with the answer. A board or executive team that never requested the proof described above will have a hard time showing it exercised oversight at all.
GBQ's Business Technology Solutions practice empowers the growth of our clients across six disciplines: risk management, cybersecurity, IT governance, AI and automation, data and analytics, and business systems.
If this article raised questions that you cannot yet answer about your own cybersecurity strategy, the first place to start is with a conversation. GBQ’s cybersecurity advisory services allow us to assess where your organization stands today, prioritize use cases worth your investment, and help build the governance that lets you prove what AI is returning.
To continue the conversation, schedule time with Doug Davidson, director of GBQ’s Business Technology Solutions practice. Or, contact him directly at ddavidson@gbq.com.
Net Effect is a biweekly column written by Doug Davidson, director of the firm's Business Technology Solutions, published in the firm's Bottomline newsletter. Email ddavidson@gbq.com to have your technology questions addressed in a future column.