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

• What format and style is appropriate for ISMS documentation?
• What ISMS documentation is mandatory or suggested?
• What are the SoA, RTP and AP?
• What should our security policies cover?
• Do we need an ‘ISMS Manual’?
• How big should our policies be - one page or a whole manual?

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 organisation to anyone with access to 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 impenetrable 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 ISMS documentation is mandatory or suggested?”

A:  Just 14 (yes, seriously, just 14) documents are formally required of every organisation seeking certified conformity to ISO/IEC 27001 ... but in practice, most organisations choose to prepare and incorporate rather more than those docs, for business reasons. There are many more than 14 discretionary documents, including those needed to justify, manage and track the typical ISMS implementation project, docs regarding governance of the ISMS, additional docs concerning the information risks and, most numerous of all, documentation concerning the organisation’s information security controls.

On the shrunken preview mind map below, the mandatory docs are outlined in orange. Click it to download and peruse the full diagram in all its glory, bearing in mind that your organisation and its ISMS documentation requirements are unique. This is merely a general prompt.

Implementation tip: you need to prepare all 14 mandatory docs for certification, no question, so this is clearly something important to incorporate into your ISMS implementation planning. What must the 14 mandatory documents cover? [Hint: take a look at the free ISO27k Toolkit for inspiration.] What form, style and format will they each take? Who will prepare them? Do they need to be reviewed, authorised, mandated, issued/circulated, maintained?

What about all the other documentation that is appropriate for your particular business needs: what is it, for starters? An ‘ISMS documentation management procedure’ perhaps? Is there going to be so much that a document management system or ISMS support system is justified?

Before you get carried away, remember that your primary objective is to manage the organisation’s information risks and security controls effectively and efficiently for sound business reasons, not to generate reams of red tape, accumulating unnecessary burdens and costs. KISS! Some documentation (such as details of applicable legal and regulatory obligations that are relevant to information risk and security) may be better managed outside the ISMS (by your legal and compliance function/advisors in that case).

Top

FAQ: “What are the differences between the SoA, RTP and AP?”

A: The Statement of Applicability 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 Action Plan and Risk Treatment Plan 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 mitigate risks identified and evaluated in you risk assessment, whereas the AP (or program/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 organisation'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 organisation 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:

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.

Although 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 organisation 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 organisations 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 organisation (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: simply put, no.

However, It is generally worth cataloguing, introducing/outlining and referencing your policies and other ISMS documents somewhere e.g. in the ‘Security Zone’ on your intranet. As well as making it easier to keep important documents accessible and under control, the certification auditors will appreciate having a neat list of the key ISMS documents, and you will have a handy shopping-list of the docs the auditors are most likely to ask for.

For bonus marks, identify the document owners, revision status and date of next scheduled review.

Implementation tip: rather than duplicating content and trying to maintain control of all versions, publish documents such as your information security policy once, definitively, and refer to them consistently from elsewhere. Use a Content Management System if that helps.

Top

FAQ: “I am drafting a document for working in secure areas. How much information should it contain i.e. is this just a one pager or a lengthy document?”

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 or at least 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 organisation’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 organisation’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 on the payroll, 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 JTC 1/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 find it lacking. The new 2022 version of 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. Although the decisions about which headings and attributes are most appropriate for each control are sometimes arbitrary, the ISO/IEC standard is a reference that is known and accepted worldwide;
3. ISO27k provides a generally understood common vocabulary and structure, meaning your ISO/IEC 27001 certification auditors, ISMS consultants and any new ISMS-aware employees will be instantly familiar with the layout, princples and general structure of your information security arrangements.

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 >