Hotline: Cybersecurity and Privacy | June 2025

Teaching Nuance Without Burning the Rulebook

Dear Hotline: How do you help frontline security and privacy professionals understand that enforcing the rules involves nuance and that risk management can't be viewed solely through their lens?

Take, for example, the renewal of enterprise software for a campus hotel. What happens when a vendor won't jump through all of the hoops you ask of them? How do you balance the security and privacy risks with the possibility that alumni and parents might not be able to check in during Homecoming week?

Risky Business

Dear Risky: It's a good thing I don't get paid for writing this column, or I'd ask for hazardous duty pay for this question. I'll answer your question, but I'll also put on my security manager hat and make a few observations about your question.

As I love to say, middle managers assert relevance by creating bureaucracy. Too often, that bureaucracy (or, as you describe it, "the rules") morphs into an end in itself and loses sight of the true goal: reducing risk. Sometimes, I wonder if this is a result of the way we talk about security. We say, "How do we secure the hotel business software?" when what we should say is, "Here's a list of the risks we've identified with the business process and software; let's mitigate them." The former lends itself to opinion, whereas the latter points to specifics we can make factual statements about. If "the rule" is "follow the rules," then there's simply no space for the conversation you're hoping for. I have seen security staff say to someone, "If you just follow the rules on this piece of paper, you'll be fine." So there are individuals who can be just a tad too self-righteous in their quest.

I hope security managers are coaching their staff to recognize that their roles extend beyond day-to-day operational activities. The security office is largely a service center that helps other offices achieve their mission objectives. Real business processes are messy, complex, often entrepreneurial, and do not always easily align with predefined security controls. Security practices need to be tailored to reality; they're not theology.

However, (and before I continue, let me say how smart your question is and ask if you have been hitting the gym) let's look at some of the details. I'm not sure if the rules you're running into are annoyances (the vendor won't provide enough liability insurance) or widow makers (their point-of-sale system isn't PCI compliant). If you're getting pushback on the former, then frame and quantify the risk and bring it to someone senior enough to discuss risk acceptance. If it's the latter, then it's likely time to move on to another product. Try to avoid opening with the catastrophic conclusion (TCC) "that alumni and parents can't check in during Homecoming week," which, while theoretically true, rarely survives scrutiny. Security staff regularly hear the TCC trope: "My research project will have to stop if my server is behind the campus firewall." Or, "Students will stop enrolling if we make them use multifactor authentication." We've heard them all.

The trope I'd rather hear is this one: "We need to communicate better." Sometimes, of course, we run into someone who's being difficult. But sometimes that someone is us. From your perspective, the security team is being unnecessarily rigid. From their perspective, you're suggesting that the security and privacy of customer data aren't really that important. Both perspectives are often true. That's why I'm suggesting a focus on enumerated risks and mitigations. This approach helps shift the conversation from either perspective and toward concrete, manageable, and quantifiable actions.

One last caveat to keep in mind. Even at the smallest institution, the security team can't negotiate every possible control in every possible situation. Foundational security controls like multifactor authentication, anti-malware software, or encrypted off-site backups should no longer be negotiable except under truly extraordinary circumstances. So maybe a little security theology crept in.^Footnote1

Measuring What Matters

Dear Hotline: Metrics for cybersecurity seem like a red herring. How can I show that my efforts make the institution more secure today than it was yesterday?

NoQuantZone

Dear NoQuantZone: I find it almost impossible to see anything but "quantum" embedded in your nom de guerre, so I'll refer to you as Entanglement from here on in. Entire libraries are populated with tomes on cybersecurity metrics, and I'm sure no one wants to see one here. However, I want to commend your question, my dear Entanglement, for it gets right to the issue of demonstrating improvement, something that both managers and staff benefit from.

A lot of the frustration surrounding metrics stems from a conflict of purpose. Boards want to illustrate the state of cybersecurity, while security practitioners want to call out the roadblocks. Boards and executives typically like clean, straightforward metrics that don't require an explanation—such as the percentage of systems running anti-malware software. Security offices, on the other hand, want to footnote every metric with exceptions and explanations. For example, the huge number of unpatched vulnerabilities found by scans is explained by the fact that a quarter of the systems on your network are BYO laptops brought by students. Neither of these metrics truly addresses the resilience of your institution. Worse, metrics can give a false sense of confidence, which will work against you during an actual crisis.

My advice is to proceed on two fronts. First, when asked for measures, don't argue with your management about whether they are good or bad measures; provide the metrics and move on. If the board asks for X, give them X. Ideally, if you have sufficient agency, provide metrics for the initiatives you have underway. If you're pushing to have your institutional anti-malware package deployed more broadly, start measuring that deployment. Let the results speak for themselves. If the numbers don't look good, this could create space for a conversation about the barriers you're facing. Good management engages constructively rather than reactively.

Second—and this one is quite difficult—start a campaign to coach your institution on what good metrics should look like. This isn't something you can create overnight, but it should be a permanent workstream. Put some time into thinking about where you want to be in a year (or three or five) and what initiatives you'll need to get there. Start by including material in your updates and briefings identifying national trends and growing risks. Present rough estimates about your institutional exposure to those risks and possible steps you could take to mitigate them. Decide for yourself how you will measure the effectiveness of these mitigations and then start working them into your annual work plan. Do this thoughtfully and introduce new risks at a modest cadence, trying to avoid creating panic. If your leadership is panicking, then they will likely assume you weren't on top of an issue until it was too late. You need your leadership to trust you and your judgment before they'll trust your advice on metrics.

I know that it can be frustrating when you're being asked for specific metrics, but remember, everyone thinks their geese are swans. Simply telling your institution that its metrics are poor will usually fall on deaf ears. As with most things, you'll need to prepare your leadership (the coaching I mentioned above) to engage in a meaningful conversation about metrics and risk, and that takes time and patience.

Wielding FUD with Finesse

Dear Hotline: How should I respond to cybersecurity naysayers who say that all I peddle is fear, uncertainty, and doubt? Isn't that at the heart of cybersecurity?

FUDRucker

Dear Fud: My goodness, I hope you're wrong. Several years ago, I swore I'd stop including what I call "security porn" in my talks and presentations—those endless anecdotes about ransomware, companies selling their customers' information, or foreign hackers. Yet the will is weak, and despite my best efforts, those slides still glide in, cloaked like a whisper.

Perhaps the naysayers are right, and we need to stop doing it. Part of what's going on is that we've all grown up with the idea that anything good for us is unpleasant but necessary to prevent something even worse (like exercise or kale, for example).^Footnote2 To be fair, it's incredibly useful to point to these security events as evidence that what you're asking people—and your institution—to do isn't merely theater. Hospitals and universities do get hit with crippling ransomware attacks. And since cybersecurity is a discipline of risk management, it makes sense to point to these events as data to quantify that risk.

What I'd suggest, however, is to keep that FUD in your back pocket and use it tactically. Bring it out to underscore an argument and, perhaps, to support estimates for the potential damages. But just as it's important not to oversell potential tragedy, it's also critical to offer up a countervailing narrative. Cybersecurity is so much more than "protecting against hackers." In the modern world, everything from civil society to teaching and research flows along digital pathways within a largely digital ecosystem. So instead of viewing cybersecurity as a pill they are forced to swallow, people should see it as something that is built into tools and services they already use.

Note

1. For a reasonable list of such controls, examine Table 5.3.6-1 on page 309 of "Research Infrastructure Guide," U.S. National Science Foundation, Finance and Award Management/Research Infrastructure Office, January 2025 (draft). Jump back to footnote 1 in the text.↩
2. My deepest and profound apologies to the exercise and kale lobbies.Jump back to footnote 2 in the text.↩

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