You are currently browsing the ISO 27001 & BS 25999 weblog archives for May, 2010.

 

ISO 27001/BS 25999 documents, presentation decks and implementation guidelines


Free_Downloads
 
 
 

Recent Posts

 
    

UPCOMING WEBINARS

    

 
ISO 27001 benefits: How to obtain management support

    

Wednesday
February 15, 2012

    Register_now_green
    

 
Risk Management Part 1: Risk assessment methodology and risk assessment process

    

Tuesday
February 28, 2012

Wednesday
April 11, 2012

    Register_now_green
 
 
 
 

Archive for May, 2010

Information security policy – how detailed should it be?

ByDejan Kosutic on May 26, 2010

Quite often I see information security policies written in too much detail, trying to cover everything from strategic objectives to how many numerical digits a password should contain. The only problem with such policies is that they contain 50 or more pages, and – no one is really taking them seriously. They usually end up serving as artificial documents whose sole purpose is to satisfy the auditor.

But why are such policies extremely difficult to implement? Because they are too ambitious – they try to cover too many issues, and are intended for a wide circle of people.

This is why ISO 27001, the leading information security standard, defines different levels of information security policies:

  • High-level policies, such as the Information Security Management System Policy – such high level policies usually define strategic intention, objectives etc.
  • Detailed policies – this kind of policy usually describes a selected area of information security in more detail, with precise responsibilities, etc.

ISO 27001 requires that Information Security Management System (ISMS) Policy, as the highest-ranking document contains the following: the framework for setting objectives, taking into account various requirements and obligations, aligns with the organization’s strategic risk management context, and establishes risk evaluation criteria. Such a policy should be actually very short (maybe one or two pages) because it’s main purpose is for top management to be able to control their ISMS.

On the other hand, detailed policies should be intended for operational use, and focused on a narrower field of security activities. Examples of such policies are: Classification policy, Policy on acceptable use of information assets, Backup policy, Access control policy, Password policy, Clear desk and clear screen policy, Policy on use of network services, Policy for mobile computing, Policy on the use of cryptographic controls, etc. Note: ISO 27001 does not require all these policies to be implemented and/or documented, because the decision whether such controls are applicable, and to what extent, depends on the results of risk assessment.

Because such policies should prescribe more details, they are usually longer – up to ten pages. If they were much longer than that, it would be very difficult to implement and maintain them.

In other words, information security is too complex an issue to be defined in a single policy – for different aspects of ISMS and different “target groups” there should be different policies. Middle-sized organizations usually build up to fifteen policies for their ISMS.

One could argue that this number of policies is nothing but overhead for a company. I would certainly agree if such policies are written only with the certification audit in mind – such policies will bring nothing but more bureaucracy. However, if a policy is written with the intention of decreasing the risks, then it will most probably show its value – if not right away, then probably in two or three years, by decreasing the number of incidents.


Mandatory documented procedures required by ISO 27001

ByDejan Kosutic on May 04, 2010

If you heard that ISO 27001 requires many procedures, this is not quite true. The standard actually requires only four documented procedures: a procedure for the control of documents, a procedure for internal ISMS audits, a procedure for corrective action, and a procedure for preventive action. The term “documented” means that “the procedure is established, documented, implemented and maintained” (ISO/IEC 27001, 4.3.1 Note 1).

Note: in this blog post I will not write about other mandatory documents like ISMS Scope, ISMS Policy, Risk Assessment Methodology, Risk Assessment Report, Statement of Applicability, Risk Treatment Plan, etc. – here I focus on procedures only.

The procedure for the control of documents (document management procedure) should define who is responsible for approving documents and for reviewing them, how to identify the changes and revision status, how to distribute the documents, etc. In other words, this procedure should define how the organization’s bloodstream (the flow of documents) will function.

The procedure for internal audits must define responsibilities for planning and conducting audits, how audit results are reported, and how the records are maintained. This means that the main rules for conducting the audit must be set.

The procedure for corrective action should define how the nonconformity and its cause are identified, how the necessary actions are defined and implemented, what records are taken, and how the review of the actions is performed. The purpose of this procedure is to define how each corrective action should eliminate the cause of the nonconformity so that it wouldn’t occur again.

The procedure for preventive action is almost the same as the procedure for corrective action, the difference being that it aims at eliminating the cause of the nonconformity so that it wouldn’t occur in the first place. Because of their similarities, these two procedures are usually merged in one.

But why is it that ISO 27001 requires documented procedures that are not related to information security, while security procedures are not mandatory?

The answer is in risk assessment – ISO 27001 does require you to perform risk assessment, and when this risk assessment identifies certain unacceptable risks, then ISO 27001 requires a control from its Annex A to be implemented that will decrease the risk(s). The control can be technical (for instance, anti-virus software for decreasing the risk of malicious software attack), but could also be organizational – to implement a policy or a procedure (for instance, implement a back-up procedure). Therefore, the procedures are becoming mandatory only if the risk assessment identifies unacceptable risks.

One important note though – as opposed to the four mandatory procedures which must be documented, the procedures arising from controls in Annex A  do not have to be documented. It is up to the organization to estimate whether such a procedure is to be documented or not.

You could consider the four mandatory procedures as the pillars of your management system (together with the security policy) – after they are firmly set in the ground, you can start building the walls of your house. This becomes obvious when you look at other management systems – the same four procedures are mandatory there, too – in ISO 9001 (quality management systems), ISO 14001 (environmental management systems), and BS 25999-2 (business continuity management systems). As a consequence, you can use these procedures as the main link between different management systems if you want to develop the so called “integrated management system”.