Think about what a flight school’s database actually holds for every student: passport scans for TSA and visa checks, medical certificate copies, payment plans, exam results, training records that airlines will one day ask to see. Now think about how many of those records sit behind a login that three instructors share because “the scheduling system is finicky”. That gap is what DataSecOps exists to close — the discipline, named by Ben Herzberg of Satori Cyber back on 4 August 2021, of protecting data as it and its users keep changing, rather than once a year in an audit panic. The good news for a busy academy: you can roll it out in six steps, and none of them requires pausing flying operations. We will walk them the way we’d walk a new student through a first solo briefing.
Step one: agree on what counts as sensitive
Before any tool, a conversation. Get the chief instructor, the office manager and whoever handles payments in one room for an hour, and write a single page: which categories of data hurt the school if leaked, and who decides edge cases. Passports and immigration documents sit at the top, followed by medical records, payment details, and — the one everybody forgets — training progress, because a student’s failure history is exactly the thing an airline background check should not find leaked. A decent first draft of the list, for most academies, looks like this:
- Identity documents: passports, visas, TSA clearance paperwork.
- Medicals: certificate copies, deferrals, any examiner remarks.
- Money: card details, instalment plans, refund correspondence.
- Progress: checkride results, stage-check failures, instructor notes.
- Operations: aircraft bookings, instructor schedules, simulator slots.
Write the page down and date it. This one-pager is the standard every later step leans on, and the argument it sparks usually surfaces two or three forgotten storerooms of records — a laptop drawer, an old tablet, a shared drive no current employee remembers creating.
Step two: find what you actually hold
Now go looking. Run discovery across scheduling databases, shared drives, email attachments, that spreadsheet the previous office manager kept on a desktop. Automated classifiers — Google’s, or Microsoft’s open-source Presidio — will propose labels, and they are genuinely helpful, but no scanner is completely accurate: some will miss a passport number formatted oddly, others will flag a tail number as if it were a phone number. A human confirms anything marked sensitive or identifier before rules rely on it. Expect this step to find copies nobody remembered — the scanning week between term starts is usually eye-opening. That is normal, and it is precisely the point: rules written for the data a school believes it holds are rules written for the wrong building.
Step three: switch on multi-factor authentication first
Do this before anything clever, because stolen passwords are how schools get hurt. The industry has already voted: password-only sign-ins are being retired platform by platform through 2026 — Snowflake announced its own phase-out — so getting ahead of it now means no rushed migration later. The cautionary tale is worth knowing: in 2024, an extortion campaign tracked as UNC5537 hit customers of the Snowflake platform using credentials stolen from employee devices. Roughly eight in ten of the affected accounts — 79.7% — had prior infostealer exposure, MFA was absent, and some passwords had sat unrotated for four years. Around 165 organisations wound up notifying people. A twelve-person academy is not too small for that playbook; it is exactly the right size for it.
Step four: put DataSecOps rules on the crown-jewel tables
You cannot protect everything at once, so protect the fifty tables that matter most first — student records, payments, medicals. The mechanics differ by engine. Snowflake only offers masking, row policies and classification from its Enterprise edition upward, so check your tier before promising anything. PostgreSQL can enforce row-level security; Apache Ranger can filter rows and mask columns on the Hadoop side; BigQuery applies policy tags, though a table rewritten with WRITE_TRUNCATE drops them silently, and its row policies turn off partition pruning, so queries crawl. Wherever you click rules into a console, record them as code too — copies and rebuilds (any CREATE OR REPLACE, any table copy) drop tags and leave data naked. Rules that live only in a dashboard are rules that vanish on a bad Tuesday.
Step five: make access a request, not a favour
Here is the cultural step, and it is cheaper than it sounds. From now on, nobody gets database access by wandering over to ask. They file a request that states the dataset, the purpose and the duration — until the end of the term, until the audit finishes, until the airline audit cycle closes. The data’s owner approves it the way an engineer approves a pull request, an automated check applies the grant, and an expiry date ships with it. Routine requests get answered same-day. Odd ones need a ticket and a named risk sign-off before they proceed. Sounds stiff for a friendly school? It takes the awkwardness out of saying no, which instructors will appreciate more than they expect — the rule says the grant ends Friday, not the office manager’s memory of a hallway chat. It also builds the paper trail an airline audit eventually asks for, which turns a scramble into a download.
Step six: hold a DataSecOps review that actually revokes
Three months in, sit down with the grant list and retire things. Ex-students whose files closed last year. The contractor from the website refresh. That service account from the scheduling migration. For scale: one published worked review counted 310 grants out of 1,900 — 16.3% — untouched for ninety days, and another 212 accounts, of 940 examined, holding more access than their jobs required. Schools are smaller, but the ratios rarely are, and the ex-student with an active login is a fixture of academy life. The review is also where the numbers live: how many sensitive columns sit under rules, how many reads touch plain text. A data-maturity ladder runs from ad hoc, through classified and enforced, to evidenced and finally adaptive — meaning every new sensitive table is gated before its first grant, every time. Half coverage of tier-one tables clears level two; north of ninety percent, with zero console-only rules, clears level three.
How DataSecOps differs from the audit you already do
Flight training already runs on checklists, which is why this discipline should feel familiar rather than foreign. A yearly audit is a pre-buy inspection; DataSecOps is the maintenance programme between inspections. Same instinct, continuous instead of annual. If your team already tracks aircraft health with software — say the AI approaches to engine health monitoring we covered earlier — you already accept that continuous beats retrospective. The same reasoning applies to inspection workflows, as our piece on computer vision in aircraft inspection showed: catch issues while they are cheap. The full reference behind these six steps, including the engine-by-engine quirks, is collected in the DataSecOps entry of the Ops Atlas at xOps School — bookmark it for the step-four conversation. And when the IT side of the school wants a companion discipline, our earlier look at how AIOps steadies IT operations pairs naturally with step six. Six steps, one term, no grounding of aircraft. That is the whole pitch.