Hotline: Cybersecurity and Privacy | October 2025

Learning to Live with CSVs

Dear Hotline: Our admissions office would like to utilize Power BI with admissions data. They have been in touch with the vendor of our admissions software, who can utilize the API to pull the desired data. To get it into Power BI, the developer suggested that there would need to be CSVs stored somewhere, which makes my skin crawl. (We're talking all admissions data, including financial.) I am by no means an expert in this area, but is there a way for the developer to put the data directly into Azure SQL or BigQuery and then have Power BI pull from those? Or could the data be pushed to Power BI on an hourly basis? Am I wrong to think that creating flat files and storing them somewhere is insecure?

Flat-File Phobic

Dear Phobic: Before I began working for a proper IT organization, I was asked to participate in a planning focus group for a new, systemwide enterprise resource planning (ERP) product. I volunteered that we needed a commitment to move away from flat files, which were the bane of my existence on the mainframe, and use dynamic data access via APIs. I can't recall if they actually rolled around on the floor while laughing, but metaphorically, they were playing with my pride like cats batting a roll of toilet paper around.

Sadly, despite living in an era of space travel, quantum mechanics, and instant ramen, humans have moved no closer to eliminating the flat file than to inventing fat-burning pizza. One way to look at this is to examine why you're allergic to it. In one sense, a flat file is merely one of any number of possible data stores, just as a SQL database file or a JSON file is. In some sense, almost every database format relies on a file of data stored somewhere, though it's often encoded in some fashion and not trivially readable, such as a CSV file. But I suspect you're responding less to the file format than you are to the long and hallowed tradition of not curating flat files; i.e., forgetting about them and not removing them when they're no longer useful.

In my opening example, part of my own disdain for flat files stemmed from having to identify their purpose and ownership, and then migrating or removing literally hundreds of thousands of files from our mainframe as we prepared for a migration to a new ERP. Many of these simply hadn't been touched in decades (God bless the accounting prowess of OS/390). So, I have a lot of sympathy for your goal. But unfortunately, I don't think I can agree that flat files are inherently insecure. It really comes down to how well you control access and handling.

In similar circumstances, I've seen systems that automatically encrypt files stored in a directory (independent of any native full disk encryption), whereby a file is decrypted only long enough to be read into an application before it is re-encrypted. Commonly, these files are then archived off the host or removed on a schedule. One risk you need to control is the temptation to send flat files via FTP or email, precisely because they don't require any specific application to read them. Keep your eyes peeled on how these files are created, and ensure that individual developers or test systems treat them with the same rigor they would in production.

It's worth pointing out to your team that financial aid data is coming under the umbrella of Controlled Unclassified Information (CUI), and while it's unclear from your question if financial aid data is part of what you're calling admissions data, it's better to start with sufficient rigor than try to add it down the road.

As to whether there's an alternative approach to push the data directly into Azure SQL or BigQuery, I suspect the proper solution is to eliminate the CSV as soon as possible, such as by having an automated process (e.g., a serverless function, an Azure Data Factory pipeline, or a Python script) read the data directly into Azure SQL and delete the CSV immediately afterward. Or never write it to disk at all and keep it in memory. But it's been ages since I touched Azure or BigQuery; I'd suggest redirecting that part of your query to one of the EDUCAUSE Community Groups, a vendor-specific forum, or even Reddit or Stack Overflow.

Backfilling Staff to Avoid Burnout

Dear Hotline: How do I make the case for backfilling staff? I lost a person (for ordinary reasons), and I was told I can't backfill the position. Spreading the work this staff member did across the team is killing everyone.

In need of HR Spackling

Dear Spackling: One dimension of working in higher education that has kept me tied to it throughout my career is the passion most people have for its mission, and how this is expressed through thoughtfulness and dedication to their jobs. If I had a nickel for every time I've seen someone work through lunch, late into the evening, or part of a weekend—or even during their vacation—I'd be writing this from my superyacht in the Mediterranean. This dedication, while noble and essential to the mission, makes the impact of staff loss all the more brutal. Worse, the effect of work overload is typically context switching, jumping from project to project, which is both inefficient (you lose a good twenty minutes when switching contexts) and corrosive to your thinking.^Footnote1

To make the case for backfilling, demonstrate that your need aligns with institutional risk, efficiency, and mission. Consider the request from the perspective of your management. Especially in our current environment, managers may be forced to find staff reductions, and when an employee voluntarily leaves, it's difficult not to see that as a gift. The alternative is far worse for everyone. View making the case for backfilling from a broader organizational perspective, not just your team's. Even when you have a strong hand to play (your risk and compliance lead leaves, putting the organization at risk of compliance fines), management will value your help in solving the larger, systemic challenges of staffing rather than just addressing your own problem.

Ask yourself and your team if there are less-skilled activities that might be shifted elsewhere in the organization. Many security teams still absorb end-user support for security software and services; this could be shifted to your service desk or to student help. Are there individuals outside your team who want to build skills in your area and could be assigned to you for 10–20 percent of their week? Such an arrangement might help another manager retain staff who might otherwise leave and demonstrate that they're a team player as well.

I once had an entirely new service assigned to my team (emergency notification), and lacking any staff to run it, I simply emailed "all-staff" and found an underutilized system administrator who was oddly passionate about timely emergency notification. I worked out a part-time job-sharing arrangement with his manager until a later date when the position received new funding.

My point is that by doing these things, you can demonstrate that you're approaching the problem from a broader perspective, prioritizing organizational efficiency over local needs and perhaps even freeing up some of the salary savings needed to backfill the employee's position. However, this approach alone is unlikely to secure a backfill, but it tills the soil to make your leadership more receptive to your request.

The request needs to be detailed. Specify precisely the responsibilities of the remaining team members and include estimates of the time commitment required for each item. Couple each responsibility with its corresponding business driver; for example, a GLBA (Gramm-Leach-Bliley Act) requirement or a management corrective action from an audit. Your goal is to demonstrate that your office functions are determined by concrete requirements and not "nice to haves," even if those truly are generally accepted best practices. Of course, include the specific risk being addressed by each function.

One of the more difficult challenges you face is that people are not fungible; you can't simply replace one person with another. People have specific skills and inclinations, and that can get lost in conversations with your management about "staff" or "staffing." These terms can become too reductionist. You can add human color to your analysis by highlighting individuals who are flight risks or have personal issues that put them at extreme risk of burnout. Remind leadership that overwork and burnout carry real costs, including turnover, lost expertise, and lowered morale, which far exceed the savings of an unfilled position. Fundamentally, the case you want to make is that as part of a program of resource optimization, backfilling your position lowers risk, builds organizational resilience, and advances its mission.

Author's Note

This month's Hotline is a tad shorter than usual due to our desire to publish it before the EDUCAUSE Annual Conference. Feel free to track me down at the conference (I'll probably be in the Executive Leaders Lounge) to debate this and earlier columns and suggest topics or questions for future columns.

Note

1. Kevin P. Madore and Anthony D. Wagner, "Multicosts of Multitasking,"Cerebrum (April 2019): cer-04-19.Jump back to footnote 1 in the text.↩

---

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