Ask most IT professionals about shadow IT, or technology brought into the organization without official sanction or oversight, and they'll tell you that it's a fairly common challenge. A recent Frost & Sullivan
From an IT standpoint, the challenges with shadow IT are obvious: economic inefficiencies because licenses are purchased singly rather than centrally and in volume; questions about support responsibility; technical concerns such as security or performance problems; the lack of pre-deployment technical/risk vetting; contractual issues (or the lack of them) and numerous other potential obstacles.
But while these concerns are more obvious, shadow IT is often under-the-radar for compliance practitioners. Shadow IT visibility is usually lacking for compliance pros: Specific shadow IT use examples are unlikely to be communicated to the compliance department through formal channels. As a result, shadow IT is a potential blind spot for compliance professionals and one that creates potential surprises during an audit and deviates from regulatory mandates.
The 'shadow' cast on regulatory compliance
It's important to understand how shadow IT can lead to potential regulatory compliance concerns. On the surface, it's not much of a mystery: A user entering regulation-related data such as personally identifiable information or payment data into an unvetted application or storing that data on an unapproved personal device creates obvious compliance concerns. There is no doubt that these example are of concern, of course, but the compliance issues extend much deeper than that.
By understanding the motivators for shadow IT, we get the best of both worlds: better service for the business and the opportunity to safeguard it responsibly.
Consider compliance mandates that require inventories. For example, there are HIPAA's §164.308(a)(7)(ii)(E) ("Assess the relative criticality of specific applications and data…") and PCI DSS 3.0's requirement 2.4 ("Maintain an inventory of system components…").
Under HIPAA rules, any clinical application, regardless of who in the organization sourced it, is a potentially critical application that should be included in your analysis. It's the same with a SaaS application that intersects with an organization's common desktop environment: The app should be considered a "system component" under PCI DSS rules even if that application was brought in by someone outside of the organization's IT department. PCI DSS specifically references applications in the definition of "system components."
Inventory is just one example. Many other regulatory mandates might apply to shadow IT, depending on where and how the technology in question is used. After all, how would a compliance professional learn that these technologies are being used? Unlike IT, you aren't likely to get requests to help support an under-the-radar SaaS application. Compliance is also not likely to get a call from an employee asking you to connect their new tablet to the network.
IT shops rarely have a formal policy for tracking shadow IT when it's encountered, and it's even rarer for them to publish that list to non-IT stakeholders. As a result, the first time members of the compliance department learn about shadow IT use might very well be when an auditor informs them.
Ensuring shadow IT compliance
First and foremost, your organization's compliance officers should seek a communication channel to inform them about shadow IT when it's discovered. Just like they probably have mechanisms and relationships where they learn about new, approved technology use, those same mechanisms can be used to address shadow IT. For example, enlist partners to notify you (formally or otherwise) if they learn about unexpected, unapproved or unmanaged technology use. Members of the IT department are particularly useful, as they are often the first to learn about shadow deployments.
Ramsés Gallego, international vice president for ISACA, said cultivating this relationship is very important.
"I firmly believe that now is the time to build bridges between IT and other areas of the business -- engage them in a two-way conversation to help [them] both get to a greater understanding of the issue."
Gallego suggests that doing so allows compliance professionals to understand the motivators for the shadow deployment in the first place.
More on technology deployment and compliance
FAQ: How does shadow IT influence GRC processes?
"The everything-as-a-service mentality has made it possible for the business -- the real users of technology -- to buy specific technology that fulfills important needs in a matter of hours," Gallego said. "By understanding the motivators for shadow IT, we get the best of both worlds: better service for the business and the opportunity to safeguard it responsibly."
As you build this communication framework, consider enlisting other sources such as purchasing, finance or accounting to open up additional avenues of data investigation.
Second, during the course of activities you're already involved in, try to identify and flag new and potentially unmanaged technology deployments. For example, if you're conducting a business impact assessment to support business continuity planning or to create regulatory-mandated inventories, ask about technologies brought in without IT oversight. If you're conducting an audit, keep an eye out for any new or unexpected technology deployments.
It's helpful to maintain an inventory of these deployments as you come across them. You can use an inventorying tool if you have one or even just input the data on a spreadsheet if you don't.
Lastly, as new technology deployments are discovered, leverage existing risk evaluation and reporting processes to evaluate risk and potential areas of noncompliance. Also keep in mind that any unauthorized tool may be used for several processes. It's important to understand and make note of the technology's appropriateness in your regulatory ecosystem and to determine potential further compliance concerns if its use expands.
About the author:
Ed Moyle is director of emerging business and technology at ISACA. He previously worked as a senior security strategist at Savvis and a senior manager at CTG. Before that, he served as a vice president and information security officer at Merrill Lynch Investment Managers.
This was first published in February 2014