One Security Policy Document Or A Series Of Documents?

Plan First: We all know that it’s advisable to create a plan before undertaking a large and complex project. For instance, most reasonable people would not consider building a modern residential house, with plumbing, heating, electrical, lighting, and communications systems, if they did not first have a clear and specific plan (aka blueprint). Of course, all of these systems could be added-on after the house was built, but the result will look jury-rigged, function much less efficiently, and be subject to breakdown in ways that would not plague a well-planned house.

The writer of new or substantially revised information security policies faces a similar situation. Yet many of these policy writers, especially the ones new to the task, think they can just slap a few sentences together (ideally sentences copied out of somebody’s book or another organization’s policy statement). After they do this, they think they’re done, uttering words like “there you go.” Those who have been down the security policy development road before, particularly those who have revised policy statements written by others, well … to be kind, let’s just say they know better. The surprisingly high level of complexity in the modern information security environment is revealed in these moments.

So here’s the practical advice: to keep your job as well as your good reputation, if you’re writing information security policies, be sure to sketch out a plan for the structure of the policies before the policies themselves get written. This structure for policy statements should define the titles of, scopes of, and release dates of specific areas to be addressed in the information security policies.

Risk Assessment Directs: There are of course a few types of security policies that apply to everybody, such as an access control policy based on the need to know. Beyond those, things get a lot more complicated. The types of policies that need to be written will be reflected by a recent broadly scoped information security risk assessment. If, for instance, the risk assessment speaks to risks associated with the release of classified government information, then a set of policies consistent with the department of defense would be appropriate. Alternatively, if the risk assessment talks about the risk of unauthorized software copying, then a separate set of policies — perhaps addressing access controls which prevent the downloading of any unauthorized software — would be appropriate.

A well-known intellectual property attorney recently mused about writing information security policies in a conversation with the author, saying: “The law doesn’t require that you be perfect, only that you’re taking prudent steps, and clearly making demonstrable progress.” To have a schedule for the release of various policies, with dates, and scope statements, and titles — that type of documentation can indicate that your organization is addressing what needs to be addressed, that it has a plan, and that it is making progress. In that respect, this plan for policies can at least partially document management’s due diligence process in the information security area.

Short & Modular: If the organization in question is very small, perhaps a startup cloud service provider with a handful of employees, then for a while, they can get away with a single document. But soon they will need to break their information security policy document into a series of segments. Larger and more complex organizations will find that short, modular, and tightly focused policy statements are easier to index, search, and update. Short and modular policy statements are also ideal for easy insertion into pop-up help screens, application system user manuals, and other system-resident text that is relevant to a specific task.

The title of, scope of, topics covered by, and scheduled delivery date of policy statements is additionally a function of the delivery systems to be employed. If more than one major delivery system is to be employed, the same ideas may need to be expressed in very different ways, compatible with the delivery systems involved. For example, if policy statements are slated to be delivered by broadcasters on a periodic management satellite-broadcast TV show, to a worldwide network of sales offices, and if the recipients are non-technical, typically impatient, and not particularly motivated to pay attention, then very short abbreviated verbal policies would be appropriate. But if policy statements will be delivered via an intranet, and users will have a wide variety of automated tools at their disposal, such as key word search utilities, then a longer more literate text-oriented style can be, and probably should be used.

Know your Audience: The way in which policy statements should be scoped, and hopefully modularized into bite-sized pieces, is also a function of the audience to be receiving the information contained therein. Policy writers should define who the major audience members are. Three favorites of this author are: end-users, technical information systems staff, and management. Another example of audiences, for an Internet merchant, would be: customers, third party business partners, in-house technical staff, in-house marketing staff, and top management. Still another example for a multinational manufacturing firm would be: staff in countries where there are operations, headquarters staff, and IT staff (both in-house and outsourced).

Of course there will be some redundancy of the messages delivered across these audiences, but it is important for the policy writer to define, in advance of writing policies, just what messages need to go to which audiences. After these messages and recipients are defined, the policies will often — of their own accord — naturally fall into certain categories, and these categories can then be used as a guide to segment the policy statements into different documents.

Start with the Essentials: So for now, concentrate only on what’s essential, but map out how all the rest of the policies will be structured, what they will entail, when they will be delivered, and who will receive them. See the big picture now, but don’t issue too many policies all at once. The ability of users to metabolize information security policies is surprisingly limited. Care and feeding requires well-thought-out, bite-sized pieces that are well tailored to the needs of the organization, and clearly viewed as essential at the time they are published. A steady diet of this type of policy will gradually raise the awareness level of the audiences receiving the material. Overfeeding will result in indigestion and push-back, and the recipients will then be unwilling to receive more policy material for a considerable period of time.

So the answer to the question “one or several policies?” should almost always be: “never just one policy, and not just several policies either, but instead a regular stream of tasty interesting policy vignettes.” These policy vignettes should be supported by examples, delivered only to relevant recipients as required, and consist only of information that the recipients absolutely must have now in order to maintain good information security. If the policy writer consistently uses this approach, he or she will see that the recipient appetite for more remains strong, and the credibility attached to each policy vignette likewise remains high.

——-

Charles Cresson Wood, MBA, MSE, CISA, CISM, CISSP, is an independent technology risk management consultant with InfoSecurity Infrastructure, Inc., in Mendocino, California. In the field since 1979, he is the author of a collection of ready-to-go information security policies entitled Information Security Policies Made Easy. His latest book is entitled Kicking The Gasoline & Petro-Diesel Habit: A Business Manager’s Blueprint For Action (see www.kickingthegasoline.com). He can be reached via www.infosecurityinfrastructure.com.