My Greatest IT Asset: Naval Flight Officer Wings

**Orignally posted on LinkedIn 14 Feb 2017**

I'll start by saying that when you begin a new career field, previous, seemingly unrelated experience can be invaluable - don't underestimate it.

It may seem a bit counter intuitive to hear me say that in my so-far short career in IT, the experience I fall back on the most isn't an IT or IT related job. For those of you that know me, you know my professional career began as a Student Naval Flight Officer, followed by designation as a Naval Flight Officer - specifically an Electronic Countermeasures Officer. (For those that don't know what a NFO does, Wikipedia has a pretty spot on write up: https://en.wikipedia.org/wiki/Naval_flight_officer). Currently, I am a Governance, Risk, and Compliance Analyst at a Fortune 500 Company, mainly focusing on risk at the moment.

Why do I claim my biggest asset is my NFO Wings? The one quote I will use is from one of my former Maintenance Officers, an experienced NFO who now commands a squadron: "Hey SUDS, don't mess it up", but said a bit more flowery. While said somewhat jokingly, it resonated. How do you not "mess it up" when operating a medium attack-type aircraft around the carrier, in combat or 500 feet above the ground? You perform a continual exercise in risk management that starts when you write the flight schedule, and it doesn't end until the end of the flight debrief.

You may be asking yourself how that translates into IT Risk Management. In any type of risk management, the idea is to understand how a selected set of controls relates to performance, vulnerabilities, and likelihood of realizing a loss event. In aviation your controls are documents like NATOPS, Squadron Policy, Skipper's Standing Orders and other documents that govern how the Navy will operate aircraft.

Second comes understanding what performance indicators you evaluate to implement and measure the effectiveness of those controls. Things like crew rest (mandatory rest periods for aircrew), aircraft maintenance status and history, weather, aircrew interactions, dates of last flights, and a host of other factors. Performance indicators are meant to show what areas of execution can incur risk based on how well controls are implemented. For instance, if an aircraft has a certain maintenance issue, you may be able to fly a benign Point A to Point B flight with little risk, but a more dynamic flight may incur too much stress on the airframe, dramatically increasing the risk of a loss event (in this case, damage or loss of the airframe and potentially the crew).

Next, you need to develop a set of risk indicators - metrics that, when correlated to performance indicators and controls, can indicate that a loss event is becoming more or less likely. In aviation, we're looking at things like weather development, airspeed, altitude, aircrew physiology, aircraft performance (engine status, oil pressure, cabin pressure, etc.), and others. The idea is to continuously monitor those metrics and make decisions the reduce the likelihood of a loss event.

To pull that all together, I'll use the example of flying a low level route. When writing the schedule, all of the control documents go into deciding things like who flies together, launch times, times between flights and more. During the brief, more control points are identified, as well as an evaluation of performance indicators - what's the weather doing, are we all qualified to fly the flight, do we need to take additional safety measure in flight, jet status and more. At this point, the risk indicators are also discussed. Things like minimum altitudes and air speeds, separation requirements for multi-aircraft formations.

In the example of the low level, one major risk item that's continually monitored in the risk of terrain impact - hitting the ground or something attached to it. Risk indicators include radar altimeter altitude, aircraft attitude, the "is the ground getting closer" question and more. If you know you're supposed to maintain 500 feet above ground or higher, you set the radar altimeter alarm to 450 feet - an indicator that shows an increased risk of terrain impact would be the alarm sounding with the aircraft in a nose down attitude. Those two indicators together will tell the aircrew that they are descending, and that corrective action needs to be taken - in this case the pilot should pull up and climb until the alarm silences and the radar altimeter reads 500 feet or greater.

The point here isn't a lesson in flight planing, but to show how, being an aviator, you are exposed to, and expected to adhere to, a comprehensive risk management framework designed to identify pre-flight and in-flight risk, and decrease the likelihood of experiencing a loss event. The translation is evident - the goal of IT Risk Management is to understand where risk exists from multiple vectors and how to make informed decisions on taking corrective actions.

The basics are the same - identify controls and how to evaluate performance, which will help identify potential loss events. Once those are identified, risk indicators should be developed an monitored - what characteristics of the environment can show an increasing or decreasing likelihood of realizing a loss event?

In both cases, having an established framework cannot be overstated, as that framework is the foundation for being able to understand what the risk environment and appetite is, and how to correlate those identified risks to a business, organizational, or mission impact.

The second point is that, as a professional, while daunting, switching career fields isn't impossible, and you'd be surprised at how much knowledge and experience can translate from one to the other. At one point, I was a Naval Flight Officer that understood IT and the business impact that IT can have. Now, I'm a security and risk management professional

Remember - don't underestimate what you can bring to the table, even if you're in a "new" career field. Previous seemingly unrelated experience can be invaluable.