Six questions you have to answer about technology risk in the AI age

And how a wall-mounted storage controller shows all technology management is risk management

One of my favorite small data centers used to be in Westchester County, N.Y. (For our younger readers, any enterprise technology organization of any size used to have, and sometimes still has, specialized facilities to…oh, never mind.)

The first time I visited, I noticed a controller from a fiber channel storage frame mounted on the wall. I asked the crusty old infrastructure leader about it. He explained: “That was from the first fiber channel frame we ever bought. We used to have to get up in the middle of the night every time a direct-attached drive failed. As soon as we put in a storage area network, we didn’t have to get up in the middle of the night so often. So when it came time to retire the first frame, we mounted the controller on the wall in the conference room because we appreciated it so much.”

All enterprise technology management is risk management. Building a demo? Easy. Deploying a production system that runs all day, every day, with scalability, with security, and compliant with regulatory mandates? Much harder. CIOs, CTOs, and their reports spend much of their day doing risk management. Using a new technology versus a well-established one? Allocate more or fewer resources to an effort? Run more or fewer test cycles for a new application? All decisions trade off cost or capability against the likelihood of a bad event happening.

How much does technology risk management change, given the advent of AI? As with everything else in enterprise technology right now, the complexities and opportunities expand, but the underlying constructs remain the same.

Technology risk management involves a series of questions that CIOs, CTOs, and CISOs should ask.

What are the business-technology risks you worry about?

Unencrypted data is not a risk. That’s a vulnerability. Ransomware is not a risk. That’s an attack vector. Not being able to run your plants is a risk. An offshore competitor getting access to intellectual property worth hundreds of millions of dollars is a risk.

Traditionally, companies have thought of business risks in terms of confidentiality, integrity, and availability—whether bad actors will get access to your data, whether you will question the validity of business transactions, and whether your systems will be able to run business processes. Most frameworks are bunkum—this one stands the test of years. I would only add compliance and delivery—whether you will stay on the right side of regulatory mandates and whether you will deliver promised capabilities required by the company’s business strategy. So “CIA” becomes “CIACD.”

Notice there is nothing about security in that framework. Some businesses have elevated their CISOs to be CTROs (Chief Technology Risk Officers), but most, for reasons I have never understood, continue to segregate cybersecurity from other types of technology risks. No customer who couldn’t access account data has ever cared whether the cause was a DDoS attack or a misconfigured router. The result is the same.

While all the external risks remain, GenAI introduces a new class of integrity risks, resulting from hallucination, subversion, and improper use. In updating technology risk frameworks, technology executives need to think through all the ways that non-deterministic systems might return nonsensical results, the implications of attackers compromising models, and all the ways that employees might use AI slop in place of human thought.

What is your risk appetite by business domain?

One well-respected CISO liked to say his job wasn’t to eliminate or even necessarily reduce risk. His job, he said, was to help business leaders take intelligent technology risks, justified by likely business value. Which leads to the obvious question: how much risk is the right amount of risk? Many companies try to answer this question by establishing a risk appetite. Unfortunately, they often use generic and qualitative risk appetites, stating that the company has minimal tolerance for downtime or zero appetite for loss of customer data.

How might a CIO, CTO, or CISO make decisions based on this type of appetite? It’s impossible. Instead, companies need to set quantitative risk appetites by business domain. How many minutes of unplanned downtime per year will the company accept? How many open audit findings?

While much remains the same in setting risk appetite in the age of AI, new types of business risks will require new types of risk appetites. For example, how many incidents of hallucination would be acceptable for a customer-facing technical support process?

What control objectives must you have in place to achieve your risk appetite?

Technology managers put controls in place to mitigate technology risks. They scan code for vulnerabilities. They encrypt data. They place systems on segmented networks. They monitor environments for intrusion.

Historically, many technology organizations have thought about controls in terms of maturity. This is necessary, but not sufficient. Yes, there is a baseline level of controls organizations must have in place to achieve good hygiene—but that doesn’t necessarily mean you’ll be within risk tolerance or achieve your risk appetite, especially for critical business domains or applications. In these areas, architects need to think through risks and threats and determine what combination of controls will ensure less than, for example, sixty minutes of unplanned downtime per year.

Based on that thinking, architects can specify precise control objectives—e.g., all customer personal information must be encrypted at rest or all systems supporting critical business processes must use two-factor authentication.

How will changes to the environment affect your risk posture?

Every change you make to your environment changes your risk posture. New businesses, new vendors, new products, new applications, new technologies, and new jurisdictions all change your risk posture in a way that might alter your ability to achieve your risk appetite. For this reason, different parts of technology organizations spend countless hours doing risk assessments—vendor risk assessments, product risk assessments, application risk assessments—to understand, for example, what control objectives might be relevant for a new application.

At best, architects build threat models to assess what could go wrong with a new system or a new technology. At worst, project managers mechanically fill in checklists or scorecards.

As AI evolves, architects will need to develop the muscles to do threat analysis for agentic systems—and game out all the things that could go wrong when your code is non-deterministic.

At the same time, GenAI can both diminish the toil in and increase the reliability of risk assessments. For example, you can use the interrogative power of GenAI to compare architectural documents with risk and security standards—eliminating hours of manual review. You can also use GenAI to correlate results from risk assessments with production incidents (and other lagging risk indicators) to improve risk assessment tools over time.

Does your control coverage support your control objectives?

Few breaches or outages I’ve seen result from insufficiently stringent policies or standards. Most result from incompletely implemented controls. Few things have more power in managing technology risk than knowing to what extent the controls you want to have in place are in place. If I could report on only one number on technology risk to the board, it would be: percent of critical systems fully adherent to control objectives.

Everybody agrees that Risk & Control Self-Assessments (RCSAs) are thin gruel. Most professionals agree that we need to get to continuous control monitoring—where you can see in real time which controls you have in place for which systems and how that compares to your control objectives.

Data integration makes this difficult in the cloud, even with Cloud Security Posture Management (CSPM) tools, and traditionally all but impossible in on-premise environments. Fortunately, GenAI allows you to “look inside” the data set (rather than just the field name) when correlating exhaust data from the array of tools you use in your environment. This makes it much easier for you to develop a programmatic (rather than survey-based) view into control coverage.

Are your controls collectively effective?

Just because your controls are in place doesn’t mean they are effective. They must work in concert to protect your environment from a determined attacker or simple blunders. Traditionally, companies answered questions about control effectiveness via testing—but this only scales so far, even if you can afford a dedicated red team organization.

The combination of GenAI and knowledge graphs provides a fascinating complement to traditional testing. You create an ontology describing the elements in your environment (processes, systems, technology elements, controls) and model them using a knowledge graph—the nodes and edges in a graph much better mirror a technology environment than the relational databases that most common configuration management databases (CMDBs) use. You can use GenAI to interrogate exhaust data from your tooling (as well as architectural documents) and hydrate a knowledge graph. This provides you with a digital twin of your environment you can use to model different risk scenarios.

Nothing gets easier in technology risk, but sometimes the opportunities get bigger

Nothing ever gets easier in technology risk. The expectations get higher and the environments more complex. AI, especially GenAI, adds yet another layer of complexity, and brings with it a new set of risks that enterprise technology organizations will need to manage. But GenAI, sometimes in conjunction with knowledge graphs, also creates new opportunities to orchestrate data and manage risk in a fact-based and scalable way.

A data center anecdote

[I didn’t include this up top because ChatGPT scolds me for letting my writing get too discursive. Pearls before stochastic swine! The data center mentioned above was pristine. Every cable color-coded and perfectly aligned. As close to ship-shape and Bristol fashion as I’ve ever seen in a data center.

I expressed my admiration to the facility manager. He barked at me: “That’s the way I learned to do it in Vietnam!”

Photo credit: HistoryNet.Com

He explained that he had gotten his start in the technology game as a non-commissioned officer in Vietnam. The United States deployed field computers in Vietnam as part of Fire Direction Centers to control artillery. Like others, he created a little data center in a tent with power generation, fans, and cooling to keep the computer running in an unfriendly environment.

He further explained that they tended to put explosives underneath the floor of the tent, so they could blow the computer up rather than let it fall into enemy hands. One green lieutenant that the facility manager had known got himself court-martialed when he panicked and prematurely destroyed one of Uncle Sam’s expensive computers.]