Hotline: Cybersecurity and Privacy | June 2026

Resisting Unnecessary Complexity

Dear Hotline: Avoiding excessive complexity in expressing software makes it easier to read the code and notice cybersecurity vulnerabilities that can be corrected. What organization uses language that makes it practical to avoid excessive complexity across wide subject matter and seeks language that does so more effectively?

Bureau for the Reduction of Unnecessary Complexity

Dear Bureau: The complexity of your question suggests a deliberate touch of irony. Your phrasing creates a "double layer" of language by using language to express software, which is itself expressed in language. My aging brain briefly debated whether you are talking about coding languages or human languages.^Footnote1 If I'm understanding your question correctly, you're asking how organizations can champion simpler software and reduce technical complexity effectively.

It's difficult to deny that code complexity goes hand in glove with an increased risk surface. In researching this, I found at least six different "schools" promoting simplified application coding, each focused on a different layer of simplification—from the well-known (Ruby on Rails), to the principle underpinning Unix ("do one thing and do it well"), to "worse is better" ("start with a minimal creation and grow it as needed") to more modern anti-complexity architectural movements, such as Ink & Switch. ^Footnote2

I suspect, however, that the best models for what you're asking about come from high-reliability, safety-critical domains, such as aerospace or embedded systems engineering. MISRA comes to mind as an example. These fields embrace the core idea that complexity equals risk surface and that simpler systems are more auditable, testable, and resilient.

The irony, of course, is that these areas also have the greatest number of detailed requirements, which, wait for it, breed complexity.

There is no dominant organization dedicated to "simple code" because economic incentives favor complexity. More features attract more buyers, and more abstraction gives a company more hiring leverage. Thus, enterprise environments reward generality over clarity because tooling ecosystems (frameworks, the cloud, AI) trend toward abstraction layers.

So, simplicity tends to survive only when teams are small, accountability is tight, or failure is very expensive. Most groups don't optimize for simple code but for something adjacent to it. For example, a simple product (Rails), simple interfaces (Unix), simple implementation (worse is better), simple operations (DevOps / platform engineering), or a simple mental model (local-first). ^Footnote3 I have no doubt that I'm oversimplifying this.

I think the more interesting way to frame your question is this: What organizational structures actually produce simple systems consistently? The answer isn't technical. It's governance, incentives, and ownership. Until higher education leaders treat technical complexity as a risk to the institutional mission rather than an IT line item, we will continue to drown in the code we build.

Accepting Imperfection

Dear Hotline: How can security and privacy professionals effectively communicate program capabilities limitations to executive decision-makers, particularly when those limitations are influenced by institutional culture?

We Need to Talk

Dear Hotline: After every breach, the president asks whether the security team can guarantee this will "never happen again." We cannot. Yet the institution keeps chasing the illusion of perfect security. Is the industry complicit in selling this fantasy? How do we speak truth to power when the truth is uncomfortable?

Inconvenient Truths

Dear Talking Inconveniently: I'm combining these two terrific questions, since they are different versions of the same challenge. As security professionals, we understand that our greatest security vulnerability isn't our technology—it's institutional culture, and our goal is to trade the comfortable lie of "perfect defense" for the uncomfortable reality of "resilient mitigation." Yet most of us struggle to inculcate these structural realities into our leadership's world model.

The first step is recognizing that your leadership isn't crazy. Once you've been poked in the eye, it's natural to ask what safety glasses cost. Savvy leaders may recognize that a problem is nuanced and that solving it is complicated and involves subtle changes over time, but what they want are crisp, explicit solutions: a technology to buy or a policy to adopt. I have no doubt that we are complicit in fostering this behavior. Despite our best intentions, as security practitioners, we tend to speak the simpler language of controls rather than the messier language of risk.

Part of what drives this is context. Too often, we're only afforded the opportunity to speak to power when a crisis takes place, and everyone is in reactive mode: decide quickly, spend money, solve a problem. When we're not in crisis mode, we sabotage discussion by subtly creating a crisis. We say things like, "I really need this problem solved," or "we have this huge risk, so I need some executive fiat." Both of these conversational feints force your leaders to react instead of learn. Remember, the primary function of your job is to coach members of the campus community on how to think about cyber risk in all its dimensions. You and your team can't independently address the entirety of digitally mediated risk; you need to bring the village along with you, so to speak.

The first question asks about a communication framework. I recommend approaching this in two ways. First, develop an explicit plan around executive communication. Try to become embedded—even if ex officio—on executive governance committees and meetings. Just being present often results in being asked for updates. Discussing cybersecurity risks and activities at faculty senate or business managers' meetings, for example, can increase your visibility and diffuse your concerns throughout the "governance sphere" of your institution. Your goal is to be present and heard regularly, not merely when requested.

Second, focus your message on understanding and thinking about risk, not controls. Try to limit presentations that include an ask. Instead, use them to raise discussion topics that surface assumptions about risk and risk acceptance. For example, in light of the recent Canvas ransomware incident, don't focus on "what we are doing to address this," but instead ask "how degraded can instruction and research be during an outage and still function?" This is the governance and leadership question you need answered before you can design a mitigation. Answering it shines a light on the cultural expectations for instructional continuity, as well as the limitations of any possible response.

Hopefully, your immediate manager can be your partner in this. I've worked with CIOs who supported and encouraged my roaming the halls of executive governance, and others who resisted it, viewing it as their prerogative alone. If your manager is a gatekeeper, don't fight them—arm them. Give them the exact risk questions and operational frames they need to carry into those rooms for you, ensuring that even if you aren't in the meeting, your strategy controls it. In either case, do your best to ensure that the two of you are on the same page and communicating the same message.

Exposing Performative Compliance

Dear Hotline: My institution recently completed a mapping exercise for the NIST Cybersecurity Framework (CSF). We have a beautiful spreadsheet. We have color-coded tiers. We have a presentation for the board. We have almost none of the actual controls. At what point does compliance documentation become performance art, and how do I stop being the star in the show?

Technically Compliant, Spiritually Dead

Dear TCSD: According to Merriam-Webster, the word "exercise" refers to "something performed or practiced in order to develop, improve, or display a specific capability or skill." Therefore, a mapping exercise aimed at displaying your capabilities is, by design, a kind of performance art. But your nom de guerre worries me. If you have none of the actual controls, are you truly technically compliant? And I really hope you're not spiritually dead, or at least, not because of NIST compliance. If you're going to lose your soul, let it be for a worthy tragedy—like the last pizza parlor in town going out of business or your state banning Taco Tuesdays. (I probably shouldn't write these columns so close to lunchtime.)

What I think you're really asking is this: "Why am I spending so much time on performative compliance? It's taking up time better spent on becoming compliant." Rather than avoiding the performance, you might consider reveling in your leading role. Become the voice of compliance and leverage your celebrity for the resources you need. Of course, this is basically the underpants gnomes model of compliance, but instead of collecting underpants, you're collecting data: collect data > ? > profit.^Footnote4 It's that middle part of the business model—explicit risk acceptance—that needs to be addressed.

I suspect you're falling into the trap we all have stepped into at one point or another: Your compliance documentation is trying to show the half-full part of the glass, when what you really need to draw attention to is its emptiness. NIST CSF, in particular, is a maturity model, not a binary (pass/fail) audit standard. A CSF exercise should focus less on "look at how good we are" and more on "what does it mean for the organization to remain at the maturity level we've identified?" You need to state plainly—and openly—what happens if the organization doesn't change and what risk is currently being silently accepted. Make it clear that by choosing not to fund or implement these specific controls, the institution is actively choosing to carry this exact operational liability. This framing nudges institutional governance structures to treat risk assessment not as a final theatrical production for the board, but as a live, operational intake process for actual mitigation.

Remember, a maturity model is only useful if it forces explicit acceptance of risk at that maturity level. Years ago, I learned that whoever controls the agenda controls the meeting. As the author and star of this performance, what happens in the final act is up to you.

Notes

1. You may be surprised to learn that, when it comes to human language, there is an entire ecosystem of plain language advocates within the federal government. See, for example, "Plain Language," U.S. Office of Personnel Management, accessed June 11, 2026. Jump back to footnote 1 in the text.↩
2. Richard P. Gabriel, "Worse is Better," Dreamsongs, accessed June 11, 2026.Jump back to footnote 2 in the text. ↩
3. Local-first eliminates the architectural nightmare of the infinite cloud by returning to data ownership.Jump back to footnote 3 in the text. ↩
4. The "underpants gnomes" joke is the source of a common meme mocking poorly thought-out business strategies in which the middle step is missing. See, "Gnomes (South Park)," Wikipedia, updated May 19, 2026.Jump back to footnote 4 in the text. ↩