Hotline: Cybersecurity and Privacy | August 2026

Using Organizational Judo to Build Security into the Process

Dear Hotline: My college just rolled out business relationship managers (BRMs) to sit between the IT department and the academic and business units. In practice, they seem to be functioning like IT project managers, tracking timelines and vendor requests with zero security lens on anything they touch. By the time a project lands with the security team for review, the BRM has already made promises to the department about scope, cost, and go-live dates. The security review is essentially an afterthought bolted onto the end of the process, and it is viewed as an obstacle.

How do I get security priorities onto a BRM's radar without becoming the person who shows up to kill every deal they've already sold?

Bolted On, Not Built In

Dear BONBI: Boy oh boy, have I seen this problem. I've lived this problem. It's challenging but worth tackling. Historically, most IT organizations treated cybersecurity not as an intrinsic part of IT service deployment but as something layered on top of it. "Add this control, introduce this security technology, and check for standards compliance." Bolted on, as you said.

What you're describing is the exact same issue but at a meta level: you're being asked to layer a cybersecurity process on top of an IT deployment process. So, it's no surprise that security is viewed as an obstacle; your BRM process positions it as one.

There are two dimensions to tackling this challenge: one is mechanical, and the other is strategic. On the mechanical side, I suggest demonstrating a little organizational judo: treat the BRM process as exactly that, a process that is itself subject to analysis. Ask for the BRM process diagram and ensure that security assessment and risk analysis are integrated into project intake. In other words, don't allow security to be relegated to a compliance gate. Insist on treating late-stage review as a process defect and shift the conversation to where the process should be corrected. The judo here is that you're redirecting the force of what is essentially a business process exercise onto itself and away from a preconceived (and reductionist) understanding of security. Your energy should be spent less on control implementation and more on determining how services are deployed.

On the strategic side, the deeper work is not persuasion but shifting how the organization defines success. The goal is to coach the organization as a whole, helping people (including your boss and the BRM team) understand that security is more than a checklist. The quickest, most effective path to rigor is to deeply integrate security principles into every business process and project workflow. Security is integrated when insecure outcomes require effort, secure behavior is observable without trust, and deviation carries real cost.

You can ask the BRM team a few questions that help surface whether security is truly integrated in each project. For example, "At what point in this process can an insecure outcome still occur, and who has to actively intervene to stop it?" This reveals whether insecurity is the default path. Similarly, you can ask, "What measurable signal would tell us—without asking anyone—that this process is operating securely?" What you're looking for here is whether security is observable and grounded in telemetry (integrated) or dependent on attestation, policy, or trust (bolted on).

Put simply, it's probably unreasonable to expect your BRM team to understand the nuances of security unless you educate them. Of course, they may have been given marching orders (and incentives) that work against you, which is why your educational campaign needs to include senior leadership.^Footnote1

The BRM function isn't the problem—it's the lever. If you can reshape that process, you're not just fixing project intake; you're redefining how your institution builds resilience into delivery, rather than negotiating for it at the end.

Putting Some Teeth into Risk Acceptance

Dear Hotline: You've noted in past columns that when leadership demands cuts or radical actions, they have to own the resulting risk. But I'm seeing something different: department heads invoking "risk acceptance" not because of budget constraints but because a control is inconvenient. Someone doesn't want to use MFA, or someone doesn't want to patch a legacy system on schedule, so they sign a risk acceptance form, and suddenly my legitimate, already-funded security control is optional for them.

How do I stop risk acceptance from becoming a permission slip to opt out of security whenever it's annoying without turning every request into a political fight I'll lose?

Signing Away My Sanity

Dear Signing: Your question gives me flashbacks to the first time I signed a mortgage. I'm still not sure if it was an act of optimism (that I'd be able to pay it off) or pessimism (this is my sad future of debt). Regardless, I have the same conflicted sense when I think about risk acceptance. On the one hand, risk acceptance is so profoundly bound to how cybersecurity is supposed to work in an organization that it can feel wildly successful when an executive makes an informed risk acceptance decision. On the other hand, many colleges and universities push risk acceptance into organizational cul-de-sacs (I'm thinking about deans or department heads), which ignores the reality that malware and attacks are blind to organizational structure. I recall seeing a state actor use seven-year-old credentials from a host in the business school to jump to a server in a campus data center and then pivot to a marine sciences unit. As security professionals, we often need to think about risk independently of the cultural and governance structures that dominate academic life.

But let's be honest: at some colleges and universities, you're simply not going to win this battle, at least not quickly. Personalities, politics, and campus traditions being what they are, senior leadership at your institution may prefer to defer to unit heads despite your elegant and cogent arguments to the contrary. What you can do, however, is put the dead fish on the table. Remember that simply having a risk acceptance process (effectively a policy exception process) isn't a sign of maturity; how you curate those exceptions is. Risk acceptance only works when it is a costly, visible signal. When it is cheap, local, and consequence-free, it stops being governance and becomes a permission slip for ignoring controls.

For every exception, ensure you have a notification list that includes deans, senior executives, or department heads. Include a scoping description on each exception form that identifies which systems, data stores, and campus departments or units are being put at risk. Include the leaders of those units and systems in your notification list. And, critically, require every exception or risk acceptance to be reviewed and reapproved annually. In your annual reports and presentations, include simple metrics on the number of exceptions that have been approved, reviewed, and rescinded. If exceptions are never reviewed or rescinded, then your policies are ineffective, and your body of exceptions effectively becomes your policy. In other words, if creating a policy is difficult and expensive but ignoring it is easy and inexpensive, you've incentivized security sloth.

Making Peace with Documentation

Dear Hotline: Do you think it's antithetical for somebody to have a career in information technology and not like documentation?

Running from Requirements

Dear Running: No. Our lives are filled with things we don't like yet embrace. For me, it's the treadmill at the gym. Would I rather be melting in the sauna? Sure, but cardio keeps me alive. Almost no one enjoys getting a shot in the arm, but we're not foolish—we really don't want to get (or spread) the flu. So, every fall it is.

With apologies to those of you who relish working on documentation, I get it. You're an engineer, a coder, or an incident response expert, so spending time documenting your work can seem like a diversion from the thing you're truly passionate about. Part of what makes "documentation" such a trigger for so many of us is that we tend to view it as something outside of what we "really do."

I grew to appreciate documentation back when I was a programmer and had to maintain my own codebase. I realized that without that documentation, I had no idea what my code was doing eighteen months later. Think of it as cognitive preservation. I'm guessing from your nom de guerre that part of your struggle is with the endless documentation that security compliance now seems to require. System security plans (SSPs) can seem endless, and despite the promises of governance, risk, and compliance tools, auto-generating them (especially in research environments) is still farther over the horizon than fusion power.

It may be helpful to frame documentation as a form of thought work. Where most IT organizations fail is in treating documentation as a compliance artifact instead of a cognitive artifact. Documentation is not "writing things down." It is making thinking durable under normal organizational entropy. Security compliance documentation isn't really separate from engineering or incident response; it's the continuation of thought when our attention has moved on.

We tend to treat documentation as overhead because we assume the work is complete at the moment of execution. But in complex systems, work does not end when action is taken—it only becomes legible later through preserved thought. Documentation, therefore, is not a distraction from real work; it is the only mechanism by which real work remains real over time.

I suspect this won't make documentation work more palatable to you. But I do believe work can be transmuted into joy by bringing creativity to a problem and connecting that work to the broader institutional mission. I hope you're finding ways to bring your creative vitality to some of the less compelling parts of your workflow—even compliance documentation. Though I'm sure I won't be reading any of it while hoofing it on the treadmill.

Notes

1. For a related discussion of incentives, see Michael Corn, "Obsolescence under Discontinuity," Michael Corn: Society, Cybersecurity, Higher Education, Privacy (blog), Substack, August 6, 2026. Jump back to footnote 1 in the text.↩

---

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