Wednesday, September 23, 2009

Security policy for CMS implementations

Something I've been looking at recently is the question of how to create an enterprise security policy for your enterprise CMS (DAMS, etc.). It comes, like many other things, to a question of investment and governance.

Security policy here can be described as access control for different user types in each participating business unit. In a CMS implementation, this would mean access for various editorial and production functions, staff and vendor access levels, and access across business unit content sets.

With an enterprise implementation across many business units, requirements come from two directions. The first is each business unit's requirements. If a business unit has not been part of an enterprise CMS implementation before, however, then they may not have given this much thought, and it may be difficult to document their true needs.

The danger here is that relying only on business unit requirements and maybe a few voices from other areas of the company means that security policy will be developed organically. One of the problems that this raises is inconsistencies with the initial business plan. An enterprise system is enterprise for a reason - and an organically developed security policy might end up reducing access for too many users, which may operate counter to the implementation goals generally. Therefore, perhaps an enterprise policy should be developed and maintained.

But there are dangers in relying only on an enterprise policy too, which will tend toward being heavy handed. Not knowing how each individual business unit works may lead to problems. Some who do critical content development or production work may find they are arbitrarily locked out of their work - causing all sorts of problems in rectifying the situation or in gaining acceptance of the CMS in the first place. In publishing, for instance, with the outsourcing trend has been pursued for many years, some critical functions in the publishing process are done by trusted freelancers or vendors who need high levels of access to content. A policy of arbitrarily drawing a line on specific user types (staff vs. vendor, etc.) may not be realistic with the current methods of doing business.

So the answer seems to be that both the enterprise and business unit security requirements need to be taken into account in creating a security policy for implementation. This may require an initial enterprise policy that clearly states the enterprise requirements, and which contains a governance model for adapting to individual business unit needs. Challenges in actually doing this stem from at first not recognizing the risk in a lack of governance for this issue, and then a lack of investment in analysis. A good analyst will propose an appropriately nuanced security policy and governance model that can be implemented for the benefit of all.