Monday 23 September 2013

ISO 27001:2005 - 10 Lessons Learnt from the Journey!

I have had my share of consulting/implementing and auditing experience on a few of the ISO standards and to me ISO27001 has been the most difficult and significant learning experience.
As I talk about the information security standard ISO27001:2005, the 2013 version is due sometime later, but the final draft suggests it is going to remain pretty much intact with easy integration with other management standards.
Here are my 10 lessons learnt during my journey towards driving ISO27001 certification at various organizations worldwide.

Basis:  Service provider has 2 categories of project: type a) managed projects, and type b) resource augmentation projects, to deliver goods/services to customers.
  1. Scope & Exclusions
    Though scope is a common aspect of all ISO standards, I would caution to explicitly mention exclusions.  Some of the common functional groups might not be willing to participate directly or indirectly in audits and it is imperative to have them cleared prior to stage 1 audit. 
  2. SOA
    With scope being finalized, the statement of applicability needs to be run with all project teams and functional stakeholders to qualify applicability of annex controls and justify with reason of exclusion.  I have seen this to be an iterative exercise and until everybody understands the rationale, the whole exercise becomes futile.
  3. Risk assessment & risk methodology
    I have seen most organizations have some standard risk management framework and templates  handy for the projects or at business unit level, however the support functional risk assessment is not available.  It would be imperative to take stock of how risk is managed at support function as their lapse would affect the outcome of your certification.
  4. Security plans
    This is the trickiest of documents from practicability standpoint. For example, managed projects would need to have a robust security plan considering the fact of meeting contractual requirements and SLAs. For resource augmentation projects, it would be a choice to make a security plan adhering to your service provider organization and spell out clearly to third party/client about non availability of resource means, SLAs cannot be met.  This has to be documented clearly and approved at the memorandum of understanding (MoU) between 2 parties.
  5. Security controls for offshore and onsite resources
    Today most organizations have employees work at client locations (onsite) and also deliver work from offshore (remote) locations.  Be clear on the scope of your ISO27001 certification including locations. E.g., if you only have offshore locations in scope, but all resources for both onsite/offshore covered, onsite security controls would still be applicable and needs to be demonstrated for compliance.
  6. Business continuity plan (BCP)
    Identifying the criticality of service and contractual need will ascertain the business continuity plan at your center or business unit level.  Is it not applicable for projects?  I would say it depends mostly on how you have signed contract with your client or your account teams before arriving at BCP for projects.
  7. Effectiveness measurement
    This is one of the fundamental differentiators to show senior management why institutionalizing ISMS yields us real benefits.  With regular review of corrective and preventive actions, it gives all involved the urge to follow and adhere to security controls.
  8. Training, awareness and education
    This is an ongoing exercise and there needs to be a specific focus on enablement and readiness for all regular and contract workforce (CWF) working in organizations. Most importantly the process of onboarding and exit checklist must be specific to projects of both categories.
  9. Cooperation and collaboration
    With 11 domains and 133 controls to be complied, it is lot of hard work from all project and functional teams to cooperate and collaborate and meet SOA requirements.  Mutual respect and willingness to go the extra mile would be essential to go over brooding issues and stalemates.
  10. ISMS standard has to become part of culture
    All these steps and controls are aimed to create that culture of information security among all the teams.  This has to be adopted in true spirit to inculcate the culture and provide the clients and customers the required confidence and trust in all dealings.
These are some of the aspects that I have seen to be critical, to get your certification and ISMS institutionalization a repeatable success

This post was published earlier on July 22nd at ITSM Portal http://www.itsmportal.com/columns/iso-270012005-%E2%80%93-10-lessons-learnt-journey#.Uj_t2mW6bZ4

No comments:

Post a Comment