Things have sure changed a lot since Larry and Sergey borrowed a few 4-gigabyte disk drives from Stanford so that they could have enough storage to develop their Google algorithm in 1996.

We have since seen some empires rise and fall in the tech world, most spectacularly perhaps the original dot-com bubble of 2000. In the ensuing years, we have seen major disruptions like YouTube ultimately leading to Netflix and Hulu. We rarely use keyboards anymore given the super-computing touchscreens we carry in out pockets. Pick your own example - things move fast, and every new success likely replaces something old and successful.

Within organizations, we have seen similar ebbs and flows in the major functional areas. Back in the middle 90s, the IT guy was something of an enigma, but soon became a star player in most organizations. When they brought on services like Akamai they looked like absolute geniuses (I still remember that day - the day the pages loaded). They had control of arcane bits and pieces, and the technology they were working with was hardly interoperable (in fact quite the contrary, most of the bigger players were trying to maintain dominance via an inability to communicate with competitive products.) Soon these heroic efforts were rewarded, and Technologists and Engineers became major players on both budgets and results.
Trusting SaaS Technology: Sanctioned, Suffered, and Shadow IT

Now, of course, we have a new set of technology - tech that is not only is based upon interoperability but works the way it's supposed to most of the time. Add to that the new full stack developers, who are only too happy to test their code; Agile Development, which releases us from the bureaucracy of Functional Requirements Documentation; and even video, which further democratizes the solutions to coding issues through its on-demand/show-don't-tell pedagogy.

But at what cost.

Trusting SaaS Technology: Sanctioned, Suffered, and Shadow IT

We have discussed a few methods for identifying your full SaaS portfolio (and the importance of doing so), so now I'd like to explore the range of trust you are likely to have in any given app.

Sanctioned IT

These are the backbone of your organization - they were brought on with much fanfare, and endured a fair amount of scrutiny for their security procedures and expected returns. Probably, they

  • have SSO
  • have good administrative visibility and analytics
  • have the ability to quarantine compliance or policy risks (systems or users) at a moments notice
  • have executive interest and visibility

Suffered IT

You know these products exist. You know the folks that use them and (probably) why they like them. They sent you an article about the app before they started using it. Although not officially sanctioned, you have enough knowledge about them not to be too concerned on a day-to-day basis.

Shadow IT

Here's the scary stuff - venturing into the unknown unknowns in the Johari window of Donald Rumsfeld (and project managers). Shadow, or Phantom IT, includes rogue and legacy purchases or installations of apps or even trials committed by whomever whenever. Sure most of it is probably innocuous, but remember even the mighty Google's "don't be evil" mission is only good for as long as the leadership of Alphabet adheres to it. So it is in your best interest to suss out any shadow IT as early and as often as you can.

Conclusion

When strategizing about your IT and SaaS portfolio, it is helpful to classify whether or not any given solution or app is sanctioned, suffered, or shadow IT. Then you can make the decision about whether suffered or shadow solutions should be sanctioned or shuttered.

 

Click Here To Discover Meta SaaS

Did you enjoy this free article? If so, please share it:

Read Other Articles About: Security