Home > Uncategorized > What’s our Policy on That?

What’s our Policy on That?

Companies of all sizes continue to struggle with information security policies or other rules designed to help protect their information. In 30 years of information security practice some issues come up time and time again that contribute to the problem of inadequate information security policies. While few would argue the need to have actual policies about information security, often that’s where agreement stops. The concept of having policies, defining policies and enforcing them is often more than a little controversial for many companies.

Most information security policies evolved out of the old familiar “do’s and don’ts” set of rules.  Often times the do’s and don’ts were the least controversial of policies and included such things as guidance on what not to say in an e-mail, how to handle confidential company information, what usage of the Internet is permissible, and so forth. Too often the do’s and don’ts policy was a clone of a year’s earlier article in an HR manager journal and has received almost no attention since then.  Companies often lack the resolve to use the do’s and don’ts policy as a basis for disciplinary measures of any kind, let alone as the basis for termination.  However, the one thing the do’s and don’ts policy did enable everyone to do was to righteously claim, “yes, Boss, we do have an information security policy.”

The do’s and don’ts policy almost never covers important areas such as business resumption planning, compliance, systems development, and other areas. Upon review of a draft of a comprehensive ISO 27002 based set of policies I’ve had a client’s systems development manager cross out every mention of systems development because he was simply unwilling to acknowledge that systems development played a role in effective information security or was unwilling to allow another part of the company to define policies that might actually affect the behavior of professionals within the systems development organization. Similarly, I’ve seen network and operations managers attempt to exempt themselves from rules about the secure management of networks and operations when it becomes apparent that a comprehensive policy usually covers those areas.

A major gap in most do’s and don’ts based policies is the lack of a clear differentiation of roles within the organization and an additional set of rules for managers within the organization. Managers have a higher standard of behavior when it comes to information protection. Unless you believe that security is someone else’s job managers throughout the organization have some basic roles and responsibilities that must be acknowledged, trained in, and complied with before any organization can claim it has reached the first step in effective information security policy governance. Among these special manager obligations are approval of access requests, answering of subordinate questions about situations where security potentially conflicts with other operational objectives, implementation of security controls needed within individual organizations,  regular review of open access requests on file, etc., etc. An organization desiring to move past the evolutionary do’s and don’ts policy should focus on the manager’s role and how managers contribute to better security of organizational information.

Beyond the manager role, other roles may need to be defined that capture the reality of effective policy-based governance inside the organization. For example, internal IT auditors often require read access to a broad array of information they use in order to perform their jobs. It is important that this access be read only so that they can retain effective independence from any information integrity issues that may exist.  Another area for special role based policies focuses on special rules for those who have administrative access to systems. Such matters as snooping through e-mails without specific direction and authorization by upper management are covered here. Also, policies that define when a privileged account may be used versus a personal account are examples of special case situations that need to be part of the overall policy fabric to protect those with high access and also to reassure others that policies are not just about being “trustworthy.”

Policy should fit the organization. It may make sense for policies to define the over 200 standards needed in a typical ISO 27002 based policy set. However, if it is a very small organization or a relatively immature organization in terms of either established business operations or the experience and maturity of those who work in the organization it may make sense for policies to be at a more summary level as a way to put a toe in the water of governance without overcommitting the organization to structure it can’t cope with. One inflection point that can be used effectively in this regard is the use of imperative language versus merely providing guidance or passive voice policies as a first step in policy language. In an immature company facing its first policy need, it may make sense for the “do’s and don’ts” policies to be defined with imperative language. For example “passwords must not be shared with others.” But for higher-level concepts passive voice may make more sense.  For example, “At Acme Company employees must protect Acme-confidential information.  Here there may be 100 standards eventually defined by Acme Company to protect its data. But if the desire is to get on the scoreboard and start a discussion, a passive voice statement such as this is often the best route to take.

A major issue in the adoption and uptake of policies by large organizations is the complete failure or in adequate socialization of the policies throughout the organization. Senior management must be personally involved in the overall effort and communicate that involvement and the importance of success in policy-based governance personally to the organization. When the CEO has taken time to write a paragraph or to deliver a 3 min. video message to all managers and employees about the new information security policies, everyone will know that their attention is required.  Further, managers within the organization must receive their own message that their acknowledgment and support of the information security policies is critical to the overall success of policy-based governance. Many issues are avoided by effective socialization. The “book on the shelf” reputation acquired by many policies is an example. If the policy manual is never consulted except when an outside entity such as an auditor or a consultant asks, they are not providing much value to the organization.  Yet another pitfall of inadequate socialization: when the policies are only dusted-off so they can be used in a punitive way but no broad effort is ever made to encourage compliance.  Avoid these issues by effectively socializing your policies through the organization.

Finally, culture is an extremely important yet poorly understood aspect of policy-based governance for information protection. How does your company articulate policies and rules that everyone understands and observes? Make your information security policies align in language and tone with the best of the policies already in place within the company. Here an example might illustrate the issue. Many years ago the IBM company purchased a Silicon Valley-based maker of telephone equipment called Rolm. Shortly after the deal was closed, two senior IBM executives showed up at a regular Friday afternoon get-together of Rolm employees. The IBMers had on their suits, white shirts and ties and were rather startled to see T-shirt clad engineers gathered around a beer keg enjoying a quintessentially Silicon Valley social event.  At that time, alcoholic beverages of any kind were prohibited at IBM premises.   It took a minute for the IBMers to get oriented and understand that the correct response in this situation was not to go over and shut down the beer and give Rolm managers a stern talking to. Rather, the IBMers were the ones who needed to adapt and their ultimate adaptation arguably helped IBM on its journey to a new leadership role in technology when so many of their competitors of the era would fall by the wayside. Culture is important and cannot be forgotten when defining policy about something most knowledge workers think about every hour of every day on the job: how they handle and protect company information.

Categories: Uncategorized Tags:
  1. No comments yet.
  1. No trackbacks yet.
You must be logged in to post a comment.