Keith Formell — CIO · VP of Information Technology

From the Desk of

Keith Formell

Chief Information Officer · VP of Information Technology

Cybersecurity, Risk & Incident Response · Data, Analytics & AI Governance & Assurance · Enterprise Apps, ERP & Cloud · Manufacturing, Supply Chain & 24/7/365 Operations · U.S. Air Force Veteran · Girl Dad ×3

ISC2 · Certified in Cybersecurity
Google · Cybersecurity Certificate
PeopleCert · ITIL Foundation


Nearly thirty years in enterprise technology, and a method for deciding what it means.

Profile ↓

Profile

I'm a process and framework technology leader, deliberately agnostic to the technology underneath. Not because the technology doesn't matter, but because I've owned enough different stacks to know it is rarely the variable that decides whether something holds.

The instinct came early, and it came before the necessity. I started in December 1996 as assistant to the lead developer at the Center for the Application of Information Technologies at Western Illinois University, a state-recognized center built out of a satellite distance-learning network and partnered nationally in distance education. I built its first web presence with dynamic content refresh, when most of the web was still hand-edited static pages. And I was drawn to structure and framework extensively: business analysis, detailed design documentation, project management. Nobody assigned me that. It was the part of the work I kept moving toward. And the pull kept extending, into infrastructure, into ITIL, into master data management, into analytics, each one absorbed because I kept following the same instinct.

Expand Full Profile

Eventually it pulled me out of the trenches into management, reluctantly, because leaving hands-on work was never the goal. Structure was, wherever it could be applied. Once I was in the seat, the same instinct fed forward into the leadership itself: process improvement, automation, and building people. Writing job descriptions not as documents to file but as a level set, the baseline that training, feedback, accountability, and reward all have to tie back to or they are decoration.

That is the causal claim, and it is the whole thing. I didn't arrive at method because I never did the work. I arrived at method because I have done the work for nearly thirty years and learned that method is what makes a build survive.

Which is why the first deliverable is never the rebuild. It's the assessment: an honest picture of what is there, what it depends on, and what it will take to make it enterprise grade. Then the plan. Then the documentation. Then the execution, and then a base the organization can actually run on. Then continual improvement, so it never quietly drifts back into being unmapped.

The pattern holds. Established a CIO function where none existed. Rebuilt an enterprise systems environment in forty-six days following an international cyberattack. Built a business intelligence department from nothing. Owned ERP and the manufacturing planning stack across two multi-plant food manufacturers. The founder's seat isn't new to me either. I've built and run my own ventures since the 1990s, which is why I read technology from both sides of the table: the founder who builds from zero, and the executive who has to make it scale and keep it secure.

What I bring is the seat where the pieces come together. Applications, infrastructure, data, security, process, vendors, budget, and the business held as one estate rather than eight functions that happen to report to the same person. Specialists are findable. People who can see the whole board and then build the teams to run it are not.

What makes that foundation rare is the depth underneath it. I lead security at a level most CIOs delegate: identity, vulnerability, governance, and the layer most programs reduce to a checkbox: awareness and training, built so that people stop being the softest control in the building. Because an organization's risk appetite sets its security posture long before any control does. And I treat AI the way I treat any production system: provenance, source-of-truth governance, and verification, so it's a capability an organization can stand behind rather than a liability it can't see. Design it right, secure it, sign your name to it. One discipline, three layers, one signature.

That standard has a date on it. I signed up during Desert Shield and Desert Storm, and specifically because of them. What I ended up on was a U.S. Air Force Boeing KC-135 Stratotanker, the aerial-refueling platform that gives American airpower its global reach, extending the range and endurance of fighters, bombers, and airlift wherever they have to go. That same airframe carried crews through Vietnam and through the air campaign that put me in uniform, and it is still flying today, more than six decades into continuous service. I was an operational crew chief on it, holding Red X authority: the aircraft flew or it sat grounded on my inspection and my signature, and by technical order no one could direct me to change the call. Rank could not overrule it. The systems have changed since. The standard has not.

The discipline is old. Only the system is new.


Capabilities


On Security

Every organization already knows its risks. They sit in a register somewhere, documented, ranked, signed. The breach almost never happens in the gap between the threat and the control. It happens in the gap between the risk that was written down and the remediation that was funded.

Controls don't accept risk. Architecture doesn't accept risk. People do.

That gap is not a technical failure. It is a decision, made by someone, in a room, with a budget in front of them. Closing it is the work I care most about.

Read the full perspective →

Perspectives


Contact

A true north on the wall is easy. The will to follow it is not. Those are the only companies I'm interested in, and if the technology underneath yours doesn't yet match the ambition, that's the problem I want.