Contrary to what some may think, analysts of different firms do get together and talk from time to time. We are invited to many of the same vendor and industry summits, and it’s inevitable that you end up at the same food table or in the same sessions. The occasion is very much like when competing wrestlers get together, except the friendly slap on the back when you see them doesn’t hurt so much. :-/
One of our colleague firms made reference to the fact that policy management wasn’t discussed nearly as much as it should be in IAM when talking about the lifecycle of IAM. We could not agree more on that. Some of our previous research has talked about this, notably one of our summit presentations by Chris Byrnes that I truly like: “Policies: Proactive Plan for Protection or Purposeless Pile of Paper?”. After all, when we plan for IAM design and configuration, a good part of it focuses on the instantiation of access and acceptable use policy into living controls in the enterprise.
But there is a niggling problem I have about the discussion. Whether described by vendors or analysts, we often assume to much on the part of the audience (the customer, the press, one another) that we understand the definition of policy in the context used in that discussion. I’m personally irritated when I’m in wide-ranging briefings where “policy” is thrown around as much as “management”, or an even more abused favorite, “services”, without providing the audience with a basis for understanding. Many of us believe we already know the definition of policy (e.g. ” 1-course of expedient action or procedure, often pursued by government”, “2- a procedure, guiding principle, plan or course of action, intended to influence and determine decisions, actions, etc.”, or my personal favorite “3- prudence, shrewdness or sagacity in practical matters), but that only helps frame the discussion. What exactly are the types of policy we deal with in IAM? In my simplistic brain, I at least try to frame the discussion along lines like these:
(1) Corporate policy: the basic business policies, written in plain language, the actions of guiding principles, the enterprise plan of action. Sometimes that policy may have indirect references to IAM in the form of risk management, but it is basically the highest form of policy focused on, well, business matters;
(2) Business policy: often mistaken as the binder that isn’t read much, this policy gets more specific about the procedures and plans that remain relatively consistent in an enterprise, capturing a ‘success practice’ or best practice approach to the rules of work and providing more specific direction to IAM planners. A good bit of technical direction is actually available here when business policy is well written, but only if there’s a mapping or translation expertise to get those policy directions into
(3) Technical policy: this is the converted form of business policy into IT procedures and rules of action. I like to think of these as specific rules or guidelines regarding matters such as access, protection of data, etc. Business policy provides the direction for these technical policies, but technical policies are needed to guide IT organizations in now to deliver detective and preventive controls through (among other things) IAM;
(4) IT product policies: I often find vendors actually talking about “policy” at this level, i.e. the code written to make a particular product work according to specific rules. For example, if I look at rulesets sometimes used with entitlement enforcement to separate specific types of access with the same role, I consider these IT product policies, since they’re structured for use within that product. These policy types may also be written in plain language, but often have specific syntax and input mechanisms.
I’m sure there’s more than one way to slice this policy picture, but the point being made here is that it needs to be sliced. We need to make sure we understand where we are in the policy discussion, what relationships to different policy categories exist and what proposed policy products (alliterative, eh?) really do in the larger scheme of policy management in the enterprise.
Read Complimentary Relevant Research
Top Strategic Predictions for 2019 and Beyond: Practicality Exists Within Instability
Technology-based change is happening continuously, and most organizations struggle to see the change in advance. Continuous change can...
View Relevant Webinars
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.