Gartner Blog Network


What is policy anyway, when discussing IAM?

by Earl Perkins  |  July 30, 2009  |  4 Comments

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.

Category: 

Tags: classification  iam-policy  

Earl Perkins
Research VP
5 years at Gartner
32 years IT industry

Earl Perkins is a research vice president in the Security and Privacy team at Gartner. His focus areas include identity and access management (IAM), including user provisioning, role life cycle management… Read Full Bio


Thoughts on What is policy anyway, when discussing IAM?


  1. […] Earl Perkins of Gartner also has issue with confusing and over used terms.  Here is his recent blog covering the many definitions of “policy” in security and GRC.  It is very true that we […]

  2. Steve says:

    Praveen – I agree.

    I almost fell off my chair after reading this definition.

  3. […] What is policy anyway, when discussing IAM? "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:" (tags: policy definition earlperkins iam) […]

  4. […] by enforcing compliance through product policies (as opposed to technical policies – see Earl Perkins’ blog for more details) and by allowing reconciliation between the policy-based view of user […]



Comments are closed

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.