It is no surprise that computer programs are called "languages." They are written in complicated codes that are designed to send messages to a machine. The actual codes may be incomprehensible to the layperson, but they are designed to be efficient and translatable commands. It is not necessary to know precisely which languages your company's developers use, but it is helpful to know whether they use their own proprietary operating code, a code owned by someone else and licensed to you, or an open source code. (Often, it will be a combination.)

It is also a good idea to know the various positions in your IT group and learn what they do. It may look like they all just sit at a computer and type, but each specific function has a different approach to your company's IT needs. Sit down with the head of IT, armed with a copy of your IT organizational chart, and go through each individual function. Learn what each position does and which people need access to sensitive data.  

While you are at it, check out the innumerable network of connections that make your system run. Ask to see the list of IT assets and contracts that your company has amassed. You will probably find a variety of hardware and software among the assets, and likely a few contracts with vendors that power, run, support or supply the telecommunications services that run your network.

Once you have a handle on the people and the tangible and intangible assets and obligations, it is time to see what needs to be done from a risk management perspective.

What Is Mine Is Yours -- Or Is It?

As a risk manager, you know the importance of protecting what is yours and preventing the improper use of what is owned by others. In the IT world, protecting trade secrets is possibly the most important issue that companies face. Go back to your operating code. Your IT department has already told you who owns it, so now you need to figure out how to secure it. If it is proprietary code, it is probably important to you that no one copy and use that program without your permission. That means you will want as much protection as possible. That is tough to do these days, when there are often thousands, if not millions, of lines of code across multiple applications in a variety of servers, databases and storage devices involving dozens of developers, many of whom may be subcontracted or outsourced. 

Nevertheless, you will want to make sure that the IT department has done a good job of protecting your code by requiring developers to sign agreements noting the company's ownership and agreeing not to share it with anyone. 

If the code is licensed from someone else, a licensing agreement should be on file, documenting who owns what, for how long and at what cost. After that, you want to make sure that the code itself is secured and accessible only to those IT professionals and users that need to have access to it. 

If your code includes some open source material, the equation becomes a little more complicated. You may run into some problems if you are modifying the code and calling the modifications your proprietary property. If your legal group has not already checked out the usage of open source in your environment, you will want to get them on the case. There are few things as harrowing to a technology-driven company than a question of rights to use a core piece of software.  

Gatekeeping in the Electronic Age

Getting a handle on the intellectual property rights that your company has in its system is one thing. Making sure they stay protected is another. One of the easiest ways to address IT protection is to approach it like you would any other loss prevention program. For instance, you know that tangible assets and inventory need to be accounted for. You should already have a listing of your capital assets and inventory, and you have ways to prevent theft or leakage, whether it be through alarms, locks or security guards. But how do you protect the intangible? Surprisingly, it is not much different.

Start by developing an IT asset list. As with the list of capital assets, you should know precisely what kind of software your company uses. If you have licensed software and have loaded it onto your network, then you probably already have it listed as an asset, especially if the license term is for more than a year. Make sure that you have a good handle on the terms of the license agreement. Will it ever expire? If so, then make sure that your organization is prepared when renewal time comes around. Are there any restrictions on usage? Using software outside of its usage parameters can be expensive, especially if such usage results in intellectual property infringement.  

But what if you do not actually have any software, but rather use a subscription service that lets you load data onto someone else's pre-configured system and then pay for it on a monthly or yearly basis? Clearly, your company has no ownership interest in the system or the software that runs it, but the data-the very lifeblood that runs through the system-is yours and you need to take steps to make sure that it is protected.

Start by understanding precisely what kind of data is being loaded onto those third party systems. Most IT departments have data maps that document the type of information that is stored in a given place and provide direction to your computer system. For instance, a data map of accounts receivable will be directed to a database of payments made to determine which customers have paid or not paid in any given month. 

Sometimes, the data within one of those maps will include sensitive or confidential information that needs to be protected. Once you have properly mapped your data, you are on your way to protecting proprietary, confidential or personal information. It can be a laborious process, but creating data maps and ensuring the control of access to sensitive data is an absolute must for preventing unauthorized access.

Once you know and have categorized your data, look at your company's agreement with the IT vendor. Find out what representations they are making about confidentiality. What steps are they taking to ensure that your data is not commingled or leaked? More importantly, what responsibilities are they not taking? An IT vendor may blithely agree to take responsibility for data losses, but what exactly will it look like when there has been a breach? Most indemnification agreements include requirements that the party agreeing to indemnify the other (here the IT vendor) has the right to control any lawsuit regarding the breach. Do you really want a vendor handling a lawsuit regarding sensitive, confidential or proprietary data? Make sure that your legal group understands the sensitivity of the data provided to the vendor.

The Human Ghost in the Machine

As with any loss prevention program, the most sensitive component is the human element. Regardless of whether your company runs its system or uses a third party, the danger of disclosure exists as long as there are people with access to it. The best way to control the dissemination of data then is by limiting access. In fact, the process of controlling access to data has mushroomed into one of the most important sub-industries in the high-tech world.  

Access controls occur at virtually every layer in a network. Logging into a system usually requires a password. After entering the required information, a user will have to pass through a system's firewalls and demonstrate that he or she has access rights to a particular dataset. Data may be encrypted, making it useless to anyone without an encryption key, and it must survive scrutiny by malware or data-leakage prevention software. Back-up tapes can also be encrypted, and the entire operation should be located in a secure server behind locked doors. Still, if there is a person with the right skill and a rudimentary understanding of your operations, your data will be at risk.

Your IT department has probably worked with your human resources department to write and distribute IT policies and procedures. Hopefully, they have also arranged for your existing employees and new hires to acknowledge their IT obligations in writing. Remember that those documents are not always required of outsourcers and contractors. Make sure that those contracts are up to date and do not hesitate to ask those vendors what they are doing to ensure that their people keep your confidences.

Engaging Your IT Department

Your IT department has a lot on its hands, and would likely welcome some support. One of the things that risk management has in common with IT is the dubious distinction of being noticed only when something goes wrong. Thus, it is natural for IT and risk management to join forces and take the steps necessary to protect the company's interests.

The first and arguably most important thing to do is to acknowledge that, even with the best protections in place, something is bound to go wrong. Use your risk management experience to help your IT department build a viable disaster recovery program that is not only designed to get the system up and running again, but to do so efficiently and proactively. Make sure that there are security vendors standing by in the event of an outage and that the IT group understands its obligations to contact risk management to trigger whatever coverage may exist under an insurance policy.

Support IT's efforts to develop and implement best practices in the security realm. Help secure the most effective security controls that are available and quantify the impact of an outage or a data loss before one happens. Take the lead in finding and securing the services of third party vendors that exist to help data owners after a loss. Arranging to pay the costs of a loss before it occurs is far more cost-effective than waiting until after an event.

Pay close attention to your IT group's efforts to achieve levels of compliance with various standards such as the Payment Card Industry Data Security Standard, Sarbanes-Oxley or SAS 70. Offer your support when they ask for upgrades to their intrusion prevention system or their unified threat management system.  

Above all, do not be intimidated by the technical jargon or the rapid evolution of the high-tech world. Just like any other language, it is not entirely out of your reach. A basic interest and a little practice can go a long way toward gaining valuable understanding.

Written by: David Chavez

David Chavez is a senior vice president and technology underwriter in the San Francisco office of Hiscox Inc.

The above article is reprinted from the June 2010 edition of Risk Management Magazine.