Many IT challenges stem from unclear ownership of IT risks. People don’t talk about who owns what risk, and then when risks are realized people start pointing fingers (or cutting budgets).
If Admissions is using an IT-provided tool for recruiting, who owns the risk of that IT service failing? What if it’s just a little slow? What if it can’t import data from an Excel file that Admissions staff created? What if it can’t pull out its data in a useful way? What if Admissions purchased the tool against IT’s recommendation?
I’m going to call the space between what IT believes to be their risk, and what users expect IT to own, as the “risk gap.” Risk gaps most commonly surface with disaster recovery. Users expect IT can restore service immediately, so that no one knows the service ever failed. IT expects campus to have a campus disaster recovery plan and to have back-up manual processes.
When an IT tool is introduced, the risk gap is often huge: users expect IT to own all risk, but IT implicitly assumes very little risk. For example, IT may assume that users will not put FERPA data into an insecure system. Users may expect that IT has controls to prevent FERPA data from being added to the system.
Understanding common IT-related risks is a skill. IT tends to be more aware of the risks than users even if they don’t own the risks, because of their past experience and focus on risk management. Here are common risks that keep IT people up at night:
- PCI compliance
- FERPA compliance
- HIPAA compliance
- RIAA cease-and-desist letters
- Financial audit compliance
- PII exposure
- IT security threats (Huge body of knowledge; for example see ISO 27002)
- Backups & restores (e.g. how to make sure the backups are not corrupt)
- Capacity sufficient for demand (e.g. how to keep the registration system going)
- Disaster recovery, as mentioned earlier (aka IT Service Continuity Management)
IT’s understanding of risk leads them to be very risk-averse. IT people get fired for realized risks (e.g. if Blackboard data for the current semester disappears and cannot be restored).
What’s within IT’s control?
IT is not able to control many things that end up affecting their risks. As examples:
- What people are doing with the network
- What people install on their computers
- Where people collect credit card information
- Whether people have manual processes in case IT service stops working
It is unreasonable for IT to be accountable for these risks. Some of them are obviously not IT’s job–others are more questionable.
If someone installs Dropbox on their computer, and they then accidentally share FERPA data with the world, is it IT’s fault? The answer could range from “IT should not let people install programs like Dropbox” to “IT should offer training on FERPA data” to “IT should ensure all FERPA data is encrypted” to “That’s the user’s fault.”
Preventing risk can be very expensive
Because IT is risk-averse, and there are often no conversations about who owns what risks, IT may over-engineer solutions to prevent unlikely risks.
To prevent against any risk, IT might buy network load balancers, hot standby databases, data masking software, or high-cost storage systems. This equipment is not only expensive to purchase but it is expensive to implement and maintain. There should be an intentional design based on conversations with campus about risk before this level of redundancy or security is added to systems.
IT departments receive many questions about their budgets because of money spent planning against highly unlikely risks.
IT service value proposition: owning some of the risks
ITIL’s definition of a service says that customers should not have to own “specific costs and risks.” However, there’s a range of risks that IT could manage:
- IT ensures the mail server occasionally accepts mail
- IT ensures the mail server always accepts mail
- IT ensures users can always access the mail server
- IT ensures users have adequate mail server storage
- IT ensures that mail can only be read by the intended recipient
Some of these may be true. In a computer science department the faculty may be comfortable owning a lot of risk–they may run their own backups, for example. In another department, they want no risk. IT can own a continuum of IT risk for a service, ranging from “you’re mostly on your own” to “we will ensure you never have to worry about this service.”
As IT is able to own more risks, the IT service’s value increases.
Takeaway: Talk about risks
IT and campus need to talk together about risks. IT and campus can each see some of the risks. They need to work together to understand the significant risks. Risks can then be given owners, who can decide whether and how to address those risks.
These conversations can happen as part of a service level agreement. Risks can be assigned explicitly to BOTH IT and campus. Then, when it costs money for IT to mitigate those risks they have an advocate for why the service ends up being expensive.