ISO27k-aligned security awareness service
FAQ: ISMS documentation
Creative security awareness materials

Creative security awareness materials for your ISMS

Copyright © 2016 IsecT Ltd.

This section of the ISO27k FAQ addresses typical questions about ISMS documentation including information security policies.

 

 

FAQ: “What format and style is appropriate for ISMS documentation?”

 

A: I would suggest putting your ISMS documentation online, typically on the corporate intranet or a similar communal directory/shared area. There are several advantages to this approach:

  1. The intranet and hence the ISMS documentation will be readily available throughout the organization to anyone with access to a PC on the corporate LAN. Other departments can not only read and refer to your materials but hyperlink directly to them in their own policies, procedures etc. (and vice versa of course!).
  2. The content can be structured and presented neatly (e.g. short, easy-to-read summary/intro pages hyperlinked to more detailed supporting pages containing the nitty gritty; embedded graphics such as process flow charts, mind maps ... oh and security awareness stuff).
  3. It is easier to control the ISMS website than printed/hardcopy ISMS documents, provided someone has control over what gets posted to the intranet ISMS area (implying some sort of change management process to review and publish stuff). Everyone should be clear that the ISMS materials on the intranet are the current, live, versions. [You may like to have a separate 'trial' or 'draft' area to expose proposed policy changes for feedback, but make sure that area is easily identified as such e.g. with a different colored page background and an explicit statement that these are drafts, not the current, live, versions of your policies.]

There are two drawbacks though:

  1. You need the skills and tools to design, prepare, publish and maintain the website, or at least easy access to someone who does that.
  2. Web pages (like this one!) don't usually print out very well, so for things that people want to print and refer to, comment on, or whatever, you may need to supply printable versions (e.g. PDFs) to download and print from the same web pages.

That covers the format and type of communication. As to the writing style, that's something you will have to develop. Parts of the ISMS are inevitably formalized (e.g. policies), others can usefully be more user-friendly (e.g. guidelines). It’s perfectly OK to have some fun too, using more creative security awareness materials such as quizzes, crosswords, seminar/workshops and prize draws. The idea is to draw people in and engage them, provide useful, readable content, not scare them off forever with miles of inpenetrable red tape.

 

Implementation tip: It definitely helps to have a consistent style/format for each type of material, and even better consistent elements on all of them to bind them into a coherent, professional suite. Do you have an ISMS logo, perhaps, with which to ‘brand’ the documentation and your other security awareness materials? Do you employ professional authors? Do they use templates and styles consistently?

Top

 

 

FAQ: “What are the differences between the Statement of Applicability (SoA), Risk Treatment Plan (RTP) and Action Plan (AP)?”

 

A: The SoA is your formal definition of the controls listed in ISO/IEC 27002 that are relevant to your ISMS. There needs to be some rationale to explain your reasoning and persuade the auditors that important decisions were not made arbitrarily. Be ready for some robust discussions if you decide not to implement common controls, or to accept significant risks.

The AP and RTP seem similar at first glance but the AP is normally a development or contraction of the RTP. The RTP systematically identifies the controls that are needed to address each of the identified risks from your risk assessment, whereas the AP (or program plan or project plans) says what you are actually going to do - who will do it, by when, and how. A single control, especially a baseline control such as physically securing the organization's perimeter, may address numerous risks and so may appear multiple times in the RTP but hopefully only once in the AP when it is designed, implemented, verified and ‘operationalized’ (horrid word!).

ISO/IEC 27000 should help resolve any remaining confusion.

 

Implementation tip: Don’t get too hung up on the acronyms and titles of the documents. Concentrate on their primary purpose, which is to document the links between information risks, control objectives and controls.

Top

 

 

FAQ: “I would like an RTP example, with one or two risks managed, please ... I would give anything to see a little part of one... I don't know how to start... I recently finished my risk analysis and I'm really stuck here.....”

 

A: The idea of the Risk Treatment Plan is essentially to document how your organization intends to “treat” identified risks, where “treatment” means reduce, avoid, accept or transfer. Here's a fictitious RTP extract:

 

    21. Risk: network infection by worms and similar malware, causing network outages, data damage, unauthorized access to systems and various consequential damages/losses including incident investigation and cleanup costs.

    Risk treatments: mitigate the risk primarily through antivirus controls, plus network, system and data logical access controls, plus incident management, backups, contingency plans, plus policies, procedures and guidelines.

     

    22. Risk: serious fire in the data centre, causing loss of datacentre IT services for an extended period.

    Risk treatments: avoid risks by taking care over the location and construction of the data centre, including any post-build modifications. Also avoid excessive storage of flammable materials including magnetic media (e.g. locate the media archive elsewhere on site). Physical security controls including fire alarms, extinguishers etc., coupled with fire evacuation procedures and training. Also insurance cover against fire damage. Also avoiding excessive reliance on the data centre through dual-siting of critical network devices and servers.

     

    23. Risk: corporate prosecution for copyright abuse.

    Risk treatments: avoid copyright abuse through using a centralised software and license inventory, regularly audited and reconciled both internally (e.g. actual number of installations <= licensed number) and against installed software on corporate IT systems (e.g. searching for additional software not listed in the inventory), coupled with various compliance measures, policies and procedures. Also restrict physical site access to authorized persons, limiting the potential for license snoopers ...

     

    24. Risk: unreliable commercial software causing Blue Screen Of Death at the worst possible moment.

    Risk treatments: specify and test security aspects in software procurement process. Maintain software. Accept the residual risk for Windows.

 

Implementation tip: You could set this up as a table or matrix, since many risks will require some combination of treatments and, in virtually all cases, “accept residual risk” is a necessary evil:

 

 

Risk

Treatment

Reduce

Avoid

Accept

Transfer

1. Name or describe an information risk here (with reference to the output of your risk analysis and prioritization process)

Say how you plan to reduce or mitigate the risk through the implementation of suitable information security controls selected from ISO/IEC 27002 or elsewhere

Can you avoid the situation that creates the risk in some way e.g. by good design and pre-planning, or by not doing risky business processes?

If it is not cost effective to completely mitigate a risk, management should openly acknowledge the residual risk

Can you transfer some or all of the risk to a third party, for example an insurer or business partner?

2. Next risk ....

 

 

 

 

 

Top

 

 

FAQ: “What should we cover in our [information] security policy?”

 

A: It’s up to you - well, strictly speaking, it's up to your management. See ISO/IEC 27002 for a decent outline of what the policy should cover, as a minimum.

Policy pyramid 500Although your approach may well differ, my personal preference is the pyramid structure shown here, reflecting greater volumes and details in the lower levels.

The principles, axioms and policies should be formally reviewed and mandated by management, demonstrating their support for the entire security programme. Don't neglect the value of senior management support, right from the start. The programme will most likely lead to changes to working practices and systems throughout the organization so management must be aware of the overall objectives and support the changes when it comes to the crunch. Consider starting with security awareness activities targeting the C-suite: build your cohort of supporters by talking in strategic business terms as much as possible (e.g. do you have a documented business case for the security work?).

Individual policies covering specific information security topics or issues such as “Email security policy” and “Network access control policy” tend to be quite formal but need not be stilted. They typically specify security responsibilities of key groups, functions, teams or people. They may include introductions and explanations to aide reader comprehension, and should reference relevant documents at higher and lower levels of the policy hierarchy. They should be technology-neutral and succinct - ideally no more than a few pages.

Corporate security standards expand on the high-level policies with technical details needed for their implementation.

Most organizations publish the entire policy suite on the corporate intranet because:

  1. The online set is the definitive reference - no more wondering about whether printed policies are still current or have been superseded;
  2. Everyone with access to the intranet can read and refer to the policies etc. easily, for example cross-referencing between them or to/from other policies etc. using hyperlinks to the respective URLs.

Bob Ralph expressed this issue very eloquently on the ISO27k Forum: “Sooner or later, whatever it is, it needs to be documented - worded to suit top middle or bottom (e.g. policies, procedures or work instructions). If its properly hierarchical then the system is like a completed jigsaw, each part a perfect fit with its partner, no more no less, and if that is achieved hey presto you get the big picture. The number of parts will depend on the size of the organisation and the number of processes.”

 

Implementation tip: as with the information asset inventory issue noted above, information security policies, standards, procedures and guidelines are never truly “finished” as they need to be updated from time to time to reflect changes both within and without the organization (e.g. the emergence of new information security threats may justify the modification of existing policies etc., or at least the generation of additional security awareness materials about the changing threats). It helps to have a reasonably complete policy suite but it need not be totally comprehensive provided that you establish the ISMS processes necessary to identify and make updates on an ongoing basis in normal operation.

Top

 

 

FAQ: Do we need an ‘ISMS manual’?

 

A: whereas an ‘ISMS Manual’ might have been appropriate under the previous version of the standard, it is no longer necessary.

In accordance with ISO/IEC 27001:2013, ‘Context of the Organization’ is a useful place in which to declare the scope of the ISMS and state related legal, regulatory and contractual requirements or obligations. 

It is worth cataloguing and describing your ISMS documents in a Document Control section. As well as making it easier to keep the documents under control, to know what they are about and to reference them properly by name, the certification auditors will appreciate a neat list of the key ISMS documents that need to be controlled - and you will have a shopping list of the things the auditors are most likely to ask for.

 

Implementation tip: repeating or duplicating information in the ISMS remains a bad idea because it (a) makes the system bigger and more complex, and (b) increases the likelihood of document control non-conformities if the duplicates somehow become out-of-synch. It’s much better to specify something (such as, say, a cloud computing security policy) once, definitively, and refer to it from elsewhere without repeating it. [Thanks to Dave Anders of SecuraStar for this Q&A.]

Top

 

 

FAQ: “I am trying to put together a document for working in secure areas. How much information should it contain i.e. is this just a one pager or a full manual?”

 

A: Regarding corporate policies, procedures and the like, shorter and more succinct is almost always better as it means less to:

  • Write;
  • Review, consider, check out;
  • Approve;
  • Implement i.e. mandate, circulate, put into practice;
  • Read and understand;
  • Train people about/make them aware of;
  • Police i.e. check/ensure compliance with, and audit against; and
  • Maintain ...

 ... but there are practical limits to this. It needs to be sufficiently comprehensive to meet your organization’s particular risk mitigation needs, expansive and clear enough not to be totally cryptic, and needs a certain gravitas to be considered by management and staff as an actual policy (a single policy of “Keep all our information assets secure” scores very high on the succinctness scale but very low on the “What on Earth am I meant to do to comply with this policy?” scale!).

ISO/IEC 27002 guides you on the sorts of controls you ought to consider in the specific area you are working on. It makes sense to use the standard as a basis, a starting point. See how well it fits your organization’s needs (considering your particular risks, circumstances and other supporting controls), modify it as necessary, then implement your policy ... and finally drop into ‘maintenance mode’ where subsequent practice, incidents, near misses and any changes in the security threats and vulnerabilities or business impacts in that part of your ISMS imply the need to change your controls.

Your policy development process will, in time if not now, come up against the challenge that many potential subject areas could be covered by multiple policies, looking at similar issues from different angles. “Working in secure areas”, for instance, begs obvious questions about what constitutes “working” (do you mean just employees, for instance, or does it apply to contractors, cleaners, maintenance people, even security guards on patrol?), and how you have identified and defined “secure areas” (is there a physical risk assessment process? Does it take into account the security risks associated with information assets in each area? Does it adequately cover information that is in use, in storage or in transit? Are you dealing with classified information, whether internally classified or national security classified). You can carve up all your controls in numerous ways, and (trust me!) it is very easy to end up with a totally unworkable mess of overlapping, conflicting and yet gappy policies if the overall policy development process is not itself well managed. Again, my advice is to think and plan comprehensively from the outset, using ISO/IEC 27001 and especially the more detailed ISO/IEC 27002 as a basis for your policy set, since:

  1. The ISO27k standards’ authors (members of committee ISO/IEC JTC1/SC 27) have put a lot of work into figuring where each potential subject area is ‘best’ covered. ISO27k is reasonably comprehensive in coverage but the option remains to extend it if you need more. ISO/IEC 27002, in particular, incorporates numerous cross-references between applicable areas where appropriate rather than duplicating controls;
  2. ISO27k constitutes good practice, in other words it is a sound basis for information risk management, accepted worldwide;
  3. Even where an arbitrary decision has been made about which heading suits some topic, it is specified thus in an international standard which makes it OK to copy that;
  4. ISO27k provides a generally understood common vocabulary and structure, meaning your ’27001 certification auditors, ISMS consultants and any new ISMS-aware employees will be instantly familiar with the layout and general content of your policy suite.

 

Implementation tip: keep it short if you can. You don’t necessarily need to write a complete suite of policies, the entire edifice, right now. You can work on it piecemeal, one policy, standard, procedure or guideline at a time. Using ISO27k as ‘the picture on the box’, all the pieces should gradually fall into place like a nice 2D jigsaw, not some fantastic but weird piece of modern art.

Top

< Previous FAQ section      FAQ index      Next FAQ section >