Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
· Home
· Content
· Feedback
· News
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: otawudav
New Today: 16
New Yesterday: 43
Overall: 231631

People Online:
Visitors: 132
Members: 0
Total: 132



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

NOTE: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - People related info on CMDB
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

People related info on CMDB

Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management
View previous topic :: View next topic  
Author Message

Joined: Mar 08, 2005
Posts: 36

PostPosted: Tue Apr 18, 2006 11:21 pm    Post subject: People related info on CMDB Reply with quote


The Service Support book talks about storing people related information in the CMDB. There is a statement which says

"The CMDB may also be used to store and control details of IT Users, IT staff and business units, although the legal implications of holding information about people in the CMDB should be considered."

What kind of legal implications do you think is being mentioned. I would be interested in knowing your views on this.
Back to top
View user's profile
Senior Itiler

Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Wed Apr 19, 2006 1:04 am    Post subject: Reply with quote

These days most countries (if not all) have some kind of regulatory framework in place that governs (at the very least) how personal information may be used (more stringent legislation governs things like required security, disposal, sharing, etc., et - and the ever important question of liablity for misuse).

This will vary considerably in scope and intent from country to country so no specific advice should be given - in fact anyone without some legal training and knowledge of the applicable statutes should not be advising you.

Fortunately most HR departments will be fully appraised of these issues and can advise you. They probably also have internal policies governing access and usage. HR may not have considered IT a legitimate user of some personnel information in the past, so be prepared to answer their questions and do some extra homework if necessary.

Practically, however, in most cases IT will already have quite high levels of access to information systems with personnel info on it. Really it isn't a matter of 'putting' personal information in the CMDB, but integrating ITSM process with HR information, under the guidance of existing company practices and policies.

If you are in an oraganisation too small to have a legal dept. there will be a local small business advisory arm of a relevant govt department in your part of the world, who will probably have a fair bit of prepared material answering any legal questions.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Senior Itiler

Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Wed Apr 19, 2006 4:37 am    Post subject: Reply with quote

Hello Arnoldmram,

I would agree with RJP that you defer to your HR department for the details on what is considered confidential, before you choose to put it into a CMDB.

Typically, what is considered confidential is usual some identifier that correlates to a government identification. For example, in the US, Social Security numbers, Driver's License IDs, Passport IDs, etc. are considered confidential and cannot be stored in general repositories where users with no "need-to-know" have access to the information, such as in the case of a CMDB. We know this because we actually have completed the full representation of Resources and Organizations in our CMDB, along with all other trackable entities, and there was a significant amount of conversation around confidentiality. In the end, we found that very little is considered confidential.

Even in the case of a smaller employer, such information is not allowed to be shared with other employees and, therefore, should not be in a public repository.

One thing to keep in mind is that "anything" can be kept in the CMDB if you implement true "need-to-know" security entitlements and authentication around such information.

I hope this helps.

[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Senior Itiler

Joined: Apr 26, 2005
Posts: 57

PostPosted: Sat Apr 22, 2006 5:32 am    Post subject: Should People info be kept in a CMDB? Reply with quote

hi, I agree with both RJP and Guerino1 if you where to implement people into your CMDB.

I would like to share the approach that most organizations, if not all, already have a people database. Its called an HR database. I have found many people want the CMDB to store everything within the IT organization. If you choose to do that, you will find yourself with a CMDB that is so large and complex, that is difficult to manage.

So to address this, use a federated approach (the latest buzz word). A federated approach is to have a link to your HR data within your CMDB. When you need people info, link out to the HR data and retrieve what you need. There are other things to consider with this approach; who can update info; who owns the data; which version will be considered correct etc.

You may find this easier to implement as you don't have to worry about what data can be made public, who can see what, etc.

By identifying what you want your CMDB to be and how it will be used, will help in answering the question, do I add people?


Back to top
View user's profile Send e-mail
Senior Itiler

Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Mon Apr 24, 2006 8:18 am    Post subject: Reply with quote


In addition to Azard's recommendation, I would like to recommend you evaluate another option, as well.

If you work for a company who is not in the business of building and selling CMDBs, I would strongly recommend that you look at the option of purchasing one that is already complete.

What we find is that developers will go off and build things that they're interested in without the formal approval of the enterprise they work for. This means the developers are not putting their organization's resources to the kind of use that owners of the organization would prefer to see. As a result, this will cause problems in the future for the organization. You should consider that whatever you're building has already been built by a vendor. If your organization is not specialized in building solutions, such as a CMDB, you are going down a path that is lose-lose for your enterprise.

First, if you're organization does not have the formal expertise necessary to build such solutions, you must understand that you will not build a complete solution anytime in the near future. Everything that is necessary to build a formal and complete CMDB is very elaborate and requires a tremendous amount of development and investment, over years of design and implementation. What this means is that your organization will never have a complete solution. Whereas a vendor who is specialized in providing such solutions will provide a far more complete solution, out of the box, than you can ever provide. They had a head start and have dedicated staff to keep building it up.

Second, if your organization is not formally in the business of building and selling such soutions, then you may be (or will be) taking and spending resources, such as time, money, people, and energy that belong to your company, without their formal permission, agreement, and blessing. If you do this, then you are violating the fundamental trust they put in you as an employee of their firm. Most company owners will believe that their resources should be better spent on efforts that generate revenue for them.

For these reasons, I strongly recommend that you discuss your need for a CMDB with the people in your organization that drive direction and revenue generation. I'm sure they're very smart people and will understand your needs. In having these discussions with them, I recommend you propose both the "Build" vs. "Buy" options to them, being honest about factors such as your expertise levels and what they truly can or can't expect from either solution. They will make the decisions based on their expertise and common sense. And, even if they make decisions you are not happy with or disagree with, you should keep in mind that it is, in fact, their decision to make, not yours.

While I know it is very attractive for developers to go off and build something new, especially something they feel they can learn from or need for their own day-to-day work, I feel it is important for developers to understand that they are spending someone else's money to do so. I have found that more often than not, the owners/strategy setters of an enterprise do not agree with the vision of the developers and would not allow such projects to move forward. If this is the case, and developers continue to build something "because they feel they need it" or because they think it's a very good way of "learning" then the driver for building such solutions should honestly be re-evaluated.

To be honest about where my views are coming from, my company is in the business of providing a formal CMDB and the above recommendations come from the fact that most enterprises are very upset when they find that their developers went and built something that had nothing to do with their core business and for which they never got formal approval or funding for. What we've found is that developers who have built their own solutions usually create a tangled web of dependencies that a company cannot easily undo, making it even more expensive to own a custom solution, in the long run.

I hope this helps you in your endeavors.

[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website

Joined: Mar 08, 2005
Posts: 36

PostPosted: Tue Apr 25, 2006 3:21 pm    Post subject: Reply with quote

Hello all,

thanks a lot for your thoughts on this. I really did not imagine so many dimensions to a thing like people realted information in the CMDB.

Thanks again
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management All times are GMT + 10 Hours
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003

Forums ©


Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.