Hotline: Cybersecurity and Privacy | July 2026

Untangling the Research Security Blame Chain

Dear Hotline: Federal research security requirements are tightening fast. The researchers say it's overreach. The compliance office says it's mandatory. The CISO is caught in the middle with no budget and a deadline. Who actually owns research security on a college or university campus, and more importantly, who owns it when something goes wrong?

NSPM-33 Gave Me a Twitch

Dear Twitchy: What I like about this question is it allows me to use two of my favorite metaphors. On the one hand, you are handed a single, nonnegotiable reality where the alternative is institutional suicide. For a higher education institution, a strict federal compliance mandate is often a Hobson's choice: "Implement these exact security controls or lose your federal research funding entirely," which is pretty much what NSPM-33 threatens. Whether you view these mandates as overreach is irrelevant.^Footnote1

On the other hand, you are torn between two valid, opposing forces; for example, a CISO trying to enforce rigorous data isolation (duty A) while enabling open, friction-free academic research collaboration (duty B). Both are responsibilities; choosing to fully optimize for one actively compromises the other. This is Antigone's dilemma. And here I was thinking that all those years I spent studying literature and philosophy in college weren't relevant.

I'm also glad that you asked, "most importantly, who owns it when something goes wrong?" However, I'd argue that it's most important to begin by determining who owns it. In practice, the execution of your research cybersecurity program will be a partnership, an integration of agents. It will require research affairs, research compliance, cybersecurity, research IT, and local IT support all singing from the same hymnal despite their disparate roles and functions. Notice that I used the word "integration" and not "coordination." You should aspire to a cohesive, organic program that is seamless for faculty and researchers.

But the "ownership," in my opinion, should rest with your vice chancellor or vice president for research. By definition, they are responsible for the research mission of the institution, and frankly, that is exactly who the faculty expect to be steering the ship. It's also valuable to define "ownership." It doesn't mean "the person who does everything." Clearly, your fax machine isn't the right "person" to develop a compensating control for a technical challenge. But in this case, ownership should mean "the responsible party who ensures that actors remain engaged and that transitions between actors are understood and seamless."

I tend to think of a research cybersecurity program not as an administrative workflow, but as a dynamic regulatory loop. A triggering event, such as a new grant award, must drive explicit commitments about system outcomes (controls, compliance) under defined failure conditions (resistance, technical limitations). It takes broad, institutionally scoped authority to ensure these technical controls don't just exist as an inventory on paper but actually perform under stress: specifically, the chaotic reality of everyday research activities.

At most institutions, responsibility for something as complex as research security doesn't typically fall to one individual. As many CISOs know, research compliance offices often cede anything "cyber" to the CISO and their office's "skill authority." And CIOs frequently find themselves on point for the cybersecurity component of research security programs. They play a critical role in catalyzing a program, often through their role as mediators between the trifecta of cybersecurity, research IT, and academic IT professionals; i.e., those who will be most directly involved in supporting NSPM-33 technical controls.

Finally, if you're a CISO who's stuck being asked to solve this on your own, resist the temptation for heroics. NSPM-33 discussions may focus on issues of compliance with technical controls, and while those may be challenging, that's a diversion from the real issue: cultural change. The era of research programs treating cybersecurity as a "best-effort" activity is over. Cybersecurity threats are simply too sophisticated and too ubiquitous for anything but professional engagement. And here we return to the true existential choice (a Morton's fork, if you will): does your institution recognize the need to engage the resources; i.e., leadership and budget, to address this change, or will it choose the path of gradual institutional obsolescence?

Decoding the CMMC Pause Without Losing the Plot

Dear Hotline: What is the deal with the new edict from the Department of War that CMMC L2 requirements are being immediately suspended? ^Footnote2 Is this a legitimate recognition that the CMMC ecosystem could use some thoughtful care and attention, or is it the prelude to a mass exodus from CMMC writ large? And, how do I explain this to leadership, who wants to know if we should continue to pursue (the now-suspended) CMMC L2 certification or just sit and wait (some more).

Policies Come and Go

Dear Policies: As you might imagine, everyone has their ear to the ground on this one, and there is a lot of wild speculation, er, reasonable advice to be found in the professional press and blogosphere. Is the Cybersecurity Maturity Model Certification (CMMC) truly about to be jettisoned in its entirety? Will the program be merely tweaked to eliminate the bureaucratic cost burden for the smaller members of the Defense Industrial Base (DIB)? Is this the Department of Defense (DoD) finally listening to reason about the problems with the program, or are we seeing the ebb and flow of battle between warring factions—those making money off CMMC versus those paying money for it?

If you're reading this, then at least by press time it remains a mystery wrapped in an enigma and deep-fried into a chimichanga. Nobody seems to know, yet that hasn't stopped any of us from speculating. So, it's in that spirit that I'll try to answer your question and offer some advice, particularly on how to talk about it with your leadership.

It's reasonable for institutional leaders to question whether the investment in CMMC is justified. As cybersecurity professionals, we've been yelling "the sky is falling" for five years or more, asking for new and recurring funding, and now leadership is reading that the entire raison d'être for those resources may be going away. Perhaps it was no more than an acorn falling on our heads. Your job is to gently correct that assumption.

First, I'd remind leadership that regardless of what happens to the CMMC program, the institution's contractual obligations for cybersecurity remain in effect. You're still at risk of falling afoul of the False Claims Act if you've accepted DoD awards and are not meeting the obligations of DFARS 252.204-7012 clauses. You still need to record accurate and defensible Supplier Performance Risk System (SPRS) scores. You still need complete system security plans available anytime an auditor comes knocking. So, whether it's called CMMC or DFARS-a-go-go, the obligations remain unchanged. What might change is the scale and cost of the bureaucracy necessary to demonstrate that you're meeting those obligations.

Next, you can point out that the DoD (and other agencies) is not retreating from cybersecurity; it is retreating from paperwork. In an era of dwindling federal funding, a mature cybersecurity program is not merely a floor, but a competitive, differentiating feature, particularly in the defense sector. Remember to underscore that CMMC is much more than a compliance program; it is a forcing function for capability maturity. Any investment your institution has or will make in CMMC will establish the ability to adapt to current and future requirements. Your program enables researchers at your institution to compete for funds that would otherwise be left on the table.

While the jury is still out on whether CMMC 3.0 (or whatever it's called) is the leaner and smarter program we've all been hoping for, this pause may offer us the opportunity to refashion our programs. In the spirit of my eternally optimistic nature, I would frame this pause as a good thing. It allows you to develop "what if" scenarios for how you might restructure your CMMC programs in anticipation of significant changes from the DoD. Transmuting uncertainty into an actionable planning process surely demonstrates strategic maturity to your leadership.

Building an Off-Ramp Before You Need It

Dear Hotline: A vendor my institution relies on had a significant data incident. Their response was a form letter, a free year of credit monitoring, and a webinar about their "renewed commitment to security." Because of the data involved, we had to report the breach to an external entity, which was the opposite of fun. We renewed the vendor contract anyway because switching costs were too high. Is this just higher education, or is the entire industry operating on a handshake and a prayer?

Breach Me Once

Dear Breach: You got both a handshake AND a prayer? You must be a terrific negotiator.

It seems like every week I get an email from a colleague about another major vendor breach, and yet other than a few days of bad press, it's quickly forgotten. To be fair to our corporate colleagues, that form letter, year of free credit monitoring, and promise of a renewed commitment to security closely parallels the practices followed by many colleges and universities after a breach. Granted, the consequences vary by industry, but in general, breaches have come to be viewed as a cost of doing business.^Footnote3

Looking at those switching costs is an interesting exercise. The average member of your community probably views your enterprise services through the eyes of a consumer. If they tire of Dropbox, they sign up for Google Drive. If LastPass is no longer doing it for them, a few clicks later they've migrated to 1Password. For higher education institutions—particularly given their broad demographic user bases—switching involves re-engineering complex API integrations, executing massive data migrations, retraining helpdesk staff, rewriting entire knowledge bases, updating public-facing websites, and hand-holding thousands of reluctant users through the transition. I've seen some product transitions, especially those involving academic technologies, last for years. Our inability to be more agile is quite exasperating.

In light of this, the hesitancy to switch due to the work involved is understandable. Nevertheless, a mature institution will always have a contingency plan for urgently transitioning away from a service. To combat vendor lock-in, I advise CIOs and CISOs to incorporate agility into their project designs. Build an "off-ramp" into every major project plan and identify key inflection points where the organization should evaluate whether to keep, modify, or transition to a new architecture or service.

A failure to plan for the inevitability of change can create technology gridlock, preventing an organization from moving forward and hobbling long-term strategy. Think of failing to develop a planned "off-ramp" as a kind of deferred maintenance—something you can take care of before the system fails.

Agility isn't the ability to move fast—it's the ability to leave. If you can't do that, then every breach is just something you learn to live with.

Notes

1. I don't believe NSPM-33 mandates are an overreach; what's proposed is quite modest, both in the grand scheme of things in light of today's threat landscape. Jump back to footnote 1 in the text.↩
2. Department of War,"Forging the Arsenal of Freedom: Department of War Suspends CMMC Phase II Requirements," press release, July 13, 2026. Jump back to footnote 2 in the text.↩
3. In economic terms, this is referred to as internalizing an externality. Jump back to footnote 3 in the text.↩

Michael Corn is an Executive Strategic Consultant at Vantage Technology Consulting Group.