Read NBlog, the NoticeBored blog
Click the banner for the site map  of NoticeBored.com, the information security awareness service
Frequently Asked Policy Questions

This FAQ answers questions and issues that commonly crop up when customers are thinking of purchasing our information security policy materials.  If you have other questions or comments, do please let us know.

 


Policy FAQ quick links

 


 

Q: We already have a whole bunch of security policies we’ve written ourselves.  What’s wrong with those?

A: You tell me!  Does the fact that you are reading this FAQ mean you are not entirely happy with your existing policies?  Or are you simply looking for improvement ideas?  Anyway, see just how many of the following commonplace concerns ring true:

  • Limited scope - ‘security policies’ are typically restricted to IT or technical security matters in reality, leaving substantial gaps, especially in the wider aspects of information security such as human factors.  In the absence of an overall policy map, framework or architecture, holes in coverage are likely to remain unnoticed at least until an incident slips out between the cracks (oh-oh, too late!);
  • Poor quality - aside from the lack of context, weak structure, grammatical errors, undefined terminology and loose ends, policies are often drafted in a curiously stilted pseudo-legal style that makes them hard for ordinary people like you and me to read and understand.  Do we really need to be told there are “three (3) requirements”?  Must we wade through pages and pages of junk to get to the bits that matter?  Writing readable, motivational and actionable policies of any sort is a particular skill that takes years of practice: it’s not a job to leave to the office junior;
  • Inconsistencies - policies that were drafted by various people at various times for various reasons, and may have been updated later by others, tend to drift apart as they evolve, becoming disjointed.  Even if a corporate style guide is in place, in practice policies often end up looking different and lacking coherence.  If anyone bothers to look closely, it is not uncommon to find bald contradictions, gross discrepancies or conflicts both within and without the policy set (e.g. differing interpretations of legal or regulatory obligations around, say, privacy).  Security obligations are often scattered across the organization, partly on the intranet (typically in several different places at once, in various states of disarray and decay!) and others embedded in employment contracts, employee handbooks, union rulebooks, printed on the back of staff/visitor passes and so on;
  • Lack of awareness - policies are passive, formal and frankly boring documents, dust magnets.  They don’t fly off the shelves like best sellers.  They take some effort to find, read and understand.  Unless they are accompanied by suitable standards, procedures, guidelines and other awareness materials, and supported by structured training, awareness and compliance activities, employees can legitimately claim that they didn’t even know of their existence;
  • Lack of accountability - if it is unclear who owns the policies and to whom they apply, noncompliance is the almost inevitable outcome.  This, in turn, makes it risky for the organization to discipline, sack or prosecute people for noncompliance, even if the awareness, compliance and enforcement mechanisms are in place;
  • Lack of compliance - policy compliance and enforcement activities tend to be minimalist, often little more than sporadic reviews.  Maybe management circulates a reminder to staff shortly before the auditors arrive or following a security incident (oops, too late, again!).  Policies that are simply not enforced for some reason are merely worthless, whereas those that are truly unenforceable are a liability: management believes they have the risks covered while in reality they do not.  Badly-written, disjointed and inconsistent security policies are literally worse than useless;
  • Lack of process - many of these issues can be traced back to inconsistencies in the way that security policies are generated, mandated, interpreted, applied and enforced by management.  Documented policy management processes are rare, meaning that there is no standard lifecycle for policies.  Policy exceptions and exemptions (often confused but quite different in fact) are handled inconsistently.  Simple housekeeping activities such as version control and scheduled periodic policy reviews are beyond many organizations, while policies generally lag far behind rapidly-emerging issues such as the information security aspects of cloud computing.

When you look at it dispassionately, the list of issues is not only long but the causes are often deeply entrenched in dysfunctional organizational practices and poor corporate governance.  Some unfortunate organizations would benefit from more or less scrapping their home-grown policies and starting afresh!  A few have a firmer grip on the accountability and process issues but may be looking for inspiration in other areas, perhaps information security controls derived from the ISO27k standards to support their ISO/IEC 27001 Information Security Management System.  Many fall in the middle ground with a mixture of policy materials that can simply be spruced-up and supplemental policies to plug the gaps.

 

Quote from Larry Ponemon of the Ponemon Institute

 


 

Q:  I am compiling an information security policy for our organization. The information security policy must reflect the organization’s specific information security risks and requirements, so what use are generic policies to us?

A: Like the international standards on which they are based, the policies we supply are indeed generic and therefore need to be tailored to some extent for your organization.  The policies document popular, commonplace information security controls, drawing from the wide range of options suggested in ISO/IEC 27002 plus others that are not (at least, not yet) in the ISO/IEC standard e.g. we propose supplementary environmental protection controls for the typical computer suite such as remote-reading over-temperature alarms, that aren’t mentioned in the current version of the standard.  The generic policies provide a sound starting point. It is up to you to review and where necessary customize and adapt them to fit your unique context. 

You may already have certain information security policies or standards that need to be incorporated, for instance length and complexity parameters for passwords, although we hope you will consider the value of the suggested parameters and policy statements (you never know: we might just have come up with a better way of dealing with things or putting them across).  Management may have determined that, for example, business continuity planning is out of scope of your information security function and hence the information security policies, perhaps because there is a separate department in charge of contingency planning, so you can trim out those policy statements accordingly.  If, say, your organization has chosen to continue using triple-DES instead of moving to AES, you should check that any policy statements around encryption allow for 3DES to be specified in the supporting standards/guidelines. 

Unfortunately, we can’t do that for you!  However, customizing a set of policies is much easier, quicker and cheaper than writing them from scratch.  Starting with a suite of materials that were all written by the same person and are based on the same ISO/IEC standards makes them more consistent and effective than compiling policies from a variety of sources. 

We have invested literally hundreds of man-hours of painstaking work in drafting, finalizing and maintaining the materials.  You need only spend some small change from your budget to have your own professionally-written, coherent, comprehensive, high-quality and ISO27k-aligned policy set ready to go in next to no time.

 


 

Q: We are about to commence a project to implement an ISO27k Information Security Management System (ISMS) within the organization and are currently weighing-up our options for the implementation: should we do it all ourselves, or engage a consultant to assist, or source and amend template policies and procedures?

A: You are in a fortunate position if you have the skills and resources to do the ISO27k ISMS implementation entirely in-house!  The ideal would be to find a project manager with prior experience of designing, implementing and perhaps operating and managing an ISO27k ISMS.  At the very least, we would recommend putting some of your information security people through the Lead Implementer and/or Lead Auditor courses which are offered by several trustworthy organizations.  If neither option applies, then yes we would definitely advise finding a suitable consultant to mentor and support an in-house ISMS project manager (usually the Information Security Manager) rather than simply take on a contract project manager to run the whole show.  The point is that the ISMS will continue indefinitely, so it's best if your people have been in the driving seat for both the design and implementation, albeit with expert guidance.

Information security policy and procedures development is a discrete part of ISMS implementation.  As we see it, you essentially have five options:

  1. Do the policy and procedures development entirely in-house, perhaps adapting and extending your existing materials in line with ISO/IEC 27001 and 27002.  This is a good approach but relatively slow, and costly if you account for all the research and development and proofreading time needed.  Do you even have the skilled person or people available and willing to dedicate sufficient time to this?
  2. Simply adopt a set of information security policies written by someone else - perhaps our generic policy set, or maybe pick from Charles Cresson Wood's huge set of 1300 ‘policies’ (most of which are actually security standards!).  This is also a decent option but is unlikely to deliver a set of policies that exactly matches both your specific situation and the requirements of ISO27k.  Your chances of finding useful security procedures this way are low - there is too much variation in security processes between organizations.
  3. Accumulate and consolidate a set of policies and procedures based on various sources such as examples in books and on the Web.  The original materials may be free or at least freely available (copyright compliance is itself an information security matter!) but you will need time to consolidate them, make them all consistent, and fill in the inevitable gaps.  This may or may not be quicker and cheaper than starting from scratch, depending on the quality and suitability of the materials you obtain.  Either way, it is a lot of work.
  4. A hybrid approach, taking a set of pre-written policies such as our policy set as a starting point but customizing/adapting them to suit your organization, and developing the supporting procedures etc. as needs be (perhaps using NoticeBored as a source).  The cost of licensing commercial products is offset by the savings in R&D time and money, and by the quality of the product.  We are convinced this is the best option for most organizations but of course we are biased!
  5. Employ a consultant specifically to write precisely what you need.  This would be the most expensive and time consuming approach, especially given that they need to research your specific situation and needs before writing anything much (and if they don’t even appreciate the need to do this, you have some serious questions to ask).  At the end of the project, provided you have chosen your consultant wisely, you should end up with a very nice set of security policies and procedures ... that you then need to maintain ...

Visit www.ISO27001security.com for guidance on implementing the ISO/IEC 27000-series (“ISO27k”) standards, including a free ISO27k Toolkit.   If you want to discuss your proposed approach to implementing the ISO/IEC 27000 series standards, or get some tips on policies, awareness and all that, just let us know and we’d be pleased to help (within reason!  Up to one hour of telephone/email advice is free of charge for customers.  If your needs are more involved, talk to us about bespoke consultancy options and rates, including our virtual consulting service).

 


 

Q: The Information Security Policy Manual seems rather lengthy at ~160 pages, covering the whole of ISO/IEC 27002.   Surely you wouldn’t expect us to circulate the whole thing to everyone in the organization?

A: True, we would not anticipate giving the complete Information Security Policy Manual to everyone in the company.  It is far too formalized and lengthy, and few employees would have enough interest or time to read and understand it.  In short, there is no value in doing this and we certainly don't recommend it.

The policy manual is better suited as an internal reference document primarily for information security, risk management, governance and assurance professionals, laying down guidance on the full range of controls that need to be designed, implemented, used and maintained.  The comprehensive coverage of information security (not just IT security, remember) is a key strength of ISO/IEC 27002 that underpins an ISO27k ISMS, and is the reason the manual is so lengthy. 

Policy pyramid sloped colored 200The top two layers of the policy pyramid (i.e. the principles and axioms) are suitable for circulation to everyone if you wish (especially in the succinct 5 -page form of the Corporate Information Security Policy), but are more likely to be sent to and discussed with senior management in order that they consider them, accept the need for them, endorse them, mandate them and ultimately support compliance with them.  Do not underestimate the value of genuine management support for your security policies.

The policy manual in turn should be supported by more focused and easily understood policies such as our New product Nov 2011Topic-based Information Security Policies, plus a variety of awareness and training materials.  The policy manual cites common procedures, standards and guidelines throughout, and references them all towards the front.  Those are the things that employees should be given, where appropriate and relevant to their needs (e.g. technical security standards for the folks in IT, guidelines on end user stuff for end users ...).  They are not incorporated within the policy manual for two simple reasons: (1) the policy manual would be even longer than it already is; and (2) the implementation details are far more likely to vary between organizations than the generic principles and axioms in the corporate policy and the detailed policy statements in the manual.  We can however help you further though the NoticeBored subscription service which does provide additional policies, procedures etc. - more on that below.

 

This manual template has saved us

 


 

Q:  As I understand it, an information security policy that applies and is circulated to all employees should be high-level, understandable and concise.  Do your Information Security Policy Manual or Topic-based Information Security Policies fit the brief?

A:  No, not really.  Take another look at the policy pyramid above.  The Information Security Policy Manual is almost certainly too detailed to have much meaning or value for non-technical employees, unless for some reason they are concerned about specific information security risks and controls.  The Topic-based Information Security Policies are more readily understood by a general audience but don’t cover the full breadth of information security and are not universally applicable.  The Corporate Information Security Policy, on the other hand, is a high level specification that applies throughout the organization.  Once approved by senior management, the corporate policy could be circulated to all employees on paper although this is not normally necessary nor advisable.  It is generally more appropriate to make it available, usually on the corporate intranet, as a definitive source to be referenced by the supporting policies, standards, guidelines etc.  In this way, the specific standards or guidance to employees on matters such as password length can be linked directly to policies explicitly mandated by management.

Making compliance with the information security axioms an explicit obligation for all employees and contractors is a key control, a corporate governance matter in fact.  It enables management to hold everyone personally accountable for their part in upholding information security.  There are several ways to ensure that employees are made formally aware of their obligations under the security policies, according to local practices and, perhaps, legal requirements:

  • The corporate policy can be cited by or incorporated in employment and service contracts.  When these are signed, there is clear evidence that the person acknowledged their security obligations at that point in time, although it might be argued that the person did not really understand the material and may even have signed under duress.  It may be feasible to get everyone to re-acknowledge every so often, and perhaps to incorporate wording covering any later updates to the policy, but you should definitely seek legal advice if this may be an issue for your organization;
  • Everyone may be required to read the policy and sign something formal to accept it.  While this is conventionally done on paper, filing away the acknowledgment slips in personnel records, it may be possible instead to automate the process by citing the policy during the network logon, periodically insisting that people read and click an acknowledgment before the logon completes (but please, not too often!  Annually might be sufficient);
  • Most policy and learning management systems offer the facility to make people undertake essential training and if appropriate pass a comprehension test on completion.  The associated reports may be retained as part of the personnel record;
  • Involvement in various other security awareness and training activities can also be tracked - for example, web logs for Information Security’s intranet site plus attendance sheets for security orientation or refresher courses may provide evidence that someone should have been well aware of the security rules.

Our Information Security 101 module is specifically designed to provide guidance on the essentials to new employees without overwhelming them too much detail.  Thereafter, the NoticeBored security awareness materials fill-in the gaps, reminding people of the basics and exploring individual topics in more depth on a rolling monthly basis, one topic at a time.  We provide acceptable use policies, guidelines, procedures and more through NoticeBored.

 


 

Q: Is your Corporate Information Security Policy or Policy Manual the same as an ‘information security policy document’ (ISO/IEC 27002 section 5.1.1) or an ‘ISMS policy’ (ISO/IEC 27001 section 4.2.1b)?

A:  An ‘information security policy document’ (A) is a requirement of both ISO/IEC 27002 and ISO/IEC 27001.  It is necessary for the organization’s ISMS to be certified compliant with ISO/IEC 27001.  Furthermore, it is considered good practice and is common among organizations that take information security seriously.  Since it sets the framework for the ISMS as a whole, it is essential in practice to avoid the ISMS being fragmented, disorganized and generally ineffective.  Without it, there will most likely be duplication and gaps in the ISMS, leaving serious control weaknesses and hence inadequately managed information security risks.

Unfortunately the ‘ISMS policy’ (B) noted in ISO/IEC 27001 is not explicitly defined in the standard but in our experience this is generally interpreted to mean a governance document or strategy laying out the basis and rationale for the management system, plus the management structure.

The information security policy set covers both (A) and (B), plus more besides:

    (A) The Corporate Information Security Policy satisfies the requirements of an ‘information security policy document’.  This is concise enough to be readable, yet specific enough to reinforce the accompanying Information Security Policy Manual and other supporting documents, plus the ISO/IEC standards from which it was derived.

    (B) Section 6 of the Information Security Policy Manual reflects ISO/IEC 27002 section 6 on ‘organizing information security’, outlining a typical governance structure for information security management, with key roles and responsibilities plus reporting lines and management review processes.  Admittedly, this section is likely to need customization to suit your organization’s department/function names and remits but again we provide a starting point for your consideration as an ‘ISMS policy’.

Although still quite formal in style, the Topic-based Information Security Policies provide more general guidance, interpreting the high level principles and axioms from the Corporate Information Security Policy in terms that most people should be able to understand.

By the way, the information security principles and axioms laid down in the corporate policy are written in such a way that it would be quite hard to argue rationally against them - they are mostly just common sense.  Still it would be fascinating to find out why managers disapprove of any or feel there are gaps, hence we advise circulating your customized policy to management in draft, giving them time to read and consider it and perhaps scheduling a workshop to finalize them, prior to formally authorizing and mandating them.  Believe me, time invested now in gaining the understanding and support of senior management and dealing with any concerns will pay dividends later when it comes to implementation, compliance and enforcement.

 


 

Q:  Do you maintain the policies?

A:  Yes ... and no.  The policy set has evolved over many years and although the structure is stable, the details vary.  We maintain the master templates from which we create materials for customers, updating them from time to time e.g. to reflect new ISO27k standards as they are released.  The detailed glossary section of the Information Security Policy Manual is updated quite often with new terms and evolving definitions.  Customers automatically receive the very latest available version at the time of purchase.

We do not send out updated policies to previous customers, however, mostly because we anticipate customers customizing them to suit their specific circumstances and of course we have no knowledge of those customizations.  We could potentially offer an update and customization service but it would probably not be cost-effective.  If that’s a concern for you, talk to us.

We will no doubt be making more extensive changes during 2012 and 2013 as both ISO/IEC 27002 and ISO/IEC 27001 are in the process of being substantially revised by the responsible ISO/IEC committee.  Watch this space for details.  Since we contribute to that committee, we do at least have the advantage of forewarning!

Matthew Putvinski quote re importance of policies


HomePolicies > Infosec Policy FAQ >

Copyright © 2012  IsecT Ltd.