How to Talk About Information Security Risks

Computer BurglarOne of the weakest areas of subject matter expertise for most IT project managers is information security. The problem is compounded by the fact that most of our project stakeholders are even less expert than we are.  Consequently, conducting an adequate security assessment of our projects can be difficult. We want to identify real information security risks and understand both the probability of a security-related event and the potential impact, but we don’t have the expertise for it. Most projects will have access to an information security expert who can provide guidance, but that expert won’t necessarily understand the work at hand or the products we’re using or developing. The trick is to establish a meaningful vocabulary.

Threats, Vulnerabilities, and Risks

A Threat is a potential source of harm. This can include human sources, both internal and external, as well as non-human sources like malware. Certain types of information will attract certain types of Threats; other types of Threats are pervasive, and the content won’t matter as much. In some cases, a specific Threat may have been identified, based on their previous behavior. It is possible to trace distributed denial of service (DDoS) attacks or intrusion attempts, for example, to their source. In other cases, a Threat may be perceived, such as the potential for harm from employees who want access to their colleagues’ compensation data. This sort of Threat may be somewhat non-specific, but is still identifiable.

A Vulnerability is a weakness that can be exploited by a Threat. A Vulnerability can be in application software, or the underlying networks and systems. It can also be in people and their behaviors. It can even be in a business process. Weak passwords are a Vulnerability. An unattended workstation with an open application is a Vulnerability. Transmitting data outside the system of record, whether in a user-requested report or an interface to another system, is a Vulnerability.

An information security Risk is thus a function of the likelihood that a Threat will exploit a Vulnerability, and the potential impact of that event.

Responses for Information Security Risks

As you might expect, risk response strategies for information security risks fall into the usual categories: Avoid, Mitigate, Transfer, and Accept.  Here are some examples for each strategy:

  • Avoid: limit access to sensitive data via role-based security, enforce password complexity and aging rules, and de-provision accounts when a user no longer needs them.
  • Mitigate: encrypt data in motion and at rest, devise continuity of operations plans, and monitor failed logins in order to detect possible intrusion attempts.
  • Transfer: use a single SFTP site in the network DMZ for the entire organization to support file transfer outside the firewall, use a robust single sign-on solution for all applications, and outsource DDoS detection and response.
  • Accept: allow users who are authorized to view data in the application to save reports in Excel, make role exceptions for specific individuals who need access in specific situations, and allow delegation of authority for specific application business processes.

Note that many of these strategies may already be required by policy. However, members of the project team and stakeholder community should still be participants in making decisions on how these strategies will be implemented.

Image courtesy of chanpipat /

This entry was posted in Risk Management and tagged , by Dave Gordon. Bookmark the permalink.

About Dave Gordon

Dave Gordon is a project manager with over twenty five years of experience in implementing human capital management and payroll systems, including SaaS solutions like Workday and premises-based ERP solutions like PeopleSoft and ADP Enterprise. He has an MS in IT with a concentration in project management, and a BS in Business. In addition to his articles and blog posts, he curates a weekly roundup of articles on project management, and he has authored or contributed to several books on project management.